[Bf-interface] Revising the video output interface

Sam Brubaker sam at worldsday.org
Thu Sep 4 18:30:42 CEST 2014


I had a feeling this proposal would open into a discussion of exactly what
codecs even belong in a 3D application.

While it is true that Blender Is Not An Encoder, Blender is not a video
editor either. *Except it is.* 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 *encode that sequence
into a video file.* Sometimes an intermediate codec is desired, other times
not.

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.


On Wed, Sep 3, 2014 at 5:14 PM, Troy Sobotka <troy.sobotka at gmail.com> wrote:

> Huge apology if this double or triple posts. Email aliases... Urf.
>
> On Sep 3, 2014 12:56 PM, "Sam Brubaker" <sam at worldsday.org> wrote:
>
> > The preset menu offered may be more advanced than necessary, but I
> wanted to show what might be possible instead of the current solution.
>
> The current solution is a far cry from a designed solution, and ended up
> the way it has due to evolutionary reasons.
>
> 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.
>
> 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.
>
> 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.
>
> BINAE (Blender Is Not An Encoder), and the design decisions should likely
> consider this facet as well as the audience goal.
>
> With respect,
> TJS
>
> _______________________________________________
> Bf-interface mailing list
> Bf-interface at blender.org
> http://lists.blender.org/mailman/listinfo/bf-interface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-interface/attachments/20140904/dc053124/attachment.htm 


More information about the Bf-interface mailing list