We still own it on failure, and there's no point trying to feed it again.
This should address the issue reported in dav1d #383 and part of VLC #26259.
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
They were done in preparation for an upcoming 1.0 release.
Keep supporting previous releases for the time being.
Reviewed-by: BBB
Signed-off-by: James Almer <jamrial@gmail.com>
It is not used here at all; instead, add it where it is used without
including it or any of the arch-specific CPU headers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Look at the event flag that signals a new sequence header was found
in the bitstream on supported libdav1d versions for this purpose.
Signed-off-by: James Almer <jamrial@gmail.com>
The main benefit comes from propagating container level metadata like hdr,
which is more commonly used than the relevant Metadata OBUs.
Signed-off-by: James Almer <jamrial@gmail.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This cap is currently used to mark multithreading-capable codecs that
wrap external libraries with their own multithreading code. The name is
highly confusing for our API users, since libavcodec ALWAYS handles
thread_count=0 (see commit message in previous commit). Therefore rename
the cap and update its documentation to make its meaning clear.
The old name is kept deprecated until next+1 major bump.
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9 to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread_count=0 itself or pass the zero directly to the
codec implementation. Within this meaning, it is clearly supposed to be
an internal cap rather than a public one, since from the viewpoint of a
libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
in the generic code or within the codec internals is not a meaningful
difference for the caller.
External aspects of this flag will be dealt with in the following
commit.
This patch is relatively straightforward with one exception:
the decoder option flag.
The option was introduced to troubleshoot but its existence is conflicting
and redundant now that we have a codec-generic flag.
Hence this patch deprecates it.
The way it interacts with AV_CODEC_EXPORT_DATA_FILM_GRAIN is as follows:
If filmgrain is unset and AV_CODEC_EXPORT_DATA_FILM_GRAIN is
present, disable film grain application and export side data.
If filmgrain is set to 0, disable film grain and export side data.
If filmgrain is set to 1, apply film grain but export side data if
the AV_CODEC_EXPORT_DATA_FILM_GRAIN flag is set. This may result in
double film grain application, but the user has requested it by setting
both.
Disable by default to output all the layers, to match libaomdec wrapper.
Add option to select the operating point for the spatial layers.
Update the documentation with the new options.
Signed-off-by: James Almer <jamrial@gmail.com>
As suggested by Ronald, don't map auto threads to frame threads only, and
instead distribute them between frame and tile more efficiently.
Add a new framethreads override option, similar to the tilethreads one.
Signed-off-by: James Almer <jamrial@gmail.com>
Replaces the libdav1d internal allocator. It uses an AVBufferPool to reduce the
amount of allocated buffers.
About 5% speed up when decoding 720p or higher streams.
Reviewed-by: "Vittorio Giovara <vittorio.giovara@gmail.com>"
Signed-off-by: James Almer <jamrial@gmail.com>
Bump the minimum required version to the first one with the logger API callback.
Reviewed-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Dav1dPictures contain more than one buffer reference, so we're forced to use the
API properly to free them all.
Reviewed-by: BBB
Signed-off-by: James Almer <jamrial@gmail.com>
