The custom IO flag actually never is set for muxers, only for
demuxers, so the check was pointless (unless a user intentionally
would set the flag to signal using custom IO).
Signed-off-by: Martin Storsjö <martin@martin.st>
If one track doesn't have any samples within a moof, no traf/trun
is written for it. When the omit_tfhd_offset flag is set, none
of the tfhd atoms have any base_data_offset set, and the implicit
offset (end of previous track fragment data, or start of the moof
for the first trun) is used.
Signed-off-by: Martin Storsjö <martin@martin.st>
These allow getting the absolute start timestamp of a fragment
without reading preceding timestamps. This fixes sync between
tracks if starting from fragments in different streams that don't
align exactly.
This also is a prerequisite for producing DASH content.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is necessary to get the right timestamp offset for content
that starts with dts != 0.
This currently only helps when writing fragmented files with a non-empty
moov atom. When writing an empty moov atom, we don't have any packets
yet, so we don't know the starting dts for the tracks.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure that audio preroll for e.g. AAC is signaled correctly.
Previously we only wrote the edit list correctly if we had negative
dts but started with pts == 0 (e.g. for video with B-frames).
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's
codec context.
Using codec options inside lavf is fragile and can easily break when the
muxing codec context is not the encoding context.
F4V is Adobe's mp4/iso media variant, with the most significant
addition/change being supporting other flash codecs than just
aac/h264.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fragmenting blindly to a certain duration isn't a good choice
if one should be able to switch between different qualities,
therefore default to keyframes instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure other sanity checks for conflicting options
can work properly, e.g. for the conflict between the faststart
flag when using the ismv mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes the output fragments independent of their position in
the output stream, making the output work better when streamed.
QuickTime Player doesn't support fragmented mp4 without the base
data offset, though.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is a bit more work, but avoids having to fill in
the data offset field afterwards instead of directly when
the rest of the trun atom is written.
This simplifies future cases where this field needs to be set to
something different.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure the faststart vs fragmentation check works as
intended when fragmentation is enabled due to using the ismv mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
This should improve write performance quite significantly.
---
Tested with both writing a normal mp4, by using the faststart
feature and writing a fragmented mp4 file; all turn out with the
same md5sum as before.
Signed-off-by: Martin Storsjö <martin@martin.st>
On failures in the write_trailer function, we could also ignore
the errors and try to finish the file despite these errors (which
would only leave an incomplete chapters track). It's probably better
to signal the error clearly to the caller though (and if this
function failed there's no guarantee that there's enough memory to
finish the trailer either).
Signed-off-by: Martin Storsjö <martin@martin.st>
