Simple lightweight container to run ffprobe
.
This uses Alpine v3.15.1
and ffprobe v4.4.1
.
Note: I haven't explored buildx
yet as a multi-arch solution.
This project is now on Docker Hub under the same name (mikeoertli/ffprobe-docker)! Instead of needing to clone this repo and build, you can just pull down the pre-built images and run with those.
The docker pull
command is:
docker pull mikeoertli/ffprobe-docker
ffprobe
is a part of the FFmpeg library.
The ffprobe
version number is kept in ffprobe-version.txt
so this build command doesn't need to change.
However, the Dockerfile
is currently manually kept in sync with the txt
file.
Building ARM:
docker build --platform linux/arm64 -t mikeoertli/ffprobe-docker:"$(cat ffprobe-version.txt)-arm64" -t mikeoertli/ffprobe-docker:latest .
Building AMD:
docker build --platform linux/amd64 -t mikeoertli/ffprobe-docker:"$(cat ffprobe-version.txt)-amd64" -t mikeoertli/ffprobe-docker:latest -f Dockerfile.amd64 .
These images are published to Docker Hub under mikeoertli/ffprobe-docker
.
Right now, GitHub actions only support amd64
architecture, so for now, those are the only images that are build and published automatically.
Images for arm64
architecture must be pushed manually, the command to do that is:
docker push mikeoertli/ffprobe-docker:"$(cat ffprobe-version.txt)"-arm64
Images for amd64
architecture are pushed when tagging the repo with a tag matching the format of v*.*-*
.
In addition to automatic publication via GitHub Actions, repos can also be pushed manually, the command to do that is:
docker push mikeoertli/ffprobe-docker:"$(cat ffprobe-version.txt)"-amd64
There are a couple important items to note:
- You will need to provide a file name.
- As shown below, a Docker Volume is created that maps the current working directory on the host machine to
/temp
inside the container. - The
WORKDIR
is/temp
, since this is where files are expected, a relative file reference is fine.
docker run -it --name ffprobe --rm -v $(pwd):/temp mikeoertli/ffprobe-docker:latest "<FILE>"
You can still pass command line args, for example, if you want to print the format using the flat
format with -show_format -print_format flat
, you can.
docker run -it --name ffprobe --rm -v $(pwd):/temp mikeoertli/ffprobe-docker:latest -show_format -print_format flat "/temp/<your_file>.m4a"
More useful info about options for ffprobe
can be found via helpmanual.io among many other sources.
The --rm
on the run
command will auto-delete the container when it stops (you can read more about this here). This makes it easier to use this containerized ffprobe
solution in a way more similar to running it natively (this can be helpful when called from a script, too).
The container sets a CMD
value of --help
, this serves as the default parameter if none is provided when the container is run. According to the Dockerfile Best Practices:
The best use for
ENTRYPOINT
is to set the image’s main command, allowing that image to be run as though it was that command (and then useCMD
as the default flags).
To put it differently, if you don't pass an audio file argument to the docker run
command, you're effectively performing the equivalent of executing ffprobe --help
from a native command line.
In order to make this (appear to be) a "true" drop-in replacement for running ffprobe
natively, you could define an alias... something like this:
alias ffprobe='docker run -it --name ffprobe --rm -v $(pwd):/temp mikeoertli/ffprobe-docker:latest'