Implementing a media player using Gstreamer: Mapping the STOPPED state

[Mandeep Sandhu]

> 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