GNOME Bugzilla – Bug 335858
Video playback out of sync
Last modified: 2006-03-24 18:56:16 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/gstreamer0.10/+bug/33073 "A (while IMO funny but quite politically incorrect :) video seems to be played back with a sync problem between audio and video. Subjectively the audio seems to lag behind about half a sec or more. The lag seems to be constant neither seeking around nor longer playeback seem to make it better or worse. Please get the video from http://www.dinamixx.info/diverses/wow_forporn.avi or ask me if the location should become unavailable. Now I have no idea about totem, gstreamer, container formats and containers. Hence I do not know whether I filed this bug against the right package. I have a feeling that the decoder needed comes from universe/ugly, though." As commented on the distribution bug totem-xine and xine-ui have the same issue but mplayer works better
some data points: there is a rather unusual dwInitFrames != 0 (12 actualy) in the avih. There is an equal dwInitFrames in the strh header field. Normally the dwInitFrames from the strh should be used as a sync delay offset for that stream. Most files have a value like 1 for this, which is a very small offset. mplayer does not used this value at all apparently and looks a bit off-sync sometimes on some file I have.
Created attachment 61937 [details] [review] patch to combine global and stream delay and fix sync this patch combines the global init_frames with the stream init_frames. Rationale being that the global delay should be subtracted from any stream delay.
* gst/avi/gstavidemux.c: (gst_avi_demux_parse_index), (gst_avi_demux_stream_index), (gst_avi_demux_stream_scan), (gst_avi_demux_massage_index), (gst_avi_demux_handle_seek): this patch combines the global init_frames with the stream init_frames. Rationale being that the global delay should be subtracted from any stream delay. Fixes #335858.