Sandybridge H264 dxva

Seems like someone has a problem in the nightly build similar to the people in this thread (DEVICEHUNG)
http://forum.xbmc.org/showthread.php?tid=81367

Did you ever figure out why it happened and what fixed it?
The weirdest thing is that it doesn't crash when debug-logging is enabled...

Intel drivers are less forgiving than nVidia or ATI. In that case the subtitle had a picture with no characters and the driver was asked to render zero primitives. It crashed.

Running with the D3D debug runtime is pretty useful to identify the weird problems, to get more information and a more accurate crash point. XBMC in release mode can be run under a debugger to get the D3D debug messages.

I have an i3-2100 HTPC.

Without using a different filter (such as LAV), neither XBMC, MPC-HC or VLC work. They ALL experience severe macroblocking for certain h264 encoded content in DXVA2 (hardware).

I also have a Virtu solution, so can switch to using my GTS450 istead of the Intel chip for video which has no issues with DXVA2. No .dll's posted in these forums have worked, and no build (HEAD) or otherwise has helped in getting XBMC (through FFMPEG) to work with these sources. I can post some screenshots later, including full logs from XBMC, VLC or MPC-HC.

This appears to be a poor implementation of DXVA2 in FFMPEG. However, if LAV works, which is open source, why doesn't FFMPEG?

Interestingly, as of today, there's an Intel guy who's released a new ffdshow filter hoping to fix DXVA2 running correctly in ffdshow, which he says will be integrated into the whole of that process. Is this likely to generate some quick patches for XBMC's own implementation of DXVA2 on Intel hardware?

Have you tried the nightly build ?

The reason I ask is because I found a lot of macroblocking with certain files using an old Radeon 2600 Pro which were "fixed" by the ffmpeg implementation in the nightly build.