Unable to change state GST_STATE_PLAYING

[amitchawla]

Hi,

I am using the following pipeline, where I am reading from the network

"tcpserversrc blocksize=4194304 host=192.168.100.58 port=3000 !
 decodebin async-handling=true name=demux !
 autoaudiosink async-handling=true demux. !
 imxeglvivsink async=false"

I need to restart the pipeline, when new data is coming through the network.
The initial state is that, the above pipeline is playing normally -- the pipeline is in GST_STATE_PLAYING.

then, I do the following operations : -

     set_pipeline_state(GST_STATE_PAUSED);
     set_pipeline_state(GST_STATE_READY);
     set_pipeline_state(GST_STATE_NULL);
     --- enable_fresh_data_from_network --- ;
     set_pipeline_state(GST_STATE_READY) ;
     set_pipeline_state(GST_STATE_PAUSED) ;
     set_pipeline_state(GST_STATE_PLAYING) ;

It goes to GST_STATE_NULL normally.
But I notice that the pipeline state never changes to GST_STATE_PLAYING from GST_STATE_PAUSED. It is stuck at GST_STATE_PAUSED.
The status of the operation returns  GST_STATE_CHANGE_ASYNC always. I have used gst_element_get_state but it always returns GST_STATE_CHANGE_ASYNC.

I enabled GST_STATES debug output. The log output shows all the elements moving to GST_STATE_PLAYING eventually but the, the stream doesn't start playing.

But when I tried to grab the bus messages, I noticed that I don't get state change message to PLAYING on the bus, I only get state change message upto PAUSED.  
 
I would be very thankful, if anyone could provide some explanation.

regards
Amit





 

[amitchawla]

Hi,

Please waiting for some help....

Thanks

[Arun Raghavan-4]

On Tue, 31 May 2016, at 04:32 PM, amitchawla wrote:

> Hi,
>
> I am using the following pipeline, where I am reading from the network
>
> "tcpserversrc blocksize=4194304 host=192.168.100.58 port=3000 !
>  decodebin async-handling=true name=demux !
>  autoaudiosink async-handling=true demux. !
>  imxeglvivsink async=false"
>
> I need to restart the pipeline, when new data is coming through the
> network.
> The initial state is that, the above pipeline is playing normally -- the
> pipeline is in GST_STATE_PLAYING.
>
> then, I do the following operations : -
>
>      set_pipeline_state(GST_STATE_PAUSED);
>      set_pipeline_state(GST_STATE_READY);
>      set_pipeline_state(GST_STATE_NULL);
>      --- enable_fresh_data_from_network --- ;
>      set_pipeline_state(GST_STATE_READY) ;
>      set_pipeline_state(GST_STATE_PAUSED) ;
>      set_pipeline_state(GST_STATE_PLAYING) ;

You don't need to set each intermediate state. Setting the state from X
to Y makes sure that the pipeline goes through all the intermediate
states.

> It goes to GST_STATE_NULL normally.
> But I notice that the pipeline state never changes to GST_STATE_PLAYING
> from
> GST_STATE_PAUSED. It is stuck at GST_STATE_PAUSED.
> The status of the operation returns  GST_STATE_CHANGE_ASYNC always. I
> have
> used gst_element_get_state but it always returns GST_STATE_CHANGE_ASYNC.
>
> I enabled GST_STATES debug output. The log output shows all the elements
> moving to GST_STATE_PLAYING eventually but the, the stream doesn't start
> playing.
>
> But when I tried to grab the bus messages, I noticed that I don't get
> state
> change message to PLAYING on the bus, I only get state change message
> upto
> PAUSED.  

This suggests that a sink is waiting for some data to arrive from the
source, and this never happens.

-- Arun
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[amitchawla]

Hi,

Thanks for your answer.

  tcpserversrc blocksize=4194304 host=192.168.100.58 port=3000 !  

  decodebin async-handling=true name=demux !

  autoaudiosink async-handling=true demux. !

  imxeglvivsink async=true

 I do the following operations : -
 
        set_pipeline_state(GST_STATE_PAUSED);
       set_pipeline_state(GST_STATE_READY);
       set_pipeline_state(GST_STATE_NULL);
       --- enable_fresh_data_from_network --- ;
       set_pipeline_state(GST_STATE_READY) ;
       set_pipeline_state(GST_STATE_PAUSED) ;
       set_pipeline_state(GST_STATE_PLAYING) ;

I also notice that when I move from GST_STATE_NULL -> GST_STATE_PLAYING .....

I do not get the GST_MESSAGE_ASYNC_DONE on the bus, which means the pipeline in not getting pre rolled..... the data is not reaching the sinks .... the audio sink or the video sink .  

In case of the above pipeline -- after setting to GST_STATE_NULL .... before setting to GST_STATE_PLAYING ... do I need to do something to the pads....? or does it take care by itself.

Why is the pipeline not pre-rolling ? Actually from debug outputs... I notice that the decodebin is working and I can see video decoder logs..... but after putting logs in the eglvivsink (video sink) .... I see that it does receive the GST_STATE_CHANGE_PAUSED_TO_PLAYING command .... even when I am setting the pipeline to GST_STATE_PLAYING. ... .. ?

Thanks a lot for shedding some light on the above problem.

Thanks and Regards
Amit

[amitchawla]

Hi,

Can anybody please let me know, what type of state change should I use in case my pipeline mentioned above.... synchronous or asynchronous . Should the async option of decodebin, autoaudiosink and imxeglvivsink be true or false ?

Please put some light on the problem mentioned above.

Thanks
Amit

[amitchawla]

Hi

I have discovered that when I restart the pipeline, the source pads of the demux (decodebin) , do not get linked. From the GST_PADS debug messages, it is appearing that ,
 
During the initial normal playing of the pipeline (from gst_parse_launch ), decodebin src_0 and src_1 pads are connected to imxeglvivsink and autoaudiosink , but after I restart the pipeline....
 
GST_STATE_READY -> GST_STATE_PAUSE , the debug messages from GST_PADS show that decodebin is attempting to send events and messages on decodebin source pads src_2 and src_3 , which were obviously not linked initially... that is why it is getting "not linked" debug messages.

it is a possible bug in decodebin, or do I have to do something else to reconnect to src_0 and src_1 pads ?

Amit

[Thornton, Keith]

Hi,
it does not re-use src_0 and src_1 until it has cycled through the possibilities. The next pads used are src_2 and src_3. ... When you know this, you can use this information when reconnecting. I don't think it is a bug.

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von amitchawla
Gesendet: Freitag, 3. Juni 2016 11:07
An: [hidden email]
Betreff: Re: Unable to change state GST_STATE_PLAYING - possible bug in decodebin ?

Hi

I have discovered that when I restart the pipeline, the source pads of the demux (decodebin) , do not get linked. From the GST_PADS debug messages, it is appearing that ,
 
During the initial normal playing of the pipeline (from gst_parse_launch ), decodebin src_0 and src_1 pads are connected to imxeglvivsink and autoaudiosink , but after I restart the pipeline....
 
GST_STATE_READY -> GST_STATE_PAUSE , the debug messages from GST_PADS show that decodebin is attempting to send events and messages on decodebin source pads src_2 and src_3 , which were obviously not linked initially... that is why it is getting "not linked" debug messages.

it is a possible bug in decodebin, or do I have to do something else to reconnect to src_0 and src_1 pads ?

Amit





--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Unable-to-change-state-GST-STATE-PLAYING-tp4677811p4677874.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[amitchawla]

Thanks Keith for your reply.

Could you please just suggest, what do I have to do so that , decodebin reuses the previously made pad links i.e. src_0 and src_1  ?

Thanks for your help.

Amit

[Thornton, Keith]

Hi,
I'm afraid I can't help here, Maybe Tim or Sebastian. I don't use the bins, I have fixed self built pipelines

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von amitchawla
Gesendet: Freitag, 3. Juni 2016 13:38
An: [hidden email]
Betreff: Re: AW: Unable to change state GST_STATE_PLAYING - possible bug in decodebin ?

Thanks Keith for your reply.

Could you please just suggest, what do I have to do so that , decodebin reuses the previously made pad links i.e. src_0 and src_1  ?

Thanks for your help.

Amit



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Unable-to-change-state-GST-STATE-PLAYING-tp4677811p4677879.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[amitchawla]

Hi Sebastian,

Could you please help me with above problem ?

Thanks
Amit

[Arun Raghavan-4]

On Fri, 3 Jun 2016, at 10:28 AM, amitchawla wrote:
> Hi,
>
> Can anybody please let me know, what type of state change should I use in
> case my pipeline mentioned above.... synchronous or asynchronous . Should
> the async option of decodebin, autoaudiosink and imxeglvivsink be true or
> false ?
>
> Please put some light on the problem mentioned above.

It looks like your audio sync is likely still waiting for a buffer. You
probably want some queues to split up the audio and video streams into
separate threads (and maybe set up your audio sink to also do
async=false, by using the actual audio sink instead of autoaudiosink).

-- Arun
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[amitchawla]

Hi Arun, Sebastian

I have tried async=false and also using separate queues. From the GST_PADS debug messages, for now it seems that, after I restart the pipeline (GST_STATE_READY->GST_STATE_PAUSE) decodebin is trying to send events through source pads src_2 and src_3, which were not connected, as the GST_PADS logs show that initially src_0 and src_1 were used.

I am using fixed pipeline as a string description to pass to gst_parse_launch, and when I restart the pipeline I see messages that decodebin pads are not linked ... such as decodebin is unable to send caps as it says "src_2 not linked" , "src_3 not linked".

Could you please provide some guidance?

Thanks and Regards
Amit

 

[Sebastian Dröge-3]

On So, 2016-06-05 at 20:58 -0700, amitchawla wrote:

> Hi Arun, Sebastian
>
> I have tried async=false and also using separate queues. From the
> GST_PADS
> debug messages, for now it seems that, after I restart the pipeline
> (GST_STATE_READY->GST_STATE_PAUSE) decodebin is trying to send events
> through source pads src_2 and src_3, which were not connected, as the
> GST_PADS logs show that initially src_0 and src_1 were used.
>
> I am using fixed pipeline as a string description to pass to
> gst_parse_launch, and when I restart the pipeline I see messages that
> decodebin pads are not linked ... such as decodebin is unable to send
> caps
> as it says "src_2 not linked" , "src_3 not linked".
>
> Could you please provide some guidance?

Please provide a runnable, as simple as possible testcase for your
problem.

If the problem is that pads are not linked, check the code where you
expect them to be linked. Check if linking actually succeeds or if it
fails for some reason (which?).

If all is linked and the pipeline just does not preroll, check up to
which point in the pipeline data is flowing. Which sinks do not receive
data, where does it get stuck?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel