[FFmpeg-devel] (no subject)

[Paul B Mahol]

On 6/7/13, Stephen Hutchinson <qyot27 at gmail.com> wrote:
> 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.

Really?

>
> 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).
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>