CPU Utilization

[Plug1n]

I just installed vomp after a couple of years using vdr-mediamvp. 

Easy install and the vomp osd graphics are really great.

The problem I am having is with cpu utilization for live tv.  This is important as I am running vdr in an ancient Pentium 166 - for vdr this is not a problem cpu is normally ~5-8%.  But when I stream live tv to a mediamvp cpu soars - for mediamvp about 50-80% and for vomp ~90%.

The strange thing is that playback of recordings is fine (10-20%) for the same video content.

I think something is wrong in the streamdev code although I haven't used this recently.

I'd be happy to work on this but last time I looked at debugging the dynamically loaded vdr plugins, it was a real nightmare.

Any suggestions on how to find out what is going on?

I think that Pentium 166 should actually be OK as I can stream fine from my dbox with ppc 66mhz processor.

Thanks for any ideas.

Plug1n

[Chris]

Hi, I would have a look at this myself except that my dev system doesn't live at the moment and my live system is way too fast to be measuring how much cpu time live playback uses. Firstly, I am not surprised that live tv takes a lot more time than recording playback. Recording playback is simply read 100k from disk, squirt it out onto network. Live tv is far more complicated.

Firstly, the data is received by the vomp plugin from VDR in 188 byte chunks - you can imagine how many times that function is called by VDR. Then it sits in a buffer until a seperate thread remuxes it from TS to PS I think. Then it sits in another buffer until requested by the MVP in the same way as it requests recording playback data.

If the CPU load is hovering at 90% but not 99% then I don't know what to suggest. I wouldn't have thought it would take that much CPU time to stream live tv. Whereas if it is using all the available CPU time then maybe there is something wrong - some runaway task perhaps.

As for debugging the plugin, what was a nightmare about vdr plugins before? I'm not quite sure how you would go about investigating why vompserver takes 90% but at least you will be able to put logging messages in and watch the logfile while it's running. That's all I do.

[Plug1n]

Chris

Thanks for the reply and the outline of the architecture.

I get pretty similar problems sreaming with mediamvp. streamdev (to mplayer on a PC)  and vomp, so I guess the issue is with VDR and buffering or maybe the api to get at the buffer from a plugin.  This got a lot worse somewhere just after vdr 1.3.12.

The problem with plugins was profiling, I couldn't get any of the tools used for gcc to work in a dynamically loaded module.

Since the first message, I have tried building the whole vdr with the Intel C++ compiler as it has a reputation for better optimisation.  This seems to give me some improvement (maybe 20%) but cpu is is still frequently in the high 90%'s.

I thought I would try and build the streampes/streamts clients from the Tuxbox project.  This is what a 66mhz ppc dbox is using successfully.

Plug1n

[Chris]

Does this definitely occur only when you hit play on live TV on the MVP? And then stop immediately as you press stop?
Also, when the CPU is in the 90%'s is the other 10% idling or is vompserver using all available CPU time?

[Plug1n]

Yes any remaining cpu is idle (and depeds on how much picture movement there is).

So in "top" for a static info card I see:

11668 root      16   0  131m  16m 2308 S 54.3 17.5   7:13.32 vdr
11677 root      17   0  2044 1052  820 R  2.2  1.1   0:18.85 top
8759 root      16   0  6236 2016 1608 S  0.3  2.1   0:06.64 sshd
and about 36% idle.
 
When I go back to the vomp menu:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
11668 root      16   0  129m  14m 2296 S  5.2 15.2   7:52.80 vdr
11677 root      16   0  2044 1052  820 R  2.0  1.1   0:20.90 top
8759 root      16   0  6236 2016 1608 S  0.3  2.1   0:06.75 sshd

and 80% idle.

[Chris]

I got my dev system working again and had a look at the cpu usage for streaming a live channel to the mvp. It's about 45%, the CPU is a VIA C3 running at 533MHz. I hope the major cpu usage lies in the double ringbuffering and the remuxing process, as it is possible to change how all this works by moving some of the work to the MVP. If that isn't where the cpu load is, then it's definitely time for the profiling tools...

[Plug1n]

Yep,  it seems to need about 200Mhz so a 166 is a problem :-(

I ran oprofile and most of the time was spent in memcpy but haven't had much time to follow up recently.

Plug1n