2011-03-07, 12:10
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).
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).