After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 774716 - vlc does not play mp4 file that was merged using splitmuxsrc and splitmuxsink
vlc does not play mp4 file that was merged using splitmuxsrc and splitmuxsink
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.10.x
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-19 13:43 UTC by sonntex
Modified: 2018-11-03 15:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
video-chunk-01.mp4 (60.60 KB, video/mp4)
2016-11-19 13:43 UTC, sonntex
Details
video-chunk-00.mp4 (66.32 KB, video/mp4)
2016-11-19 13:43 UTC, sonntex
Details
video.mp4 (127.23 KB, video/mp4)
2016-11-19 13:44 UTC, sonntex
Details

Description sonntex 2016-11-19 13:43:15 UTC
Created attachment 340305 [details]
video-chunk-01.mp4

I have two or more correct mp4 files that were grabbed from usb video camera using splitmuxsink with mp4mux muxer. 

sonntex@home ~/video1 $ ls -l
total 132
-rw-r--r-- 1 sonntex sonntex 67913 Nov 18 17:32 video-chunk-00.mp4
-rw-r--r-- 1 sonntex sonntex 62051 Nov 18 17:32 video-chunk-01.mp4

sonntex@home ~/video1 $ ffprobe -show_packets video-chunk-01.mp4 2>&1 | tail -n 30
[PACKET]
codec_type=video
stream_index=0
pts=145692
pts_time=14.569200
dts=145692
dts_time=14.569200
duration=130
duration_time=0.013000
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=54537
flags=_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=145822
pts_time=14.582200
dts=145822
dts_time=14.582200
duration=1
duration_time=0.000100
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=54549
flags=_
[/PACKET]

As you can see dts, dts_time, pts, pts_time, duration and duration_time are correct.

sonntex@home ~/video1 $ gst-launch-1.0 -qe splitmuxsrc location="video-chunk-*.mp4" ! splitmuxsink location="video.mp4"

sonntex@home ~/video1 $ ls -l
total 260
-rw-r--r-- 1 sonntex sonntex  67913 Nov 18 17:32 video-chunk-00.mp4
-rw-r--r-- 1 sonntex sonntex  62051 Nov 18 17:32 video-chunk-01.mp4
-rw-r--r-- 1 sonntex sonntex 130286 Nov 19 16:33 video.mp4
sonntex@home ~/video1 $ ffprobe -show_packets video.mp4 2>&1 | tail -n 30
[PACKET]
codec_type=video
stream_index=0
pts=-161503839
pts_time=-140438.120870
dts=-161503839
dts_time=-140438.120870
duration=1
duration_time=0.000870
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=114820
flags=_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=-161503775
pts_time=-140438.065217
dts=-161503775
dts_time=-140438.065217
duration=1
duration_time=0.000870
convergence_duration=N/A
convergence_duration_time=N/A
size=12
pos=114832
flags=_
[/PACKET]

Result of the merge has incorrect dts, pts and duration. So, I can not play this mp4 file using vlc.
Comment 1 sonntex 2016-11-19 13:43:46 UTC
Created attachment 340306 [details]
video-chunk-00.mp4
Comment 2 sonntex 2016-11-19 13:44:20 UTC
Created attachment 340308 [details]
video.mp4
Comment 3 Jan Schmidt 2016-11-21 10:08:05 UTC
The first input file starts with these timestamps:

gst-launch-1.0 file://`pwd`/video-chunk-00.mp4 ! qtdemux ! fakesink silent=false -v |less

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (4188 bytes, dts: 0:00:00.000000000, pts: 39:01:07.231900000, duration: 0:00:00.038400000, offset: -1, offset_end: -1, flags: 00000040 discont ) 0x7f6f7c003380
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (15 bytes, dts: 0:00:00.038400000, pts: 39:01:07.270300000, duration: 0:00:00.011500000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f6f7c003160
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (11 bytes, dts: 0:00:00.049900000, pts: 39:01:07.281800000, duration: 0:00:00.049500000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f6f7c003050
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (11 bytes, dts: 0:00:00.099400000, pts: 39:01:07.331300000, duration: 0:00:00.010200000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f6f7c003160
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (11 bytes, dts: 0:00:00.109600000, pts: 39:01:07.341500000, duration: 0:00:00.090800000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f6f7c003380
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (11 bytes, dts: 0:00:00.200400000, pts: 39:01:07.432300000, duration: 0:00:00.010200000, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f6f7c0035a0

As you can see, there's a gigantic offset between DTS and PTS that just messes everything up from there.
Comment 4 sonntex 2016-11-21 13:24:41 UTC
Are you sure that the reason is incorrect file, and not qtdemux? I see that ffprobe shows me correct dts and pts for all packets.

sonntex@home ~/video1 $ ffprobe -loglevel 8 -show_packets video-chunk-00.mp4 | head -n 30
[PACKET]
codec_type=video
stream_index=0
pts=0
pts_time=0.000000
dts=0
dts_time=0.000000
duration=N/A
duration_time=N/A
convergence_duration=N/A
convergence_duration_time=N/A
size=4188
pos=48
flags=K
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=384
pts_time=0.038400
dts=384
dts_time=0.038400
duration=N/A
duration_time=N/A
convergence_duration=N/A
convergence_duration_time=N/A
size=15
pos=4236
flags=_
[/PACKET]
Comment 5 Nicolas Dufresne (ndufresne) 2016-11-21 14:27:40 UTC
It's plausible, could be an overflow, or a missing "invalid time" check.
Comment 6 Jan Schmidt 2016-11-22 02:20:01 UTC
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.
Comment 7 sonntex 2016-11-28 13:04:02 UTC
Do you file a new bug?
Comment 8 GStreamer system administrator 2018-11-03 15:14:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/326.