GNOME Bugzilla – Bug 511489
avimux muxed audio and video out of sync
Last modified: 2008-05-21 15:26:01 UTC
Please describe the problem: avimux doesn;t correctly mux audio and video Steps to reproduce: ggst-launch-0.10 videotestsrc num-buffers=250 ! 'video/x-raw-yuv,format=(fourcc)I420,width=320,height=240,framerate=(fraction)30/1' ! timeoverlay ! queue ! mux. audiotestsrc num-buffers=440 ! audioconvert ! 'audio/x-raw-int,rate=44100,channels=2' ! queue ! mux. avimux name=mux ! filesink location=test.avi ffplay test.avi Actual results: Shows that the video is played at half its rate and the audio start cracking (buffer underruns?). Windows media player the audio is good but drifts apart from video at a factor 2 (only visible with real content). Expected results: Video should display in image timestamps that folow the normal second clock Does this happen every time? yes Other information: When ONLY video is muxed it is ok. When playing the file with gstreamer it is ok.
Retested with HEAD of CVS. Still has the same problem
Created attachment 106492 [details] [review] Patch to fix (pcm) audio stream header * Fix audio stream header rate field in case of raw audio. With this patch, the result of the pipeline given above plays well on gstreamer, ffplay, mplayer, xine (and I'll just assume WMP, which I can't test ;) )
Works relatively well. Audio and video are now in sync but after several seconds audio still start giving ticks on my system. On Media Player stream works fine. This patch is definitely an improvement over the previous situation. I would like to get this patch into the main code, but keep the bug open for further improvement.
(In reply to comment #3) I have had another look at this: - according to MS AVI specs (which are pretty clear for PCM at least), all stream header fields etc are as they should be (when patched at least). And it would seem that WMP concurs (mentioned above). - still plays OK for me in various cases as indicated above, except that in some cases only ffplay is indeed a bit ticky (which I pretty much attribute to ffplay) So, is there still a problem ? with sync in particular ? for what players ? Is only ffplay generating ticks ? for an avimux generated AVI ? (as opposed to other files) ?
Hi Mark, If you say that the headers are according to standard, then I am happy to close the bug.... but the ticking still bothers me a bit. As I am not really an avimux expert... could it have something to do with interleaving of audio and video?? Just guessing here. I noticed (remembering by heart) that the ticking only starts after a few 10's of seconds which may be symptomatic for a skew in both streams that increases over time and only becomes a problem when it has built over a certain buffer size. Something like this wouldn't show up in the headers would it? Best regards, Ruud
A player could get into (undefined) trouble if video and audio data would be badly interleaved, which is evidently not defined or determined by the header itself. However, interleaving is also just fine in avimux output. More testing (including longer samples) shows only ffplay sometimes glitches (ticks) minutely on the (not-so-realistic) audiotestsrc generated audio. As such, unless other (overwhelming) input/results, I'll be closing this soon.
OK, thanks for the feedback
Created attachment 111113 [details] [review] Patch to fix (pcm) audio stream header 2008-05-18 Mark Nauwelaerts <mnauw@users.sf.net> * gst/avi/gstavimux.c: (gst_avi_mux_audsink_set_caps): Set proper rate in avi stream header for PCM audio, and also do some more sanity checks on caps in this case. Fixes #511489.
Created attachment 111278 [details] avimuxer combination test python script small testscript to try various combinations. Useful when enabling more. On the audio side alaw/mulaw could be added to avimux.
Just added alaw/mulaw too, so ignore it