[Bug 749090] New: hlsdemux: set uri handler blocksize to reduce CPU usage

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 749090
           Summary: hlsdemux: set uri handler blocksize to reduce CPU
                    usage
    Classification: Platform
           Product: GStreamer
           Version: 1.4.5
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dpalmer at digisoft.tv
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

When streaming some encrypted HD content (bitrate about 7 Mbps) using HLS
demux, I found CPU usage was hitting 100% on my embedded processor (a Sigma
SMP8674). An unencrypted version of the same content was using 47% of the CPU.

A bit of digging shows that is because of the default 4K blocksize used by
souphttpsrc. Increasing this to 64K reduced CPU usage to 47% for the encrypted
stream, and 27% for the clear stream.

The solution I've implemented is to modify hlsdemux to set the blocksize
property on it's uri_handler.

The value set for blocksize is calculated from the bitrate of the current
variant, to ensure we can fill a block in 125ms (which seems like a nice low
number to me - this shouldn't introduce too much jitter into the pipeline). I
set a lower blocksize limit of 4K (as used by gstbasesrc), and a higher limit
of 64K. Testing with both clear and encrypted versions of my test stream shows
no improvement once blocksize is increased beyond 64K. Block sizes are
incremented in 4K steps.

With this algorithm, all variants below 262144 bps use a 4K blocksize, and
above 4194304 bps use a 64K blocksize.

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