The previous allocation increment of 16384 meant that the cluster
array was allocated for 0.6 MB initially, which is a bit excessive
for cases with fragmentation where only a fraction of that ever
actually is used.
Therefore, start off at a much smaller value, and increase by
doubling (to avoid reallocating too often when writing long
non-fragmented mp4 files).
Bug-Id: 525
Signed-off-by: Martin Storsjö <martin@martin.st>
When writing fragmented mp4, the cluster array is reset when a
fragment is written. Instead of starting off reallocating the
array only based on the number of current elements in it, keep
track of how many elements there were allocated earlier.
This avoids reallocating this array needlessly when writing
fragmented mp4 files.
Bug-Id: 525
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes the struct name (which isn't used anywhere) match the
name of the typedef, as for all the other structs declared in this
header.
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>
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>
This fixes calculation of trackDuration if the MOVIentry array
is cleared. This is required by the fragmentation support in the
next patch.
Signed-off-by: Martin Storsjö <martin@martin.st>
Originally, sizeof(struct MOVIentry) was 48, after the reordering,
it is 40 in my build configuration.
When writing really long mov/mp4 files, this can make a difference
- this saves a bit over 2 MB of memory per hour of video (down to
10.3 MB per hour from 12.3 MB per hour initially) for a video with
75 packets per second - 25 fps + 50 audio packets (which is the
case for AMR audio).
Signed-off-by: Martin Storsjö <martin@martin.st>
If an annex b bitstream is muxed into mov, the actual written
sample is reformatted to mp4 syntax before writing.
Currently, the RTP hints that copy data from the normal video
track, where the payload data might be offset compared to the
original sample that the RTP hinting used (when 3 byte
annex b startcodes have been converted into 4 byte mp4 format
startcodes).
Signed-off-by: Martin Storsjö <martin@martin.st>
