[mythtv] HD-3000 and changes from 18.1 to SVN

[Todd Freeman]

I'm the other guy with this problem... but I thought I would chime in some responses since our systems are so close...

On Mon, Oct 17, 2005 at 10:04:07PM -0400, Daniel Kristjansson wrote:
> On Mon, 2005-10-17 at 16:47 -0600, Chris Dos wrote:
> 
> This is your real problem, the nvidia implementation of XvMC doesn't
> work with MythTV's blended OSD. I'm not sure if a Sempron 64 1600+ can
> do software decoding of HDTV. If it can, you should use that.

When I had been using prior releases I did have MASSIVE stuttering while the OSD was up...  however normal video played clean... with current releases it is all crud.

Last time I tested (about the time that SVN took over) I had basically the same issues when using software decoding...  however with a Athlon XP 2800 that coulda just been me drying the CPU out.

> 
> > It took me a good three weeks to the HD-3000 card to work properly.  I kept
> > getting the "A/V diverged by 4.28889 frames, extending frame to keep audio in
> > sync" errors whenever I had the sound enabled on MythTV.  Disable the sound and
> > 720p and 1080i would play flawlessly.  Enabled sound, and the dropping frames
> > would occur again.

I had the same exact behavior

> I think the A/V diverged code is somewhat broken,
> but that just amplifies the nVidia XvMC problem.
> 

I would 100% agree...  trashing video for audio is "bad form"... and doing it badly is umm... well, my mom told me not to use words like that ;P

> > Nothing worked, until I changed the DVB recording buffer options.  MythTV 
> > defaults with 8192 for "Per PID driver buffer size" and "Packet buffer".  I 
> > changed this to 16464 and HDVD played flawlessly (well, as good as XvMC and OSD 
> > can play nice together).  So the problem doesn't appear to be sound related, 
> > just how much buffer was available to fit the signal.
> Hmm, interesting. I might just up the buffer by default...
> 

I will be trying this in my setup to see if it helps at all... *crosses fingers*

> Sure. The XvMC code used to cause machines to lock up and require a
 [snip]
> (2.8Ghz P4) and use software MPEG2 decoding, plus you get higher
> quality results.

I'm not sure how you get higher quality...  for me at least I could see no difference between hardware and software rendering when I was viewing the 1080i Olympic's back when this was working...  and having it use only 15% of the CPU to do it was VERY nice :P

> 
> Someone had promised to implement a chromakey based XvMC OSD, which
 [snip]
> surfaces. So you have a buffer of 4 frames rather than 2. My tests
> showed this is sufficient for non-sports programming @ 1920x1080
> to work well on a P4 @ 1.8 Ghz.
> 
> -- Daniel

Sounds sweet! If you need any beta testers give a holler...

-- 
Todd Freeman  Ext 6103                   .^.    Don't fear the penguins!
Programming Department                   /V\
Andrews University                      // \\    http://www.linux.org/
http://www.andrews.edu/~freeman/       /(   )\   http://www.debian.org/
                                        ^^ ^^
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20051018/bbe6d2f4/attachment.pgp