High CPU usage when watching a scrambled channel

Peter Bašista

Hi,

I am running tvheadend for Raspberry Pi without the transcoding support, version 4.3-767~gd0a79495e~raspbianstretch, from this repository:

https://dl.bintray.com/mpmc/deb raspbianstretch/unstable armhf

on a satellite receiver Octagon SF4008. It runs an embedded linux distribution called openATV with Linux kernel 4.1.37 and I am running tvheadend in a bootstrapped Debian chroot environment for armhf architecture. It works reasonably well when it comes to configuration and watching unscrambled channels.

However, when watching a scrambled channel, the CPU usage of the tvheadend process raises to 100% on a single core (the receiver has Brahma15 CPU with two ARMv7 cores). It is possible to watch the stream, but it regularly freezes and then skips over a few seconds. The receiver itself isnot used for watching the stream and there is no other resources-intensive process running on it (like Enigma 2 GUI) at the same time.

I am using oscam for descrambling. It runs on the same receiver. The descrambling keys are fetched from another server. But the oscam process is not consuming any significant CPU time when watching a scrambled channel. There are also no network-related issues that I am aware of.

To summarize, tvheadend is consumingvery little CPU time when watchingunscrambled channels. The problems withhigh CPU usage only start when watchingscrambled channels.

Given the above mentioned situation, I would like to ask the following:

1. Is this kind of behavior expected? In other words, is a "powerful" CPU required for tvheadend to descramble a single DVB-S2 channel using oscam and then stream it using HTSP?

2. If the answer to the above question is "no", then where to look for the potential causes of the problem? I could not find any useful information in the verbose tvheadend log. I could try to profile it, but it seems to be an overkill.

Thank you.

mpmc

Have you tried reverting to 4.3-777~gc625df2f7~raspbianstretch? See if that has the same outcome?


sudo apt install tvheadend*=4.3-777~gc625df2f7~raspbianstretch

Joe User

Most STBs rely on hardware descrambling and are not very powerful as far as CPU goes. But I would think most should be able to handle at least one channel being descrambled via software (what Tvheadend is doing) even if it is an HD channel with 3 or 4 audio tracks.

Does someone know if debug builds set the debug2 in decrambler.c??

At startup there should be a line showing the CSA descrambling mode, something like:


 [   INFO] csa: Using SSE2 128bit parallel descrambling

Peter Bašista

Mark Clarkstone: Any particular reason why I should try this specific version?

I have just tried both @4.3-777~gc625df2f7

and

4.3-819~g7c3919b88

(which seems to be the latest as of now). There is no difference in descrambling-related behavior that I could observe when comparing with

4.3-767~gd0a79495e

that I have used originally. If you are interested, the logs are attached.

@Joe User: I am trying to descramble this channel:

http://www.onastra.com/16665077/channels#!/channel/16807

Content varies, but as of now it contains the following:


(+) Video --vid=1 (h264 1920x1080 25.000fps)
(+) Audio --aid=1 --alang=cze (mp2 2ch 48000Hz)
    Audio --aid=2 --alang=cze (ac3 6ch 48000Hz)
    Subs  --sid=1 --slang=cze (dvb_subtitle)

The CSA line for me looks like this:


[   INFO]:csa: Using 32bit parallel descrambling

The CPU on the receiver has the following capabilities:

# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 54.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x42 CPU architecture: 7 CPU variant : 0x0 CPU part : 0x00f CPU revision : 3 processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 54.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x42 CPU architecture: 7 CPU variant : 0x0 CPU part : 0x00f CPU revision : 3 Hardware : Broadcom STB (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000

Maybe it would help not to use the Raspberry Pi build, but rather compile tvheadend from scratch and use some CPU-specific compile-time optimizations. The software descrambling might then be faster. Your example CSA line mentions SSE2 128bit, which, I assume, should be faster than plain 32bit. But I am not sure which descrambling-related features this CPU supports.

Also, thanks for the information about the hardware-accelerated descrambling. I did not know about that. If you say that satellite receivers are typically equipped with hardware descramblers, is it possible to utilize them by tvheadend?

Joe User

Do you have problems with encrypted SD channels?

My line is from a PC, but there are some neon optimizations for libdvbcsa (the software decryptor) which should help. However, I am not sure if they will automatically be included if you build it yourself. But a build from scratch for your machine would be a good start.

As far as using the hardware to decrypt, it depends on the drivers. I looked at this briefly when I tested tvheadend on my Amiko Alien2 (spark7162) box, but never had the time to do much. In theory, if you set oscam boxtype just like you do for enigma2 and use a capmt socket connection to tvheadend, then oscam can use IOCTLs to directly use the hardware decoders on the box.

BTW - OpenATV uses oe-alliance and openembedded has recipes to build tvheadend (and oscam.)

Peter Bašista

Joe User wrote:
> Do you have problems with encrypted SD channels?

Yes, with my previous setup, the receiver was not able to descramble even a single SD channel in real time. The tvheadend's CPU usage was still 100% on a single core and the resulting stream froze regularly.

I did not try to build tvheadend myself, because I wanted to make the hardware descrambling work in the first place. I assumed it must be possible, because when Enigma2 is running on that same receiver, it uses oscam for descrambling as well and it can somehow descramble multiple channels simultaneously without any significant CPU usage.

Thank you for the suggestions about oscam configuration. Originally, I have had the boxtype parameter set to 'pc'. I have changed it to 'dreambox', because that value was also used by oscam instance, which was working fine with Enigma2. After that, tvheadend was able to descramble multiple channels simultaneously without any significant CPU usage, just like Enigma2.

I have also made one more change to oscam's configuration. As you suggested, I have set pmt_mode to '0', so that oscam clients can use a socket file instead of a TCP connection. Is it a necessary step in order to enable clients to use hardware descrambling?

I have also tried to change the boxtype back to 'pc' while using the socket file for client connections. It caused tvheadend to fallback to software descrambling again (judging from the high CPU usage). So, I assume that the most important part was to set the boxtype to 'dreambox', at least in my case.

Thank you once again for all the suggestions. My issue with high CPU usage while descrambling is now resolved.