[FFmpeg-user] hwaccel vaapi and "No VA display found for device"

Mark Thompson sw at jkqxz.net
Wed Nov 23 17:29:11 EET 2016


On 23/11/16 11:48, desktop ready wrote:
> On Wed, 23 Nov 2016 10:00:25 +0000, Mark Thompson <sw at jkqxz.net> wrote :
> 
>> On 23/11/16 03:09, desktop ready wrote:
>>> Hello,
>>>
>>> I would like to confirm a bug/problem before submitting a bug
>>> report. I am working on Debian Jessie/Stable amd64 on an Intel
>>> Skylake i3-6320 and would like to decode an HEVC 8-bit encoded UHD
>>> movie.
>>>
>>> With a fresh ffmpeg github checkout I am able to use the following
>>> command without errors:
>>> ffmpeg -hwaccel vaapi -i castle.mp4 -f null -
>>>
>>> However with ffmpeg release 3.2, I have the following errors:
>>> [AVHWDeviceContext @ 0x7fdcf83adba0] No VA display found for
>>> device: . [vaapi @ 0x30a61e0] Failed to create a VAAPI device
>>> vaapi hwaccel requested for input stream #0:0, but cannot be
>>> initialized.
>>> [hevc @ 0x52bad20] Error parsing NAL unit #0.
>>
>> The device selection for VAAPI works as follows, stopping at the
>> first usable device it finds:
>>
>> 1) If the user passed a device name, try to open that name an X11
>> display. 2) If they didn't, try to open the default X11 display (i.e.
>> $DISPLAY). 3) If the user passed a device name, try to open that name
>> as the path to a DRM device. 4) If they didn't, try to
>> open /dev/dri/renderD128 as a DRM device.
>>
>> Step 4 was added after the release of ffmpeg 3.2, so you only get
>> steps 1-3 there.  Since you didn't pass a device name and
>> (presumably) aren't running X, it doesn't manage to open anything.
>>
>> In general, you always want to give it a device name; the implicit
>> selection may be right in some cases but it's better not to rely on
>> it.
>>
>> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
>> castle.mp4 -f null -
>>
> 
> Indeed it works with ffmpeg 3.2 (and the decoding is very fast),
> thanks !
> 
> Now the mystery I have to solve is why Debian ffmpeg 3.2.2 is decoding
> this file without error, but very slowly (with high CPU load).
> 
> Here is the output first with ffmpeg 3.2 from github and after that the
> output from Debian ffmpeg 3.2.
> 
> I would be grateful if someone can point the meaningful differences.

I think the Debian backport version will not include the support for H.265 with VAAPI, because it is built against a version of libva which is too old.

H.265 decoding was added in libva 1.5.0, while Debian stable contains 1.4.1.  Therefore, a backport ffmpeg would be built with the libva 1.4.1 headers and hence not include H.265 VAAPI support at all, even though at runtime you have a newer version than that.

Building it yourself uses the headers from the newer version which you have installed, and therefore does include H.265 support.

The reason you don't get an error is that the -hwaccel option fails silently when it cannot support the given codec - this exists to allow transparent support for falling back to software decode, which is exactly what has then happened in this case.

- Mark



More information about the ffmpeg-user mailing list