[Bug 774716] vlc does not play mp4 file that was merged using splitmuxsrc and splitmuxsink

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774716

--- Comment #6 from Jan Schmidt <thaytan at noraisin.net> ---
There is something wrong with our DTS calculations indeed.

Here's the CTTS for the first file:

0:00:01.852043693  6298      0x1ae8f70 LOG                  qtdemux
qtdemux_dump.c:927:qtdemux_node_dump_foreach:           'ctts', [40],
Composition time to sample
0:00:01.852064380  6298      0x1ae8f70 LOG                  qtdemux
qtdemux_dump.c:510:qtdemux_dump_ctts:             version/flags: 00000000
0:00:01.852080746  6298      0x1ae8f70 LOG                  qtdemux
qtdemux_dump.c:511:qtdemux_dump_ctts:             n entries:     3
0:00:01.852094943  6298      0x1ae8f70 LOG                  qtdemux
qtdemux_dump.c:519:qtdemux_dump_ctts:               sample count :      60
offset:        0
0:00:01.852112490  6298      0x1ae8f70 LOG                  qtdemux
qtdemux_dump.c:519:qtdemux_dump_ctts:               sample count :       1
offset: -1404672319
0:00:01.852129365  6298      0x1ae8f70 LOG                  qtdemux
qtdemux_dump.c:519:qtdemux_dump_ctts:               sample count :     359
offset:        0

The 2nd entry in the table has an absurd shift of -1404672319 between DTS and
PTS, which causes us to calculate a large start-time offset for the segment (to
leave headroom), but shouldn't make the PTS and DTS mismatched in the first 60
and last 359 samples of the stream where the offset is supposed to be 0. That 1
sample in the middle might cause trouble even if the DTS offset is corrected
though.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.