Implementing a media player using Gstreamer: Mapping the STOPPED state

Federico Zamperini fzamperini at tiscali.it
Wed Dec 5 05:41:01 PST 2012


Did you wait for the pipeline to reach the NULL state before setting it 
again to the PLAYING state?
(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.
>
>


More information about the gstreamer-devel mailing list