search

adamrehn / pixel-streaming-linux

Issue tracker repository for Pixel Streaming for Linux
https://adamrehn.com/articles/pixel-streaming-in-linux-containers/
22 stars 7 forks source link

Failed to initialize Pixel Streaming plugin because Nvidia NVENC was not installed #12

Closed amitavshaw closed 4 years ago

amitavshaw commented 4 years ago

Hi Adam, I'm trying to run the Pixel streaming on Ubuntu 18.04 natively (not dockers). Using the git repository: https://github.com/adamrehn/UnrealEngine/tree/4.23.1-pixelstreaming/Engine

When starting the packaged binary I get the error "Failed to initialize Pixel Streaming plugin because Nvidia NVENC was not installed".
Can you please help me figure out what I'm missing?

adamrehn commented 4 years ago

I'm guessing you've missed the last step from the example Dockerfile in the article:

# Create a symbolic link to the path where libnvidia-encode.so.1 will be mounted, since UE4 seems to ignore LD_LIBRARY_PATH
# (Replace "ProjectName" with the name of your actual Unreal project)
RUN ln -s /usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1 /home/ue4/project/ProjectName/Binaries/Linux/libnvidia-encode.so.1
amitavshaw commented 4 years ago

Thanks for replying. Found that application was trying to search for the symbolic link elsewhere. I packaged the binary in a separate folder. The hierarchy of the directory is something like this: Packaged/LinuxNoEditor/DummyProject/Binaries/Linux. The application expects the symbolic link to the .so file and .sym file over here. Created and copied the symbolic links in this directory and the issue was resolved.

On the other hand while trying with docker containers and following the tutorial at https://github.com/adamrehn/ue4-example-dockerfiles/tree/master/pixel-streaming/4.23, the application throws the following error after running the container:

4.23.1-8386587+++UE4+Release-4.23 517 0 Disabling core dumps. sh: 1: xdg-user-dir: not found error: XDG_RUNTIME_DIR not set in the environment. Signal 11 caught. Malloc Size=65538 LargeMemoryPoolOffset=65554 CommonUnixCrashHandler: Signal=11 Malloc Size=65535 LargeMemoryPoolOffset=131119 Malloc Size=52256 LargeMemoryPoolOffset=183392 Failed to find symbol file, expected location: "/home/ue4/project/DummyProject/Binaries/Linux/DummyProject-Linux-Shipping.sym" Engine crash handling finished; re-raising signal 11 for the default handler. Good bye. Segmentation fault (core dumped)

I used exactly the same Dockerfile provided with this tutorial.

Also how do you use the -RenderOffScreen option in Linux?

adamrehn commented 4 years ago

Could you try packaging the project in Development configuration (i.e. replace RUN ue4 package with RUN ue4 package Development in the Dockerfile, rebuild and re-run) and post the full log output please?

The -RenderOffscreen flag doesn't apply to the OpenGL RHI, to the best of my knowledge it's only necessary when using DirectX or Vulkan. So when the 4.25 version of Pixel Streaming for Linux is released with Vulkan support (no timeline to share on that unfortunately) you'll use -RenderOffscreen, but it's not needed when using the 4.23 version with OpenGL.

amitavshaw commented 4 years ago

Please find the logs as you asked for: DummyLogs.txt

It seems I'm not able to use GPU here. Can only see CPU information in the logs.

Thanks for updating about 4.25, is pixel steaming on 4.24 on the way anytime soon?

adamrehn commented 4 years ago

It looks like you haven't enabled GPU support (e.g. by specifying the --gpus=all flag to docker run), are you able to run the nvidia-smi command in the container?

Given that there were extensive architectural changes to Pixel Streaming in both 4.24 and 4.25, and Vulkan offscreen rendering support is only present in 4.25 and newer, it's likely that I'll end up simply skipping the 4.24 version, since it would involve significant additional effort in exchange for very little benefit.

amitavshaw commented 4 years ago

Thanks!! with --gpus=all I was able to get the application running. I'm quite new to dockers. Just one last thing, when I try to use the WebProxy through container it is not able to connect to cirrus. When I run the WebProxy on Linux (native), signalling server in container and the application in container it works. The docker command I run to start the 3 components are as follows:

docker run --name web webproxy:1.0 docker run --gpus=all --publish 8124:8124 --name dummy1 dummy:1.0 docker run --publish 80:80 --publish 8888:8888 --name signal signallingserver:1.0

To which the WebProxy gives the following output: [2020.07.09-12.24.07:536]: ERR: LogDefault : Failed to open log file '-2020.07.09-12.24.07.log' [2020.07.09-12.24.07:537]: ERR: LogDefault : Failed to open log file '-2020.07.09-12.24.07-WebRTC.log' [2020.07.09-12.24.07:537]: LOG: LogDefault : CmdLine: /bin/WebRTCProxy [2020.07.09-12.24.07:539]: LOG: LogDefault : Connecting to UE4 127.0.0.1:8124

But if I start just WebProxy through native Linux could start the pixelstreaming properly. Can you please point out what am I missing.

Thanks for updating about 4.25, eagerly waiting to see how its implemented there. All this is a great work!

adamrehn commented 4 years ago

I've previously discussed the networking requirements for running Pixel Streaming containers in this comment on Issue #8:

Ideally, each of these three components should be packaged into separate container images and run as three separate containers. Because the three containers need to communicate with each other via localhost, they will need to be run either with host networking mode or with a shared networking namespace (e.g. as a Kubernetes pod or through Docker Compose.)

amitavshaw commented 4 years ago

Sure thanks!! I'll try to set the networking using your guidelines. Closing this issue. Thanks