GNOME Bugzilla – Bug 745684
directsoundsink: 11025Hz audio playback hangs at the end (no EOS message)
Last modified: 2015-03-06 18:22:42 UTC
I've stumbled across a bug on Windows (on Linux it works just fine) with GStreamer 1.4.5. When a specific video file plays, a GST_MESSAGE_EOS is never sent by the pipeline (playbin). As a result, the application is waiting forever for the video to finish playing. The video file that triggers the problem: http://83.212.107.13/~realnc/misc/gstreamer_no_eos.avi In my case, the video decoding is handled by gst-libav, but even with that plugin missing (gstreamer-1.0-x86-1.4.5.msi doesn't ship it, for example), the bug is still reproducible. Running: gst-launch-1.0.exe playbin uri="file:///path_to/gstreamer_no_eos.avi" will only play audio (and the audio playback is broken compared to Linux, but that's material for another bug report I guess). But it will still hang at the end. For me, the problem is reproducible in all the below environments: Windows 7 x64 Windows 8.1 x64 Wine under Linux Again: This only happens with the Windows version of GStreamer. Linux (also GStreamer 1.4.5) plays it correctly. I do not know if the data streams inside the AVI file are wrong/bad/corrupted or not. I assume that even with a broken data stream, GStreamer should be able to either recover or abort instead of getting stuck indefinitely.
*** Bug 745677 has been marked as a duplicate of this bug. ***
Perhaps you could create a GST_DEBUG=*:6 log, zip it and attach it? Just abort with control-C once it finished playing.
Created attachment 298648 [details] GST_DEBUG=*:6 log OK. Attaching the output of: gst-launch-1.0.exe playbin uri="file:///video.avi" > debug_log.txt 2>&1
I forgot to note: Letting this run produces more and more debug output. It never ends. I aborted a few seconds after the sound stopped playing.
I can reproduce on windows too the problem is related to the audio: 1) a pipeline that play only video works fine and eos is received 2) this pipeline never get eos filesrc location=... ! avidemux name=d d.audio_0 ! decodebin ! autoaudiosink this one receive eos: filesrc location=... ! avidemux name=d d.audio_0 ! decodebin ! fakesink so probably something wrong in autoaudiosink (directsoundsink) P.S. you can rerun the msi installer and select libav, is deselected as default option
Created attachment 298652 [details] GST_DEBUG=*:6 log I did a complete install with all components. A video window now pops up and the video plays in it. It still hangs at the end. Attaching new log file.
It seems when the audiosink gets the first buffer it never finishes rendering it. It all starts here: 0:00:05.504562200 1732 0BEBD848 DEBUG audiobasesink gstaudiobasesink.c:1690:gst_audio_base_sink_render:<audiosink-actual-sink-directsound> And then you just follow the thread to see it hanging on it forever in some busy loop.
ringbuffer gstaudioringbuffer.c:1571:default_commit: copy 442 bytes while the format is S16LE, 2 channels. So the bytes per frame is 4. 442 / 4 = 110.5 (oops) So we are writing 442 bytes, which means 110 frames and a half. And then we rely on; in_samples -= towrite / bpf; out_samples -= towrite / bpf; Which will decrease only the 110 samples and ignore that that half sample was also there. In the end the math doesn't add up and we have 0 bytes to copy while in_samples/out_samples haven't reached 0 yet, so we loop again and again.
Created attachment 298659 [details] 11.025kHz WAV sample Yes, it seems all 11025Hz audio exhibits the problem due to the math not working out. I'm attaching a small sample file that triggers it for future reference: gst-launch-1.0.exe playbin uri=file:///problem_sample.wav will hang. No need to use the previously linked video file.
Created attachment 298663 [details] [review] directsoundsink: fix modulo math with ringbuffer parameters This likely fixes the issue. Can someone with a windows box confirm? Thanks
Thank you, Thiago. I applied the patch on top of gst-plugins-good 1.4.5 and it fixed the issue for me.
Test on git master too, works.
Thanks for the tests. Pushed. 1.4: commit 7833fafbdd48bb8a75dfe78caaf8950eeeb933b7 Master: commit c194f2de1206ebd41b3d7b8b2f4902c48dc5ebb8 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Thu Mar 5 17:54:43 2015 -0300 directsoundsink: fix modulo math with ringbuffer parameters To get a multiple of bpf use a subtraction and not an addition https://bugzilla.gnome.org/show_bug.cgi?id=745684