Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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. > > ... [show rest of quote] _______________________________________________
gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
55 posts
|
> 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, > Cheers _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 > ... [show rest of quote] 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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 ... [show rest of quote] _______________________________________________
gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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. > > ... [show rest of quote] _______________________________________________
gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 ... [show rest of quote] _______________________________________________
gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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. > > ... [show rest of quote] _______________________________________________
gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 ... [show rest of quote] _______________________________________________
gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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 |
Free forum by Nabble | Disable Popup Ads | Edit this page |