[FFmpeg-devel] xvYCC Conversion to Wide Gamut RGB with FFmpeg

Michael Niedermayer michaelni at gmx.at
Sat Apr 2 21:39:36 CEST 2011


On Sat, Apr 02, 2011 at 12:29:11PM -0700, Thomas Worth wrote:
> On Sat, Apr 2, 2011 at 7:33 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Apr 02, 2011 at 04:32:00PM +0200, Michael Niedermayer wrote:
> >> On Fri, Apr 01, 2011 at 09:28:16PM -0700, Thomas Worth wrote:
> >> > On Fri, Apr 1, 2011 at 8:45 PM, Kieran Kunhya <kieran at kunhya.com> wrote:
> >> > >> Are you sure Canon DLSRs use xvYCC? I thought this was a
> >> > >> Sony thing.
> >> > >> If you want to check you can download our tool, 5DtoRGB,
> >> > >> and convert a
> >> > >> clip using "none" as the decoding matrix. This will show
> >> > >> you raw pixel
> >> > >> values for Y, Cb, and Cr copied straight from the H.264
> >> > >> file prior to
> >> > >> being decoded. I don't know if Canon use values outside
> >> > >> 16-240 for
> >> > >> chroma, but it's possible. Some tests with a color chart
> >> > >> and jacking
> >> > >> up the saturation in a Picture Style may help determine
> >> > >> this.
> >> > >
> >> > > There's an SEI if I remember rightly that has all this information. The H.264 full_range_flag is usually incorrect.
> >> >
> >> > Does the full_range_flag setting affect the actual decoding of the
> >> > stream? In other words, will pixel values be different off the decoder
> >> > if this is 1 vs 0? I'm just talking about the decoder, not any chroma
> >> > reconstructing or matrix decoding.
> >>
> >> ffmpegs h264 decoder returns whats stored thus theres no change in the
> >> returned YUV values from that flag but the decoder might choose to
> >                                             ^^^^^^
> > i meant of course player
> >
> >> interpret them differently
> 
> Ok, so just to confirm, the H.264 decoder doesn't care what
> full_range_flag is for its own decompression, it will just return
> whatever YUV values are stored in the file. full_range_flag is only
> useful to the scaler / player. Correct?

yes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110402/51a160d4/attachment.asc>


More information about the ffmpeg-devel mailing list