2016-11-23 16:29 GMT+01:00 Mark Thompson <[email protected]>: > On 23/11/16 11:48, desktop ready wrote: > > On Wed, 23 Nov 2016 10:00:25 +0000, Mark Thompson <[email protected]> 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 ! _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
