https://en.m.wikipedia.org/wiki/XvYCC there is another interesting standartized hack for wider-gamut color space ==== The BT.709 YCbCr signal has unused code space, a limitation imposed for broadcasting purposes. In particular only 16-240 is used for the color Cb/Cr channels out of the 0-255 digital values available for 8 bit data encoding. xvYCC makes use of this portion of the signal to store extended gamut color data by using code values 1-15 and 241-254 in the Cb/Cr channels for gamut-extension. ==== not sure how (if at all) ffmpeg supports this, let alone players under Linux ..... https://fanrestore.com/thread-1961-post-85235.html#pid85235 some convolved way via avisynth and x264 (windows by default, but vapoursynth/zscale-enabled ffmpeg exist under linux) === copypasta ===== deleted user Wrote: <https://fanrestore.com/post-70888.html#pid70888>Ok for anyone who's wondering how to encode xvYCC, I might have found out. First, you need to start out with some color space that has a big gamut to begin with. Let's say Rec 2020. It doesn't have to be HDR, you can just do a normal Rec2020 Gamma 2.4. This ensures that your source has all the colors you want to preserve. So work in and/or render out in Rec2020. If you are working in After Effects for example, in 32 bit floating point mode, then your working color space can be Rec709, you just have to set Rec2020 for the output, since the gamut gets preserved thanks to the ability of the 32 bit floating point data to hold negative values. Otherwise you likely have to work immediately in Rec2020. Load your source in AVISynth and perform the following command: Code: z_ConvertFormat(colorspace_op="2020:709:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16") Note that you have to adapt the part before "=>" to your own input. The above example would be for a YUV Rec2020 Gamma 2.4 file with Limited range. The reason I put "709" there is because that's the transfer characteristic for Gamma 2.4. It doesn't look elegant but it works. Now let's say you're encoding straight from a HDR source, then you'd do: Code: z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16") This probably isn't a great idea though because converting straight from HDR without any tonemapping will lead to clipped highlights. An alternate approach that would allow for tonemapping: Code: z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f",pixel_type="RGBPS") // First convert to linear floating point Rec2020 // Do tonemapping here with whatever method you like. It needs to accept the "RGBPS" color space, which is a 32 bit floating point planar RGB color space. I believe the DGHable functions and such accept that. z_ConvertFormat(colorspace_op="rgb:linear:2020:f=>709:xvycc:709:l",pixel_type="YUV444P16") // Now finally to xvYCC, while preserving as wide of a gamut as possible For these commands to work, you need this plugin: http://avisynth.nl/index.php/Avsresize Now finally, I did a test loading such a script in VirtualDub and encoding to x264 with the internal x264 encoder. I loaded that back into AVISynth and I'm happy to say that the data was preserved. I tested it with some very saturated scenes. So now the data gets preserved, but the player still won't know that it's dealing with xvYCC data. I can't say with 100% certainty that the following will work, but it does produce the proper metadata in the MediaInfo. Simply use the following x264 parameters instead of the usual: Code: --transfer="iec61966-2-4" --colormatrix="bt709" --colorprim="bt709" To my knowledge, colorprim and colormatrix stay the same, but the transfer characteristic is different. When you encode it like this, the resulting file will show "xvYCC" as the Transfer characteristic. I think that should do the trick, but it would take someone with a compatible TV to try. I can definitely see a difference in MPC-HC, however I haven't attempted to verify that it looks "correct". If anyone wants a sample encode with 2 frames (one in xvycc and one in rec709), PM me. It's just 100KB. Note: This will also work with DCI-P3 as the source for example. The only requirement really is that z_ConvertFormat supports the source color space you are feeding into it and you give it the correct info about it. With that said .... now you have no more excuses for not having wide gamut colors in your projects. [image: Wink] These files are compatible with normal Rec709 as far as I know. ==== end of copypaste ====