Unixfd not compatible with rtppay memory

Hi, I’m trying to reduce redundant processing and have been testing a pipeline the dumps H.264 RTP into a unixfdsink element.

videotestsrc ! videoconvert ! vaapih264enc rate-control-2 bitrate=2000 ! h264parse ! rtph264pay ! unixfdsink socket-path=/tmp/rtpVideo

Then I try to consume it with multiple instances of the following pipeline ran by the gst-rtsp lib

unixfdsrc socket-path=/tmp/rtpVideo ! rtppasthroughpay name=pay0

But I get the following error in the sink pipeline

unix_fd_sink_render:<unixfdsink0> Expecting buffers with FD memories

But if I try just sending H.264 it works by adding a depayloader, but now all my consumer instances need to payload and causes high cpu usage

videotestsrc ! videoconvert ! vaapih264enc rate-control-2 bitrate=2000 ! h264parse ! rtph264pay ! rtph264depay ! unixfdsink socket-path=/tmp/h264
unixfdsrc socket-path=/tmp/h264 ! h264parse ! rtph264pay ! name=pay0

Is there anything I can do to dump rtp into an fd socket or reduce CPU usage on my rtsp implementation?

Please create an issue in gitlab about this. Thanks!

The error was intentional. Xavier really wanted to prevent implicit copies in that element. None of the parser or payloader actually care about downstream allocation, so these don’t work.

I made this work in progress patch, to opt-in for copies, it adds a new “allow-copy” property, perhaps “enable-copy” would be more accurate, the implementation is still not very clear either, this is why its a WIP.

1 Like

That should probably come with an upload element and a capsfeature then so negotiation works correctly at least :slight_smile:

I could introduce memfdupload element instead of the property, sure. But caps feature are serious pain, one per 5years is enough :smiley:

So having an rtp/parser element with a unixfd src or sink, with your patch, defeats the zero-copy benefits of fd backed memory?

can the rtp and parsers even access fd memory once it’s been allocated?

It’s copied into the memfd once in unixfdsink, and passed zero-copy through unixfdsrc. If you use that with VA or V4L2 memory, which are DMABuf, these are zero copy end to end.

Put this in context, if you use a socket, it will be copied twice.