Decoders implementing the receive_frame API currently mostly use
stack packets to temporarily hold the packet they receive from
ff_decode_get_packet(). This role directly parallels the role of
in_pkt, the spare packet used in decode_simple_internal for the
decoders implementing the traditional decoding API. Said packet
is unused by the generic code for the decoders implementing the
receive_frame API, so allow them to use it to fulfill the function
it already fulfills for the traditional API for both APIs.
There is only one caveat in this: The packet is automatically
unreferenced in avcodec_flush_buffers(). But this is actually
positive as it means the decoders don't have to do this themselves
(in case the packet is preserved between receive_frame calls).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
From ETSI EN 300 472 V1.3.1 (2003-05) Specification for conveying ITU-R System
B Teletext in DVB bitstreams:
4.1 Transport Stream (TS) packet format
The standard TS packet syntax and semantics are followed, noting the following
constraint:
- adaptation_field_control only the values "01" and "10" are permitted.
Some set top boxes (Motorola, Arris, Zyxel) refuse non-conforming packets.
Signed-off-by: Alex Shumsky <alexthreed@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Commit 6f36eb0da7 claim it fixes endless loop on
package generation if muxrate specified and copyts used. But actually it does
not work properly if -mpegts_copyts 1 is specified:
ffmpeg -y -copyts -i loewe.ts -c:v libx264 -x264opts nal-hrd=cbr:force-cfr=1 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 1000k -c:a mp2 -f mpegts -mpegts_copyts 1 -muxrate 4500k -vframes 1000 test.ts
ffmpeg generate huge file until it reach zero-based pcr value equal to first dts.
Attached patch fixes it.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
