[FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions

[Ryan Williams]

On Mon, Dec 7, 2020 at 11:06 AM Carl Zwanzig <cpz at tuunq.com> wrote:

>
> What are the advantages of using a docker-based ffmpeg?


Good question… I think these images could provide advantages, at least in
some contexts, in terms of:

• Reproducibility:
    • ensuring the same ffmpeg build + environment across machines and time
    • I'm never totally sure what I'll get from brew/yum/apt-get, depending
on what repositories+versions they're updated with)
- Being a good citizen of a multi-tenant environment:
    • not installing or upgrading any system-wide libraries
    • not having to build from source yourself, which is nontrivial (see
image layers:
https://hub.docker.com/layers/runsascoded/ffmpeg/4.3.1/images/sha256-c75b6c176f02b7180362c85b05792db6b33d020b61b3e1143d822d3d3d55c982)
and seems to take me ≈30mins
• Hermeticity / Reusability:
    • I am using ffmpeg in a pipeline that involves other tools written in
Go and Python. I was building one big Docker image with all of these
libraries+runtimes, and it was unwieldy.
    • I am refactoring it to just run each piece as a separate Docker
container, the different tools are better decomposed, each have all the
exact system libraries they want, etc.

I am relatively new to using FFmpeg, so perhaps there are easy ways around
these issues without introducing Docker, but for casual FFmpeg use it's an
easy way to get started, and there's a lot of downstream tooling (workflow
managers, cloud-based schedulers, etc.) where the input is "a Docker image
wrapping an arbitrary 3rd-party tool" like I tried to do here.


> In my minimal
> research, docker adds overhead, but not much else, for most users
> (especially if they're using static exe's).
>

re: overhead, there are definitely size/bandwidth considerations to be
aware of; these images are around 3GB! I will note that in the docs.

I'm not sure pulling them uses that much bandwidth, but it seems like the
right order from watching `docker pull` progress-bars. There's surely a lot
of optimizing that that could be done to bring that size down, but
definitely something to be aware of.

re: performance, I ran one very unscientific timing comparison of the
Docker version vs. my brew-installed ffmpeg (on macOS); down-sampling a
≈500MB 40Mbps video to 10Mbps. I have Docker for Mac configured to use 7 of
8 available cores, and ffmpeg-in-docker seemed to use up to 7 cores, and
run about 10% slower than the same command in my brew-managed ffmpeg (which
can use all 8 available cores on my machine); it was something like 2m10s
vs 2m30s iirc.

So I am cautiously optimistic that performance is at least on the same
order inside Docker vs. outside, though it would be a good thing to study
further.


>
> Later,
>
> z!
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".