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>
Its bad to free things without zeroing them.
This fixes a potential issue when mov_read_close() would be called twice.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If mov_read_header exits under error, the memory allocated is
not freed.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Convert key_off initialize to use the same sc->keyframe_count as
used elsewhere in the function.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The format is slightly proprietary.
DVDs use a format of
code byte (0x00, 0x01, 0xfe or 0xff), two data bytes
MOV uses instead
cdat/cdt2 atom, two data bytes
Auto-detecting and supporting both in one decoder is trivial,
so a single codec ID is used.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The correct point that seperates ISO and MAC language codes is 0x400
according to the current QT spec. Old QT specs did not list where this
seperation is but apparently only defined the meaning of the first 137.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The handler name is stored as a pascal string in the QT specs (first
byte is the length of the string), thus leading to an invalid metadata
string export.
Also add a second length check based on the first character to avoid
overwriting an already specified handler_name (it happens with Youtube
videos for instance, the handler_name get masked), or specifying an
empty string metadata.
This patch fixes the sample from trac issue #522.
The issue is that the mov demuxer insists on using its
calculated sample_size (which is nonsense for old-style tracks)
instead of the one encoded in the track.
The old raw audio code should be using the value in stsz, because
the size of a single sample never makes sense for the size of
a full audio packet, whereas the new code will multiply the
sample size by the chunk size, so it should use the calculated value.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This patch fixes the sample from trac issue #733.
The issue is that the size of the trak elements is coded
too large, so that the next trak element would be parsed
as part of the first and truncated incorrectly.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Michael Niedermayer
Piotr Bandurski
Anton Khirnov
Diego Biurrun
Carl Eugen Hoyos
Justin Ruggles
Ronald S. Bultje
Paul B Mahol
Martin Storsjö
Clément Bœsch
Mans Rullgard
Yusuke Nakamura
Dale Curtis
Reimar Döffinger
Baptiste Coudurier