[FFmpeg-trac] #7037(avcodec:open): ffmpeg destroys HDR metadata when encoding

[FFmpeg]

#7037: ffmpeg destroys HDR metadata when encoding
-------------------------------------+-----------------------------------
             Reporter:  mario66      |                    Owner:  cehoyos
                 Type:  enhancement  |                   Status:  open
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  libx265 hdr  |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-----------------------------------

Comment (by Balling):

 {{{
 This will be the end of free open source video processing.
 }}}
 Next update to you. First some complaints ;)
 WTF, you still did not write that this
 https://forum.doom9.org/showpost.php?p=1886901&postcount=41 is fixed in
 #8228? You are very lazy, really. I, on the other hand... But see next.
 WTF, you still did not address that "there is global metadata and metadata
 in SEI". I suppose you did not understand!!! And need an example. Player
 should not really only look in values in global meta!!! It is just wrong!
 Download this:
 magnet:?xt=urn:btih:AB4E88D2999CEC65F1C59A55EE786E8DEFB0DC22 open in madvr
 in Media Player classic and open Ctrl-J info and go to 16:15 minutes and
 on 16:20 metadata in mkv will change from 284 nits to 378 nits as the
 scene changes... Okay??? That is the point, metadata in mkv in HDR10
 static metadata can change on scene basis! So one can say it is dynamic
 actually)) We need to support that properly, that is the point... And it
 will be after this (or at least I hope so):
 https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200223234124.17689-18-sw@jkqxz.net/
 Also look in EDID (DisplayID) standard CTA861-3A: "The Dynamic Range and
 Mastering InfoFrame carries data such as the EOTF and the Static Metadata
 associated with the dynamic range of the video stream.
 If the Source supports the transmission of the Dynamic Range and Mastering
 InfoFrame and if it determines that the Sink is capable of receiving that
 information, the Source shall send the Dynamic Range and Mastering
 InfoFrame once per Video Field while it is sending data associated with
 the dynamic range of the video stream. The Source shall not send a Dynamic
 Range and Mastering InfoFrame to a Sink that does not have at least one of
 the ET_n bits set to ‘1’."
 Note: this actually works on LG C9 in zero frame latency and I think
 should work everywhere...
 Also look here
 https://www.intel.com/content/www/us/en/programmable/documentation/aky1476080261496.html#ink1506343118369

 Now news: VLC finally did IPTPQc2/IPT/ICtCp color (so bad colors in Dolby
 Vision decoding might be good in the near future with some interframes
 problems still). See discussion https://github.com/mpv-
 player/mpv/issues/7326 and link to code
 https://code.videolan.org/videolan/libplacebo/commit/f850fa2839f9b679092e721068a57b0404608bdc,
 but I am afraid the matrixes are actually wrong and should look like this
 after 2^13 multiplier

 {{{
 /** IPT to LMS */
     public static final short[] IPTPQ_YCCtoRGB_coef = {
         8192, 799, 1681, // 1.0,
         8192, -933, 1091, // 1.0,
         8192, 267, -5545, // 1.0,
     };

     /** IPT to LMS */
     public static final long[] IPTPQ_YCCtoRGB_offset = {
         0, 134217728, 134217728 // 0, 0.5, 0.5
     };

     /** LMS inverse cross-talk matrix for c == 0.02 */
     public static final short[] IPTPQc2_RGBtoLMS_coef = {
         17081, -349, -349,
         -349, 17081, -349,
         -349, -349, 17081,
     };

 }}}
 also we are missing scaling polynomials and some other things that Dolby
 still hides, mfers.

 Next I am now in gmail with Google HDR10+ dev, he promised to open a fork
 of ffmpeg on github with HDR10+ ready! And soon it will be in Youtube and
 Google Films, also 1:1 Dolby Vision and HDR10+ will be produced!!! It is
 perfect, is not it! Look here #8530, I will post a link when they are
 ready, he promised he will post it on 21st of February... Well, he did
 not...

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7037#comment:74>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker