GNOME Bugzilla – Bug 586848
qtmux, asfmux: remuxing streams with different start times
Last modified: 2011-05-09 10:00:43 UTC
Trying to transcode this file: http://dirac.kw.bbc.co.uk/download/video/maybefinal/bbb-tr2200.ts Been trying to convert it to a series of formats and in most cases audio and video goes badly out of sync. The original plays fine in Totem. Only transcoded file so far which works well has been when I transcoded to Ogg+Theora+Vorbis. Works: Ogg+Theora+Vorbis Matroska+mp3+Theora (plays fine in mplayer, doesn't play at all in Totem) These gives me audio/video sync issues: H264+AAC in Quicktime H264+MP3 in Quicktime MPEG4+mp3 in AVI Transcoding using Transmageddon, but getting same behaviour with gst-launch Can provide any generated file upon request
Tried re-transcoding the working Ogg Theora+Vorbis file and it give me the exact same sync issue as transcoding the original MPEG TS file directly to Quicktime.
By looking at the timestamps at the buffers received by qtmux I can see there is a 1s difference between the first buffer of one stream, and the first buffer of the other. Maybe there is a timestamping problem, or maybe it is meant to be like this and our muxers aren't handling this properly.
I implemented the 'late' streams handling in qtmux and it remuxes in sync (quicktime works), but qtdemux ignore empty edit list entries (which is how we add empty segments in qt) and doesn't play correctly.
Created attachment 147123 [details] [review] Handling empty segments in qtdemux This patch makes it play correctly in qtdemux.
Created attachment 147131 [details] [review] Patch(1) for qtmux
Created attachment 147132 [details] [review] Patch(2) for qtmux The 2 patches for qtmux makes it mux it in sync.
Just fixed it for asf as well. Will commit all those after the freeze.
Pushed the fixes for qtmux/asfmux Module: gst-plugins-bad Branch: master Commit: 1d155a6357f3e42786ffdb75c65274e82bed15c6 URL: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=1d155a6357f3e42786ffdb75c65274e82bed15c6 Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Fri Nov 6 10:34:39 2009 -0300 qtmux: handle 'late' streams Module: gst-plugins-bad Branch: master Commit: 48a2bbd6ad982d92bfe797b18dcf99320dc99b21 URL: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=48a2bbd6ad982d92bfe797b18dcf99320dc99b21 Author: Thiago Sousa Santos <thiagoss@redmoon.(none)> Date: Tue Nov 17 17:25:14 2009 -0300 asfmux: handle streams with different start times (ugh, and I again forgot to set my name and email on the last commit, I just installed a new system, sorry for that)
Could someone review the patch for qtdemux, please?
Review of attachment 147131 [details] [review]: Commited
The following mp4 was create using the qtmux patch in the below bugzilla ticket. qtmuxedits-test.c was modified to use v4l2src/alsasrc instead of the test sources. The audio track contains non-empty/empty edits in 5 second intervals. http://www.bluedigits.com/misc/test-edits.mp4 When using totem with the qtdemux patch in this thread, the video plays back totally in sync all the way through. However, the progress bar will jump ahead to the next non-empty edit as soon as an empty edit is encountered. Also, if moving the progress bar back within an empty edit, playback from that point is out of sync. Playback using a gst-launch pipeline will cause gst-launch to get stuck during preroll: gst-launch filesrc location=test-edits.mp4 ! qtdemux name=demux demux.video_00 ! queue ! ffdec_mpeg4 ! ffmpegcolorspace ! ximagesink demux.audio_00 ! queue ! faad ! alsasink This thread relates to the following (quicktime mp4 sync issues): https://bugzilla.gnome.org/show_bug.cgi?id=601033
Please ignore the part about gst-launch getting stuck on preroll. The above pipeline uses ffdec_mpeg4 insted of ffdec_h264 (the posted recording is h264).
Review of attachment 147132 [details] [review]: commited
Any suggestions how to deal with the seek and position, within empty edits, bugs?
Comment on attachment 147123 [details] [review] Handling empty segments in qtdemux Updated and posted on the edit lists bug: 345830
Roland, would you mind if we separate the issue about seeking and positioning within empty edits into another bug entry? If so, I think we can mark this bug closed.
Yes, please do. I have added comments to #345830 on this subject.
Ok, based on latest comments I will close this bug as fixed.