This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing else seems to have changed.
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing else seems to have changed.
This commit only factors out freeing the common SEI parts,
not whether the fields indicating whether an SEI is present
shall be reset. H.264 and HEVC differ in this regard
(ff_h264_sei_uninit() really resets, whereas ff_hevc_reset_sei()
only uninits.) and neither actually honours the persistency
as prescribed by the relevant specs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Supports both prefix and suffix SEI, decoding all of the common SEI
types and some more obscure ones. Most of this is tested by the
existing tests in fate.
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
HEVCSEIPictureHash should store only the information extracted from the
bitstream and exported to the higher layer (the decoder or the parser).
The MD5 context is allocated, used and freed by this higher layer, so it
makes more sense for it to also be stored there.
It doesn't depend on hevcdec anymore.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Jan Ekström
Andreas Rheinhardt
Limin Wang
James Almer
Anton Khirnov
Mark Thompson
Mohammad Izadi
Praveen Karadugattu
Vittorio Giovara