What is use case for rtppassthroughpay? Could it reduce forwarding latency somehow?

1.24.0 has new element rtppassthroughpay:

New rtppassthroughpay element which just passes RTP packets through unchanged, but appears like an RTP payloader element. This is useful for relaying an RTP stream as-is through gst-rtsp-server, which expects an RTP payloader with certain properties at the end of an RTSP media sub-pipeline.

from GStreamer 1.24 release notes

I use gst-rtsp-server to provide access to the IP camera from another network, simplifying “ugly” RTSP urls, real passwords, etc.

My “legacy” pipeline looks like this:

rtspsrc location=... protocols=tcp latency=100 buffer-mode=slave ! capsfilter caps="application/x-rtp,media=video" ! queue max-size-buffers=0 name=pay0

Since 1.24.0 I can use new rtppassthroughpay like this:

rtspsrc location=... protocols=tcp latency=100 buffer-mode=slave ! capsfilter caps="application/x-rtp,media=video" ! rtppassthroughpay name=pay0

This also works, and I don’t see the difference. I still get maybe ~50ms of added latency due to forwarding IIRC.

So I’m not sure what is the use case, advantages, disadvantages of rtppassthroughpay.

Should it work better for low-latency forwarding?

Thanks!

Compared to your “legacy” pipeline it should not make any difference with regards to latency. But your “legacy” pipeline is using a queue element as “payloader”. gst-rtsp-server assumes certain behaviour and interface of the “payloader” element to function correctly under all conditions, and the queue element does not provide that while rtppassthroughpay does. That’s the only difference between both pipelines, effectively.

So I guess it’s just “official” way to perform RTSP forwardings, instead of that dummy “queue” element as a workaround of sorts.

Thanks.

Yes, and it works more correctly.