Gstreamer custom sink renderer takes too long time !

[Duchassin Frederic]

Hello Nicolas,

My renderer is locked by mutex so it makes it synchronous. There is no way for me to make different.

And I can't lose any frame (or data).

But because I have a queue in the upstream, I probably could ask for buffering during my renderer isn'it ?


-----Message d'origine-----
De : gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] De la part de Nicolas Dufresne
Envoyé : mercredi 5 septembre 2018 14:52
À : Discussion of the development of and with GStreamer
Objet : Re: Gstreamer custom sink renderer takes too long time !

Le mercredi 05 septembre 2018 à 12:41 +0000, Duchassin Frédéric a
écrit :
> Hello All !
>  
> I try to make my own sink.
> My main problem is that my renderer is quite slow (about 50000ns to
> get out render() function) and give poor performance with high input
> bitrate. (packet lost !)
>  
> For example a case which doesn’t work :
> This is the interval between each time I feed my sink (without
> renderer):
> dt=127654ns
> dt=138320ns
> dt=51995
> dt=55661
> dt=75326
> dt=139319
> dt=76660
> dt=91991
> dt=159318
> dt=91991
> dt=21664
> dt=54995
> dt=88324
> dt=135986
> dt=88324
> dt=18665
> dt=81326
> dt=51995
> dt=77659
> dt=100990
> dt=17665
> dt=78659
>  
> As you can see, sometimes I feed my sink every 21 µs and as my
> renderer take 50µs, I can lose packet.
>  
> Can you advice me about a way to stop feeding my sink during renderer
> ???
> Or if there is another way….

What we usually do is to make the renderer asynchronous. This way, you
don't wait for the renderer to finish, and can receive the following
frame immediately. Then, whenever a frame is submitted while another is
being rendered, you can skip it (ideally sending a QoS message to tell
the app you have done so).

You should also check that max-lateness/deadline-timeout and other sink
properties are configured correctly. That QoS is enabled also, since
some element can decide a head of time to drop a buffer is it's safe to
do so and that this buffer isn't going to make it.

>  
> Thanks in for your help.
>  
> Frederic
>  
>  
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel