hlsdemux: set uri handler blocksize to reduce CPU usage

Submitted by Duncan Palmer

Link to original bug (#749090)

Description

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.

Version: 1.4.5