According to the PIFF specification[1] the base_data_offset field MUST be
omitteed. See section 5.2.17. Since the ISMV files created by ffmpeg state
that they are 'piff' compatible via 'ftyp' box, this needs to be corrected.
[1] http://www.iis.net/learn/media/smooth-streaming/protected-interoperable-file-format
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to the PIFF specification[1] the base_data_offset field MUST be
omitteed. See section 5.2.17. Since the ISMV files created by libavformat
state that they are 'piff' compatible via 'ftyp' box, this needs to be
corrected.
[1] http://www.iis.net/learn/media/smooth-streaming/protected-interoperable-file-format
Signed-off-by: Martin Storsjö <martin@martin.st>
Other software does not store it in this case, and the information
is provided by the codec stream
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The QuickTime specification does not contain any hint that the atom
must not be written in some cases and both the QuickTime and the
AVID decoders do not fail if the atom is present.
This change allows to signal (visually) interlaced streams with
a codec different from uncompressed video.
As a side-effect, this fixes ticket #2202
Some software does not support edit lists at all, the adobe flash
player seems to be one of these. Which results in AV sync errors when
edit lists are used to adjust AV sync.
2nd try on implementing this, the first try had various issues
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The timebases before where only guranteed to be 1/fps precisse
and could cause AV sync errors on low fps
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>