Hang when playing MPEG TS from disk with buffering

[Tvrtko Ursulin]

Hi all,

I am seeing a reproducible hang where gst-launch pauses the pipeline and
starts buffering never to get out of that state.

Test command is:
gst-launch-0.10 -v playbin2 uri=file:///home/storage/bbc-end2.ts flags=0x103
audio-sink=alsasink

It only happens when buffering (0x100 in flags to playbin2) is turned on. (What
does that option exactly do? In case of MPEG TS?)

It happens most of the time but not always - I suspect it is timing related so
some sort of a race condition. Because I was seeing it 100% of the time at
first and it went away when I turned on verbose debug to console. Redirecting
that to a file and hang was there again.

I am attaching stdout log, while compressed debug output is 2Mb so I can email
it on request.

It is also probably content related and smallest transport stream which
reproduces is 9Mb. Again, if someone would like to have a look I can email it
or something.

Any hints on how to try and debug this are appreciated.

Software used:
gstreamer-tools-0.10.34-1.fc15.i686
gstreamer-plugins-good-0.10.29-1.fc15.i686
gstreamer-0.10.34-1.fc15.i686
gstreamer-plugins-base-0.10.33-92.fc15.i686
gstreamer-plugins-bad-free-0.10.22-1.fc15.i686
gstreamer-python-0.10.19-2.fc15.i686
gstreamer-plugins-ugly-0.10.18-1.fc15.i686

Thanks,

Tvrtko

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tvrtko Ursulin]

On Thursday 28 Jul 2011 09:23:29 Tvrtko Ursulin wrote:

> Hi all,
>
> I am seeing a reproducible hang where gst-launch pauses the pipeline and
> starts buffering never to get out of that state.
>
> Test command is:
> gst-launch-0.10 -v playbin2 uri=file:///home/storage/bbc-end2.ts
> flags=0x103 audio-sink=alsasink
>
> It only happens when buffering (0x100 in flags to playbin2) is turned on.
> (What does that option exactly do? In case of MPEG TS?)

I have now looked at back traces of all gst-launch threads (attached). But
since I am quite new here I am not quite there yet to untangle and make sense
of it all.

It looks a lot of interesting threads are blocking in synchronization
primitives - which would indeed suggest a race condition.

Demuxer is sitting in gst_data_queue_push, two threads in gst_queue_chain and
another two in gst_base_sink_wait_preroll.

If a GStreamer expert could have a look and maybe figure out who is waiting on
who here that would be great!

Many thanks,

Tvrtko

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel