[FFmpeg-devel] (no subject)

[Stephen Hutchinson]

Ut Video version 13.0.1 introduced two new variants, ULH0 and ULH2,
which are analogous to the existing ULY0 and ULY2, except that they're
explicitly meant for BT.709. I've added some of the necessary bits to
the libutvideo decoding wrapper so that it can detect and decode these
if FFmpeg has been built against libutvideo v13 (satellite issue:
GNUmakefile has been removed from the official Ut Video source zip due
to the author considering it a separate project and seemingly because
an issue with compiling on Linux cropped up in 12.2.1*; I still update
my buildsystem branch of libutvideo on Github**, and both Linux
compilation is fixed and v13 has been integrated).

*in the comments for the 12.2.1 release here:
http://umezawa.dyndns.info/wordpress/?p=3933

**address:
https://github.com/qyot27/libutvideo

Problems concerning the new formats in v13 and FFmpeg:
There is a collision between the native decoder and libutvideo decoder:
if both are enabled, the  native decoder prevents libutvideo from
decoding video, even if the user tries to force libutvideo to be the
decoder.

The native decoder does not have ULH0/ULH2 support, which results in
the following issue(s). Probing 'works', but there's an error message
from the native decoder that complains about not recognizing the FourCC
(said message even shows up when the user tries to force libutvideo to
decode), and attempts to encode from this fails.  The native decoder has
to be disabled for libutvideo to do any decoding, at which point encoding
from said streams will also work.

For encoding, it looks like there will need to be differentiation between
the 601 and 709 variants so that the wrong one isn't selected for encoding.
I didn't enable them in the encoder because I have no clue how to do this
correctly (my attempt to do so resulted in it *always* selecting the 709
variant, regardless of whether the input was ULH* or ULY*).  Such
differentiation may also need to be in the decoder just to be safe, even
if only for general color coefficient issues, but I don't know where/how
to start with that either (as in, I'm not sure if it is necessary for the
decoder to do this, or if it would require something from libutvideo's
side or from lavc/lavf).