VLC 3.0.2 hardware acceleration problems on Debian

[amarcine]

Hi,

I already posted this as a bug in Debian (https://bugs.debian.org/cgi-bin/bugrepo ... bug=899384) :

After recent upgrade to 3.0.2 when I try to increase the speed above certain level (16x), the video is frozen. The same procedure on the same movie file worked without problem up to 64x before the upgrade. Looks like there is some problem with hardware acceleration, which is set to AUTO in the VLC config - I am getting the following error in the console:

libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open
/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
[00007f249c016240] vaapi generic error: profile(3) is not supported
Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object file: No such file or directory

I am doing this on a laptop with integrated Intel graphics + Optimus nvidia card. What I understand is happening it tries to run vaapi (fails) and then falls back to vdpau, which also fails. The vdpau probably would require to run with nvidia card, but unfortunately
> optirun vlc
is unable to open the Qt interface and falls back to console interface which is pretty useless (at least for my case).

Maybe the new VLC version requires newer libva - libva2, which provides VA-API 1.0.0?

If the problem with VA-API cannot be solved, then maybe it is easier to make VLC Qt interface run with optirun? While it would not bring the user experience back to what was before upgrade to 3.0.2 (hardware acceleration out-of-the-box on Intel graphics), it would still be acceptable.

but I am not sure if it is really due to a problem in Debian or VLC 3.0.2 itself. I would appreciate if somebody from VLC community could comment on that, so that the problem is reported in the correct place. Basically there seem to be 2 different problems:
- failure of VA-API with unsupported profile(3) - libva vs libva2
- failure of Qt interface with optirun

Best regards,
Antoni

[Rémi Denis-Courmont]

Codec profile is not supported by your Intel card, at least as reported by the VA-API driver. In all likelihood your iGPU just cannot handle it.

As for Qt support issues, wrong venue.

[amarcine]

My observation is that I could watch the same file on this machine in 64x speed before upgrade to 3.0.2. The only thing that changed is VLC. Could it be that it did work without hardware acceleration before, but there is some non-hardware-acceleration problem in 3.0.2 that would cause it to hang when the speed is increased beyond 16x?

[Rémi Denis-Courmont]

I don't have your exact hardware and system installation. I cannot answer a question on performance.

Given how fringe a use case playing at 16x is, it is unlikely that anybody will come forward. You need to figure that out yourself.

[amarcine]

Hello again,

As I mentioned at https://bugs.debian.org/cgi-bin/bugrepo ... bug=899384 I have some new findings.

Let me make the full description of what I am doing. I am converting a set of photos into a movie for monitoring purposes. Since frequently the movie shows lights blinking and no action that requires my attention, I watch these movies changing playback speed to run through non interesting parts and slow down for interesting ones. I make these movies using ffmpeg:

Code: Select all

ffmpeg -v error -y -r 24 -f image2 -pattern_type glob -i '*'.jpg -vcodec mpeg4 -r 24 -q:v 8 movie.mp4

Formerly (when everything worked smoothly for VLC 2.2.x) I used mpeg4 codec. Now for the test, I prepared 3 movie files using mpeg4, h264 and mpeg2video.

For the case of VLC 2.2.x - VLC 2.2.7 on my laptop and my desktop, both on Debian 9, VLC 2.2.6 on my laptop but on Win10 64bit - for all 3 movies I was able to increase the playback speed to 31.25x (shown on status bar; the value displayed in the top right corner of the screen went up to 64x, but looks like the status bar was showing the actual speed), with some minor artefacts - green squares for h264 file. Hitting "+" to increase speed further had no effect. Then I could reduce the speed without problem. This is the desired state.

For the case of VLC 3.x.x - VLC 3.0.2 on my laptop and my desktop, both on Debian 9, VLC 3.0.3 on my laptop but on Win10 64bit - the movie freezes for all 3 codec cases once 16x is crossed. That is time goes further, but the image does not change. It should be noted that at least for mpeg2video the hardware acceleration with VA-API works (for both machines on Debian), but still the movie freezes. There are some exceptions from this unwanted behaviour:
- for laptop on Debian with 'optirun cvlc', the h264 works (but the other 2 are still frozen)
- for desktop on Debian h264 works - this is why in Debian bug report I said that I've found the workaround (unfortunately on laptop this doesn't work, only 'optirun cvlc' without the Qt interface)

For Debian tests I have outputs of 'cvlc/vlc -vvv' as .tar.gz file:
https://drive.google.com/open?id=1RxFCg ... npJEJdyJ-z
- report_optirun_3.0.2*.txt - VLC 3.0.2 on laptop on Debian with 'optirun cvlc'
- report_desktop*.txt - VLC 3.0.2 on desktop on Debian
- report_3.0.2*.txt - VLC 3.0.2 on laptop on Debian
- report_2.2.7*.txt - VLC 2.2.7 on laptop on Debian, but for desktop the behaviour was the same (i.e. no problems)

Comparison with the case of Win10, where 2 different 2.2.x and 3.x.x versions than on Debian were used, shows that actually this is not a Linux specific problem. So this part of forum is probably not appropriate any more. The fact that 3.x.x is broken even with VA-API hardware acceleration for mpeg2video and checks with different codecs and machines shows that it is something more general than just the unlucky codec/hardware combination.

Could it be that in 3.x.x when some frames are being missed the image is frozen, while for 2.2.x the frames simply didn't appear but the next ones did? Was there a change in 3.x.x regarding behaviour of VLC when it cannot render a frame because the speed is too large?

I think there is a general regression in 3.x.x which deserves attention from developers. Should I post this message as a bug report? Or do you still think that it is too fringe a case for developers to spend time on fixing this?

Best regards,
Antoni Marcinek

[Rémi Denis-Courmont]

Are you even using the same FFmpeg version and smae hardware/software decoder settings in both cases? And even if you are, how do we know that the performance "regression" is not necessary to fix some bug?

If you can pinpoint the problem to a suboptimal implementation in a specific part of the VLC code, then sure file a bug. But if it's at the level of "it fails at 16x", then don't bother.

[amarcine]

What do you mean by "in both cases"?

"the performance "regression" is not necessary to fix some bug" Do you mean, that it might be necessary to introduce some regression to fix the problem that I observe?

The final part I understand. So if I say bisect to find commits which introduce this behaviour, may I file a bug?

[amarcine]

I just found the problematic commit in git://git.videolan.org/vlc/vlc-3.0.git : 3f5daf4d2f5501a5e8868bf2dbfccbe615cfdf5a

[Jean-Baptiste Kempf]

That's weird.

[InTheWings]

I just found the problematic commit in git://git.videolan.org/vlc/vlc-3.0.git : 3f5daf4d2f5501a5e8868bf2dbfccbe615cfdf5a

Well, since that should only drop preroll blocks, that's pretty confusing.

Seems to me the bug is it taking the path requiring internal frame drop,
because the required output is changed by the framedrop algorithm, and it never recovers, because frame is never output,
but that should only happen with avcodec-hurry-up which is on by default.

What's weird is that you never hit the "11 frames late" warning...

You should test with:
--no-avcodec-hurry-up

And there's also some changes in post VLC 3, if you can try master branch

[amarcine]

--no-avcodec-hurry-up Is it a build option? I cannot find it in the output of 'vlc --help'

As for the master branch and post VLC 3, I am pretty confused with VLC Git repositories layout. You seem to have branches divided into separate repositories. So the master branch of which repository should I look into?

[amarcine]

Additionally I can provide the 3 movies that I tested + console output from ffmpeg while they were produced showing ffmpeg and libraries versions, if that might be of any help

[InTheWings]

see also https://forum.videolan.org/viewtopic.ph ... 2&p=475207

[InTheWings]

--no-avcodec-hurry-up Is it a build option? I cannot find it in the output of 'vlc --help'

As for the master branch and post VLC 3, I am pretty confused with VLC Git repositories layout. You seem to have branches divided into separate repositories. So the master branch of which repository should I look into?

I have issues at 4X on 3.0 which does not exists in master. --no-avcodec-hurry-up does not help for me.
I'm checking the issue

[InTheWings]

Well seems hw decoding does not work on my master..

Anyway,
with hardware decoding, i can't even get flawless 2X with 2.2, 3.0 or master. Speed up only works with software decoding.

Might be hw decoders limitation, sleeping internally for power conservation due to hardcoded fps

[InTheWings]

rate speedup issue dissapears with hardware if b_force=true picture display... weird

[InTheWings]

Seems the issue is just HW decoding being not able to push above 30 or 60 fps on those cards.

VAAPI will provide vaQueryProcessingRate in the future so we can probably get more accurate capabilities.

[amarcine]

Dear InTheWings,

Are you discussing now the https://forum.videolan.org/viewtopic.php?f=14&t=145092 or my issue?

Still you didn't answer to these questions:
- is --no-avcodec-hurry-up a build option?
- the master branch of which repository should I look into?

I also didn't get answer to other questions:
- should I post a link to the 3 movies that I tested + console output from ffmpeg while they were produced?
- should I submit this as a bug?

Cheers,
Antoni

[amarcine]

I checked with --no-avcodec-hurry-up and indeed the problem of freeze is gone. Thank you! Now I have a good workaround.

I also checked current master of git://git.videolan.org/vlc/vlc-3.0.git that is commit 3.0.3-1-45-g531fb72410. It behaves exactly as 3.0.2.

[InTheWings]

I checked with --no-avcodec-hurry-up and indeed the problem of freeze is gone. Thank you! Now I have a good workaround.

I also checked current master of git://git.videolan.org/vlc/vlc-3.0.git that is commit 3.0.3-1-45-g531fb72410. It behaves exactly as 3.0.2.

Your HW decoding isn't fast enough to playback those speeds.
--no-avcodec-hurry-up will just not drop, so you're not playing expected speed but drifting at max possible speed, and possibly run out of memory.
If you want to use high speed rate, use cpu, cpu speed bound, only.

[amarcine]

Your HW decoding isn't fast enough to playback those speeds.
--no-avcodec-hurry-up will just not drop, so you're not playing expected speed but drifting at max possible speed, and possibly run out of memory.

I think I am not using HW decoding at all. With e.g. optirun (nVidia card) I didn't observe any problems with playback.
What does "drifting" mean? That I am seeing only some frames out of all and actual playback at this speed would mean that I would see all of them, but switching very fast?

If you want to use high speed rate, use cpu, cpu speed bound, only.

How to "use cpu, cpu speed bound, only"? You mean that I should not increase the speed to the level where playback fails, or that I should change something in settings?

VAAPI will provide vaQueryProcessingRate in the future so we can probably get more accurate capabilities.

For h264 I am not using VA-API I think - at least I do not get a message about this, contrary to mpeg2video where I do get the message that VA-API is used. Anyway, do you mean that in the future, VLC will be able to realise that the user is trying to go beyond hardware capabilities and prevent it?

[blugir]

For the case of VLC 2.2.x - VLC 2.2.7 on my laptop and my desktop, both on Debian 9, VLC 2.2.6 on my laptop but on Win10 64bit - for all 3 movies I was able to increase the playback speed to 31.25x (shown on status bar; the value displayed in the top right corner of the screen went up to 64x, but looks like the status bar was showing the actual speed), with some minor artefacts - green squares for h264 file. Hitting "+" to increase speed further had no effect. Then I could reduce the speed without problem. This is the desired state.

thanks for your sharing