It is not correct in all cases and it is less predictable than a skip of 0
for user applications.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Frames described by this grouping are the starter of a closed or
an open GOP.
This is useful for open GOP of H.264 stream which is not described
by sync sample atom.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A quite widespread pattern in the demuxer is read a 32bit unsigned
integer and then loop till this value is reached.
Checking for EOF prevents pathological situations.
Fix near infinite loop in stsd parsing.
Bug found by: Diana Elena Muscalu
The size is unsigned according the specification.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Avoid a near infinite loop.
Issue discovered by cosminamironesei.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes crashes when called from rtpdec_qt, where
AVFormatContext->pb is null, a crash present since 3bab7cd128.
Signed-off-by: Martin Storsjö <martin@martin.st>
According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.
Replace it with the average framerate where it makes sense.
FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.
In some other tests lavf starts making up frame durations from different
frame.
The native decoder and MPlayer's binary decoder only need the
APRG atom, QuickTime at least requires also the ARES atom and
four additional 0 bytes padding at the end of stsd.
Apple softwares seem not to add a tref for the timecode (the next commit
fixes this issue), but at least FFmpeg does.
This can be used to generate a sample that demonstrates the feature:
./ffmpeg -f lavfi -i testsrc \
-f lavfi -i mptestsrc \
-f lavfi -i rgbtestsrc \
-map 0 -map 1 -map 2 \
-metadata:s:0 timecode=00:00:00:12 \
-metadata:s:2 timecode=01:02:12:20 \
-t 10 -y out.mov
./ffprobe out.mov
The timecode metadata being transmitted to the video streams, it can be
kept while transmuxed/transcoded.
Skip to parse fields for additional independent substreams and its
associated dependent substreams since libavcodec's E-AC-3 decoder does not
support them yet.
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Instead of allocating over the original, free first. MOVStreamContext
is zero initialized so no double free will occur. Same style as other
fixes for the same problem in this file.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>