Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
saites opened this issue Apr 27, 2021 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@saites
Copy link

saites commented Apr 27, 2021

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!

@generalova-kate generalova-kate self-assigned this Apr 30, 2021
@generalova-kate
Copy link
Contributor

generalova-kate commented Apr 30, 2021

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 generalova-kate added the enhancement New feature or request label Apr 30, 2021
@saites
Copy link
Author

saites commented Apr 30, 2021

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants