Closed gabrc52 closed 3 years ago
Hmm, that's weird! Weylus is definitely built against libva 2.8.0. I just updated it to 2.10.0 and once CI is done you should be able to download the latest build here: https://github.com/H-M-H/Weylus/actions/runs/556217800
Additionally it works on my system and I run Arch Linux too. What does vainfo
report for you?
On the latest build I get the following error message instead:
[h264_vaapi @ 0x7f10cc157100] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x7f10cc157100] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x7f10cc157100] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
[h264_vaapi @ 0x7f10cc157100] Quality attribute is not supported: will use default quality level.
Output of vainfo
(from the Manjaro live media):
vainfo: VA-API version: 1.9 (libva 2.10.0)
vainfo: Driver version: Mesa Gallium driver 20.2.3 for AMD Radeon(TM) Vega 8 Graphics (RAVEN, DRM 3.39.0, 5.9.11-3-MANJARO, LLVM 11.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
The latest release works fine on Ubuntu, though.
Alright, it took a while but I think I figured out what's the problem. It seems the driver wrongly reports to support a pixel format that actually is not supported, a very similar issue can be found here https://github.com/ammen99/wf-recorder/issues/13. The solution is to force NV12 as pixel format for the affected drivers. Currently only radeon appears to be a problem.
Something I still need to figure out: How to detect radeon being used? It seems vaQueryVendorString
from libva is a good option but unfortunately ffmpeg won't let you access the underlying libva pointers...
Cool, thanks for the progress! :D
If you can't find a way to detect it, a temporary workaround would be to add a checkbox saying something like Workaround Radeon driver bug (enable if VAAPI doesn't work)
. NvIdia users already have to tick a separate checkbox, right?
Alright please try the latest build. Thanks to the nice people over there at #ffmpeg irc I found a solution!
I get a blank screen on the client and the following output:
Feb 17 12:02:11.101 INFO weylus::web: Client connected: 192.168.0.104:61774
[h264_vaapi @ 0x7f6de40d9440] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x7f6de40d9440] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x7f6de40d9440] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
[h264_vaapi @ 0x7f6de40d9440] Quality attribute is not supported: will use default quality level.
The log on the client now says undefined:Lundefined:undefined: undefined
I got a similar output on https://github.com/H-M-H/Weylus/actions/runs/556217800, but that build crashed (segmentation fault) as soon as I connected; the new build doesn't crash anymore.
I get the following vainfo
:
vaInitialize failed with error code -1 (unknown libva error),exit
I get the following output:
Feb 17 18:25:43.166 INFO weylus::web: Webserver listening at 0.0.0.0:1701...
Feb 17 18:25:46.872 INFO weylus::web: Client connected: 192.168.0.104:61909
[AVHWDeviceContext @ 0x7f396c001a80] Failed to initialise VAAPI connection: -1 (unknown libva error).
[libx264 @ 0x7f396c002200] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x7f396c002200] profile Constrained Baseline, level 6.1, 4:2:0, 8-bit
[libx264 @ 0x7f396c002200] 264 - core 161 r3039 544c61f - H.264/MPEG-4 AVC codec - Copyleft 2003-2021 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=8 lookahead_threads=8 sliced_threads=1 slices=8 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=12 keyint_min=1 scenecut=0 intra_refresh=0 rc=crf mbtree=0 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=0
Output #0, mp4, to '(null)':
Stream #0:0: Video: h264, yuv420p, 1920x1080, q=2-31
I get the following output as well:
[AVHWDeviceContext @ 0x7f84e8001a80] Failed to initialise VAAPI connection: -1 (unknown libva error).
[libx264 @ 0x7f84e8002200] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x7f84e8002200] profile Constrained Baseline, level 6.1, 4:2:0, 8-bit
[libx264 @ 0x7f84e8002200] 264 - core 161 r3039 544c61f - H.264/MPEG-4 AVC codec - Copyleft 2003-2021 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=8 lookahead_threads=8 sliced_threads=1 slices=8 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=12 keyint_min=1 scenecut=0 intra_refresh=0 rc=crf mbtree=0 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=0
Output #0, mp4, to '(null)':
Stream #0:0: Video: h264, yuv420p, 1920x1080, q=2-31
^C
This is on both the newest build and latest release.
This is my vainfo
on Ubuntu:
libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.8 (libva 2.8.0)
vainfo: Driver version: Mesa Gallium driver 20.3.2 for AMD RAVEN (DRM 3.38.0, 5.8.0-7642-generic, LLVM 11.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
Thanks for the detailed report!
the new build doesn't crash anymore
This is a good sign, I actually got it working on a radeon card myself.
I get a blank screen on the client
Do you also get a blank screen if you connect with another device or if you choose a small window?
The log on the client now says undefined:Lundefined:undefined: undefined
The latest build should improve this error message.
EndeavourOS
If vainfo doesn't work I am not surprised weylus doesn't either, perhaps the driver (libva-mesa-driver) is missing.
On Ubuntu 20.10 (Pop!_OS)
Now this is strange, vainfo works fine but weylus doesn't! Does this work ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc2=size=1920x1080 -vf 'format=nv12,hwupload' -vcodec h264_vaapi -t 10 -bf 0 -movflags frag_keyframe+empty_moov+default_base_moof test.mp4
?
Do you also get a blank screen if you connect with another device or if you choose a small window?
Yes
The latest build should improve this error message.
This is what I get now:
ERROR: Failed to obtain resource, target: [object HTMLVideoElement] type: error src: blob:http://192.168.0.113:1701/23e00341-6489-43e9-aa36-970a3ad78e1d Error object: {"isTrusted":true}
ERROR: Failed to obtain resource, target: [object HTMLVideoElement] type: error src: blob:http://192.168.0.113:1701/01fd11e5-87e3-4c9e-9fc1-e4e3e5210116 Error object: {"isTrusted":true}
Now this is strange, vainfo works fine but weylus doesn't! Does this work ... ?
Yes, it does.
I am afraid but the error message from the browser sounds like bad news: It means the video is indeed arriving at the browser but can not be decoded. Possibly because some headers could not be written properly as the warnings stated earlier.
On Ubuntu you could try this with the latest build:
WEYLUS_LOG_LEVEL=TRACE LIBVA_MESSAGING_LEVEL=2 LIBVA_TRACE=va.log WEYLUS_VAAPI_DEVICE=/dev/dri/renderD128 ./weylus
But I have to admit that I don't see how you should get this Failed to initialise VAAPI connection
message because after looking into ffmpeg's source again this means calling av_hwdevice_ctx_create
fails, which is the very first thing related to VAAPI at all and it's done the same way with the ffmpeg command line util.
Thanks for all your help again!
This is the output on Ubuntu (here, the client renders the screen fine):
Contents of va.log.*
:
[46557.338673][ctx none]==========va_TraceInitialize
[46557.338686][ctx none]=========vaInitialize ret = VA_STATUS_ERROR_UNKNOWN, unknown libva error
[46557.338773][ctx none]==========va_TraceTerminate
[46557.338822][ctx none]=========vaTerminate ret = VA_STATUS_SUCCESS, success (no error)
Hmm, the video works fine because Weylus falls back to software encoding. Sadly the logs still don't feel like spilling their secrets. The only thing I can think of is some difference between the statically linked version of libva included with Weylus and the system version. I guess I will build a dynamically linked version then.
Alright, please try running weylus_va_dynamic from the latest build. It uses the system version of libva.
The latest build crashes on Ubuntu. This is the output:
Feb 19 14:03:52.308 INFO weylus::web: Webserver listening at 0.0.0.0:1701...
Feb 19 14:03:53.104 INFO weylus::web: Client connected: 192.168.0.104:63186
[h264_vaapi @ 0x7fcf4c16f000] Driver does not support some wanted packed headers (wanted 0xd, found 0x1).
[h264_vaapi @ 0x7fcf4c16f000] Quality attribute is not supported: will use default quality level.
Output #0, mp4, to '(null)':
Stream #0:0: Video: h264 (High), vaapi_vld, 1920x1080, q=2-31
Feb 19 14:03:53.559 INFO weylus::log: Video: 1920x1080@h264_vaapi pix_fmt: bgr0
Segmentation fault (core dumped)
Alright, this is progress! But I see this is different hardware Mesa Gallium driver 20.3.2 for AMD RAVEN (DRM 3.38.0, 5.8.0-7642-generic, LLVM 11.0.0)
which wasn't blacklisted to workaround the pixel format problems I mentioned earlier. The latest build has AMD RAVEN
blacklisted too, please check if this works.
The only error I could find in the logs from libva points me to: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1428 so perhaps this issue is related.
Cool, thanks :D
From my testing on Ubuntu, it seems that hardware acceleration works now, since I didn't get any errors, and it seems smoother than CPU acceleration (no lag spikes, but these could be caused by network conditions).
I'll test with other distros tomorrow.
Awesome, that's a relieve! I guess I will make dynamically linking libva the default then.
Fedora output of vainfo
:
libva info: VA-API version 1.9.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_9
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.9 (libva 2.9.0)
vainfo: Driver version: Mesa Gallium driver 20.2.0 for AMD RAVEN (DRM 3.38.0, 5.8.15-301.fc33.x86_64, LLVM 11.0.0)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
Fedora output of ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc2=size=1920x1080 -vf 'format=nv12,hwupload' -vcodec h264_vaapi -t 10 -bf 0 -movflags frag_keyframe+empty_moov+default_base_moof test.mp4
:
ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
built with gcc 10 (GCC)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' --extra-ldflags='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' --extra-cflags=' -I/usr/include/rav1e' --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-version3 --enable-bzlib --disable-crystalhd --enable-fontconfig --enable-frei0r --enable-gcrypt --enable-gnutls --enable-ladspa --enable-libaom --enable-libdav1d --enable-libass --enable-libbluray --enable-libcdio --enable-libdrm --enable-libjack --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-liblensfun --enable-libmp3lame --enable-libmysofa --enable-nvenc --enable-openal --enable-opencl --enable-opengl --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librav1e --enable-libsmbclient --enable-version3 --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-version3 --enable-vapoursynth --enable-libvpx --enable-vulkan --enable-libglslang --enable-libx264 --enable-libx265 --enable-libxvid --enable-libxml2 --enable-libzimg --enable-libzvbi --enable-lv2 --enable-avfilter --enable-avresample --enable-libmodplug --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-lto --enable-libmfx --enable-runtime-cpudetect
libavutil 56. 51.100 / 56. 51.100
libavcodec 58. 91.100 / 58. 91.100
libavformat 58. 45.100 / 58. 45.100
libavdevice 58. 10.100 / 58. 10.100
libavfilter 7. 85.100 / 7. 85.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 7.100 / 5. 7.100
libswresample 3. 7.100 / 3. 7.100
libpostproc 55. 7.100 / 55. 7.100
Input #0, lavfi, from 'testsrc2=size=1920x1080':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
[h264_vaapi @ 0x559cdfa53980] No quality level set; using default (20).
[h264_vaapi @ 0x559cdfa53980] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x559cdfa53980] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x559cdfa53980] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
Output #0, mp4, to 'test.mp4':
Metadata:
encoder : Lavf58.45.100
Stream #0:0: Video: h264 (h264_vaapi) (High) (avc1 / 0x31637661), vaapi_vld, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 25 fps, 12800 tbn, 25 tbc
Metadata:
encoder : Lavc58.91.100 h264_vaapi
frame= 250 fps= 51 q=-0.0 Lsize= 15686kB time=00:00:09.96 bitrate=12901.3kbits/s speed=2.02x
video:15684kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.013537%
But trying to play it displays "No valid frames decoded before end of stream"
Whoops, I am sorry, but I forgot to tell you that I switched things around. weylus
has the dynamic version of libva now and weylus_va_static
is what didn't work previously so please try weylus
.
Oops, sorry, I didn't realize it said "static".
On Manjaro, ./weylus
crashes:
On Fedora, I still get the
[h264_vaapi @ 0x7f0d402ca500] Driver does not support some wanted packed headers (wanted 0xd, found 0).
[h264_vaapi @ 0x7f0d402ca500] Driver does not support packed sequence headers, but a global header is requested.
[h264_vaapi @ 0x7f0d402ca500] No global header will be written: this may result in a stream which is not usable for some purposes (e.g. not muxable to some containers).
[h264_vaapi @ 0x7f0d402ca500] Quality attribute is not supported: will use default quality level.
and the client can't play the video with:
ERROR: Failed to obtain resource, target: [object HTMLVideoElement] type: error src: blob:http://localhost:1701/29bdb1cf-8f14-4502-b2fe-42e75552a4c7 Error object: {"isTrusted":true}
ERROR: http://localhost:1701/lib.js:L305:0: IndexSizeError: Index or size is negative or greater than the allowed amount Error object: {}
It might be a distro issue, since I get the same error message from ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc2=size=1920x1080 -vf 'format=nv12,hwupload' -vcodec h264_vaapi -t 10 -bf 0 -movflags frag_keyframe+empty_moov+default_base_moof test.mp4
:
Generated test.mp4:
https://drive.google.com/file/d/1eMOoN6G7KZ-uo5DUQKh3bLtkErAkSn2q/view?usp=sharing
(The video doesn't seem to be playable).
Fedora contents of va.log.220225.thd-0x000018d2
:
Ah great, thanks for the help! The video you generated confirms my suspicions and running ffprobe tells me [extract_extradata @ 0x56334679a040] No start code is found.
, sadly this means that ffmpeg can't hardware encode to the required format and there is nothing I can do about it.
And I am pretty sure I know why it crashed on Manjaro this time, it was more or less a typo in my C code https://github.com/H-M-H/Weylus/commit/a2092ea18dfea59d1b5050d77c2484a96343e440 , now it shouldn't crash anymore.
Okay, thanks. Now on Manjaro I'm getting a very similar result as Fedora (broken ffmpeg command [similar ffprobe error] and "Failed to obtain resource"). I'm guessing this should be filed as an upstream bug/regression?
To me it looks like those are mesa issues. Here is what I could dig up:
Pixel formats reported as supported even though they are not:
Encoded video being invalid
I think this is as far as we can get here.
Okay, thanks for all your help!
Likewise! I am closing this for now.
On Manjaro (Arch-based), trying to use VAAPI acceleration results in the following error:
From a web search, I found this Arch bug: https://bugs.archlinux.org/task/56298
From that and the error message, it could be inferred that Weylus was built against libva 1, but Manjaro comes with libva 2. Would it be possible to get Weylus for the newer libva?