Instead of manually assembling the string, use av_dict_get_string
which handles things like proper escaping too (even though it is
not yet needed here).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This unfortunately involved adding some parameters
to ff_h2645_sei_to_frame() that will be mostly unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is valid for HEVC; in fact, the ATSC-HEVC spec [1] simply
refers to the relevant H.264 spec.
It is also trivial to implement now: Just move applying AFD
to ff_h2645_sei_to_frame() and stop ignoring AFD when parsing
a HEVC SEI containing it.
A FATE-test for this has been added.
[1]: https://www.atsc.org/atsc-documents/a3412017-video-hevc/
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are only slight differences between H.264 and HEVC
for this side data, so it makes sense to share the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Currently, several components select atsc_a53, despite
not using anything from it themselves. They only select
it because parsing SEI messages adds an indirect dependency.
But using direct dependencies is more natural, so add
dedicated subsystems for them.
It already allows to remove a superfluous dependency of
the HEVC QSV encoder on hevc_sei and atsc_a53.
Adding new subsystems only becomes effective after a reconfiguration.
In order to force this, some needed headers (which are only included
implicitly before this commit) were included explicitly in
libavformat/allformats.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SEI NALUs and several SEI messages are naturally byte-aligned,
so reading them via the bytestream-API is more natural.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
VPP in the SDK requires the frame rate to be set to a valid value,
otherwise init will fail, so always set a default framerate when the
input link doesn't have a valid framerate.
Reviewed-by: Soft Works <softworkz@hotmail.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It means more than one output is ready when
MFXVideoVPP_RunFrameVPPAsync() returns MFX_ERR_MORE_SURFACE [1].
Currently the returned value from MFXVideoVPP_RunFrameVPPAsync() might
be overridden, so the check of 'ret == MFX_ERR_MORE_SURFACE' is always
false when MFX_ERR_MORE_SURFACE is returned from
MFXVideoVPP_RunFrameVPPAsync()
[1] https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#video-processing-procedures
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The SDK will return error if feeding h264_qsv encoder p010 input.
$ ffmpeg -f lavfi -i testsrc -vf "format=p010" -c:v h264_qsv -f null -
[...]
[h264_qsv @ 0x55584888b080] Current pixel format is unsupported
[h264_qsv @ 0x55584888b080] some encoding parameters are not supported
by the QSV runtime. Please double check the input parameters.
Error initializing output stream 0:0 -- Error while opening encoder for
output stream #0:0 - maybe incorrect parameters such as bit_rate, rate,
width or height
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
adaptive_i and adaptive_b cannot work with MFX_GOP_STRICT,
so only enable MFX_GOP_STRICT when these features are disabled.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
The SDK may provides HDR metadata for HDR streams via mfxExtBuffer
attached on output mfxFrameSurface1
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
