[Bug 709826] mpegtsmux: performance issue

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=709826
  GStreamer | gst-plugins-bad | git

--- Comment #8 from Jesper Larsen <knorr.jesper at gmail.com> 2014-07-21 11:22:59 UTC ---
I have some time on my hands, so I took a peak at this one again.

Right now the mux works as follows:

 - A buffer is received through collectpads, this buffer is mapped and appended
to an internal list.
 - A buffer for a single packet (188/192 bytes) is allocated, and payload is
memcpy'ed from the internal list
 - The buffer is pushed to a output GstAdapter
 - If the alignment property is set, a multiple of align packets are read from
the adapter, and pushed on the src pad. If the alignment property is not set,
all data in the adapter is pushed.

I'm working on a preliminary change that does something like this

 - During initialisation, a buffer pool is created, and 3 buffers of size
188/192 * align is pre-allocated. Default alignment is 32 packets.
 - Buffers received through collectpads are still mapped and appended to the
internal list
 - The muxer writes headers and memcpy payload from the internal list directly
into a mapped buffer from the buffer pool
 - Once the outgoing buffer is full, or the incoming buffer is starved, the
output buffer is unmapped and pushed on the src pad

A side effect is that the alignment property will no longer give you output
buffers that are a multiple of the alignment, but rather exactly the alignment
or less. IMO this is what the alignment property is expected to do, and it
removes the need to do chopmydata like hacks to send output through udpsrc
(discussed here https://bugzilla.gnome.org/show_bug.cgi?id=722129).

I wanted to avoid the memcpy of payload, since there is no need to read/write
the actual payload data. However, we do need to allocate memory for the
headers, and that means we need to make a buffer that contains multiple
memories. As far as I can tell, the data in a GstBuffer containing multiple
GstMemory will be merged (i.e deep copied) if it is mapped, which means that
the need to memcpy the payload is not removed. Please tell me that I'm ignorant
and wrong in this regard!

I'm testing by muxing a single 1080p h264 stream. (i.e filesrc ! h264parse !
mpegtsmux ! fakesink)

The changes reduces the instruction count used on an incoming buffer by 17% -
80%. The 17% reduction is seen when alignment is set to 1 packet. 80% reduction
is with the default alignment of 32 packets. Alignment of 7 packets (suitable
for UDP packets with MTU size 1500 bytes) shows ~73% reduction.

The output from the test is 100% binary identical with output made with current
master.

There is still a lot of work to do, to actually support everything as before.
It should not be things that will reduce the performance significantly though.
I'm not attaching a patch since it is very much WIP, but I wanted to share my
findings.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.