#55 wide-gap "interleaving" with MP4box

[Anonymous]

material is h.264 video and aac+ audio, in mp4.
muxing was done from separate files, just passing a
-fps 23.976, using mp4box on windows.
the problem can be reproduced with mp4box built from
0.4 tarball on linux here.

following lines are from "mplayer -v -v thefile.mp4"
chunk-offset-table dumps. the <== parts are comments
added by me.

MOV track #0: 3128 chunks, 34407 samples <== video
pts=34441407 scale=24000 time=1435.059

Sample 20494: pts=20514494 off=0x057D34D0 size=12712
<== 20514494/24000 == 854.77 sec

MOV track #1: 3058 chunks, 33636 samples <== audio
pts=68884992 scale=48000 time=1435.104

Sample 20035: pts=41030144 off=0x05549B4E size=507
<== 41030144/48000 == 854.79 sec
Sample 20494: pts=41970176 off=0x057D32E4 size=492
<== 41970176/48000 == 874.37 sec

V#20494 - A#20035 -> offsets 0.02 seconds, 2660738 byte
V#20494 - A#20494 -> offsets 19.60 seconds, 492 byte

thats 2.5 MB in-stream distance for A/V samples of the
same "time", or 20sec temporal distance for samples
muxed next to each other in the stream.
that goes somewhat beyond "not so tight" interleaving.

remuxing with "-hint -tight" fixes it, but increases
filesize quite a bit more than is acceptable to just
get less chunky interleaving.
changed code to allow -tight without hinting, fixes it
as well, with a much more reasonable filesize increase
(going from ~3000 to ~30000 chunks, +250kB filesize).

a proper fix would probably be to do the interleaving
based on the timecodes instead of the sample-IDs.
if that is somehow unreasonable, at least allowing
no-hinting-but-tight-interleaving without having to
change code would probably be acceptable for most purposes.

DISCLAIMERS:
i am not the guy who made the file i am rambling about,
i am just someone who wasted three days trying to
figure out why playing it was trashing a machine here
by seeking around madly.
spare me comments about mplayer, unless the comments
include a better way to dump comparable information
about the interleaving.
i know close to nothing about mp4, so in particular the
"how to fix" parts may be dead wrong.
if any of this can be fixed by passing more options,
they are well-hidden, and i agree to be insulted a
little as long as the insults are interleaved with the
options i failed to find. ;)

[Jean Le Feuvre]

Logged In: YES
user_id=815447

A short answer: interleaving time is too high for the
desired bitrate.

A longer answer - eg, lack of MP4Box documentation ;)
MP4Box doesn't reorder tracks when interleaving, it just
interleaves tracks based on their order in the file. The
default interleaving time in MP4Box is 0.5 sec, which means
each track data is stored as chunks of max 0.5 sec,
regardless of the data size. From what you explain, it
looks like the interleaving is done by first checking the
audio track, then the video track. Depending on the video
coding (assuming constant bit-rate for audio), having such
gaps is quite normal, especially if you have I-frames (IDRs
for AVC) in the given chunk.
If you really need to lower these gaps, then simply use a
lower interleaving value; a good test would be to use the
video framerate for that (in your case roughly 42ms), or
twice the framerate to lower file size. This can be done
with -inter option.

I'll have a closer look at the patch on isomedia storage,
it's quite interesting - probably a new storage option in
MP4Box soon...

[Jean Le Feuvre]

Logged In: YES
user_id=815447

I just commited both patches on CVS. The default storage
mode of MP4Box is now the drift-controled interleaving one,
since not using it may indeed impact playback on long
movies.
Once again, a great many thanks for this patch !!