Try to make the feature easier to use, especially since the user
have enabled -strict experimental manually. The user shouldn't
be surprised that hls_playlist is enabled for lhls automatically,
so change the log level from warning to info for that.
There is a little chance that user specified contradicted options
like -streaming 0 -ldash 1, however, it's more likely that user
didn't know or forgot to enable streaming for ldash. So enabling
streaming automatically to make the feature easier to use, similar
like enable FF_MOV_FLAG_FRAGMENT/EMPTY_MOOV/DEFAULT_BASE_MOOF and
so on for FF_MOV_FLAG_CMAF.
Fixes: integer overflow
Fixes: 40313/clusterfuzz-testcase-minimized-ffmpeg_dem_AIFF_fuzzer-4814761406103552
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes -Wstringop-overflow warnings with libaom >= 2.0.0, where the unused alpha
plane was removed from aom_image.
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This fixes linking errors where variables cannot be correctly linked in from an external shared library such as with msvc (requires dllimport which is not used by libaom). Instead just call the function that returns the same variable.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
OpenBSD only supports riscv64 but this is an attempt at adding
some of the initial bits for RISC-V support.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If original packet is corrupted, then parsed packet is probably corrupted too.
Let the application decide what to do.
Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Prevents desktop stutters caused by the change (specifically on KDE).
We're not a game, we don't actually need it disabled.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The packets delivered to this decoder are often decoded to more than
one frame and if the internal buffer packet is not unreferenced,
the decoder will still output frames derived from the old packet (from
before the flush).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder may output multiple AVFrames for every AVPacket
passed to it, but after it has returned AVERROR(EAGAIN),
it is completely drained and there is no reason to flush it
at the end with a NULL packet. Furthermore, there is also no
delay in the common sense of the word.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Such fields can be seen as generally useful in cases where the
API user is not implementing custom AVIO callbacks, but still would
like to know if data is being read or written out, such as in case
data is being read from input but no AVPacket has been received yet.
Originally added as a private entry in commit
3f75e5116b, but its grouping with
the comment noting its private state was missed during merging of
the field from Libav (most likely due to an already existing field
in between).