docker_ci icon indicating copy to clipboard operation
docker_ci copied to clipboard

Can these images be used with the `gstreamer` `vaapi` plugin in a non-interactive shell?

Open saites opened this issue 4 years ago • 2 comments

Maybe I'm missing something obvious, but if I try to use this image without first initializing an interactive bash session, I cannot use the vaapi plugins. Compare the output of the following, executed on an Ubuntu 18 host:

Creating a container based on the data_dev image and directly running gst-inspect-1.0:

docker run -it --rm --device '/dev/dri:/dev/dri' \
        openvino/ubuntu20_data_dev:latest \
        gst-inspect-1.0 vaapih264enc
error: XDG_RUNTIME_DIR not set in the environment.
No such element or plugin 'vaapih264enc'

Doing the same, but running the command within the context of an "interactive" bash shell:

docker run -it --rm --device '/dev/dri:/dev/dri' \
        openvino/ubuntu20_data_dev:latest \
        /bin/bash -i -c "gst-inspect-1.0 vaapih264enc"
error: XDG_RUNTIME_DIR not set in the environment.
[setupvars.sh] OpenVINO environment initialized
Factory Details:
  Rank                     primary (256)
  Long-name                VA-API H264 encoder
  Klass                    Codec/Encoder/Video/Hardware
  Description              A VA-API based H264 video encoder
  Author                   Wind Yuan <[email protected]>
  
# <etc...>

As I understand it, using the -i flag when starting bash has many effects, including reading startup files. I can see in the output that [setupupvars.sh] runs in the interactive session. However, there seems to be something more going on. I tried creating a new derived image with an ENTRYPOINT script that sources /opt/intel/openvino/setupvars.sh (and/or .bashrc or .profile files), then execing the original command, but that is not sufficient to make the vaapi plugin available (and this may just be my misunderstanding about how bash's environment propagates -- suggestions are welcome).

Obviously, the command above (using /bin/bash -i -c) works around this issue, but it is not ideal. Is there a way to run a gstreamer command that uses the vaapi plugin within a container based on this image without using an interactive bash session?

Thanks!

saites avatar Apr 27 '21 02:04 saites

Hello, Thank you for your notice. Current images require a setup environment script. We will add a native environment to a container for future releases starting from 2022.1. Internal ticket 56507.

generalova-kate avatar Apr 30 '21 12:04 generalova-kate

Thanks for your response, and I'm happy to hear a future image might be able to offer a more native experience.

Even so, the issue I have isn't that the setup script is required, it's that it seems to work only if the session is marked interactive. Or at least, the vaapi plugin specifically fails to load in non-interactive sessions, even if the non-interactive session directly sources any combination of the various setupvars.sh scripts and/or .bashrc/.profile files, etc. I've not found a way to get those plugins to load unless they're wrapped in bash -i -c, which means I've got to introduce a lot of ugly quoting (and it gets worse if I need to pass a quoted string as an application argument, e.g., as an element property in gstreamer pipeline syntax). In fairness, the problem might be with the vaapi plugin itself (if it's for some reason detecting whether its in an interactive session & changing its behavior as a result).

I'm OK with creating an ENTRYPOINT that sources the correct files before execing the incoming command, but that still doesn't work in all cases, and I'm hoping y'all might have some guidance on what is going on during initialization that's causing this to fail in non-interactive session.

Thank you again!

saites avatar Apr 30 '21 22:04 saites