Questions on PREROLL: let 1 buffer pass the sub-pipeline to get PREROLL working

[Maurer, Marie]

Hello,

 

I have a single live video pipeline:

 

v4l2src -> caps -> tee -> queue -> v4l2sink

 

With this pipeline I can change state from NULL to PLAYING and vice versa.

 

Now I connect a sub-pipeline to the above tee, where I can create one or more still images from the live video.

Because I want only one image at a time I let only one buffer pass my sub-pipeline, every time a picture is requested.

To survive pipeline state changes, I must let pass 1 frame data packet (via a pad probe callback function),

otherwise PREROLL does not work and complete pipeline does not go to PLAYING.

 

Is this the common way to let 1 buffer pass and drop all others to get PREROLL running?

Or is there a better way?

 

What happens when I use some element (e.g. a H264 encoder), which needs multiple buffers to generate some output data?

Do I then need to let e.g. 3 buffers pass so that PREROLL is working? And if for some circumstances nothing is coming

out of the element (e.g. because I am not sure always 3 input buffers are needed to generate 1 output buffer), then everything hangs?

 

Can someone shed a bit more light on this topic?

 

Many thanks!

 

Best regards,

 

Marie

 

 

 

 

 

 

 

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

[Tim Müller]

On Tue, 2018-05-08 at 14:38 +0000, Maurer, Marie wrote:

Hi Marie,

> I have a single live video pipeline:
>  
> v4l2src -> caps -> tee -> queue -> v4l2sink
>  
> With this pipeline I can change state from NULL to PLAYING and vice
> versa.
>  
> Now I connect a sub-pipeline to the above tee, where I can create one
> or more still images from the live video.
> Because I want only one image at a time I let only one buffer pass my
> sub-pipeline, every time a picture is requested.
> To survive pipeline state changes, I must let pass 1 frame data
> packet (via a pad probe callback function),
> otherwise PREROLL does not work and complete pipeline does not go to
> PLAYING.
>  
> Is this the common way to let 1 buffer pass and drop all others to
> get PREROLL running? Or is there a better way?

You could try setting async=false on the new sink you add (not to be
confused with the "sync" property) where you don't have regular buffer
flows.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Maurer, Marie]

Hi Tim,

thanks for the answer. What does async=false change in behavior/flow of data?

What do I need to change or can save in the code? Or same as before needed?

Best regards,

Marie

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von Tim Müller
Gesendet: Dienstag, 8. Mai 2018 17:15
An: [hidden email]
Betreff: Re: Questions on PREROLL: let 1 buffer pass the sub-pipeline to get PREROLL working

On Tue, 2018-05-08 at 14:38 +0000, Maurer, Marie wrote:

Hi Marie,

> I have a single live video pipeline:
>  
> v4l2src -> caps -> tee -> queue -> v4l2sink
>  
> With this pipeline I can change state from NULL to PLAYING and vice
> versa.
>  
> Now I connect a sub-pipeline to the above tee, where I can create one
> or more still images from the live video.
> Because I want only one image at a time I let only one buffer pass my
> sub-pipeline, every time a picture is requested.
> To survive pipeline state changes, I must let pass 1 frame data packet
> (via a pad probe callback function), otherwise PREROLL does not work
> and complete pipeline does not go to PLAYING.
>  
> Is this the common way to let 1 buffer pass and drop all others to get
> PREROLL running? Or is there a better way?

You could try setting async=false on the new sink you add (not to be confused with the "sync" property) where you don't have regular buffer flows.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.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

[Tim Müller]

Hi Marie,

> thanks for the answer. What does async=false change in behavior/flow
> of data?
>
> What do I need to change or can save in the code? Or same as before
> needed?

It doesn't change the data flow, but it tells the pipeline to ignore
this sink for preroll/state-change purposes. This means that the
pipeline will preroll even if that sink never receives any data.

It's possible I misunderstood your problem, I thought it was related to
that.

Cheers
-Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[parithi]

I am also having similar usecase. I've tested udpsink, filesink and
splitmuxsink with async=false. With this both udpsink and filesink states
are set to PLAYING. But it is not working with splitmuxsink.

This is the pipeline I am using:

gst-launch-1.0 videotestsrc is-live=true ! queue ! x264enc tune=4
key-int-max=50 ! h264parse ! queue ! valve drop=1 ! mux1.video audiotestsrc
is-live=true ! queue ! avenc_aac ! aacparse ! queue ! valve drop=1 !
mux1.audio_0 splitmuxsink mux=mpegtsmux name=mux1  location=/root/mux1.ts
async=false



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel