Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu mandeepsandhu.chd at gmail.com
Wed Dec 5 22:20:25 PST 2012


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


More information about the gstreamer-devel mailing list