[mediainternals]

I'm seeing this issue too... I'd be surprised if this is just down to the nVidia support for DXVA2, strikes me more as a mishandling of the stream on the ffmpeg side of the equation, allow me to elaborate.

At first I'd assumed this was a straightforward stream splicing issue on the skip's... i.e. it simply wasn't flagging a discontinuity to the DXVA2 decoder after a seek in the video elementary stream it was passing it.

However it's more subtle than that. You see this issue when you start playing a file in the first instance, i.e. when there is no preceding stream. This is especially noticeable obviously when it is resuming mid-file.

Now in that second case the decoder has no business to try rendering anything before an IDR-slice comes along as it is in a starting state, so the only way corruption can occur is if there is a bug in the decoder itself or the stream being passed to it is mashed somehow after the IDR-slice.

I need to double check this but from memory when I see this issue during seeks the corruption that occurs seemed to be from pictures _after_ the seek point, not a mashup of before and after the seek.

Now the reason I think this isn't the nVidia driver at fault, well the DXVA2 enhanced decoding through DirectShow and MediaFoundation works just fine on seeking and of course stream start.

Something else interesting, I'm only seeing this on H.264 video streams so far, the quick tests I did with MPEG2 Video in a Transport Stream worked without problems. The H.264 I tested so far was in MKV and MP4 wrappers, same issue on both.

Hardware was an Acer Revo 3700, running W7 64bit, nVidia ION2, latest ION2 drivers, the version of XBMC that was recommended for download from about 2 weeks ago.

XBMC was configured to switch display to native framerate for the source video, clocking on the Video with audio resampling (this is a great feature and the reason I've come to XBMC - audio is a bit too wobbly at first though, some room for improvement in that rate matching algorithm still I think, a bit too agressive in it's corrections).

[Mutovkin]

I'm using Zotac GeForce GT 430 1Gb on top of Intel Core i3 540 (3.06Ghz) and 4Gb RAM.

I actually experience these issues not only on Windows 7 but Linux as well. Not all MKVs cause this to happen, but some do and do all the time. On linux it happens on Natty Narwhal 11.04 + current GIT version of XBMC with NVIDIA 270.29 drivers.

On Windows I've tried to play with VLC 1.1.7 and it always plays back correctly (I checked that HW acceleration is enabled).

What I have noticed is that matching output framerate to video source is somehow related to this issue, but I'm not sure. While matching framerate on Windows and Linux my problem is stop-motion like performance as if hardware decoding is disabled (again only on some MKVs), but even without HW decoding I would have expected pretty smooth playback on Core i3.

Previously installed XBMC Live with one of the latest Dharma RC builds and manually installed GeForce 260.xx series drivers, but had to reinstall since I could not get any sound from HDMI. What is interesting is that configuration exhibited none of the playback issues even when matching frame rate.

[Kriosym]

I have same problem. Nvidia GeForce GTX280 + Core2Duo + Win7 + latest drivers. I reinstalled Windows fresh about 2 months ago trying to resolve it, no good. It only happens when fastforwarding or rewinding, and not on all movies. It also happens on one or two movies randomly throughout the movie (even without FF/RW), but that is out of hundreds of HD 720p-1080p movies, so no biggie I can just re-encode or DL those.

All of this only with DVXA2 enabled. I can't afford to disable DVXA2 however as performance suffers significantly.

It is an irritation, having this awesome media setup tweaked to hell and playing back so smooth, and then being embarrassed when I FF/RW in front of people previous impressed. :\

Someone come up with a solution? Using MPC-HC external player works, but then I lose some control with my IR remote and toggling subtitles for anime is a pain as well, not to mention the flashing when launching external player and going back in, just not "smooth" overall.

One solution that I thought of, though I've no idea how feasible it is code wise, would be to disable DVXA2 automatically whenever fastforwarding or rewinding, and of course re-enable it when resuming normal normal playback speed.

[bradvido88]

Changing the reference frames from 3 to 2 in the h264 encoding fixed a lot of the problem for me.

[talvins]

I had the same problem when I first installed Dharma a couple of days ago - movies playing fine in MPCHC, but giving artifacts in XBMC. The artifacts appeared when I started playing the movie or when I skipped.

After I installed the latest Direct X and updated my graphics driver, the problems went away. According to a post in this thread by a dev, having the latest Direct X shouldn't matter, so it was probably the updated driver that made the trick for me. I have an ATI Radeon HD 4200 (embedded graphics). After updating the driver, all movies play just as fine in XBMC as they do in MPCHC.

I don't know if this is relevant to your problem, but it's my couple of cents.

I have a 4200 too but updated drivers doesn't change anything.
The only driver that worked spent the whole screen in strange colors (pink, purple).

This artifacts/tearing problem was clearly underestimated because lots of people have this trouble, and this on various systems (ion, ati card and embedded, nvidia card).
Each time, it works only in MPC-HC.
So, why not just integrate the codec mpcvideodec?