At the moment, the moov header is written at the end of the file, so we
can use the current offset (which focus on the end of the mdat already
written) to guess if 64-bits offset will be required or not.
Though, the next commits will make possible the writing of this table at
the beginning, so this heuristic can't work. As a consequence, we check
all the values within the potential offset table for any value >
32-bits.
This is consistent with stdio and is what we want to do in all cases.
Fixes a bug in the voc muxer which didn't flush in write_trailer()
previously. This is the cause of the change in the test results.
Implements support for tmpo atom for mp4 files, typically used to store BPM. -metadata "tmpo=127" as a command line option will record 127 as the BPM in the meta data.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As packet duration is not stored inherently in MPEG4 containers,
subtitles have their duration expressed by storing an additional
empty packet with a pts matching the desired end time of the real
subtitle. Additionally, it is generally expected that all streams
start at time = 0, so an empty packet needs to be inserted at the
beginning of the stream, before the first real subtitle.
Unfortunately, ffmpeg lacks a proper way to express that a subtitle
might map to multiple packets, so the muxer is the only place we
can handle this.
Signed-off-by: Philip Langdale <philipl@overt.org>
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.
There is basic support for muxing chapter information into the
Apple Quicktime format already, but there are two errors which
prevent correct detection on the player side.
1) A special apple 'text' atom needs to be included inside the
gmhd atom.
2) The *different* 'text' atom inside the 'stsd' atom needs a
proper header.
With these changes, the chapters are now picked up by Apple
players and reported correctly by tools like mediainfo and mp4chaps.
v3 Update: The stub TextSampleEntry creation is moved to where the
chapter track is created so it's now specific to this track.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Share the formerly internal write_packet with the hinter and move the
fragment flush logic to the user facing one since it is not concerned
about movtrack-only streams.
Fixes bug #263
Signed-off-by: Martin Storsjö <martin@martin.st>
Also add missing trailing commas, break long codec_tag lines and
add spaces in codec_tag declarations.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes crashes when copying a data track as in trac
issue #236.
No proper timecode tracks will be written though.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This isn't exactly equivalent with the earlier code for codecs
other than H264 and VC1, but those are two only codecs supported
by this codepath anyway, and it simplifies it a bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
The other fragmentation options (frag_duration, frag_size and
frag_keyframe) are combined with OR, cutting fragments at the
first of the conditions being fulfilled.
Signed-off-by: Martin Storsjö <martin@martin.st>
For encoding, AVCodecContext.frame_size is the number of input samples to
send to the encoder and does not necessarily correspond directly to the
timestamps of the output packets.
This allows writing QuickTime-compatible fragmented mp4 (with
a non-empty moov atom) to a non-seekable output.
This buffers the mdat for the initial fragment just as it does
for all normal fragments, too. Previously, the resulting
atom structure was mdat,moov, moof,mdat ..., while it now
is moov,mdat, moof,mdat.
Signed-off-by: Martin Storsjö <martin@martin.st>
Clément Bœsch
Anton Khirnov
Martin Storsjö
Kari Lentz
Clément Bœsch
Michael Niedermayer
Piotr Bandurski
Philip Langdale
Diego Biurrun
Carl Eugen Hoyos
Ronald S. Bultje
Stefan Gehrer
Al@dneg.com
Alex Converse
Luca Barbato
Reimar Döffinger
Justin Ruggles