As per 8.6.1.2.2 of ISO/IEC 14496-12:2015(E), STTS sample offsets
are to be always stored as uint32_t. So far, they have been signed ints
which led to desync in files with very large offsets.
The MOVStts struct was used to store CTTS offsets as well. These can be
negative in version 1. So a new struct MOVCtts was created and all
declarations for CTTS usage changed to MOVCtts.
The actual frame_size is no longer used since commit
3d38e45eb85c7a2420cb48a9cd45625c28644b2e; and the check for
"< 0" is equivalent to the CID being valid. But this is already
checked by avpriv_dnxhd_get_interlaced() (and is actually already
ensured by mxf_dnxhd_codec_uls containing this CID).
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is just a flag per supported CID. So there is no reason to use
an avpriv function for this purpose.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It avoids the overhead of the packet list; furthermore, using
ff_interleave_packet_per_dts() is wrong for the null muxer anyway,
because said muxer accepts packets without timestamps, which
ff_interleave_packet_per_dts() can't handle.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It avoids branches lateron and will allow to easily avoid the overhead
of the linked list currently in use in case there is only one stream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Besides being unused it should not be used at all:
The order of options of bitstream filters is not guaranteed
to be stable at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MXF muxers only write the header after they have received
a packet; the actual write_header function does not write anything.
So make an init function out of it.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
None of the muxers here has the AVFMT_NOSTREAMS flag set,
so it is checked generically that there are streams.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is especially important in case avio_write() would be switched
to an unsigned type like size_t, then a potential error from avio_read()
(with negative return value) would no longer be handled gracefully by
avio_write().
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The memset here is both unnecessary (avio_read() ignores the previous
content of the destination buffer) as well as nonsense (for a char
buf[BUFSIZE] sizeof(buf) and sizeof(BUFSIZE) are not the same; the
latter is sizeof(int)).
Fixes Coverity issue #1465863.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In 45bfe8b838, short_seek_threshold was removed
from the public AVIO struct. Although this option was private and not intended
to be used by public API users, it was nonetheless, because it provided functionality
that could otherwise not be gained via public API.
This was especially important for networked I/O like HTTP, where the internal
size for lavf could be way to small depending on the specifics of a user's
usecase, such as reading interlavd media files from cloud storage.
Add an AVOption to make this functionality accessible to the HTTP client.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
There is no reason to wrap them in #ifndef guards, they should only be
defined here and nowhere else. The define guards just add the
possibility to accidentally use the same FF_API name in different
libraries.
NEEDS_UNSAFE has the same value as NEEDS_FILE,
causing "duration not allowed if safe" error
while duration directive doesn't require unsafe mode.
Signed-off-by: Googleplex <yyoung2001@gmail.com>
Previously this was hardcoded to 2500000 bytes, so probing of the stream codecs
was always limited by this, and not probesize.
Also keep track of the actual size of packets in raw_packet_buffer and not the
remaining size for simplicity.
Fixes ticket #5860.
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
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>
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).
Looking at 3f75e5116b, the field
was supposed to be private, but during merging the field and the
group that had the comment about it got separated.
Thus, move the actual privately utilized state of this variable
into the private FFIOContext. Additionally, name the private field
somewhat better, so that it does not get confused with the amount
of bytes written out.
bit_rate is not a critical field, and we shouln't hard fail if we
can't caluclate it due to a large timebase - it needlessly breaks
valid files.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Limin Wang
Gyan Doshi
Andreas Rheinhardt
Gijs Peskens
Derek Buitenhuis
Anton Khirnov
Googleplex
Marton Balint
Michael Niedermayer
Alex Shumsky
Maksym Veremeyenko
Zhao Zhili
Thilo Borgmann
Pekka Väänänen
Jan Ekström