Making a change to an image or video file using FFMPEG

In this example, we will leverage FFMPEG within a container in the same way we leveraged pandoc in the previous container. Using the FFMPEG container is especially handy because FFMPEG tends to rely on lots and lots of dependencies that I’d prefer not to install on my local machine. Additionally, it’s nice that the official FFMPEG container comes packaged with the latest version, and it works great!

Just like in the previous example, we can run –help after the ghcr.io/linuxserver/ffmpeg command to learn how to use FFMPEG, for example:
$ podman run –rm ghcr.io/linuxserver/ffmpeg –help

From the output (you can also view the man page maintained here: https://linux.die.net/man/1/ffmpeg), I can see a plethora of options, but for the sake of brevity, I will simply show how you can use ffmpeg from a container to convert video within a container, for example:
$ podman run –rm -it -v $(pwd):/config \
ghcr.io/linuxserver/ffmpeg \
-ss 00:00:30 -t 5 -i /config/input.mkv \
-vcodec libx265 -crf 30 /config/output.mp4

This command will start at 00 hours, 00 minutes, and 30 seconds (specified by -ss) into the video, and will record 5 seconds (specified by -t). It will then convert the video, and the output can be found in ./config/output.mp4.

Using Node.js within a container

Let’s say we need to build a Node.js application. To do this, we’ll want to use Node and npm. In Chapter 10, we discussed the usefulness of application streams and how you can leverage application streams to install different versions of Node.js. Well, just like anything else in life, there is more than one way to skin a cat.

Rather than installing Node.js on your host system, why not leverage Node.js within a container instead? The node container includes Node and npm. By default, when you run the node container, you are executing the node command, as this is the default entrypoint (as you may recall from earlier when we discussed entrypoints).

Let’s say we want to use the npm command instead – we can do this by overriding the entrypoint. At this point, we know we can override the entrypoint by leveraging bash and appending a command at the end, but we also need to know where to mount our host system:
$ podman image inspect node | podman run -i –rm stedolan/jq -r ‘.[].Config.WorkingDir’

From this, we can see that the default working directory within the container is null. Does that mean we can’t use the container the way we want? Of course not, because we can simply override the entrypoint and take matters into our own hands. In this scenario, I will mount the present working directory from my host system into an /app directory, and I’ll override the entry point to bash so I can instruct the container to change directory to /app before I run the npm command to build my Node.js application. Here’s how that can be done:
$ podman run –rm -v $(pwd):/app –entrypoint bash node -c ‘cd /app && npm run build’