Login  Register

Implementing a media player using Gstreamer: Mapping the STOPPED state

classic Classic list List threaded Threaded
15 messages Options Options
Embed post
Permalink
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Federico Zamperini
52 posts
Hi,
        when I want to stop a pipeline I set it to the NULL state (see
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-elements-states.html).
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.
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
> [hidden email]
> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Tim-Philipp Müller-2
1762 posts
In reply to this post by Mandeep Sandhu
On Tue, 2012-12-04 at 17:00 +0530, Mandeep Sandhu wrote:

> 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! :))

Just to make sure: you are aware of uridecodebin / playbin(2), right?

Cheers
 -Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts


On Dec 4, 2012 7:20 PM, "Tim-Philipp Müller" <[hidden email]> wrote:
>
> On Tue, 2012-12-04 at 17:00 +0530, Mandeep Sandhu wrote:

>
> Just to make sure: you are aware of uridecodebin / playbin(2), right?
>

Yes I am! :-)  its just that these bins were failing to pickup the correct vendor provided elements for decoding and sinks. The vendor plugins reside in a non-std path which I HV added to GST_PLUGIN_PATH env var. Though for some reason these readymade bins are not picking up the custom elements (I also want to mention that there are no conflicting elements in my setup, which might cause the wrong plugin to get picked up).

Though I'll try this approach again and get back here with my findings.

Thanks,
-mandeep

> Cheers
>  -Tim
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Carlos Rafael Giani
181 posts
On 2012-12-04 17:27, Mandeep Sandhu wrote:

>
> On Dec 4, 2012 7:20 PM, "Tim-Philipp Müller" <[hidden email]
> <mailto:[hidden email]>> wrote:
>  >
>  > On Tue, 2012-12-04 at 17:00 +0530, Mandeep Sandhu wrote:
>
>  >
>  > Just to make sure: you are aware of uridecodebin / playbin(2), right?
>  >
>
> Yes I am! :-)  its just that these bins were failing to pickup the
> correct vendor provided elements for decoding and sinks. The vendor
> plugins reside in a non-std path which I HV added to GST_PLUGIN_PATH env
> var. Though for some reason these readymade bins are not picking up the
> custom elements (I also want to mention that there are no conflicting
> elements in my setup, which might cause the wrong plugin to get picked up).
>
> Though I'll try this approach again and get back here with my findings.
>
> Thanks,
> -mandeep
>

Autoplugging will ignore elements whose rank is below marginal (64).
Perhaps they use zero as rank?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
>> Though I'll try this approach again and get back here with my findings.
>>
>> Thanks,
>> -mandeep
>>
>
> Autoplugging will ignore elements whose rank is below marginal (64). Perhaps
> they use zero as rank?

Hmmm...ranks is new to me! Is this a 1.0 concept or did it exist in
0.10 as well? I'm using gst 0.10.36 on my setup.

-mandeep

>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
In reply to this post by Mandeep Sandhu
> Though I'll try this approach again and get back here with my findings.

So here's what happens when I try to use 'uridecodebin' for playing an
MP4 file (I'm ignoring audio decoding to keep things simple for
explaining):

# gst-launch-0.10 uridecodebin uri=file:///videos/video.mp4 name=dec !
ismd_vidsink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPipeline:pipeline0/GstURIDecodeBin:dec: No
decoder available for type 'video/x-decoded-ismd'.
...
ERROR: from element
/GstPipeline:pipeline0/GstURIDecodeBin:dec/GstDecodeBin2:decodebin20:
Your GStreamer installation is missing a plug-in.
...
no suitable plugins found
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
#

But if I run gst-inspect on the proprietary plugin - ismd_vidsink, it
shows that the sink pad supports this capability:

# gst-inspect-0.10 ismd_vidsink
...
...
Pad Templates:
  SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/x-decoded-ismd
      video/x-raw-yuv
                 format: { NV12 }
                  width: [ 16, 1920 ]
                 height: [ 16, 1088 ]
      video/x-raw-yuv
                 format: { YV12, I420 }
                  width: [ 16, 1920 ]
                 height: [ 16, 1088 ]

...
...
#

So whats preventing it from getting picked up by the uridecodebin ? Is
there some sort of 'registration' required for these proprietary
plugins?

Thanks,
-mandeep


>
> Thanks,
> -mandeep
>
>> Cheers
>>  -Tim
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
>
> So whats preventing it from getting picked up by the uridecodebin ? Is
> there some sort of 'registration' required for these proprietary
> plugins?

I think I _might_ have figured this out.

If I just run gst-instpect-0.10, it dumps all the available
plugins/elements. And if I go through all the 'typefindfunctions',
then there's no typefind registered for the caps type
'video/x-decoded-ismd'.

Is this the reason why playbin/uridecodebin is not able to find the
sink element to connect to?

-mandeep
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
In reply to this post by Federico Zamperini
> 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
>> [hidden email]
>> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Federico Zamperini
52 posts
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
>>> [hidden email]
>>> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
On Wed, Dec 5, 2012 at 7:11 PM, Federico Zamperini
<[hidden email]> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Federico Zamperini
52 posts
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
> <[hidden email]> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
On Thu, Dec 6, 2012 at 3:39 PM, Federico Zamperini
<[hidden email]> 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
>> <[hidden email]> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
In reply to this post by Mandeep Sandhu
On Wed, Dec 5, 2012 at 2:16 PM, Mandeep Sandhu
<[hidden email]> wrote:
> If I just run gst-instpect-0.10, it dumps all the available
> plugins/elements. And if I go through all the 'typefindfunctions',
> then there's no typefind registered for the caps type
> 'video/x-decoded-ismd'.
>
> Is this the reason why playbin/uridecodebin is not able to find the
> sink element to connect to?

So I managed to 'partially' fix problem. Now playbin2 is able to find
my proprietary plugins and plays out the video and audio. Though
uridecodebin still fails with a missing plugin error: No decoder
available for type 'video/x-decoded-ismd'

I have a hunch as to why this was not working before (not sure if that
is indeed the case as uridecodebin still fails to work).

I'm guessing this problem was due to a stale 'registry' file. So i
decided to delete this file and recreate it by running gst-inspect.
This recreated the file and playbin2 started working. Though I have no
idea why the same did not work for uridecodebin element. Any ideas?

HTH,
-mandeep
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Implementing a media player using Gstreamer: Mapping the STOPPED state

Mandeep Sandhu
55 posts
In reply to this post by Mandeep Sandhu
On Thu, Dec 6, 2012 at 5:31 PM, Mandeep Sandhu
<[hidden email]> wrote:
> 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!

BTW, this problem is now fixed by switching to using playbin2 element.

Thanks,
-mandeep
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel