Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Thu Dec 6 04:01:40 PST 2012 

On Thu, Dec 6, 2012 at 3:39 PM, Federico Zamperini
<fzamperini at tiscali.it> wrote:
> My suggestion is to log every message you see on the bus
> (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstMessage.html#GstMessageType,
> GST_MESSAGE_ERROR and GST_MESSAGE_WARNING might be very interesting ...),
> not just GST_MESSAGE_STATE_CHANGED messages.

I'm was already doing that. Apart from looking for
GST_MESSAGE_STATE_CHANGED on the bus, I'm also looking for
GST_MESSAGE_STREAM_STATUS, GST_MESSAGE_WARNING & GST_MESSAGE_ERROR.

> Before that you could do a run with a high debug level
> (http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-checklist-debug.html),
> for example

I did that. I'm setting GST_DEBUG=*:3

The debugs show that all elements are transitioning through the
various states and the application is also seeing the same via
messages on the bus.

BUT, in the scenario where I'm going from PLAYING->NULL, I see the
element debugs indicating transition from PLAYING to NULL state, but
no message appears on the bus!!! How can this happen? Won't the same
transitions be put on the bus as well?

Now if I set the pipeline to PLAYING again, the transitions happen and
messages start reappearing on the bus. But after 1-2 secs of playback
the video output simply freezes and there's nothing in the debugs to
indicate an error. For the application, everything looks hunky-dory!
:/

Thanks,
-mandeep

>
> myapp --gst-debug-level=4
>
> (4 is DEBUG, 3 is INFO, 2 is WARNING etc); beware: the output with level 4
> is huge.
>
> Il 06/12/2012 07:20, Mandeep Sandhu ha scritto:
>
>> On Wed, Dec 5, 2012 at 7:11 PM, Federico Zamperini
>> <fzamperini at tiscali.it> wrote:
>>>
>>> Did you wait for the pipeline to reach the NULL state before setting it
>>> again to the PLAYING state?
>>
>>
>> No, I did not do that. Though I was sending the PLAY after quite some
>> time ~10 secs (it's sent on a button click, which I purposefully
>> waited on before clicking).
>>
>> I've now added code to look for stat change messages on the bus. I see
>> that on setting the state of the pipeline to NULL, even though the
>> video stops (blank screen), I don't see any state change messages on
>> the bus for PLAYING to NULL state transition. All these messages come
>> when changing state from NULL to PLAYING
>> (NULL->READY->PAUSED->PLAYING), but the reverse is not happening.
>>
>> I just see the following message when setting state to NULL (from
>> PLAYING):
>> ...
>> ...ismd_unlink_function:<Audio decoder:src_1> failed to detach from port
>> 2162695
>> ...
>>
>> I'm not sure if this is causing the state change to fail. This might
>> be a problem with the proprietary audio decoder gst plugin.
>>
>> Any other suggestions to narrow down this issue further?
>>
>> Thanks for your time.
>>
>> Regards,
>> -mandeep
>>
>>
>>> (BTW you know that a pipeline reached the NULL state by observing the
>>> messages on the bus)
>>>
>>> Il 05/12/2012 14:23, Mandeep Sandhu ha scritto:
>>>
>>>>> When you go to the NULL state the pipeline is flushed and all the
>>>>> resources
>>>>> are freed, so next time you start the pipeline (moving it to the
>>>>> PLAYING
>>>>> state) you don't need to seek back to the beginning of the stream.
>>>>
>>>>
>>>>
>>>> My first attempt was to set the NULL state on the pipeline! :)
>>>>
>>>> But I soon ran into a problem with that, where if the pipeline is set
>>>> to the NULL state from the PLAYING state, then subsequently setting
>>>> the pipeline to PLAYING state used to cause the playback to stop after
>>>> 1-2 secs!! There's no error emitted on the bus. Rather my application
>>>> doesn't see any error at all. Once this problem occurs, the only way
>>>> to recover is to destroy the pipeline and re-create it. This could
>>>> possibly be a bug in the vendor provided gst plugins (video
>>>> decoder/sink).
>>>>
>>>> Also, from an API point of view, the STOP command doesn't change
>>>> already parsed params of a media like duration, type of container
>>>> detected etc as a user expects this info to be retained and the
>>>> playback to start ASAP. A user cannot change the media without first
>>>> CLOSE-ing the player.
>>>>
>>>> So I thought setting state to NULL was more appropriate for a CLOSE
>>>> like operation and STOP should have a easier/faster way of resuming
>>>> playback once given the play command.
>>>>
>>>> Regards,
>>>> -mandeep
>>>>
>>>>
>>>>> Cheers
>>>>>
>>>>> Federico
>>>>>
>>>>> Il 04/12/2012 12:30, Mandeep Sandhu ha scritto:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I'm implementing a media player on an embedded board. I'm using
>>>>>> Gstreamer for the actual media playback (the chip vendor provides us
>>>>>> with some proprietary plugins for H264/AAC decoding and audio/video
>>>>>> sinks for the specific hardware).
>>>>>>
>>>>>> Currently I'm concentrating on just playing MP4/H264/AAC files (other
>>>>>> formats will be supported later when I figure out how to do
>>>>>> auto-detection! :))
>>>>>>
>>>>>> My gst pipeline essentially looks like this:
>>>>>>
>>>>>> file-source -> qtdemux -> h264dec -> vsink
>>>>>>                            |
>>>>>>                            +-----> aacdec -> asink
>>>>>>
>>>>>>
>>>>>> So, I have most of the bits worked out, except what state to set on
>>>>>> the pipeline when I'm in the STOPPED state of my player (eg: a user
>>>>>> pressed the STOP button on the player or the stream ended (EOS)).
>>>>>>
>>>>>> Initially I thought setting the pipeline to READY state would do it
>>>>>> but that turned out to be wrong. Reading docs on GST_MESSAGE_EOS
>>>>>> revealed that the EOS event is retained in the elements and has to be
>>>>>> flushed explicitly.
>>>>>>
>>>>>> I have the state of my player being tracked by state machine, so the
>>>>>> SM transitions to the STOPPED state on either an explicit command (by
>>>>>> the user) or when the EOS message appears on the pipeline's bus.
>>>>>>
>>>>>> So I wrote some code to flush the pipeline and then set it to the
>>>>>> PAUSED state (since I don't want playback to start automatically).
>>>>>> Here's what I do when going into the STOPPED state:
>>>>>>
>>>>>> gst_element_seek(m_pipeline, 1.0, GST_FORMAT_TIME,
>>>>>>                         GST_SEEK_FLAG_FLUSH, GST_SEEK_TYPE_SET,
>>>>>>                         0, GST_SEEK_TYPE_NONE,  0);
>>>>>> gst_element_set_state (m_pipeline, GST_STATE_PAUSED);
>>>>>>
>>>>>> Is this correct way to handle the scenario described or is there a
>>>>>> better/recommended way of going about it?
>>>>>>
>>>>>> I basically want the stream playback position to be set to the start
>>>>>> so that a play command will cause it to play the file from the
>>>>>> beginning.
>>>>>>
>>>>>> Any pointers appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>> -mandeep
>>>>>> _______________________________________________
>>>>>> gstreamer-devel mailing list
>>>>>> gstreamer-devel at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> Nessun virus nel messaggio.
>>>>>> Controllato da AVG - www.avg.com
>>>>>> Versione: 2013.0.2793 / Database dei virus: 2629/5906 -  Data di
>>>>>> rilascio:
>>>>>> 19/11/2012
>>>>>> Database dei virus interno non c aggiornato.
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> gstreamer-devel mailing list
>>>>> gstreamer-devel at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>> -----
>>>> Nessun virus nel messaggio.
>>>> Controllato da AVG - www.avg.com
>>>> Versione: 2013.0.2793 / Database dei virus: 2629/5906 -  Data di
>>>> rilascio:
>>>> 19/11/2012
>>>> Database dei virus interno non c aggiornato.
>>>>
>>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG - www.avg.com
>> Versione: 2013.0.2793 / Database dei virus: 2629/5906 -  Data di rilascio:
>> 19/11/2012
>> Database dei virus interno non c aggiornato.
>>
>>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

More information about the gstreamer-devel mailing list