[mythtv-users] HD-PVR playback--high CPU usage

[Andre]

On 25 Mar 2010, at 13:41, Zach C wrote:

> On Thu, Mar 25, 2010 at 9:32 AM, Brian Wood <beww at beww.org> wrote:
>> On Thursday 25 March 2010 07:22:26 am Zach C wrote:
>>> Hi,
>>> 
>>> I'm having trouble playing back recordings from my Hauppauge HD-PVR.
>>> The CPU on my Pentium dual core frontend is pegged and playback is
>>> unwatchable.
>>> 
>>> What is weird is that I can play back 720p h.264 torrented video files
>>> with no problem.  In that case playback is perfect and cpu is probably
>>> around 30%-50%.  I would think the 720p h.264 video coming from the
>>> HD-PVR should be roughly equivalent to the video files.  I don't
>>> understand why the system can't handle it.
>> 
>> Files acquired by "unofficial" means are often encoded at low bitrates. If your
>> HD-PVR recordings are at a significantly higher bitrate this might explain
>> things.
>> 
>> Are you using VDPAU? Pure software decoding of HD recordings does take a lot
>> of CPU.
>> 
>> What (if any) de-interlacer are you using?
>> 
>> Playback with Myth's internal player does take more CPU than some other
>> methods, since it is doing more (checking the DB for commercials etc.). Have
>> you tried playing the recordings back with some other program?
>> 
>> You might try a simpler playback profile (Slim?).
>> 
> 
> No--not using VDPAU, but nor am I using it on the 720p mkv files
> either.  Playback profile is the same for recordings and mkvs.  In
> fact, as far as I can tell everything is the same between the two,
> configuration wise. Also the mkv files are being played with the
> internal player, so hopefully that is equivalent to recording
> playback.

With H264 there's a lot more to encoding than just the bitrate, often a low bitrate encode can need a more powerful decoder than a high bitrate encode. More important than the rate is the tool set used, you can check this by looking at the profile level used to encode, bear in mind that most "found on the net" encodes lie about their profile, they claim 4.1 when in fact 3.0 is fine.

Once you get to 4.0 and above there are a lot of encoding tools (techniques perhaps) that are optional but if used can give a vastly better result at low bitrate, using cabac and B-pyramid encoding more than doubled the CPU requirements for some 1080p30 4mb/s material I was working with last year, looked loads better though. The same material at 140Mb/s with a simple contribution profile played very easily with low cpu usage. There are also some tricks in encoding (slicing) that permit easier decoding with multi core cpus.

I understand that the HD-PVR uses high profile 4.0 so may use some of the harder to decode techniques but most significantly doesn't slice so doesn't decode easily across cores. Anecdotally there are some other aspects of the encodes it produces that force decoding to be highly serial, causing it to be difficult to decode, I don't have a HD-PVR so I don't have access to any recordings to verify this anecdote.

You may find that actually it's easier to decode the HD-PVR recordings if you set a higher bitrate, it will certainly be worth looking for any encode profile settings. Set the profile number lower and up the bitrate to compensate and things should be easier but I don't know if the HD-PVR can be controlled at this level, it may not be that flexible.

If you find some controls this article may help explain what does what:

http://www.adobe.com/devnet/flashmediaserver/articles/h264_encoding_03.html
and
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC

or ask here

Andre


> 
> I will muck with the HD-PVR's bitrate and see if that helps, but I've
> already got it ratcheted down pretty low.  I'll check and see what the
> approximate bitrate is on the mkv files is.
> 
> Thanks
> 
> 
> -- 
> :wq!
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>