Videos of "StarWars - Making Magic" consist of 640x480 codec3 frames
which establish a background, and a 320x240 codec48 video put on top
at random left/top offsets.
To support this, a new default buffer "fbuf", which holds the final
image to be presented, is added, since codec37/47/48 need their 2/3 buffers
to be private to themselves. The decoded result is then copied to the fbuf,
honoring the left/top offsets if required.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Change the size detection a bit to recognize common video sizes,
as the FOBJ codecs>=37 cannot always be trusted, since they can
be embedded in a larger frame.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Some videos of "StarWars - Making Magic" have this subcompression
type: data just consists of the 16 byte codec48 header; the DOS player
and the c48 decoder in the "Mysteries of the Sith" game engine ignore it.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
liboapv will seemingly encode correct 4:4:4 output, but report profile_idc 33, which
is specifically the profile value for 4:2:2 10bit.
Signed-off-by: James Almer <jamrial@gmail.com>
It was possible for the buffer pointers for the last tile to go over the
end of the unit buffer leading to a read overflow during decode of the
macroblock layer. Check all tile component sizes to prevent this case
and also catch related tile size mismatch errors earlier.
Halt tile component decoding at the first entropy error (this will be a
desync and is not recoverable). If any tile components contain errors
then discard the frame unless the output-corrupt flag is set.
Also fixes CID 1646764, which is the error case where the tile component
is too large for get_bits to handle.
No reason to build the exact same table once per decoding thread.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Abort as soon as we're done reading the slice header instead of running extra checks
that assume slice data may follow.
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents printing bogus errors about the value being 0, when in fact we
overread the available slice buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
The output will be a fragment with zero units, which is a lot more user friendly
than making them think something went wrong, as it already happens with cbs_av1.
Signed-off-by: James Almer <jamrial@gmail.com>
Some loop counters were initialized incorrectly.
This patch enhances the handling of loop iterations and residual parts.
Reviewed-by: 陈昊 <chenhao@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This bsf converts AV_PKT_DATA_NEW_EXTRADATA side data in avcc format
to in-band annexb format. However, the side data wasn't been removed
and copied from input packet to output packet. So the output packet
has mixed bitstream format. We don't support mixed bitstream format.
For example, h264_metadata report error in the following case:
ffmpeg -i foo.flv \
-bsf:v "h264_mp4toannexb,h264_metadata" \
-c copy -f null
This patch removed NEW_EXTRADATA side data after process.
This patch also add a check so only NEW_EXTRADATA in avcc format is
processed. NEW_EXTRADATA in annexb format is copied to output as is.
Reported-by: jiangjie <jiangjie618@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ff_thread_get_buffer() already emits its own logmessage.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: warning: using floating point absolute value function 'fabs' when argument is of integer type
No change in output
Changing variables to float worsens compression significantly
Found-by: ePirat
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The earlier code would traverse over the code lengths
mutliple times (namely max_length + 1 times - once to get
the maximum length and once for each max_length to assign
codes) before calling ff_vlc_init_sparse() (which may traverse
them twice and sort them). The new code only traverses them once
(+ the one time in ff_vlc_init_from_lengths()).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't rely on invalid codes leading to get_vlc2() returning
-1, which then gets converted to an uint8_t, i.e. to 255
and runs afoul of a length check later. After all, get_vlc2()
could be changed to return something else which may
be valid when cast to uint8_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is better when BUF_BITS == 64 (i.e. on x64), because
the underlying put_bits can then handle 0..63 bits naturally.
It does not worsen the code when BUF_BITS != 64, because
the compiler can optimize this to the same code as now
(due to the assert).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that these trees have only nine elements and are complete,
their depth is <= eight.
Also remove the now unused FF_HUFFMAN_BITS constant.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The VLC trees used here have very few different codes
and are therefore guaranteed to not be very deep: The AC/DC
VLCs have 12 elements and therefore a depth <= 11 whereas
the run VLCs have only nine elements and therefore a depth <= 8.
This allows to reduce the worst-case number of reloads for
reading a VLC code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are only 2*3*4 VLC trees for decoding Huffman encoded
AC coefficients; see section 13.3.2 of the spec.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Return AVERROR_DECODER_NOT_FOUND.
(This can be triggered because this decoder tries to be
generic and work with multiple underlying AAC decoders,
so that there is no configure dependency for any decoder.)
Reviewed-by: Kacper Michajlow <kasper93@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
