Unixfd not compatible with rtppay memory

Application Development
1

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?

2

Please create an issue in gitlab about this. Thanks!

3

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
4

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

5

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

6

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?

7

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.