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

[FFmpeg]

#7037: ffmpeg destroys HDR information 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 mario66):

 The first step, IMHO, would be to support the video and meta-data from my
 initial post. It's a simple HDR10 video, should be no big deal. Here
 someone wrote a script to manually copy the metadata:
 https://forum.doom9.org/showthread.php?s=1e8582f9d692cbc7f04d205d05964122&p=1833683#post1833683
 It looks very complicated and if you scroll through the thread lots of
 people got error messages. I assume it will be a pain in the ass to
 actually use this script as an average end user. Something like this
 should be officially supported.
 In the end what should be possible is that the transcoded video behaves
 exactly the same in terms of HDR. My TV should use the same parameters for
 processing the video, i.e. all the meta data should be indistinguishable.
 I should not be able to tell a difference between the original and the
 transcoded version except if you have very good vision and can see the
 compression artifacts (which I cannot for example).

 Then it would be great if ffmpeg would be at least ''aware'' of all those
 meta data. That means if ffmpeg detects such meta data which it cannot
 deal with (both static and dynamic) it should at least print a warning
 that something is odd (in red font), and that the user knows he should
 probably not delete the original. On the other side if no such warning
 occurs he user should know that he is safe in a way that all the important
 information were transferred and no loss of information occurred. If there
 is maybe an option in ffmpeg that needs to be turned on to transfer the
 meta data, the existence of this option should be mentioned in the warning
 message.
 I'm not a big fan of hiding information from the user. If you make a
 design decision like dismissing meta data only because it is "technically
 incorrect" if this meta data would be copied, please be very verbose about
 this in your application. Always tell the user if there is a "twist" in
 his input video he might not have thought of, and what he can do to
 resolve that twist.

 Of course full support for every type of HDR, both dynamic and static,
 would be great. ffmpeg presents itself as an executable to the end users
 (not a library) he can use to convert videos. Thus, I think ffmpeg should
 do everything it can to avoid corrupted or incomplete outputs. But I hope
 I could give you some hints where to start.

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