The earlier code had two problems:
1. For reference frames that are not directly output (happens unless
low_delay is set), the mb skip values referred to the next reference
frame to be decoded.
2. For non-reference frames, every macroblock was always considered
skipped.
This makes the output (worse than) useless; that no one ever
complained about this shows that this feature is not really used.
It is therefore removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Broken in 5ecf5b93dda9d0c69875b80d28929f0d97dd7d06.
More precisely, 3994623df2 changed
the precursor of ff_mpv_reconstruct_mb() to always decode
to the first row of macroblocks for B pictures when
a draw_horiz_band callback is set and to (they are exported to
the caller via said callback and each row overwrites the previously
decoded row; this was probably intended as a cache-optimization).
This first macroblock row was used as source for the draw_horiz_band
callback.
This of course means that the ordinary output B-frame was not
decoded correctly at all. Therefore the first aforementioned commit
removed this special handling of draw_horiz_band; yet it did not
remove the special handling for B-frames in ff_draw_horiz_band(),
which broke draw_horiz_band for B-frames. This commit fixes this.
(Actually, draw_horiz_band was already broken before
5ecf5b93dda9d0c69875b80d28929f0d97dd7d06 when using slice-threading:
All slice-threads would write to the first row of macroblocks
for B-frames, leading to data races. It seems no one has ever complained
about this, just as no one has ever complained about the breakage
caused by 5ecf5b93dda9d0c69875b80d28929f0d97dd7d06. Probably no one
uses draw_horiz_band.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_L[01] is based upon H.264 terminology (it stands for
list); yet the mpegvideo based decoders don't have lists
of reference frames, they have at most one forward and one
backward reference. So use terminology based upon this.
This also has a second advantage: MB_TYPE_L[01] is actually
an OR of two flags (which are set independently for H.264,
but aren't for mpegvideo). Switching to different flags
makes the flags fit into an int16_t, which will be useful
in future commits.
The only downside to this is a very small amount of code
in error_resilience.c and mpegutils.c (the only code shared
between the H.264 decoder and mpegvideo).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_ACPRED is currently reused for MB_TYPE_REF0 by H.264,
so that the value fits into an uint16_t. Given that MB_TYPE_ACPRED
is not subject to any such restriction (apart from fitting into
32bits), it can be remapped to a hithereto unused bit.
The then available bit will be declared to be codec-specific
(i.e. unused by generic code), so that H.264 can use it
for MB_TYPE_REF0 and so that it can be reused later for
e.g. MB_TYPE_H261_FIL.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
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.
Andreas Rheinhardt