GNOME Bugzilla – Bug 601033
qtmux: mpeg4/aac sync issue playing in quicktime
Last modified: 2015-01-21 13:00:33 UTC
The following pipeline produces a perfectly synced video when played by totem, vlc etc.. Playing the same file in quicktime (7.6.4) produces slightly delayed video. gst-launch -e v4l2src ! 'video/x-raw-yuv,width=320,height=240,framerate=30/1' ! videorate ! ffmpegcolorspace ! ffenc_mpeg4 flags=0x00400000 ! queue ! mux. alsasrc device=hw:0 ! audiorate ! faac profile=2 ! mux. mp4mux name=mux ! filesink location=test.mp4
I couldn't see a delay testing here. Maybe you should also add a queue to the audio branch. Have you tried with git version? If it still happens with git version, could you attach a GST_DEBUG=5 and a file that shows the delay? Thanks.
h264/aac recording http://bachman.rxtx.se/tmp/out30.mp4 muxed with mp4mux it is in sync with mplayer,vlc,totem-gstreamer,wmp,mpc. but with QT you should experience a distinct out-of-sync playback.
bachman: Do you have a pipeline for the video you created? I haven't noticed a delay for h264/aac video in quicktime.. but then I used qtmux not mp4mux.
a friend of mine could play the clip on his mac using qt and a/v was in sync. strange, I have tried this on my mac and it wasn't perfectly in sync. it may be qt version dependent. is it leopard and latest qt you are testing with?
I experienced the sync issue (with your video) just as you described using the above mentioned version of quicktime on windows. The reason I asked about the pipeline is because I have only seen the sync problem with m4v/aac and mp4mux. h264/aac and qtmux videos have good sync for me, using the x264enc encoder.
Uhm, ok. According to gst-inspect mp4mux uses the libgstqtmux.so so what's the difference between qtmux and mp4mux? Should there be any at all in the mux functionality or sync related?
bachman: Yes, there's a difference in the way atoms are constructed. I tried your clip on leopard using quicktime 7.6.4.. same sync issue. Would be good to know which OS/quicktime combo your friend was using. Thiago: In middle of building git latest.. will post result.
qtmux and mp4mux (and gppmux) share are almost the same code (tiny little differences in the way the atoms are constructed), but the muxing and time usage is the same for all of them.
I tried muxing with mp4mux and looking at the sample provided here and so fat only QT plays it out of sync, tried totem, vlc and mplayer and they all were fine. I wonder if there is a way to know if a file is in sync other than just looking at the videos.
Using git latest, the delay is there. Using the previously posted pipeline, the delay is slight but noticeable (more slight than the video bachman posted). Right.. this is unique to quicktime. I also tried Meida Player (ver 12 on Windows 7), and it too plays in sync. My problem is that quicktime is the only commercial player I've found that handles edit atoms properly.
Have you tried gstreamer with the qtdemux patch from https://bugzilla.gnome.org/show_bug.cgi?id=586848 ? It hasn't been pushed to git as I'd like to have some feedback on those.
Yes, I've tried it and plays back edits in sync (using totem).. but you'll notice that when ever there is an audio gap (empty edit), totem's progress bar jumps ahead to the start point of the next non-empty edit. Using in a gst-launch pipeline, it hasn't worked for me. I'll report back more in the above thread. If you need sample edit atom videos let me know. I've amended qtmuxedits-test (from below patch) to record from v4l2src/alsasrc rather than test sources. BTW.. quictime has same sync issue with videos containing edits. https://bugzilla.gnome.org/show_bug.cgi?id=601576 I still need to find a widely available commercial player such as quicktime or media player that will support edit atoms (Meida Player 12 does not). And at the moment, quicktime looks like the only possible candidate.
Pushed some fixes to improve sync with qtmux/mp4mux, but quicktime still shows totally out of sync streams. totem, mplayer and vlc play it ok. Don't know how to investigate this further.
If we could get the same file (re)muxed with a different application that made the video work at quicktime it would be easier to spot why it doesn't sync correctly.
I have tested both mencoder and mp4box and none of them did even as near good mux as qtmux does after the last two commits.
I used a utility I found called YAMB to stip out and remux the h264/aac streams from bachman's video. The output will have the same sync diff, unless, the 'Force QT compatibility with B-VOPs' is selected. If checking this prop, sync is good. There are a few moov atom differences (using apple's dumpster utility). Remuxed file: http://www.bluedigits.com/misc/out30_track1.mp4
When inspecting these files and their differences, 2 things called my attention: 1) The _track1 variation has a btrt atom inside the stsd of the video 2) The durations of the audio samples are different I guess number 2 is more important, so I'm going to try it first.
It would also be good if you retested your applications adding aacparse to the pipeline before qtmux.
Btw, Roland, could you remux one of *your* samples with this tool and check if it also fixes your problem? If so, please, attach both the samples (the original and the remuxed). Thanks.
Unfortunately it crashes when extracting m4v/aac streams.
Forget to set 'global-headers' flag. So extracting m4v/aac streams and remuxing using yamb, produces the same result as original.. Very slight delay played in QT, and correct sync when played in the above mentioned players.
Based on comments above, I believe this bug is very much 'Confirmed'. Is there any other status update?
Hrm, so this was in 2009. Is this still an issue with qtmux in GStreamer 1.0.x ?
Chris, is this still an issue for you with gstreamer 1.x ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!