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

[Lingjiang Fang]

On Mon, 7 Dec 2020 18:39:53 -0500
Ryan Williams <ryan at runsascoded.com> wrote:

>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
The two ffmpeg binaries you used maybe different versions with different
configure options, so I think it makes no sense to do such a
comparison unless you can confirm they are binary-match.

>≈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".  
>_______________________________________________
>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".