GStreamer performance issues with small packets

[David Plowman]

Hi everyone

I'm wondering if anyone out there is having the same performance issues
with GStreamer as I am. I'm trying to play an RTSP stream where the RTP
contains an MPEG2 transport stream. My situation is probably atypical as
I'm running on a rather low power CPU (~400MHz MIPS) but which has
hardware acceleration for transport stream demuxing, decoding and
composition/output. So once I'm down to the transport stream I just
shovel that into the hardware and everything else is pretty much free
(some memory bandwidth aside, of course). Decoders and general
pixel-pushing are therefore not the bottleneck for me, as I guess they
are for many of you.

To accomplish this I'm using a uridecodebin which creates the rtspsrc,
and let it autoplug until I see a transport stream. Now my main problem
seems to be that there's quite a bit of stuff in the pipeline (rtspsrc,
udpsrc, decodebin, rtpbin, rtpsession, ssrcdemux, ptdemux,
rtpjitterbuffer, typefinder, rtpmp2tdepay), so those call stacks through
all the chain functions get pretty long, and it happens from scratch for
every single packet. In this case a packet is almost invariably 1328
bytes, that's 12 bytes of RTP header plus 7 188-byte transport stream
packets.

Profiling shows I can sustain a stream of up to approximately 4.5Mbps.
However, I did a little bit of experimentation too. If I amalgamate
buffers in the udpsrc into buffer lists (this required a bit of fiddling
elsewhere to make sure lists get passed around correctly) I could manage
nearly double this rate. If instead I actually appended these buffers
together in the udpsrc (obviously I realise this only works for certain
types of payload, and there are certain other concerns like packet
re-ordering...) and passed many fewer, but much larger, single buffers
around then throughput would approach 15Mbps.

So is there anyone else out there experiencing similar problems? Any
smart ideas on how best to handle such situations? I'm very happy to
conduct a bit of a dialogue on the subject if anyone is interested,
either here or offline.

Thanks - and apologies for the long post!

David
--
David Plowman
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Tue, 2016-03-15 at 11:38 +0000, David Plowman wrote:

Hi David,

> I'm wondering if anyone out there is having the same performance
> issues with GStreamer as I am. I'm trying to play an RTSP stream
> where the RTP contains an MPEG2 transport stream. My situation is
> probably atypical as I'm running on a rather low power CPU (~400MHz
> MIPS) but which has hardware acceleration for transport stream
> demuxing, decoding and composition/output. So once I'm down to the
> transport stream I just shovel that into the hardware and everything
> else is pretty much free (some memory bandwidth aside, of course).
> Decoders and general pixel-pushing are therefore not the bottleneck
> for me, as I guess they are for many of you.
>
> (snip) so those call stacks through all the chain functions get
> pretty long, and it happens from scratch for every single packet. In
> this case a packet is almost invariably 1328 bytes, that's 12 bytes
> of RTP header plus 7 188-byte transport stream packets.
>
> Profiling shows I can sustain a stream of up to approximately
> 4.5Mbps. However, I did a little bit of experimentation too. If I
> amalgamate buffers in the udpsrc into buffer lists (this required a
> bit of fiddling elsewhere to make sure lists get passed around
> correctly) I could manage nearly double this rate. If instead I
> actually appended these buffers together in the udpsrc (obviously I
> realise this only works for certain types of payload, and there are
> certain other concerns like packet re-ordering...) and passed many
> fewer, but much larger, single buffers around then throughput would
> approach 15Mbps.
>
> So is there anyone else out there experiencing similar problems? Any
> smart ideas on how best to handle such situations? I'm very happy to
> conduct a bit of a dialogue on the subject if anyone is interested,
> either here or offline.

Yes, it's a known issue, I've been working on that as well and I'm
hoping to add recvmmsg() and bufferlist support for udpsrc in the next
development cycle, provided we can find an API everyone can live with)
:) That should help. rtpjitterbuffer still has a few performance issues
though, and there are other small things all over the place that can
hopefully be optimised better.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[David Plowman]

Hi Tim

On 15/03/16 12:31, Tim Müller wrote:
<snip>
> Yes, it's a known issue, I've been working on that as well and I'm
> hoping to add recvmmsg() and bufferlist support for udpsrc in the next
> development cycle, provided we can find an API everyone can live with)
> :) That should help. rtpjitterbuffer still has a few performance
> issues though, and there are other small things all over the place
> that can hopefully be optimised better. Cheers  -Tim

Thanks for the response. Those sound like good ideas, and glad to hear
that someone is thinking about it. I'll keep my eye on this board in
case there's any discussion of an API (might have a suggestion or two...
:) ) and if there's any software at some point later to test drive. Also
not averse to helping out if I can be useful.

Thanks and best regards

David
--
David Plowman
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel