<div dir="ltr"><div><div>I had a feeling this proposal would open into a discussion of exactly what codecs even belong in a 3D application. <br><br></div>While it is true that Blender Is Not An Encoder, Blender is not a video editor either. <i>Except it is.</i> It is somehow a decent video editor that is really convenient for importing its own output of rendered image sequences. And after importing image sequences into the VSE, you <i>encode that sequence into a video file.</i> Sometimes an intermediate codec is desired, other times not.<br>
<br></div><div>That said, I'm fully in favor of culling the number of supported codecs to a more manageable size, and I'm glad that Troy brought this up. Focusing on improving support for industrial-driven codecs makes the most sense, but let's not scrap our more popular lossy codecs like x264.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 5:14 PM, Troy Sobotka <span dir="ltr"><<a href="mailto:troy.sobotka@gmail.com" target="_blank">troy.sobotka@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Huge apology if this double or triple posts. Email aliases... Urf.</p><div class="">
<p dir="ltr">On Sep 3, 2014 12:56 PM, "Sam Brubaker" <<a href="mailto:sam@worldsday.org" target="_blank">sam@worldsday.org</a>> wrote:</p>
<p dir="ltr">> The preset menu offered may be more advanced than necessary, but I wanted to show what might be possible instead of the current solution.</p>
</div><p dir="ltr">The current solution is a far cry from a designed solution, and ended up the way it has due to evolutionary reasons.</p>
<p dir="ltr">I would hazard a guess that 98% of the interface can be scrapped in this regard, and perhaps a more optimized pattern implemented. But this cuts deeper to _designing_ a solution, as opposed to reshuffling the cards in the deck.</p>
<p dir="ltr">Part of the issue is the number of codecs supported. None are supported well enough to make the complexity of the implementation warranted. Many of the presets (DV I am looking at you for example) are so many generations displaced as to make the inclusion almost baffling.</p>
<p dir="ltr">To this end, it might be worthwhile to discuss the merits of a reduction of codecs supported with the Blender Institute's audience of smaller studios in mind. This would have a tremendous lift of weight on developer resources and bring more robust support for fewer, industrial-driven codecs. In particular, DNxHD and ProRes options come inherently bound, with less variables to account for in the UI. x264 for dailies would likely pose the greatest complexity with regard to UI.</p>
<p dir="ltr">BINAE (Blender Is Not An Encoder), and the design decisions should likely consider this facet as well as the audience goal.</p>
<p dir="ltr">With respect,<br>
TJS</p>
<br>_______________________________________________<br>
Bf-interface mailing list<br>
<a href="mailto:Bf-interface@blender.org">Bf-interface@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-interface" target="_blank">http://lists.blender.org/mailman/listinfo/bf-interface</a><br>
<br></blockquote></div><br></div>