Setting realtime thread priority - Raspberry Pi DVB-T HD

Colin Paton

Hi,

Apologies if this has been covered elsewhere, but I haven't found anything.

I've been trying to see how well a Raspberry Pi can record HD streams from Freeview HD in the UK. I'm using a PCTV Nanostick 290e to do this.

It seems to record with no errors on my Macbook pro but I think the Raspberry Pi perhaps is just a bit slow...it mostly works but I get the occasional burst of continuity error warnings in the log, and corruption of the recordings. I've tried overclocking the pi but to no avail.

Given it seems like italmost can do it I wondered if I could tweak the code a little bit to squeeze out a little bit more.

As far as I can see from the code all threads are created using default thread priorities. I wondered if making the record thread have real time priority - e.g. pthread_setschedparam( ..., SCHED_FIFO, which (I think) is the correct way to define a realtime thread priority would solve the problem.

I'm pretty rusty using pthreads though, so this might be incorrect, or might be the wrong approach.

I'm also a bit unsure which thread is which - are the recordings carried out using the thread created in dvr_rec_subscribe in dvr/dvr_rec.c ?

Does this sound like a feasible approach to try? I'm curious to see where the bottlenecks could be but don't want to investigate if this has already been looked at.

Thanks,

Colin

mpmc

Hi Colin,

I've done just this with the 290e (and a few other tuners) in the past & came to the conclusion it really wasn't worth the effort (for me anyway).

While it does work, it just isn't that great.. I was streaming from the Pi to my desktop using vlc & for up to the first minute of playback it would glitch like hell but settle down.

I've tried changing power governor from powersave to performance but that didn't make much of a difference to be honest.

I used the following settings:

Enabled the dvb_usb force_pid_filter_usage and disable_rc_polling options

Remove smsc95xx.turbo_mode=N from cmdline.txt.

I also used a custom Raspbian install (without the desktop & stuff).

Hope this helps.

Colin Paton

Hi,

Thanks for the reply - glad to see that someone else is having similar problems.

I'd like to try some benchmarking to find out exactly where the problems occur with the pi, as it looks like the perfect machine for running TV headend.

Doing a simple test using 'dd' to copy files between a USB connected hard disk shows about 9MB/s using a block size of 1M and 1.7MB/s using a block size of 4k.

dd if=/dev/dvb/adapter0/dvr0 to the hard disk with a block size of 1M shows about 6-8% CPU usage or about 16-20% CPU usage with a block size of 512 bytes. (Very rough benchmark obtained using 'top' on a BBC1 Scotland HD stream).

Unfortunately I can't find something that seems happy to play/analyse H264 encoded TS format files to see if the data is correctly there, but it would appear that dd is probably capable of recording OK which suggests the bottleneck might be in tvheadend - but I'm not sure.

The questions to me are:

- Is there a fundamental limitation of the Pi (e.g. useless USB bus) that means this isn't feasible?

- If the hardware is capable can some easy adjustments be made to the tvheadend code to make it work - e.g. set thread priorities or adjust buffer sizes.

I need find time to look through the code properly and understand it - but would I be correct in saying the reading of DVB is done in dvb/dvb_adapter.c/dvb_adapter_input_dvr() ? I'm not yet sure of the breakdowns between the DVB thread and the DVR thread. Does one thread read from the adapter and another thread writes? Does some men copy take place between reading and writing?

If my look is correct then the dvb_adapter_input_dvr() reads into a buffer of size 10*188 which is presumably 10 transport stream packets. I might increase this number to see what happens.

Colin Paton

To follow up to my own message....

I tried an experiment using the pi without tvheadend:


tzap -r -c /etc/channels.conf "BBC ONE Scot"
dd if=/dev/dvb/adapter0/dvr0 of=testsd.ts bs=1M

to record to a raw transport stream, and then

ffmpeg -i test.ts -vcodec copy -sameq -acodec copy -f matroska test.mkv

to convert the transport stream into an MKV file.

I get quite a few continuity check errors in an HD stream - e.g.


[mpegts @ 0x11dd660] Continuity check failed for pid 6601 expected 11 got 12
[mpegts @ 0x11dd660] Continuity check failed for pid 6601 expected 1 got 2
[mpegts @ 0x11dd660] Continuity check failed for pid 6601 expected 5 got 6
[mpegts @ 0x11dd660] Continuity check failed for pid 6601 expected 8 got 11
[mpegts @ 0x11dd660] Continuity check failed for pid 6601 expected 13 got 14
[mpegts @ 0x11dd660] Continuity check failed for pid 6602 expected 2 got 5
[mpegts @ 0x11dd660] PES packet size mismatch

but I also occasionally get them writing an SD stream, which I thought the pi would easily be able to do.

I believe there was a problem earlier with this 290e DVB adapter and the pi, as the USB driver didn't correctly support USB isochronous transfers. I wonder if that bug still exists, and the problem is there rather than tvheadend?