GNOME Bugzilla – Bug 719709
Normal user cannot encode more than one stream in parallel on a headless system (where root can)
Last modified: 2015-02-04 13:00:14 UTC
Maybe expected/normal, but when launching two pipelines in parallel doesn't work: libva info: VA-API version 0.34.0 libva info: va_getDriverName() returns 1 libva error: va_getDriverName() failed with operation failed,driver_name=i965 ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: Could not initialize supporting library. Additional debug info: gstvideoencoder.c(1426): gst_video_encoder_change_state (): /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: Failed to open encoder Btw using a headless system
Hi, could you please try the git master branch of libva? I had normally fixed a VA/DRM multithread issue there. If this works for you, we should be making it an official libva 1.2.2 release then. Thanks.
I re-tested today: gst-launch-1.0 videotestsrc is-live=true ! videoparse format=i420 width=1920 height=1080 framerate=30 ! vaapiencode_h264 ! fakesink silent=false -v But the second pipeline still fails: Setting pipeline to PAUSED ... libva info: VA-API version 0.35.1 libva info: va_getDriverName() returns 1 libva error: va_getDriverName() failed with operation failed,driver_name=i965 ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: Could not initialize supporting library. Additional debug info: gstvideoencoder.c(1428): gst_video_encoder_change_state (): /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0: Failed to open encoder Setting pipeline to NULL ... Freeing pipeline ... Environment: local/libva-intel-driver 1.3.2-1 local/gst-vaapi 0.5.8-1 CPU is i7-4771 CPU @ 3.50GHz (haswell) on H97 chipset Kernel is 3.15.2-1-ARCH
Hello, some news here: apparently, i can launch multiple pipelines as root, just not as regular user who can only launch one. Any hints on how to let the user launch multiple calls ? Btw user is in video system group already.
Just checked with Sreerenj, and the issue does not appear with Xorg.
(In reply to comment #3) > Hello, some news here: apparently, i can launch multiple pipelines as root, > just not as regular user who can only launch one. > > Any hints on how to let the user launch multiple calls ? > > Btw user is in video system group already. Hi, probably just upgrade libva to the version that supports DRM RenderNodes, along with kernel >= 3.15 to have that enabled by default. A way to check whether you have render nodes enabled or not is to only check for /dev/dri/renderDxxx device. Otherwise, if you are stuck to an older kernel, does someone else use the /dev/dri/card0 device? e.g. the X server and another user logged in than the one that tries to run a headless pipeline through ssh for instance? Or some bootsplash video program that is stalled somehow? I really suggest to look into DRM RenderNodes. The gstreamer-vaapi support is readily available in master.
I have kernel-3.16 , but doesn't seems to have /dev/dri/renderDxxx... ! Lets move this to next release for now... Most probably it is just the matter of testing with rendernodes as Gwenole explained.
Just tested on Archlinux with kernel 3.18.4 64 bits, libdrm 2.4.59, libva & libva-intel-driver 1.5.0 I do have /dev/dri/renderD128 which is root:video, and my user is in the video group. My gst vaapi is 0.5.9. Problem persists (getting an error when starting the second pipeline). libva info says: VA-API version 0.37.0 (error-ing on vaInitialize).
Florent, I've created a bug to track this on fdo for intel-vaapi driver. https://bugs.freedesktop.org/show_bug.cgi?id=88948 Let's continue the work there as the root of the problem. Thanks, Sean
(In reply to comment #7) > Just tested on Archlinux with kernel 3.18.4 64 bits, libdrm 2.4.59, libva & > libva-intel-driver 1.5.0 > > I do have /dev/dri/renderD128 which is root:video, and my user is in the video > group. > > My gst vaapi is 0.5.9. > > Problem persists (getting an error when starting the second pipeline). > > libva info says: VA-API version 0.37.0 (error-ing on vaInitialize). The official release supporting DRM-RenderNodes was 0.5.10. Prior to that, you would have had to use git. So, I suggest you try again with 0.5.10.
(In reply to comment #9) > (In reply to comment #7) > > Just tested on Archlinux with kernel 3.18.4 64 bits, libdrm 2.4.59, libva & > > libva-intel-driver 1.5.0 > > > > I do have /dev/dri/renderD128 which is root:video, and my user is in the video > > group. > > > > My gst vaapi is 0.5.9. > > > > Problem persists (getting an error when starting the second pipeline). > > > > libva info says: VA-API version 0.37.0 (error-ing on vaInitialize). > > The official release supporting DRM-RenderNodes was 0.5.10. Prior to that, you > would have had to use git. So, I suggest you try again with 0.5.10. Aha good point! I thought, Thiery was using git master while we were testing on last October and the drm_render_node patches were already landed in master at that time.
I thought that too, but reading over the whole comments again, I realized that it was originally 0.5.8, then 0.5.9 and not current git. Anyway, I am pretty sure it's enough to have DRM-RenderNodes enabled, with the appropriate gstreamer-vaapi version. :)
Hello The 0.5.10 gstreamer-vaapi release indeed fixes the issue (just came in archlinux yesterday). For reference, here is my environment now: * gstreamer-vaapi 0.5.10 * libva 1.5.0 * libva-intel-driver 1.5.0 * libdrm 2.4.59 * kernel 3.18.5 Btw the user does not require to be in the video group. Many thanks for your help, you can close the issue.
okay good , thanks for testing :) Lets close this.
(In reply to comment #12) > Hello > > The 0.5.10 gstreamer-vaapi release indeed fixes the issue (just came in > archlinux yesterday). > > For reference, here is my environment now: > * gstreamer-vaapi 0.5.10 > * libva 1.5.0 > * libva-intel-driver 1.5.0 > * libdrm 2.4.59 > * kernel 3.18.5 > > Btw the user does not require to be in the video group. > > Many thanks for your help, you can close the issue. Well, the user has to be in the same group that owns /dev/dri/renderDxxx. For security reasons, this ought to be "video" or anything similar. Otherwise, this would mean you can remote DoS systems very easily with hand-crafted videos and current VA driver infrastructure...
Apparently this is not needed on my system but i guess that it is related to systemd/logind (https://wiki.archlinux.org/index.php/users_and_groups#Pre-systemd_groups) $ groups wheel users $ ls -l /dev/dri/* crw-rw----+ 1 root video 226, 0 4 févr. 13:38 card0 crw-rw---- 1 root video 226, 64 4 févr. 13:38 controlD64 crw-rw----+ 1 root video 226, 128 4 févr. 13:38 renderD128 Launching gst-launch-1.0 videotestsrc is-live=true ! vaapiencode_h264 ! fakesink as a user did work as expected. Am i missing something here ?