[Bf-interface] Revising the video output interface

[Troy Sobotka]

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