It's a common usecase to request a video size after crop. Before
this patch, user must know the video size before crop, then set
crop_right/crop_bottom accordingly. Since HEVC can have different
CTU size, it's not easy to get/deduce the video size before crop.
With the new width/height options, there is no such requirement.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
According to the VVC specification (section 8.5.1), the maximum width/height of a subblock passed for DMVR SAD is 16. This along with previous constraint requiring width * height >= 128 means that 8x16, 16x8, and 16x16 are the only allowed sizes. This re-labels vvc_sad_16_128 to vvc_sad_16 to reflect this and adds a comment about the block size constraints. There's no functionality change.
Unintentionally removed as part of 03cf10164578aed33f4d0cb5b69d63669c01a538.
Untested, but its assumed that unlike most of the old ARM code,
this one was still working.
When using offload path to play short audio, if the audio data cannot fill the buffer, it may not enter the start branch, so we need to start playing after draining the buffer.
Signed-off-by: jinxiuxu <jinxiuxu@xiaomi.com>
Before this patch, the implementation of pipe: inputs/outputs would
silently fall back to stdin/stdout for any argument not successfully
parsed by strtol().
This patch introduces an explicit error for any non-numerical arguments,
which should avoid user confusion as in #10977.
New behavior:
$ cat /tmp/video.mkv | ./ffmpeg -i pipe:aa -acodec copy -vcodec copy -f matroska pipe:1 | cat >/tmp/out.mkv
[pipe @ 0x5618c7bcf740] Non-numerical argument "aa" to pipe:
[in#0 @ 0x5618c7bced00] Error opening input: Invalid argument
Error opening input file pipe:aa.
Error opening input files: Invalid argument
Based on the patch of Nils Goroll <nils.goroll@uplex.de>.
Signed-off-by: Marton Balint <cus@passwd.hu>
libva2 doesn't require a fixed surface-array any more, so we may use
dynamic frame pool for decoding when libva2 is available, which allows a
downstream element stores more frames from VAAPI decoders and fixes the
error below:
$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \
-i input.mp4 -c:v hevc_vaapi -f null -
...
[h264 @ 0x557a075a1400] get_buffer() failed
[h264 @ 0x557a075a1400] thread_get_buffer() failed
[h264 @ 0x557a075a1400] decode_slice_header error
[h264 @ 0x557a075a1400] no frame!
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
A decoder's private data has already been zeroed (apart from options)
before init is called.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The first 32 elements of each row were correct, while the
last 16 were scrambled.
This hasn't been noticed, because the checkasm test erroneously
only checked half of the output (for 8 bit functions), and
apparently none of the samples as part of "fate-hevc" seem to
trigger this specific function.
Signed-off-by: J. Dekker <jdek@itanimul.li>
At present, consume_update evaluates timeline state on all links for
a multi-input filter. This can lead to the filter being incorrectly
en/dis-abled when evaluation on a frame on a secondary link leads to
a different result than the frame on the current main link next in
line for processing.
openvela-robot