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