The only interesting thing done in SVQ3's init function
is using zlib, but this is fine: https://zlib.net/zlib_faq.html#faq21
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the av_malloc() may fail and return NULL pointer,
it is needed that the 's->edge_emu_buffer' should be checked
whether the new allocation is success.
Fixes: d14723861b ("VP3: fix decoding of videos with stride > 2048")
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
The exif.h header doesn't use anything from tiff.h. We also just need
to include tiff_common.h in .c files where it actually used.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
bytestream.h should be directly included for GetByteContext and not
rely on other headers to include it. It could be removed from there.
Signed-off-by: Andreas Schneider <asn@cryptomilk.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If a frame-threaded decoder with inter-frame dependencies
returns an error when decoding a frame and the returned frame
isn't clean, an error message is emitted claiming that this
is a bug. This seems to be based upon the thinking that
in this case a ThreadFrame has not been properly unreferenced.
Yet this is wrong, as decoders with inter-frame dependencies
don't use the frame for output for synchronization and therefore
don't use ThreadFrames at all for this. So unreferencing
this frame generically is fine and not a bug.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The only unorthodox thing that this codec's init function does
is calling ff_get_format(). Yet this is supposed to be save,
as any get_format callback already has to deal with the scenario
of different AVCodecContext's calling it simultaneously.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes build failures for videotoolbox
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the H.264 decoder (as well as the dirac decoder,
which already uses a local copy).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Seems to have been always unused since these functions were introduced
in 1f0cd30fd9.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This piece of code has been added in an already commented-out state
in commit 158c7f059c. It certainly
doesn't make sense now (if ever) because new_picture_ptr it used
has been removed in 6571e41dcd
(and new_picture is only used for encoding).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mpegvideo-based encoders supporting bframes implement this
by opening encoders of their own to test how long the chains
of bframes are supposed to be. The needed AVCodec was obtained
via avcodec_find_encoder(). This is complicated, as the current
encoder can be directly obtained. And it also is not guaranteed
that one actually gets the current encoder or not another encoder
for the same codec ID (the latter does not seem to be the case now).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MpegEncContext is used by many different codecs and
every one of these uses just a subset of its fields.
If one tries to separate this and e.g. add a real MpegContext
and extension structures (say MpegDecContext and MpegEncContext),
one runs into two difficulties:
a) Some code is shared between decoder and encoder of
the same format and they therefore use the same contexts,
either MpegEncContext itself or identical extensions thereof.
The latter is the case for H.261 as well as WMV2.
b) In case of slice threading, the generic code can only allocate
and initialize the structure it knows about; right now this is
an MpegEncContext. If the codec has an even more extensive structure,
it is only available for the main thread's MpegEncContext.
Fixing this would involve making ff_mpv_common_init() aware
of the size the size of slice context to allocate and would be
part of separating the main thread's context from the slice contexts
in general.
This commit only intends to tackle the first issue by adding
a pointer to MpegEncContext that codecs can set to a common
context so that the aforementioned codecs can use this context
(together with the MpegEncContext) in their common code.
This will allow to move fields only used by the main thread
to more specialized contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Andreas Rheinhardt
Jiasheng Jiang
Michael Niedermayer
Anton Khirnov
Andreas Schneider
Limin Wang