[Bug 709826] mpegtsmux: performance issue

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=709826

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #315811|none                        |needs-work
             status|                            |

--- Comment #14 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Review of attachment 315811:
 --> (https://bugzilla.gnome.org/review?bug=709826&attachment=315811)

This is of course not a bad idea (the implementation needs work though). It
might not solve all the problem. Dealing with 188 bytes buffer is a disaster
performance wise. The muxer should group the buffers into logical groups, or
toward something near an MTU.

::: gst/mpegtsmux/mpegtsmux.c
@@ +322,3 @@
+  gst_buffer_pool_config_set_params (config, NULL, 188, 100, 1000);
+  gst_buffer_pool_set_config (mux->pool, config);
+  gst_buffer_pool_set_active (mux->pool, TRUE);

Cool, ever considered useful to deactivate and free this pool ? What about
downstream providing a SHM allocator ? What about downstream proposing a usable
pool ? (that's rare though for that kind of format).

@@ +1676,3 @@
+    gst_buffer_set_size (buf, NORMAL_TS_PACKET_LENGTH);
+  } else {
+//     buf = gst_buffer_new_and_alloc (NORMAL_TS_PACKET_LENGTH);

No need to explain.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.