[Bug 709826] mpegtsmux: performance issue

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #10 from Edward Hervey <bilboed at bilboed.com> 2014-07-21 11:53:00 UTC ---
(In reply to comment #8)
> I have some time on my hands, so I took a peak at this one again.

  Yay \o/

> 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).

  Yes, that is indeed the requested behaviour.

  An interesting thing to take into account while doing this refactoring would
be to:
  * move up the tsmux lib code to the mpegtsmux element itself. The split is no
longer needed.
  * Figure out a better way of interleaving the incoming buffers. AFAIR, right
now it muxes full buffers, instead of spreading them out evenly in the outgoing
buffer. That would require "driving" the collection system the other way round
(instead of pushing buffers, you have the outgoing system deciding what it
wants to pick).

> 
> 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!

  It will actually work quite nicely if you don't memcpy, as tim mentionned.

> 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.

  Nice work.

-- 
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.