[Bf-interface] Revising the video output interface

[Sam Brubaker]

I believe a balance can be struck between supporting a versatile-enough
range of codecs and supporting them well. There's a lot of productive talk
to be had in that area, but I want to return to the topic of my *proposed*
UI, <http://wiki.blender.org/index.php/User:Rocketman/Encoding_ui_proposal>because
I think it's a strong solution regardless of which particular codecs we
decide to support or depreciate in the future.

The preset menu can be a long list, or a short one. A certain codec can
either exist in the codec menu or not, but it wouldn't alter the overall
structure of my solution. My hope is that this proposed UI will open the
field so that developers can continue to add, remove, or expand on codecs
as resources permit, and the result will still be a useful interface that
makes sense.


On Thu, Sep 4, 2014 at 1:07 PM, Troy Sobotka <troy.sobotka at gmail.com> wrote:

> This is probably a drifting topic somewhat, and I apologize in
> advance. The discussion seems relevant on the subject of codecs
> however, but only after reviewing the breadth of the issue.
>
> On Thu, Sep 4, 2014 at 9:30 AM, Sam Brubaker <sam at worldsday.org> wrote:
>
> > 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.
>
> I can only offer my limited view on the situation from my experience.
> As such it is entirely anecdotal evidence, and generally worthless.
> Ignore at will.
>
> I've used Blender to take some projects to broadcast, and I can state
> beyond a shadow of a doubt that the VSE's largest shortcomings are due
> to an identity crisis. This is somewhat akin to the situation
> regarding codecs.
>
> Using a codec as an intermediate is certainly a question of "quality",
> and that's a nebulous, slippery discussion. That said, even given the
> constraints of the above, I'd think that we can agree that we would be
> discussing a subset of the original set of codecs. Questions such as:
>
> A) What codec provides viable intermediate quality, if an artist
> chooses to suffer the generative losses?
> B) Given the (hopefully) limited codecs, how should the handling of
> variables be handled? Consider often overlooked aspects such as YCbCr
> coefficients and typical broadcast / full range scaling options. (This
> is a very good case to argue for ProRes / DNxHD arguably, as they are
> _exceptionally_ limited formats with very tightly predefined outputs.)
> C) What are the design cases for the codecs given a small studio? If
> intermediate, then the issues of B are extremely important. If dailies
> or such, then the needs to bake in look LUTs and such comes into view.
>
> The point I'd make with the above is that the current offerings are
> unlikely to touch upon the points with any degree of viability for a
> small studio or independent collective's needs. It seems that there is
> somewhat of an agreement here, hence the beginning of this whole
> thread.
>
> > 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.
>
> I'm not entirely sure that a popularity metric is going to solve the
> design problems here, and would make a case that it is likely already
> the source of a portion of the issue. I'm certain that a vocal number
> of folks may want Quake 2 support, for example. This might seem like
> an alienating statement to some, but I do not believe that we can
> manage this with the typical refrain of supporting everything, or even
> a small smattering of everything as we currently have. It doesn't take
> a seasoned veteran to see how the currently supported set of codecs is
> already unfit in many capacities given the ridiculously small set of
> concerns above.
>
> h264 of course is incredibly relevant for dailies and such, but again,
> we aren't doing a very good job managing the control of import and
> export on this front, and this more than likely stems from a lack of
> developer resources and the complexity of our current set of supported
> codecs.
>
> I was extremely hesitant to chime in on this subject, as these sorts
> of subjects can blow up into irrational and reactionary rubbish
> threads, and it is pleasant to see that it hasn't exploded as such.
> Perhaps to push along further here, it might be worth looking at
> exploring some of the output codec needs for a small studio /
> independent project collective.
>
> A) Industrial formats, in particular DNxHD and ProRes. By clamping the
> set down to these primary two, Blender can get legitimate feedback on
> how the formats are interacting with other outside tools, and likely
> increase compatibility and reliability.
> B) Dailies format. In particular, h264. This is a thorny difficult
> codec to support largely because of the vast number of variables and
> nuances available. Color coefficient handling is a huge bog-up in
> _many_ applications, and it would be likely useful to expose the
> details here. Perhaps breaking h264 support down into a low, medium,
> and high grade set of presets for dealing with GOP, P / I / B frames,
> etc? Make the complexity manageable by hiding it in a presets file
> with understandable labels? Again, the BINAE rule might help here,
> while at the same time permitting knowledgeable artists to add /
> adjust the preset files?
> C) Look LUTs. Another useful tool here is baking the looks into
> dailies for viewing such as to get a handle on look approximations,
> for editorial work or otherwise. This is certainly a UI discussion on
> how to implement such.
> D) Audio muxing for dailies. Given that the output is dailies and
> offline work, reducing the number of codecs here would be equally
> rewarding.
>
> While these are just a few quick thoughts, I'd hope that we can see
> how the UI for these sorts of needs takes on quite a different twist
> as compared to a remuxing evolution of what we currently have. It also
> comes with very little development overhead, which is of critical
> importance. Finally, if we manage to remove codecs here, I'm certain
> the available developer resources would be lightened while more
> optimally serving Blender's evolving audience.
>
> 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/9b6d737b/attachment.htm