VLC 2.0 mkv seek problem?

[maktaduai]

Hi,

I am not sure if this has been already posted elsewhere, if so, apologies, and I would be grateful if somebody could point me to it, but my problem is:

After enabling GPU decoding in VLC 2.0 I found the following occuring when playing MKV files and trying to use the seek bar.



The above image is exactly what occurs when I try to use the seek bar to jump from one part of the video to another. This occurs when enabling GPU accelerated encoding in tools/preference/input & codec with mkv. I have tried the same on other formats and it's okay.

Is there any fix or discussions on this?

[Jean-Baptiste Kempf]

Does it happen with no-GPU decoding?
What is your GPU?

[maktaduai]

No, when gpu decoding is disabled it doesn't happen. And I have nividia gt 430. Can it be that my gpu is not adequate then? The drivers are updated.

[ArchLinux]

Ohh, nice. I have the _exact_ same problem. Have had since some "branch build" between 1.1.11 and 2.0.0 a while back. Doesn't matter if I use a clean settings directory or properly reinstall my Nvidia drivers: GPU accelerated videos produce choppy seeking.

Only happens with Windows (Arch's fine) so it would seem like this is some DXVA2 thing. My current GPU is Nvidia GTX 560 Ti but my old 9800 GT had this too.

It was driving me nuts that I couldn't find people with the same issue. Some were even saying that enabling GPU acceleration actually _fixed_ the choppiness.

[Jean-Baptiste Kempf]

Does anyone without nVidia has the issue?

[pokemon]

not on XP Pro SP3 with ATi Radeon X1650 and GPU driver v10.2

[Jean-Baptiste Kempf]

XP, you do not have GPU decoding.

[ArchLinux]

I remembered wrong, by the way: this doesn't happen with Arch. The playback just "pauses" for a moment until the newly seeked position starts - with Windows I get that choppiness (takes a bit longer to produce clear video even). I fixed my previous post too.

Maybe some DXVA2 thing then?

[Jean-Baptiste Kempf]

it seems DxVA2 + nVidia, indeed.

[maktaduai]

Okay, great DxVA2. Did a research on wikipedia for it, got even more confused

Does that mean this choppy seeking is specifically related to nvidia gpu + dxva2 when using VLC or is it something that is universal, I mean with other players too? Could it be fixed with VLC minor updates? Or will we have to wait for a driver update from nvidia to fix it? Just wondering.

In the meantime, I really love enabling the gpu decoding option because CPU usage incredibly drops down to 10% - 15% from about 70% with it enabled. I must remember not to use the seek bar though

[sylock]

I also have the same seek problem on MKV. I have a Nvidia Quadro NVS 5100M (into an HP workstation Laptop).
It appears when installing the 2.0 VLC version. Haven't had the problem before.

I'm on Windows 7 64 bits. I enabled GPU acceleration.

I just tried disabling GPU acceleration and there is no problem.

[ArchLinux]

Huh. This topic died.

Is this a driver issue or what?

[VLC_help]

Does Tools -> Messages (set Verbosity to 2) complain something during the seeks?

[ArchLinux]

Tough to say.

With GPU acceleration:

Code: Select all

main debug: auto hiding mouse cursor mkv debug: seek request to -1 (0.415000%) mkv debug: seek got 3599852000 (48%) main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 69% main debug: Stream buffering done (667 ms in 29 ms) main debug: End of audio preroll main debug: End of video preroll main debug: Received first picture main debug: Decoder buffering done in 71 ms direct3d debug: Created 310x68 texture for OSD main warning: audio output out of sync, adjusting dates (-44331 us) main warning: not synchronized (-44330 us), resampling main warning: buffer too early (-44663), down-sampling direct3d debug: Created 505x68 texture for OSD direct3d debug: Created 487x68 texture for OSD main debug: auto hiding mouse cursor

Without (same spot in the MKV):

Code: Select all

main debug: auto hiding mouse cursor mkv debug: seek request to -1 (0.415000%) mkv debug: seek got 3599852000 (48%) main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 69% main debug: Stream buffering done (667 ms in 26 ms) main debug: End of audio preroll main debug: End of video preroll main debug: Received first picture main debug: Decoder buffering done in 19 ms main warning: picture is too late to be displayed (missing 29 ms) direct3d debug: Created 310x68 texture for OSD direct3d debug: Created 505x68 texture for OSD main debug: auto hiding mouse cursor

Even with the latest nightly build the output is quite the same:

With GPU acceleration (I get these "PTS is out of range" messages without GPU acceleration too):

Code: Select all

main debug: auto hiding mouse cursor main debug: control type=3 mkv debug: seek request to -1 (0.415000%) mkv debug: seek got 3599852000 (48%) main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 69% main debug: Stream buffering done (667 ms in 12 ms) main debug: End of audio preroll main debug: End of video preroll main debug: Received first picture main debug: Decoder buffering done in 70 ms main warning: audio output out of sync, adjusting dates (74277 us) main warning: not synchronized (74277 us), resampling main warning: buffer too late (73944), up-sampling direct3d debug: Created 310x68 texture for OSD direct3d debug: Reusing 310x68 texture for OSD [...] main warning: computed PTS is out of range (70314), clearing out main warning: timing screwed, stopping resampling main warning: PTS is out of range (144489), dropping buffer main warning: computed PTS is out of range (72073), clearing out main warning: PTS is out of range (103582), dropping buffer direct3d debug: Reusing 310x68 texture for OSD main warning: computed PTS is out of range (73557), clearing out main warning: PTS is out of range (62400), dropping buffer main warning: computed PTS is out of range (75320), clearing out main warning: PTS is out of range (21497), dropping buffer main warning: computed PTS is out of range (76648), clearing out main warning: PTS is out of range (-20513), dropping buffer main warning: computed PTS is out of range (77873), clearing out direct3d debug: Reusing 310x68 texture for OSD direct3d debug: Reusing 310x68 texture for OSD [..]

Without:

Code: Select all

main debug: auto hiding mouse cursor main debug: control type=3 mkv debug: seek request to -1 (0.415000%) mkv debug: seek got 3599852000 (48%) main debug: Buffering 0% main debug: Buffering 0% main debug: Buffering 69% main debug: Stream buffering done (667 ms in 91 ms) main debug: End of audio preroll main debug: End of video preroll main debug: Received first picture main debug: Decoder buffering done in 21 ms main debug: audio output is starving (-59463), playing silence main warning: picture is too late to be displayed (missing 25 ms) direct3d debug: Created 310x68 texture for OSD direct3d debug: Reusing 310x68 texture for OSD direct3d debug: Reusing 310x68 texture for OSD [...]

[VLC_help]

No seeking errors there, so I would guess the decoder doesn't like it like that. But I don't know if there is any way to fix that.

[maktaduai]

Hope this can be fixed soon. It's just a minor bother really. I've just updated it from version 2.0.0 to 2.0.1, and it's still there. Here's hoping for a fix or whatever it is soon so that we all can start seeking without any choppiness whatsoever.

[Jean-Baptiste Kempf]

Nothing has changed on nVidia GPU side.