The earlier code did not account for the fact that
av_display_rotation_set() wants the angle in the anticlockwise
direction (despite what its documentation stated for a long time);
furthermore, the H.2645 spec wants the flips applied first,
whereas our code did it the other way around. This can be fixed
by negating the angle once for every flip.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The transpose filter has modes equivalent to "rotation by 90°/270°"
followed by horizontal flips.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case of an orthogonal transformation av_display_rotation_get()
returns the (anticlockwise) degree that the unit vector in x-direction
gets rotated by; get_rotation in cmdutils.c makes a clockwise degree
out of this. So if one inserts a transpose filter corresponding to
this degree, then the x-vector gets mapped correctly and there are
two possibilities for image of the y-vector, namely the two unit
vectors orthogonal to the image of the x-vector.
E.g. if the x-vector gets rotated by 90° clockwise, then the two
possibilities for the y-vector are the unit vector in x direction
or its opposite. The latter case is a simple 90° rotation for both
vectors* whereas the former is a simple 90° clockwise rotation followed
by a horizontal flip. These two cases can be distinguished by looking
at the x-coordinate of the image of the y-vector, i.e. by looking
at displaymatrix[3]. Similarly for the case of a 270° clockwise
rotation.
These two cases were previously wrong (they were made to match
wrongly parsed exif rotation tag values).
*: For display matrices, the y-axis points downward.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The cases in which there was flipping together with a rotation
that is not a multiple of the identity were wrong.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
sets coded_width / coded_height too to keep them consistent with
width / height
Fixes: OOM
Fixes: 42263/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5653333619113984
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
