corruption after seeking w/ GPU acceleration

Microsoft Windows specific usage questions
Forum rules
Please post only Windows specific questions in this forum category. If you don't know where to post, please read the different forums' rules. Thanks.
voochi
New Cone
New Cone
Posts: 7
Joined: 06 Jun 2012 18:38

corruption after seeking w/ GPU acceleration

Postby voochi » 06 Jun 2012 18:54

When using GPU acceleration on Win7, corruption/pixellation occurs immediately after seeking.

It looks like macroblocks are getting screwed up. For example you can see the outline of a person/object but they are filled in with macroblocks from a different frame. Other times it just looks like some blocking/pixellation around the frame.

The corruption fixes itself on the next keyframe. With some encoded x264 content this can take several seconds so it looks pretty screwy.

Win7 x64
VLC 2.0.1 (both 32-bit and 64-bit)
Nvidia GPU
MKVs using x264

Lotesdelere
Cone Master
Cone Master
Posts: 9967
Joined: 08 Sep 2006 04:39
Location: Europe

Re: corruption after seeking w/ GPU acceleration

Postby Lotesdelere » 08 Jun 2012 10:19

For example you can see the outline of a person/object but they are filled in with macroblocks from a different frame.
The corruption fixes itself on the next keyframe.
Well, that does make sense to me, especially with B-frames.

Anamon
New Cone
New Cone
Posts: 9
Joined: 14 Oct 2008 02:49

Re: corruption after seeking w/ GPU acceleration

Postby Anamon » 19 Apr 2013 23:20

Well, that does make sense to me, especially with B-frames.
Actually, if the original poster has the same problem as me, it doesn't make sense. I get the same symptoms as described, but one detail is that the first frame after seeking is actually displayed correctly, and only all subsequent frames until the next keyframe get corrupted. It seems that the frame I seek to is correctly reconstructed, but the subsequent delta information is applied to an older frame from before the seek, which is apparently still kept in a buffer somewhere.

Seeking to non-I-frames shouldn't lead to corruption. I don't know how it is usually handled, whether through buffering and/or just decompressing as many frames as needed, but it should be avoided. Software decoders manage, so there's no reason why hardware decoders shouldn't.

Also, while I'm not sure whether an update of VLC or nVIDIA drivers caused the issue, I'd note that I do not get these corruption artifacts when seeking through the same video files on MPC-HC or WMP, which both use hardware decoding as well. I have updated to the lastest nVIDIA drivers and the latest stable version of VLC, to no effect.


Return to “VLC media player for Windows Troubleshooting”

Who is online

Users browsing this forum: No registered users and 70 guests