Tvheadend

Adam Sutton wrote:

nothing like as high as reported here

An increase from 2% cpu load (mkv) to 8% cpuload (ts) IMO means 400% up.
That is way more then I reported!

Lol,

it wasn't clear what you were reporting and its difficult to be sure that the entire increase is due to just MKV v TS as other stuff will be happening in my system all the time.

However I was just trying to point out that I'm definitely seeing an increase.

Adam

There is more thread wakeup and mutex locking/unlocking with passthrough since the packets sent to the clients are smaller (188 bytes) than when muxing to mkv.

Claiming that the cpu load differ with 400% is a bit misleading since it depends on the actual cpu.
I've done some simple tests on some of my hardware, all using a 1080p iptv source.

streaming from vlc on one server --> tvheadend on second server --> vlc on a desktop.
Below is the cpu load (%) reported by htop.

WNR3500Lv2 (480MHz, mipsel)
---------------------------
mkv: 40-60%
pass: 48-75%

eeepc (900MHz, i686)
----------------------
mkv: 4-8%
pass: 10-20%

Intel core i5 2500K (3300MHz, amd64)
------------------------------------
pass: 8-9%
mkv: 6-7%

It might not be the most scientific method, but at least it gives you an idea of what you might gain by doing optimization.
There are some stuff that can be changed in order to reduce the load, but at the cost of code readability and maintainability.
At the moment, I don't think its worth the effort but given the right use-case, I might change my mind.

It could also be interesting to see how the load scales with multiple clients with multiple sources.

The right use case would be the case in which timeshift is implemented.
I've been led to the conclusion that using ts would be better then mkv, in this case.
Hence my report.
I might be wrong though.

bas t wrote:

The right use case would be the case in which timeshift is implemented.
I've been led to the conclusion that using ts would be better then mkv, in this case.
Hence my report.
I might be wrong though.

You are perfectly right : it should be less. remuxing to mkv, you need to demux, and change the H264 stream structure. To do this you also need to read 188 bytes chunks. Regarding waling the client more frequently, you could have a look at my tree where TS streaming and storing has been enhanced (but I did not yet take the plunge to go to 3.x). https://github.com/EricV/tvheadend

bas t:

I pushed some optimization on a new branch at https://github.com/john-tornblom/tvheadend/tree/mpegts_buf_optimization

Do you think you could give it a go?

git clone -b mpegts_buf_optimization git://github.com/john-tornblom/tvheadend.git

Cool!
Problem solved, push it to master.

Note: this will not be in 3.2 (yet) we've just done beta4 builds.

However we'll see about beta5 or possibly a later backport, obviously this is something we should have in 3.2 if we can.

Adam

Take your time, I can use master if I need to.