After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745684 - directsoundsink: 11025Hz audio playback hangs at the end (no EOS message)
directsoundsink: 11025Hz audio playback hangs at the end (no EOS message)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.4.5
Other Windows
: Normal normal
: 1.4.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 745677 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-05 15:16 UTC by Nikos Chantziaras
Modified: 2015-03-06 18:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GST_DEBUG=*:6 log (376.81 KB, application/x-bzip)
2015-03-05 15:43 UTC, Nikos Chantziaras
  Details
GST_DEBUG=*:6 log (799.90 KB, application/x-bzip)
2015-03-05 16:48 UTC, Nikos Chantziaras
  Details
11.025kHz WAV sample (41.84 KB, audio/wav)
2015-03-05 20:01 UTC, Nikos Chantziaras
  Details
directsoundsink: fix modulo math with ringbuffer parameters (1.37 KB, patch)
2015-03-05 20:57 UTC, Thiago Sousa Santos
committed Details | Review

Description Nikos Chantziaras 2015-03-05 15:16:12 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.
Comment 1 Tim-Philipp Müller 2015-03-05 15:19:21 UTC
*** Bug 745677 has been marked as a duplicate of this bug. ***
Comment 2 Tim-Philipp Müller 2015-03-05 15:20:44 UTC
Perhaps you could create a GST_DEBUG=*:6 log, zip it and attach it? Just abort with control-C once it finished playing.
Comment 3 Nikos Chantziaras 2015-03-05 15:43:37 UTC
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
Comment 4 Nikos Chantziaras 2015-03-05 16:11:09 UTC
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.
Comment 5 Nicola 2015-03-05 16:29:38 UTC
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
Comment 6 Nikos Chantziaras 2015-03-05 16:48:51 UTC
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.
Comment 7 Thiago Sousa Santos 2015-03-05 18:38:27 UTC
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.
Comment 8 Thiago Sousa Santos 2015-03-05 19:44:41 UTC
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.
Comment 9 Nikos Chantziaras 2015-03-05 20:01:29 UTC
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.
Comment 10 Thiago Sousa Santos 2015-03-05 20:57:12 UTC
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
Comment 11 Nikos Chantziaras 2015-03-05 21:15:05 UTC
Thank you, Thiago. I applied the patch on top of gst-plugins-good 1.4.5 and it fixed the issue for me.
Comment 12 Nicolas Dufresne (ndufresne) 2015-03-05 22:55:16 UTC
Test on git master too, works.
Comment 13 Thiago Sousa Santos 2015-03-06 18:03:23 UTC
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