[FFmpeg-trac] #7037(avcodec:open): ffmpeg destroys HDR metadata when encoding
FFmpeg
trac at avcodec.org
Sun Mar 21 00:37:38 EET 2021
#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):
I am going to attach a sample where HDR10 static metadata changes when
scene changes. https://gitlab.freedesktop.org/gstreamer/gst-plugins-
base/uploads/16c628c535865d7282a48317064345a2/out.mp4
That already crashes h265parse of gstreamer due to multiple SPS. mpv does
not have such a problem and ffmpeg too. Nice.
You can use
{{{
ffprobe -show_frames -select_streams v out.mp4
}}}
to check it out! Maybe add to ffprobe FATE, would be nice.
Change is as follows on frame pkt_pos=7258705:
{{{
side_data_type=Content light level metadata
max_content=284
max_average=145
}}}
to
{{{
side_data_type=Content light level metadata
max_content=378
max_average=277
}}}
According to free CTA-861-H, it must be supported by display and players.
Also, I am pretty sure it is not VFR, but alas mkv in ffmpeg is very
strange, it thinks it is VFR on all mkv's (and I got this file from mkv
blu-ray rip by ripping it D:) ). Maybe adopting a MatroskaParser like
Nevcariel did for LavFilters fork (and he even did fix some of other
ffmpeg bugs) will be it... But I doubt it.
See:
https://git.1f0.de/gitweb/?p=ffmpeg.git;a=commit;h=629d82013a9d5471bb5323890bed6969bdbe8885;js=1
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7037#comment:84>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list