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

[desktop ready]

2016-11-23 16:29 GMT+01:00 Mark Thompson <sw at jkqxz.net>:

> 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.
>
>
Indeed that would explain a lot.
It is strange because in Debian Stable (Jessie) we have:
- no ffmpeg (because of the libav fork)
- libva 1.4.1
But in Debian Jessie-backports we have:
- ffmpeg 3.2.2
- libva 1.7.3.2
So I thought that ffmpeg 3.2.2 would have been built with libva 1.7.3.2,
but I may be mistaken.
I will ask the Debian team about it.

Thanks a lot for your explanations !