Decrease latency between different branches of pipeline

[sielf]

Hello.
I'm working with IMX6 based board with gstreamer-1.4.5 framework version.
I've constructed next (simpified) pipeline : src--queue--tee--queue--videosink
                                                                                  |--queue----coder---muxer--filesink
                                                                                  |--queue---appsink
Problem is, if I only translate data from src to videosink, I have very low latency. But if I add coder or appsink branch, the videosink become slower and has higher latency, even if I use different GPU based modules. I tried increase size of the queue, but it works bad. How can I additionally decrease latency?

[Nicolas Dufresne-5]

Le jeudi 23 mars 2017 à 06:57 -0700, sielf a écrit :

> I'm working with IMX6 based board with gstreamer-1.4.5 framework
> version.
> I've constructed next (simpified) pipeline :
> src--queue--tee--queue--videosink
>                                                                      
>             
> > --queue----coder---muxer--filesink
>
>                                                                      
>             
> > --queue---appsink
>
> Problem is, if I only translate data from src to videosink, I have
> very low
> latency. But if I add coder or appsink branch, the videosink become
> slower
> and has higher latency, even if I use different GPU based modules. I
> tried
> increase size of the queue, but it works bad. How can I additionally
> decrease latency?

Expose the full pipeline, because I think you break the performance at
the "tee", which drops allocation query, hence breaks zero-copy.

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

[sielf]

Nicolas Dufresne-5 wrote

Le jeudi 23 mars 2017 à 06:57 -0700, sielf a écrit :
>

Expose the full pipeline, because I think you break the performance at
the "tee", which drops allocation query, hence breaks zero-copy.

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


signature.asc (188 bytes) <http://gstreamer-devel.966125.n4.nabble.com/attachment/4682382/0/signature.asc>

The full pipeline is:
imxv4l2videosrc-videoconvert(colorspace)-queue--tee--queue-videoconvert(colorspace)-imxg2dvideosink                                                                          
                                                                          |--queue--videoconvert (colorspace) ---imxg2dvideotransform (rescale)---videoconvert(colorspace)--imxvpuenc_h264---avimux--filesink
                                                                          |--queue--videoconvert-appsink


Queues have parameters: max-size-time=10s, max-size-bytes=100M max-size-buffers-500 , I've changed this without any effect. All sink were tried with sync false and true. Qos everywhere is true. Coder has bitrate=0, gop-size=16 quant-param=24 idr=16.

[Nicolas Dufresne-5]

Le jeudi 23 mars 2017 à 21:25 -0700, sielf a écrit :

> The full pipeline is:
> imxv4l2videosrc-videoconvert(colorspace)-queue--tee--queue-
> videoconvert(colorspace)-
> imxg2dvideosink                                                      
>                      
>                                                                      
>     
> > --queue--videoconvert (colorspace) ---imxg2dvideotransform
>
> (rescale)---videoconvert(colorspace)--imxvpuenc_h264---avimux
> --filesink
>                                                                      
>     
> > --queue--videoconvert-appsink
>
>
> Queues have parameters: max-size-time=10s, max-size-bytes=100M
> max-size-buffers-500 , I've changed this without any effect. All sink
> were
> tried with sync false and true. Qos everywhere is true. Coder has
> bitrate=0,
> gop-size=16 quant-param=24 idr=16.

In general, tee should break zero-copy. So that may explain the jittery
part. On the other side, you probably need to make the queue on the
appsink side to be leaky, so it nevers blocks. Otherwise if you don't
read the appsink fast enough, the other side will be jittery.

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

[sielf]

Nicolas Dufresne-5 wrote

Le jeudi 23 mars 2017 à 21:25 -0700, sielf a écrit :
> The full pipeline is:
> imxv4l2videosrc-videoconvert(colorspace)-queue--tee--queue-
> videoconvert(colorspace)-
> imxg2dvideosink                                                      
>                      
>                                                                      
>     
> > --queue--videoconvert (colorspace) ---imxg2dvideotransform
>
> (rescale)---videoconvert(colorspace)--imxvpuenc_h264---avimux
> --filesink
>                                                                      
>     
> > --queue--videoconvert-appsink
>
>
> Queues have parameters: max-size-time=10s, max-size-bytes=100M
> max-size-buffers-500 , I've changed this without any effect. All sink
> were
> tried with sync false and true. Qos everywhere is true. Coder has
> bitrate=0,
> gop-size=16 quant-param=24 idr=16.

In general, tee should break zero-copy. So that may explain the jittery
part. On the other side, you probably need to make the queue on the
appsink side to be leaky, so it nevers blocks. Otherwise if you don't
read the appsink fast enough, the other side will be jittery.

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


signature.asc (188 bytes) <http://gstreamer-devel.966125.n4.nabble.com/attachment/4682403/0/signature.asc>

Actually, I've solved this problem with decreasing queue size at the imxg2dvideosink branch to zero, in all max-size parameters. I tested it without appsink branch. So, your words about tee was right, thanks.
Yeah, about appsink and vpuenc parts I have more problems, but it is another question.