<div dir="auto"><a href="https://en.m.wikipedia.org/wiki/XvYCC" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.m.wikipedia.org/wiki/XvYCC</a><div dir="auto"><br></div><div dir="auto">there is another interesting standartized hack for wider-gamut color space</div><div dir="auto"><br></div><div dir="auto">====</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.<br></div><div dir="auto"><br></div><div dir="auto">====</div><div dir="auto"><br></div><div dir="auto">not sure how (if at all) ffmpeg supports this, let alone players under Linux ..... </div><div dir="auto"><br></div><div dir="auto"><a href="https://fanrestore.com/thread-1961-post-85235.html#pid85235" target="_blank" rel="noreferrer">https://fanrestore.com/thread-1961-post-85235.html#pid85235</a><br></div><div dir="auto"><br></div><div dir="auto">some convolved way via avisynth and x264 (windows by default, but vapoursynth/zscale-enabled ffmpeg exist under linux)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">=== copypasta =====</div><div dir="auto"><br></div><div dir="auto"><cite>deleted user Wrote:  <a href="https://fanrestore.com/post-70888.html#pid70888"></a></cite>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. <br>
<br>
Load your source in AVISynth and perform the following command:<br>
<div dir="auto"><div>Code:</div><div dir="ltr"><code>z_ConvertFormat(colorspace_op="2020:709:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16")</code></div></div>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. <br>
<br>
Now let's say you're encoding straight from a HDR source, then you'd do:<br>
<div dir="auto"><div>Code:</div><div dir="ltr"><code>z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16")</code></div></div>This
 probably isn't a great idea though because converting straight from HDR
 without any tonemapping will lead to clipped highlights.<br>
<br>
An alternate approach that would allow for tonemapping:<br>
<div dir="auto"><div>Code:</div><div dir="ltr"><code>z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f",pixel_type="RGBPS")
 // First convert to linear floating point Rec2020<br>
// 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.<br>
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</code></div></div><br>
For these commands to work, you need this plugin: <a href="http://avisynth.nl/index.php/Avsresize">http://avisynth.nl/index.php/Avsresize</a><br>
<br>
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.<br>
<br>
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:<br>
<div dir="auto"><div>Code:</div><div dir="ltr"><code>--transfer="iec61966-2-4" --colormatrix="bt709" --colorprim="bt709"</code></div></div><br>
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".<br>
<br>
If anyone wants a sample encode with 2 frames (one in xvycc and one in rec709), PM me. It's just 100KB.<br>
<br>
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.<br>
<br>
With that said .... now you have no more excuses for not having wide gamut colors in your projects. <img src="https://fanrestore.com/images/smilies/wink.png" alt="Wink"> These files are compatible with normal Rec709 as far as I know.<br></div><div dir="auto"><br></div><div dir="auto">==== end of copypaste ====</div></div>