<div id="readability-page-1" class="page"><div>Disclaimer: This article tested the latest LTSC Windows Server version 2022 and Windows 11 Pro (x64). Windows Server 2016 and 2019 do not provide the ‘WindowsServer’ base image.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1400/0*A-RwxHP8eNJ4VO7R" width="700" height="467" loading="lazy" role="presentation"></div><figcaption>Photo by <a href="https://unsplash.com/@skyestudios?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener ugc nofollow" target="_blank">Skye Studios</a> on <a href="https://unsplash.com/s/photos/multimedia?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener ugc nofollow" target="_blank">Unsplash</a></figcaption></figure>Starting Windows Server 2022, <a href="https://hub.docker.com/_/microsoft-windows-server/" rel="noopener ugc nofollow" target="_blank">Microsoft has released a new kind of base image called ‘WindowsServer.’</a> The ‘WindowsServer’ base image is the same as the existing base image called ‘Windows’ but designed for the Windows Server-specific feature sets and its release cadence.FFmpeg is a cross-platform multimedia transcoding software that can handle various audio, video, and image formats. You may think if the container can handle these multimedia workloads, it will be an excellent service to many users and companies. However, it’s a shame that the Windows Version of FFMPEG requires desktop APIs to run its function, and the server core container image does not have the APIs.In this case, we should consider using the ‘Windows’ base image, which has a complete set of APIs. But, this image does not fit release cadence with existing nano server and server core images. That means you cannot pull the base ‘Windows’ image with the tag ‘ltsc2022.’ Instead, you will have to choose the tag ‘20H2,’ which follows the client-side version scheme.The base image called ‘WindowsServer’ consistently solves this problem. You can change your base image name from server core to server; almost all tags will match your existing version scheme.<h2 id="1cf6">Install Chocolatey Package Manager on the Windows Container</h2>You can obtain many open-source-based Windows command-line tools on the brand-new community-driven package managers such as the Chocolatey package manager. So I want to utilize the package manager inside the Windows container too.However, unlike ~nix environments, Windows applications do not guarantee they will return exit code zero even if they have any errors. Because of this character, you may suffer; you cannot build your image with the package manager. This cumbersome also hit my work.After some trial and error, I found a stable and concise way to hedge this problem. Let’s see the code stub below.<pre>RUN powershell.exe \ Set-ExecutionPolicy Bypass -Scope Process -Force; \ iwr -Uri '<a href="https://community.chocolatey.org/install.ps1'" rel="noopener ugc nofollow" target="_blank">https://community.chocolatey.org/install.ps1'</a> -UseBasicParsing -OutFile $home/choco_install.ps1; \ powershell $home/choco_install.ps1; \ del $home/choco_install.ps1; \ exit 0;</pre><a href="https://chocolatey.org/install" rel="noopener ugc nofollow" target="_blank">In its original form</a>, the installation PowerShell script passed to the Invoke-Expression cmdlet to minimize disk I/O. But with this method, this RUN command ends up with a non-zero exit code, making the build stale.Instead, I split the single, merged command into multiple lines. Download a PowerShell script file into the home directory, and run the script via calling the PowerShell interpreter again. With this approach, the subsequent commands can not affect the exit code.Then, remove the install script because its duty has over. And lastly, ensure the entire script should return the exit code zero to continue the build process.In this way, I can make a chocolatey-powered Windows container base image. Also, this workaround worked on the server-core image.<h2 id="8696">Install one package at a single line</h2>Similarly, the choco command does not work well when I try to — or — choco command itself to install multiple packages in a single try. Let’s see the code stub below.<pre>RUN powershell.exe \ powershell choco install chocolatey-compatibility.extension -y --force; \ powershell choco install chocolatey-core.extension -y --force; \ powershell choco install ffmpeg --version=5.0.1 -y --force; \ exit 0;</pre>When you install any package via the package manager for the first time, the package manager will automatically install two core packages; the “chocolatey-compatibility extensions” and “chocolatey-core extensions” package.Unfortunately, the installation procedure will be stale if multiple packages have begun, and these symptoms look like somewhat errors due to the Windows container environment.The weird failure is gone when I split package setup commands.<h2 id="cd36">Putting Together</h2>Let’s see the full Dockerfile script.<pre>FROM mcr.microsoft.com/windows/server:ltsc2022USER ContainerAdministratorEXPOSE 3389/tcpRUN powershell.exe \ Set-ExecutionPolicy Bypass -Scope Process -Force; \ iwr -Uri '<a href="https://community.chocolatey.org/install.ps1'" rel="noopener ugc nofollow" target="_blank">https://community.chocolatey.org/install.ps1'</a> -UseBasicParsing -OutFile $home/choco_install.ps1; \ powershell $home/choco_install.ps1; \ del $home/choco_install.ps1; \ exit 0;RUN powershell.exe \ powershell choco install chocolatey-compatibility.extension -y --force; \ powershell choco install chocolatey-core.extension -y --force; \ powershell choco install ffmpeg --version=5.0.1 -y --force; \ exit 0;ENTRYPOINT [ "ffmpeg.exe" ]</pre>Then, you can build an FFmpeg Windows container with the command below.<pre>docker build -t ffmpeg:latest --isolation=process --no-cache .</pre>After then, let’s run the FFmpeg container to test.<pre>docker run --rm -i --isolation=process ffmpeg:latest -L</pre>You can see a license information message of the FFmpeg binary. In the server core container, FFmpeg fails because the container OS image does not have the required APIs.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1400/1*eZmfJl_wPlLhIN1o5jZ1Mw.png" width="700" height="373" loading="lazy" role="presentation"></div><figcaption>FFmpeg runs on the Windows container</figcaption></figure>Let’s see whether we can transcode the MP4 video into a 10-seconds GIF image with this FFmpeg Windows container. In this scenario, I will use the famous video clip “<a href="https://peach.blender.org/" rel="noopener ugc nofollow" target="_blank">Big Buck Bunny</a>.” :-)<pre>curl.exe -L <a href="http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4" rel="noopener ugc nofollow" target="_blank">http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4</a> -o movie.mp4</pre>After download, I will mount the current directory into the container as the ‘c:\data’ path. Then, pass the FFmpeg arguments through the Docker CLI arguments like below. (Note that this command is a PowerShell command.)<pre>docker run --rm -i -v "$($pwd):c:\data" --isolation=process ffmpeg:latest -ss 281.2 -t 4 -i c:\data\movie.mp4 -vf "fps=10,scale=320:-1:flags=lanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" -loop 0 -y c:\data\movie.gif</pre>Code was excerpted from <a href="https://www.codegrepper.com/code-examples/shell/ffmpeg+mp4+to+gif" rel="noopener ugc nofollow" target="_blank">the example gallery web-site</a>.A pitfall: If your container build ends up with a ContainerUser account, you will not be able to read or write the bind mount directory. If you are willing to interact files between the host and the container, you must use the ContainerAdministrator account explicitly.After running the command, you will get a small GIF file in your working directory that looks like the below. :-D<figure><img alt="" src="https://miro.medium.com/max/640/1*__-yXLRO2LnpQ-oDbXwD_w.gif" width="320" height="180" loading="lazy" role="presentation"><figcaption>Voila! The GIF image converted by FFmpeg inside a Windows container.</figcaption></figure><h2 id="668c">Conclusion</h2>Starting the Windows Server 2022 and Windows 11, you can safely ignore the container image’s build number and the operating system’s build number. Their strong coupling has gone, and now you can make your Windows container run as a process-isolated container anytime with no worries.Also, you can now build more complex applications into a container thanks to the whole “Windows Server” container base image. Because of this, we can run the FFmpeg application in the container smoothly.Unfortunately, the Azure Container Instance still does not support the Windows Server 2022 host, so the Windows Server-based FFmpeg serverless application is unavailable today (as of July, 2022). However, sooner or later, I’m expecting will Microsoft to add support for Windows Server 2022 into the existing ACI or Azure Container Apps (ACA) infrastructure.Until then, you can make your video transcoding cloud with the Windows Server-based VM scale set to support Windows-based complex multimedia workloads.</div></div>

Stories by Jung-Hyun Nam on Medium

This article explains how you can install and run FFmpeg with Chocolatey package manager in a Windows container.
Continue reading on Dev Genius »

Run FFMPEG on the Windows Container

댓글