<div dir="auto">Fantastic, thank you both. The pipeline is now working beautifully, and I'm very happy with the decode/display latency. Now on to fixing latency in the rest of the pipeline...<div dir="auto"><br><div dir="auto">I'm going no sync for now, but will try playing with sync at some point to see if it looks better.</div><div dir="auto"><br></div><div dir="auto">Thank you</div><div dir="auto">Pete</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Nov 2022, 20:50 Nirbheek Chauhan, <<a href="mailto:nirbheek.chauhan@gmail.com">nirbheek.chauhan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Nov 22, 2022 at 12:30 AM Nicolas Dufresne via gstreamer-devel<br>
<<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br>
> Le lundi 21 novembre 2022 à 13:24 +0000, Peter Allen via gstreamer-devel a<br>
> écrit :<br>
> > I have an application that needs ultra-low latency decoding and display of a<br>
> > 720p/60 H264 rtp stream. I'm using Allwinner H3 (currently an Orange Pi PC,<br>
> > but that will change to a different H3 platform in due course), and displaying<br>
> > on a 1080p/60 monitor connected via hdmi.<br>
> ><br>
> > My current gstreamer pipeline is gst-launch-1.0 -v udpsrc port=5600 !<br>
> > "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-<br>
> > name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! v4l2slh264dec<br>
> > ! kmssink plane-id=31 plane-properties=s,zpos=3<br>
> ><br>
> > if I change to fakesink, the decode is working beautifully (and according to<br>
> > gstreamer latency stats is giving a decode time  of around 5ms - better than I<br>
> > had hoped!) However I am having issues with kmssink. Initially I was only<br>
> > getting 30fps display, but applying the kmssink fix for atomic drm clients<br>
> > from <a href="https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/654" rel="noreferrer noreferrer" target="_blank">https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/654</a> and<br>
> > also the rockchip kernel fix I get smooth 60fps decoding, but only if I add a<br>
> > ! queue ! element between  v4l2slh264dec and kmssink which pushes the latency<br>
> > up unacceptably high.<br>
> ><br>
> > Playing with ! queue ! output buffers (max-size-buffers=1 leaky=downstream)<br>
> > shows it needs max-size-buffers=3 buffers before it displays smoothly. (at<br>
> > max-size-buffers=1 I alternately 1 frame dropped then 2 frames dropped, at<br>
> > max-size-buffers=2 it's one frame dropped then no frames dropped)<br>
><br>
> I can only presume that render time correctness does not matter to you. So my<br>
> advise would be to use kmssink sync=0.<br>
<br>
Another thing to try before turning off sync is changing<br>
processing-deadline to a lower value. Honestly the default 20ms is a<br>
bit too large.<br>
</blockquote></div>