stuck pipeline

[Gary Thomas]

On 2013-02-18 08:27, Gary Thomas wrote:
> On 2013-02-18 08:16, Tim-Philipp Müller wrote:
>> On Mon, 2013-02-18 at 08:05 -0700, Gary Thomas wrote:
>>
>>> I'm trying to write a pipeline which is equivalent to 'playbin2'
>>> to display an MP4 file (H.264+MP3) on my X based display.  I'm doing
>>> this to provide finer control over the result, e.g. choice of H.264
>>> decoder, etc.
>>
>> What's the "etc." ?
>>
>> If you prefer a certain h264 decoder, why not just give it a higher rank
>> than the others (you can do that in your application, fwiw, though not
>> with gst-launch, unless you change the decoder's source code)?
>
> Eventually this may be useful but for now I just wanted a simple test
> using gst-launch.  I was hoping that the pipeline I wrote was more or
> less equivalent to using playbin2.
>
>>
>>> I tried this pipeline:
>>>     gst-launch -v filesrc location=/dcim/Camera/2013-02-18_12-35-40.mp4 ! qtdemux name=demux \
>>>       demux. ! queue ! h264parse ! ffdec_h264 ! ffmpegcolorspace ! autovideosink \
>>>       demux. ! queue ! mpegaudioparse ! ffdec_mp3 ! audioconvert ! pulsesink
>>>
>>> Which starts out happy - it brings up a window with the image, but then
>>> it just gets stuck.  There is no indication or error why.
>>
>> You also want a videoscale in front of the videosink in case your sink
>> can't scale (like ximagesink). But that's not the reason if it comes up
>> in the first place.
>
> Good to know but as you say if it gets started that's not the issue.
>
>>
>>> I then tried the [arguably] simpler pipeline and it also gets stuck:
>>>     gst-launch -v filesrc location=/dcim/Camera/2013-02-18_12-35-40.mp4 ! qtdemux name=demux \
>>>       demux. ! queue ! h264parse ! filesink location=/tmp/junk.h264 \
>>>       demux. ! queue ! mpegaudioparse ! filesink location=/tmp/junk.wav
>>>
>>> Any ideas why this is happening?  Where should I look?
>>
>> If you just want some sink for testing, you can use fakesink.
>>
>> The reason it stalls might be that the queues are too small. Either make
>> them larger by increasing the max-size-* limits, or use a multiqueue.
>
> My files are *tiny* (less than 500KB) just for testing so I don't see
> how the size of the queue could make a difference.  I did try multiqueue
> and the results are the same.
>
>>
>> Btw, uridecodebin/decodebin2 also give you a way to influence the
>> plugging of parsers/decoders/etc. via the autoplug-* signals, so you can
>> pick/prefer certain decoders there if you like.
>

A little more experimentation shows that the problem has to do with
the mpegaudioparse element.  I tried building my pipeline by bits and
once I added that element, it froze, even though I had it split into
separate (threads?) using queue elements.

This is odd because I have another program, not using gst-launch, that
creates this pipeline and it works (the difference being that the source
is via RTSP, not a raw file):
   rtspsrc location=rtsp://192.168.1.136:8554/test name=src \
       src. ! queue ! rtph264depay ! h264parse ! ffdec_h264 ! xvimagesink \
       src. ! queue ! rtpmpadepay ! mpegaudioparse ! flump3dec ! audioconvert ! pulsesink

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------