| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
Fixes: Timeout (same growing chunk is decoded to failure repeatedly)
Fixes: 42582/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-6531195591065600
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
| |
./ffmpeg -i 11_wmv3_720p_24fps_7Mbps.wmv -f rawvideo -y /dev/null -an
before:131fps
after :229fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
| |
ffmpeg -i ../10_vp9_1080p_30fps_3Mbps.webm -f rawvideo -y /dev/null -an
before:294fps
after :567fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
| |
ffmpeg -i ../10_vp9_1080p_30fps_3Mbps.webm -f rawvideo -y /dev/null -an
before:170fps
after :294fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
|
| |
./ffmpeg -i ../9_vp8_1080p_30fps_2Mbps.webm -f rawvideo -y /dev/null -an
before: 210fps
after : 585fps
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
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>
|
|
|
|
|
|
|
|
|
| |
Update version based on the patch:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211009015949.1510-1-haihao.xiang@intel.com/
Signed-off-by: Daniel Socek <daniel.socek@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Zhong Li <zhongli_dev@126.com>
|
|
|
|
|
|
|
|
| |
It is more clear and easily to detect the issues similar to commit
3857ecbe70e81cb6ad7a7f155c311e8522b93b3e
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
|
|
|
|
| |
Fixes P210/P410 cases introduced (and broken) in 88d804b7ffa20caab2e8e2809da974c41f7fd8fc
|
|
|
|
| |
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.
|
|
|
|
|
| |
Apparently on some OS and Xcode versions this can select an iOS SDK,
which in turn may fail on the affected versions.
|
| |
|
| |
|
|
|
|
| |
We call this OBJCFLAGS in help text, but common.mak looks for OBJCCFLAGS.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
These are all set by AV_OPT_TYPE_INT or AV_OPT_TYPE_BOOL; the only reason
they worked before was that this is only used on little-endian.
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Also fixes symbol lookup errors on older macOS when built with a newer SDK,
introduced in 6cab5206b0ad94990c435cb7c5cf3b29675e0231
|
| |
|
|
|
|
|
| |
This avoids making terminal config changes that may not be reverted properly
during parallel testing.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
No longer requires per-format switch cases.
The frame==0 path was unused (and would've crashed anyway).
|
| |
|
| |
|
|
|
|
| |
Fixes support for alpha in hardware input frames
|
| |
|
| |
|
|
|
|
|
|
| |
Should fix ticket #7153
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
| |
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
| |
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
| |
Put them together with other similar slow flag checks.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
| |
This is instead of EXTERNAL_AVX2_FAST so that the avx2 hscale functions
are only used where they are faster.
|
|
|
|
| |
This flag is set on Haswell and earlier and all AMD cpus.
|
|
|
|
|
|
|
|
|
| |
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.
|