GNOME Bugzilla – Bug 419351
[avi/a52dec] AV synchronization problems
Last modified: 2008-08-20 13:28:09 UTC
The bug has been opened on https://launchpad.net/bugs/86551 "Binary package hint: totem When watching XviD videos the synchronization between Audio and Video is lacking. The problem is getting worse the longer I watch the video. I have no such problems with totem-xine or gxine. I tried setting all Audio options in the control panel to ALSA but that didn't help... Let me know if you need more info. ProblemType: Bug Date: Tue Feb 20 20:42:19 2007 DistroRelease: Ubuntu 7.04 Uname: Linux mika-pc 2.6.20-8-generic #2 SMP Tue Feb 13 05:18:42 UTC 2007 i686 GNU/Linux ... > thank you for your bug. Does it happen on a specific video or with any video? Do you get the same problem if you play it with "gst-launch-0.10 playbin uri=file:///path/to/file"? ... Sorry for the delay! It happens with all XVID videos I've tested. Do you happen to know freely available videos in this format? The problem persists with gst-launch-0.10 playbin, but there I also get some output which may help in finding the casue of the problem: mika@mika-pc:~$ LANG=C gst-launch-0.10 playbin uri=file://$(pwd)/test.avi Setting pipeline to PAUSED ... Pipeline is PREROLLING ... No accelerated IMDCT transform found Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock1 WARNING: from element /playbin0/abin/audiosink/audiosink-actual-sink-alsadmix: Compensating for audio synchronisation problems Additional debug info: gstbaseaudiosink.c(827): gst_base_audio_sink_render (): /playbin0/abin/audiosink/audiosink-actual-sink-alsadmix: Unexpected discontinuity in audio timestamps of more than half a second (0:00:00.500000000), resyncing Got EOS from element "playbin0". Execution ended after 1301864183000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... Any idea how to further debug this problem? BTW: vlc also has no such problems. ... http://librarian.launchpad.net/6724574/gst-debug2-86551.log Debug output with GST_DEBUG=2 Well, GST_DEBUG=5 is completely over the top. It produces so much output that my computer couldn't play the video without skipping and my disk was filled up pretty fast. So I tried with 1, 2, 3 and 4. 1 does not give any more output, the output of 2 is attached. I'll also attach a gzipped version of the 3 output (12 MB unzipped!). The output with GST_DEBUG=4 is 2.7 GB so I'll skip that one as well... ... http://librarian.launchpad.net/6724577/gst-debug3-86551.log.gz Debug output with GST_DEBUG=3 (gzipped)"
This kind of thing is much easier to look into with a sample file. Could you make a log like this please: $ export GST_DEBUG_NO_COLOR=1 $ GST_DEBUG=a52dec:5,*alsa*:5,baseaudiosink:5 gst-launch-0.10 playbin uri=file:///home/mike/test.avi 2>dbg.log $ gzip dbg.log
Hi Tim, I know that it would be easier to have a test case. Do you know how I could find out what codecs are used in the file. Then maybe I could find a publicly accessible video that has the same problem. From what I gather the video uses XviD and audio uses AC3 DVM. Is there a way to affirm that? Some command line tool? Anyway, I ran the commands and will attach the log. While running this was the output: mika@mika-pc:~$ GST_DEBUG=a52dec:5,*alsa*:5,baseaudiosink:5 gst-launch-0.10 playbin uri=file:///home/mika/test.avi 2>dbg.log New clock: GstAudioSinkClock WARNING: from element /playbin0/abin/audiosink/audiosink-actual-sink-alsadmix: Compensating for audio synchronisation problems Zusätzliche Debugginginformation: gstbaseaudiosink.c(860): gst_base_audio_sink_render (): /playbin0/abin/audiosink/audiosink-actual-sink-alsadmix: Unexpected discontinuity in audio timestamps of more than half a second (0:00:00.500000000), resyncing FEHLER: Ende des Datenstromes in Element "playbin0". Execution ended after 1301891018000 ns. Thanks for your help!
The log is here: http://www.zoopnet.de/dbg.log.gz It's 23MB so I couldn't attach it here...
I have the same problem using gstreamer apps such as Totem and Elisa. Xine and VLC are fine with the same files. The video lags about a second behind the audio and reminds me of the old "black belt theater" films. It is bad enough that it happens on most content I watch, which I'm guessing is Xvid encoded.
As I said, a sample file would make it much easier for us to fix this. Feel free to stop by on IRC (#gstreamer on freenode) or send me a mail with the link if you don't want to post one here.
I can confirm this also. Movies start out in sync, but after a while the audio goes out of sync and it seems to become worse and worse, until it's automatically resynced; Unexpected discontinuity in audio timestamps of more than half a second (0:00:00 .500041666), resyncing Seeking or pausing/unpausing also get the movie back in sync. It does seem limited to Xvid with AC-3, as I tried converting the soundtrack to mp3, and it seems to play in perfect sync that way. I'd be happy to make a sample file available, but it needs to be large file, as the sync issues isn't easily detected otherwise. I'm using version 0.10.13.
closing there is no example available, I'll reopen if the submitter sends one
Reopening as I made a sample file available to Tim.
Confirmed with CVS. The first resync occurs about 907 seconds into the movie.
so?
I have a testcase, it seems the timestamps are simply drifting and the sink will resync after it's 0.5 seconds out of sync.
*** Bug 532056 has been marked as a duplicate of this bug. ***
very subtle problem caused by rounding errors in the conversion from number of samples to nanoseconds. The rounding errors accumulated and caused a slight drift. Should be fixed now with this patch: * gst-libs/gst/audio/gstaudiosink.c: (gst_audioringbuffer_acquire): Choose to allocate one less segment but require one additional segment as latency. * gst-libs/gst/audio/gstaudiosrc.c: (gst_audioringbuffer_acquire): No need to increment the number of segments in the source. * gst-libs/gst/audio/gstbaseaudiosink.c: (gst_base_audio_sink_get_time), (clock_convert_external), (gst_base_audio_sink_resample_slaving), (gst_base_audio_sink_skew_slaving), (gst_base_audio_sink_none_slaving), (gst_base_audio_sink_render), (gst_base_audio_sink_async_play): Remove adding latency when returning the internal time while subtracting it again when we use the value a little later. When calculating the end timestamp, we are making a rounding error with the current algorithm. Ensure that we don't accumulate these rounding errors when aligning samples by not resampling at all if we don't need to. Fixes # Make the initial calibration of the clock slaving a little more predictable and accurate. Also handle the case where we don't do clock slaving.
*** Bug 548282 has been marked as a duplicate of this bug. ***