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>
This decoder does not initialize any static data in its init function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It performs no initialization of static data in its init function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It performs no initialization of static data during its init function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Nothing with static storage duration is initialized by these codecs.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Limin Wang
Andreas Rheinhardt
Paul B Mahol