[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):

 Replying to [comment:70 mario66]:
 >  "colour_primaries=BT.709" are present, and they are lost after
 transcode!
 Well, in rarbg this info is always present as they either bit to bit web
 dl (and netflix and Amazon always put that tag) or are using good scripts
 to downconvert.

 There is a simple thing: ​
 BT.601 ("Standard-Definition" or SD)
 ​BT.709 ("High-Definition" or HD)
 ​BT.2020 ("Ultra-High-Definition" or UHD).
 That is almost always the case with SD and HD.
 But with HDR and UHD, well, not at all((

 >TV does not assume BT.709 as the default
 No, that could not happen, for SDR it is assumed.
 For HDR there is other info in HDR 10 bit bitstream that says if it is
 bt2020 or dci-p3 in bt.2020 or ICtCp.

 >any guides on how to transcode a Blu Ray video
 Were you searching through avsforum? I think i saw it there. Amyway, you
 should not use ffmpeg, but other utilities like mkvtoolni GUI or TSmuxer.
 E.g. https://www.avsforum.com/forum/39-networking-media-servers-content-
 streaming/2798233-fantastic-beasts-3d-atmos-attempt-blu-ray-
 quality-2.html#post54859492

 >without huge shift in color space?
 And that happens on EVERY GALAXY DEVICE except Galaxy s10/Tab s6. Did not
 see any clever guy complaining besides me. That does not happen on LG C9,
 BTW.
 >room for improvements in documentation
 What you suggested is not really an improvement, as it is marketing BS
 editing. Nobody should care about that, solving this issue could be much
 better. But scripts are there.

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