Fix#7830
When we upload a frame that is not padded as MSDK requires, we create a
new AVFrame to copy data. The frame's padding data is uninitialized so
it brings run to run problem. For example, If we run the following
command serveral times we will get different outputs.
ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128 \
-filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010 \
-i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16" \
-c:v hevc_qsv output.265
According to https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
"Note: It is the application's responsibility to fill pixels outside
of crop window when it is smaller than frame to be encoded. Especially
in cases when crops are not aligned to minimum coding block size (16
for AVC, 8 for HEVC and VP9)"
I add a function to fill padding area with border pixel to fix this
run2run problem, and also move the new AVFrame to global structure
to reduce redundant allocation operation to increase preformance.
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
It is more clear and easily to detect the issues similar to commit
3857ecbe70
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
- Ensure the yadif .metal compiles when targeting any Metal runtime version
- Use some preprocessor awkwardness to ensure Core Video's Metal-specific
functionality is exposed regardless of our deployment target (this works
around what seems to be an SDK header bug, filed as FB9816002)
- Ensure all direct references to Metal functions and classes are gated
behind runtime version checks (this satisfies clang's deployment-target
violation warnings provided by -Wunguarded-availability).
Apparently Metal.framework is included with the command line tools
(and thus may be present without Xcode), but the Metal compiler is only
included as part of Xcode.
On some encoders, this defaults to true, which can result in encode speed
being _limited_ to only slightly above realtime (as a power-saving measure),
so we need a way to disable it.
VideoToolbox internally sets all the colorspace parameters to BT709,
regardless of what the bitstream actually indicates, so we need to
replace that with what we've parsed.
Adds support for concat demuxer to copy the side data information
from the input file to the resulting file. It will behave like the
metadata copy, where the metadata of the first file is kept in the
the output file.
Extract the current code that already performs the stream side_data
copy into a separate method and reuse the method in the concat demuxer.
Signed-off-by: Gerard Sole <g.sole.ca@gmail.com>
Check for the patch version as well as the major+minor version.
The VK_API_VERSION macros are not usable in preprocessor code due
to casts.
The patch (header) version is meant to linearly increment and
not be reset, however it's better to trust, but verify.
The check here is meant to check for whether avcintra-class option
(default value -1) has been set; yet it checks for the x264_param_t
value where 0 is the default value (treated as "no avcintra-mode"
by x264). This meant that in-band extradata has been added unnecessarily
when using global headers; furthermore, the first output packet
had two x264 SEIs.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Resolves a warning that duration is being innaccurately estimated based
on bitrate.
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Peter Ross <pross@xvid.org>
Prior to this patch, for version 2 of the file format the frame rate was
hard-coded at 15 fps. This uses the 64-bit floating-point value from
the data stream, similar to what is already done for version 3 of the
file format (around line 206).
Signed-off-by: John-Paul Stewart <jpstewart@personalprojects.net>
Reviewed-by: Peter Ross <pross@xvid.org>
Current listed maintainers for vaapi plugin are
not reponsive and/or currently active in the
ffmpeg community. Thus, vaapi plugin patches
(and qsv plugin) have generally gone ignored or
lost in the ether for too long.
Remove Gwenole Beauchesne from vaapi maintainer
who has not been active since 2016.
Current alternative maintainer for vaapi is Mark
Thompson whom has not been active since
March/April 2021.
Therefore, add Haihao Xiang to vaapi maintainer
who's primary role is FFmpeg development with a
focus on the vaapi and qsv plugins. Haihao has
over a decade of media experience and many years
of FFmpeg development experience, amongst other
media frameworks.
The additional patch for adding Haihao as qsv
plugin maintainer has been submitted previously:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210608141134.27448-1-zhongli_dev@126.com/
This will help FFmpeg to continue to be the leading
multimedia framework by allowing these plugins to be
actively improved, enhanced, and maintained for existing
and future HW platforms.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
