Implementing a media player using Gstreamer: Mapping the STOPPED state

Thu Dec 6 02:09:13 PST 2012

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.
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

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.
>
>