Up until now, it only returned the number of bits for the
start offset, but not the start offset; the GetBitContext
passed to it was unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's not possible to put USAC into ADTS due to exceeding the
field size (4 bits) for ADTS profile. As such cases where
the frame starts with 0xfff shouldn't be checked.
This ensures the sample at https://crbug.com/396190942 is
properly detected as USAC content.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Storing the values via a union of an uint32_t and a float makes
said union the effective type of the destination. This means that
it may only be read via such a union which is of course not what
our users do/expect. So store the values via AV_WN32A instead
which disables effective type analysis (for compilers that perform it).
This also fixes a -Wdeclaration-after-statement warning
introduced in 0e917389fe.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise compilers might emit code that presumes there to be
a GOT which can't be fixed by the linker.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is inspired by the equivalent dav1d attribute introduced
by Henrik Gramner in e4c4af02f3de5e6cea6f81272a2981c0fa7bae28.
Also already use it to beautify declarations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When used with the "mpegvideo" or "mpeg1video" decoder (which do not
have a private class) this would lead to the log callback receiving
a non-NULL object with a NULL AVClass pointer. The default log callback
handles this gracefully, yet it is probably an API violation.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the initialization of AMV's matrices happened
after the initialization for MJPEG matrices, overwriting
the earlier data. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the packet is reference-counted
and because we never combine the data from several packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible by moving the code using it to open a GetBitContext
from h263dec.c to mpeg4videodec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All hwaccels for MPEG-4/H.263 are run serially even when frame-threading
is in use. Therefore there is no gain in calling
ff_thread_finish_setup() in this case right before outputting
the frame.
Removing this call also allows to revert commit
39a5c0ac06.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-1/2 decoders don't need ScanTable.raster_end
(as the coefficients are unquantized as they are parsed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is pointless to try to report the true number because
decode_simple_internal() always treats the buffer as
completely consumed for video codecs anyway.
(Apart from that: The h263dec code would report to only
have consumed the header data in case decoding is aborted
due to skip_frame which makes no sense.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added in 59fa3f96f4,
yet avctx->workaround_bugs is never copied to
MpegEncContext.workaround_bugs, so this code is dead
(it seems that this was true even when it was added).
Furthermore, workaround_bugs is flagged as decoder-only,
so just remove the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by MPEG-4 (and is used in h263dec.c and can therefore
not just be moved to Mpeg4DecContext...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since d50635cd24 the
dct_unquantize_h263_intra functions have set the number of
coefficients to 63 in case of ac_pred, so ff_msmpeg4_decode_block()
doesn't have to bump it on its own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This code has been added in f5957f3fe2
when support for WMV1 has been added. It was needed for decoding
inter macroblocks, as WMV1 uses a different scantable and
the ScanTable and ScanTable.raster_end was not yet introduced
(the H263 unquantize function instead used a hardcoded version
of ff_zigzag_direct's raster_end). In other words,
there is no reason to continue to do so for WMV1 inter blocks.
(Apart from that: WMV1 inter blocks don't use
dct_unquantize_h263_inter any more, as unquantizing happens
when parsing the block via specialized RL VLC tables.)
It is also not needed for WMV1/2 intra blocks (for non-ac_pred
it uses the correct ScanTable used by the h263 unquantize
intra function; for ac_pred, the number is overridden)
as well as for WMV2 inter-blocks (raster_end is not really
used in this case; the ordinary ScanTable is used in case
abt_type is zero, otherwise there are two different ScanTables
and block_last_index is overridden in wmv2dec.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder unquantizes while parsing blocks
and does not use dct_unquantize_mpeg1_intra
(which uses *_dc_scale) at all.
repeat_field was unused since
e0a3d744a0.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value here has been set in ff_set_qscale() from
ff_mpeg1_dc_scale_table, all of whose entries are 8.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Encoding was untested before this.
Notice that the filesize degradation is partially due to
mpegvideo no longer using progressive_sequence and
progressive_frame.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Effectively reverts c59b5e3d1e.
This is possible now that ff_print_debug_info2() uses
the MPVPicture dimensions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MotionEstContext contains pointers (to function pointers) that
have been set on a per-frame basis depending upon no_rounding
in ff_me_init_pic() to avoid branches like these. Also makes
MotionEstContext more independent of MpegEncContext.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mpegvideo-based encoders do one uncommon thing with
the packet's data given by ff_alloc_packet(): They potentially
reallocate it. But this only affects the internal buffer
and is not user-facing at all, so one can nevertheless
use the AV_CODEC_CAP_DR1 for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When there are multiple candidates for macroblock type, the encoder
tries them all. In order to do so, it keeps several sets of states
containing the variables that get modified when encoding
the macroblock and in the end uses the best of these.
Yet one variable was set, but not included in this state:
The current macroblock's qscale value in the current picture's
qscale_table. This may currently be set multiple times in
mpv_reconstruct_mb(), yet it is read when adaptive_quant is true.
Currently, the value read can be the value set by the last attempt
to write the current macroblock and not the initial value.
Fix this by only setting the qscale_table value in one place
outside of mpv_reconstruct_mb() (where it does not belong at all).
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reduce binary size at the same time. The performance compared to clang -O3
is the same.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
'avs3' is registered at mp4ra.org. The Avs3ConfigurationBox 'av3c'
inside 'avs3' hasn't been registered yet, but is specified by the
AVS3 spec.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
