My current experience is that XVMC is very stable for SDTV playback but not stable with HDTV playback. As one would expect after reading all the posts, it all centers on the OSD display. With SDTV I can toggle OSD on-and-off all I want without a problem. During hidef playback, I can force a freeze within 1-2 minutes. After a lot of research I found some threads that talk about turning on "UseChromaKeyOSD" (http://www.mail-archive.com/mythtv-dev@ ... 15416.html )in the settings table. I added the row to my settings table, but it didn't have any impact.

My guess is that the code patch needed to activate this option was not included in the R5A30.2 Knoppmyth build, which would make sense since the patch is still a POC. Before I go down the path of trying to apply the patch, I thought I'd first check to see if anyone else has already tried this and, if so, what the results where. Thanks!

Marc


Backup info:

I am running a P4-2.4ghz system with a Powerspec FX5200 video card on nvida driver version 6629, knoppmyth install R5A30.2.

I have set the OSD fadeaway timing to 0 and I have set vmcUsesTextures to true' in my XF86Config-4. These two settings are what stabalized XvMC for sdef playback for me.

The chromakey OSD isn't in the stable code yet, and only exists in SVN currently. From what I've seen on the dev mailing list, it'll be included in the upcoming 0.19 release (which should be pretty soon, they've done an amazing job squashing just about all the outstanding bugs). Personally, I'm waiting (patiently, of course!) for this release. The osd won't be enabled by a checkbox or anything, you'll have to edit the database like you tried.

The chromakey OSD frees up an xvmc buffer or two for the playback. Since NVIDIA only has 8, this should make a huge difference. I've also heard it could fix the flickery OSD problems caused by bob deinterlacing.

Btw, the new 8178 driver seems to have greatly improved xvmc stability for me personally. The crashes have stopped, although the playback isn't perfect yet. But this is only for SD broadcasts scaled to 720p, I don't have a hi-def source to try yet.

Thanks for the info! I will probably wait for a Knoppmyth release that includes 0.19 to try this out.

Thanks also for the feedback on XVMC stability using 8178 drivers and SDTV. My experience with XVMC stability on SD broadcasts -- I've found XVMC to be totally stable using the 6629 driver and all of the annoying "flickering" / video studder is eliminated if you make the two changes referenced in my original post. I tried the 8178 drivers but I ran into two problems:

1. Significant increase in CPU utilization -- can't play HD recordings with my P4-2.4ghz system, with or without xvmc.

2. The 1080i modeline doesn't work -- results in blank display. Same modeline words with 6629.

It looks like others are having better results than I am with 8178...

Marc

For 1: if you have opengl vsync enabled in your playback settings, it makes the cpu usage shoot up to 100% with the 8xxx series drivers.

I've achieved 1080i with the 8178 drivers on my FX5200 (over vga) so it is possible, although I went back to 720p because it looks better to me. These 59.94 and 60hz modelines worked: http://www.linuxis.us/linux/media/howto ... ation.html

The xvmcusestextures option does seem to help quite a bit with the playback under mythtv. I only get a sort of flickering effect now after changing the aspect ratio. Unfortunately it also messes up my perfect xine xvmc deinterlaced playback. Oh well, guess I'll wait till 0.19

Misterfibble, I don't have opengl vsync enabled, but thanks for pointing that out. I know that others have had success with 8178 -- what CPU & processor speed are you using? Thanks!

Marc

I decided to try the 8178 drivers again and this time the CPU utilization is quite reasonable. My last experiment with the 8178 drivers was under the R5A16 distribution, which I now recall did not have the "opengl vsync" option on the menus -- perhaps R5A16 defaulted to having this option enabled, and that is why I had the performance problems?

In any event, 8178 now yields a very reasonable CPU utilization profile, but I am still facing the issue that my 1080i modeline that works well under the 6629 Driver with my Samsung HLR-5067 will not work under 8178 . I've tried many other 1080i modelines:



The uncommented one is the one that works with driver version 6629 -- none of them work under 8178. If anyone has a functionling 1920x1080 modeline under the 8178 driver connected to a Samsung 50" DLP (5067), I would be very interesting in it. (Misterfibble - the modelines above include the 1080i modelines listed at the site you reference.)

Marc

Any errors in XFree86.0.log?

I do recall now one error I ran into upgrading the nvidia drivers once that caused a complete black screen. It was caused by some of nvidia's opengl libraries being from the wrong driver version. Commenting out 'Load "glx"' in my X config file caused everything to come up properly. Later I removed the offending files and reinstalled the driver and I had opengl again.

This:



works on my JVC HD-56FH96 1080P tv with 8178 drivers over DVI > HDMI. This is with an nVidia 5500 card using XvMC to playback HDTV. I'm going to give these optimizations a shot as I'm running an SVN .19



[/code]

Thanks for posting that modeline. Unfortunately, it's not one I can safely use. The specs for my set show a maximum pixel clock of 72.25mhz -- 77.51 is way above spec.

Given that my 1080i modeline works with the 6629 driver but not the 8178 driver, I decided to take another approach. I diff'ed the log files created by these two different versions of the driver. The key difference I found doing a diff 6629.log 8178.log is:


So the 6629 driver declares the clock range can go up to 400.00mhz while the 8178 driver declares the clock range can go up to 350mhz.

Does anyone know what the "clock range" message is refering to? Is there an XF86Config-4 setting I can make that will change the upper end to 400mhz? Thanks!

Marc