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

[Chris Dos]

Daniel Kristjansson wrote:
> I'm not sure if a Sempron 64 1600+ can
> do software decoding of HDTV. If it can, you should use that.

The Sempron 64 2600+ (1600 mhz) pushed to 2000 mhz still doesn't have 
enough horse power to to software decoding HD.  The processor is only 
running about 30% while using XvMC and playing HD in 18.1.  I also 
compiled the Debian source packages with athlon-xp and mmx options.

>>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 think the A/V diverged code is somewhat broken,
> but that just amplifies the nVidia XvMC problem.

I wonder why when I disabled the sound in MythTV HD played perfectly 
using XvMC.  That was very strange.


>>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...

Under 18.1, and increasing the buffers, HD does play perfectly even with 
the bob deinterlace running.  The only issue appears when OSD and XvMC 
is used, and that causes a few dropped frames and stuttering while the 
OSD is on the screen.  Actually, I think I remember reading that it was 
the fading out of the OSD that was messing up XvMC.

>>Does SVN no longer use the buffer settings?
> 
> It should still respect those settings.

Then I wonder if something else that has been changed.  Because 18.1 
plays great (after increasing the buffers) except for the OSD flutter. 
But the new SVN has the same problems that 18.1 did when I had the 
default settings on the buffers.

> Sure. The XvMC code used to cause machines to lock up and require a
> hard-reboot back in the 0.16 days, in 0.17 and 0.18 we added some
> X11 locking, preventing the Linux kernel lockups. We also reserved
> two surfaces for blending the OSD to the display frame, preventing
> the mythfrontend itself from locking up. This made XvMC safe to use,
> but also made it impractical to use it for HDTV, at least with the
> nVidia drivers/hardware. It works fine for HDTV on HDTV capable 
> VIA XvMC hardware;

I think I remember reading that the VIA XvMC is limited to something 
like 1024x768 resolution and it doesn't do native HD resolutions.

> but there you have 16 XvMC surfaces, rather than
> the 8 that nVidia gives you. If you think about it, after allocating 
> one frame for display, two for blending, one for the last I/P frame,
> one for the next I/P frame, and one for the currently filling B frame,
> then you only have 2 frames left for buffering. You need really fast
> graphics hardware and a really fast main processor to make that work
> at 1920x1080... It is cheaper to buy a less fast main processor
> (2.8Ghz P4) and use software MPEG2 decoding, plus you get higher
> quality results.

Well, the results are that the Sempron 64, even running at 1600 mhz, 
with the nVidia FX5200 card can handle MPEG2 decoding without a problem 
using XvMC.  Xine and XvMC work fine.  18.1 works fine except for the 
OSD flutter.  Can I provide you with any frontend logs that would better 
show what is going on?

> Someone had promised to implement a chromakey based XvMC OSD, which
> would free up the crucial blending surfaces and make HDTV viable with
> the limited nVidia drivers/hardware, but he didn't deliver. Anyway,
> implementing chromakey OSD is now on my MythTV TODO list for after
> the next MythTV release. Chromakey OSD wouldn't look as nice, it 
> would in fact look like the mplayer OSD, but it would free up 2 XvMC
> 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.

I read that someone was working on the chromakey XvMC OSD.  I was 
looking forward to that.  Bummer it didn't get completed in time.

Currently with 18.1, I can watch 1920x1080i and 720p programming (sports 
and non-sports) and not drop a single frame (minus the OSD problem).  I 
have the front end logging all the time so I can watch what is going on.

Still, it's strange that if I turned off the sound, MythTV would play HD 
fine but after I turned sound back on, diverged frames.

I think if we can possibly isolate the changes in the DVB code between 
18.1 and the current SVN, it will gives us some insight into what is 
occuring and make HD work for XvMC in the current SVN.  Though the 
differences might be so vast it might be a huge deal.

	Chris