Request: HW Accelerated ffmpeg in container

[Ranbato]

I can't get the ffmpeg in the Docker container to use HW acceleration, it doesn't look like everything is available that is required.

I have been using the following Docker container to do accelerated transcodes for other things, but obviously I can't call it from another container.
https://hub.docker.com/r/jrottenberg/ffmpeg/ the 4.1-vaapi variant.

Since it is also based on Ubuntu, it seems like using

Code:

FROM jrottenberg/ffmpeg:4.1-vaapi as base

in your Dockerfile and adding

Code:

--device /dev/dri:/dev/dri

to the recommended container creation options might be all that is required. I don't know how you are building it obviously, if you are basing it on a .NET Core image...

I'm willing to test (or build; I guess I could try the Linux install instructions) an image to get it working.

It may also give you the ability to leverage it for the web UI streaming.

[mvallevand]

The trouble with HW acceleration is it depends on the video card, what works for one GPU might not work for another. You can play with the transcode parameters in config.xml but unfortunately outside windows sub only runs ffmpeg via the path which makes it difficult to try custom version.

Rather than relying on transcoding, there is always the option of using clients like Kodi that can direct play.

Martin

[Ranbato]

Actually, the VAAPI support in ffmpeg will work with video cards or the builtin HW decoders in Intel and AMD CPUs (https://wiki.libav.org/Hardware/vaapi) so 90%+ of users of this Docker image should be supported.

I use Kodi and host the files and DB on my NAS along with this Docker image. Unfortunately the raw .ts files are 3GB/hour so if I sync the .ts to my tablet to watch on the go I would only be able to sync a few episodes. I transcode them to to ~1GB/hour .mkv files so that they are much more portable.

All we would have to do is ensure that the custom ffmpeg is on the path which can easily be done in the Dockerfile.

If not enough people want it, that is fine.

[sub]

It's definitely on my todo list.

[Ranbato]

I'm playing with this using a multi-stage Docker build. Will let you know how it goes.

FYI Yesterday the URL for http://nextpvr.com/beta/linux/NPVR.zip was working but today with the server changes it is broken.

[sub]

FYI Yesterday the URL for http://nextpvr.com/beta/linux/NPVR.zip was working but today with the server changes it is broken.

Oops. The files are back there now.

[Ranbato]

It looks like if I build the following Docker image that everything works.  Will run it for a bit and see if it is stable.

It could use some cleanup and I don't know if I did everything correctly. I suspect some of the environment variables I copied are actually used to pick the version to install.

(looks like attaching Dockerfile is not allowed)

1. Create the following Dockerfile
   
2. Execute docker build -t marktest .
   
3. Execute the next command to setup and start the container.  Modify as needed for ports and IP
   

Code:

#Dockerfile
FROM jrottenberg/ffmpeg:4.1-vaapi AS base

#https://docs.microsoft.com/en-us/dotnet/core/linux-prerequisites?tabs=netcore22
#https://github.com/jrottenberg/ffmpeg/blob/master/azure-pipelines.yml


RUN apt-get update -y && \
    apt-get install -y --no-install-recommends unzip zip curl mediainfo libc6 libgdiplus hdhomerun-config kodi-pvr-hdhomerun liblttng-ust0 libcurl4 libssl1.0.0 libkrb5-3 zlib1g libicu60 && \
    rm -rf /var/lib/apt/lists/*


RUN curl https://dot.net/v1/dotnet-install.sh -O \
&& chmod +x ./dotnet-install.sh \
&& ./dotnet-install.sh -Channel 2.2 -Runtime dotnet -InstallDir /usr/share/dotnet \
&& ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

RUN mkdir /app && cd /app
WORKDIR /app
RUN curl http://nextpvr.com/beta/linux/NPVR.zip -O
#COPY ./NPVR.zip /app/NPVR.zip  # Used when URL was broken
RUN unzip NPVR.zip


RUN find . -name DeviceHostLinux -exec chmod 755 {} \;


## cleanup


ENV  LD_LIBRARY_PATH=/usr/local/lib
ENV  ASPNETCORE_URLS=http://+:80
ENV  DOTNET_RUNNING_IN_CONTAINER=true
ENV  DOTNET_VERSION=2.2.7
ENV NEXTPVR_DATADIR=/data/
ENV NEXTPVR_DATADIR_USERDATA=/config/

CMD         ["/app/NextPVRServer.dll"]
ENTRYPOINT  ["dotnet"]

Code:

docker run -d --name nextpvr_mark --restart always \
--volume /volume1/video/nextpvr/config:/config  \
--volume /volume1/video/nextpvr/recordings:/recordings \
--volume /volume1/video/nextpvr/buffer:/buffer \
--publish 8866:8866 \
--env HOST_IP=192.168.1.xxx \
--publish 8020-8030:8020-8030/udp \
--device /dev/dri:/dev/dri  \
marktest:latest

Results on my DS918+ NAS:

No more output streams to write to, finishing. me=01:03:59.17 bitrate=1832.6kbits/s speed=2.56x                                   
frame=230022 fps=153 q=-0.0 Lsize=  859489kB time=01:03:59.25 bitrate=1833.9kbits/s speed=2.56x                                 
video:677119kB audio:179914kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.286576%                       
Input file #0 (Stumptown.S01E01.Forget It Dex, Its Stumptown.ts):                                                                 
Input stream #0:0 (video): 230042 packets read (2881013602 bytes); 230023 frames decoded;                                       
Input stream #0:1 (audio): 119937 packets read (184231872 bytes);                                                               
Input stream #0:2 (audio): 0 packets read (0 bytes);                                                                             
Total: 349979 packets (3065245474 bytes) demuxed                                                                               
Output file #0 (Stumptown.S01E01.Forget It Dex, Its Stumptown.ts.mkv):                                                             
Output stream #0:0 (video): 230022 frames encoded; 230022 packets muxed (693369611 bytes);                                       
Output stream #0:1 (audio): 119937 packets muxed (184231872 bytes);                                                             
Total: 349959 packets (877601483 bytes) muxed                                                                                 
[AVIOContext @ 0x560e80104780] Statistics: 2806 seeks, 5669 writeouts                                                           
[AVIOContext @ 0x560e800e6d40] Statistics: 3269003776 bytes read, 2 seeks