Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
On 12/13/2020 11:02 AM, Carl Eugen Hoyos wrote: Are you endorsing a binary that violates the copyright of the FFmpeg developers? How does that violate any copyrights? Please don't make us guess. (Pointing to something is not itself an "endorsement".) If some part of that/those build(s) are license violations, how should the creator cure that? (If the license isn't violated, it's difficult to see how any copyrights would be.) Later, z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
Am So., 13. Dez. 2020 um 19:33 Uhr schrieb Ryan Williams : > > Wow, I'd missed https://hub.docker.com/r/jrottenberg/ffmpeg / > https://github.com/jrottenberg/ffmpeg somehow, looks much more > polished+complete than what I've done, thanks for the pointer. I'll update > my docs to mention it. Sorry, my understanding of docker is limited: Are you endorsing a binary that violates the copyright of the FFmpeg developers? Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
Wow, I'd missed https://hub.docker.com/r/jrottenberg/ffmpeg / https://github.com/jrottenberg/ffmpeg somehow, looks much more polished+complete than what I've done, thanks for the pointer. I'll update my docs to mention it. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
a bit crazy stuff all these pythons :-P guess it must be useful for something for some... jrottenberg's docker is much simpler and pretty universal... and w/o cuda makes <90mb... his dockerfile is very easy do mod, i made my custom docker img based on his one with all the latest libs + latest cuda + vmaf + extra usefull bins and a few custom shells in my image (tsduck etc) in 10 mins... for some running ffmpeg in dockers are a must today, e.g. we use ansible to generate a whole live transcoding conf of +100 channels running on multicast/srt/http sources on +50 nodes, 4 unified origins etc and w/o dockers it'd be a huge mess to manage network confs and restarts of failing channels. perfs are the same in docker, it's a mere env isolation technique using kernel namespaces per se ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
On 12/9/2020 8:04 PM, Lingjiang Fang wrote: re: performance, I ran one very unscientific timing comparison of the Docker version vs. my brew-installed ffmpeg (on macOS); 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. Ryan -does- say it's an unscientific comparison. That aside, anything which adds stages to an execution pipeline is going to, overall, slow down that execution (it certainly can't speed it up). In my limited experience, I (that is me, not anyone else) find that docker adds layers of complexity, especially when I'm not already using docker for anything. OTOH, I find that building ffmpeg isn't that much of a hassle, even on windoze. Different paths for different people. z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
On Mon, 7 Dec 2020 18:39:53 -0500 Ryan Williams wrote: >On Mon, Dec 7, 2020 at 11:06 AM Carl Zwanzig 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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> To unsubscribe, visit link above, or email >> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". >___ >ffmpeg-user mailing list >ffmpeg-user@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-user > >To unsubscribe, visit link above, or email >ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
Am Di., 8. Dez. 2020 um 00:40 Uhr schrieb Ryan Williams : > 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. For a very long time, 10% has been considered a huge performance impact in FFmpeg development. Carl Eugen (who has no idea what advantage or disadvantage a docker image has) ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
On Mon, Dec 7, 2020 at 11:06 AM Carl Zwanzig 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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
What are the advantages of using a docker-based ffmpeg? In my minimal research, docker adds overhead, but not much else, for most users (especially if they're using static exe's). Later, z! ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
On Mon, Dec 7, 2020 at 4:13 AM Nicolas George wrote: > Hi. > > Ryan Williams (12020-12-06): > > Just wanted to mention this in case it's helpful to anyone: > > https://hub.docker.com/r/runsascoded/ffmpeg > > > > These are Docker images I've built and published (from source releases as > > well as a few misc Git commits) using GitHub Actions on a fork of the > > GitHub FFmpeg mirror: https://github.com/runsascoded/FFmpeg#readme > > These image, some of them at least, seem to be built with the > --enable-nonfree flag. The meaning of this flag is precisely that you > are not allowed to redistribute the resulting binaries. > > Therefore, you already are in break of FFmpeg's license;, you need to > delete immediately any binary image built with the --enable-nonfree. > > Thanks for pointing that out. I deleted all the images from Docker Hub and rebuilt them without --enable-nonfree (and --enable-libfdk-aac, which seemingly requires --enable-nonfree): https://hub.docker.com/repository/docker/runsascoded/ffmpeg ``` $ docker run runsascoded/ffmpeg -version ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --prefix=/root/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --extra-libs='-lpthread -lm' --bindir=/root/bin --enable-gpl --enable-gnutls --enable-libaom --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat58. 45.100 / 58. 45.100 libavdevice58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc55. 7.100 / 55. 7.100 ``` Let me know if you see any other issues with them! Thanks, -Ryan > Regards, > > -- > Nicolas George > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
Hi. Ryan Williams (12020-12-06): > Just wanted to mention this in case it's helpful to anyone: > https://hub.docker.com/r/runsascoded/ffmpeg > > These are Docker images I've built and published (from source releases as > well as a few misc Git commits) using GitHub Actions on a fork of the > GitHub FFmpeg mirror: https://github.com/runsascoded/FFmpeg#readme These image, some of them at least, seem to be built with the --enable-nonfree flag. The meaning of this flag is precisely that you are not allowed to redistribute the resulting binaries. Therefore, you already are in break of FFmpeg's license;, you need to delete immediately any binary image built with the --enable-nonfree. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Public FFmpeg Docker images built with GitHub Actions
Just wanted to mention this in case it's helpful to anyone:
https://hub.docker.com/r/runsascoded/ffmpeg
These are Docker images I've built and published (from source releases as
well as a few misc Git commits) using GitHub Actions on a fork of the
GitHub FFmpeg mirror: https://github.com/runsascoded/FFmpeg#readme
If you have Docker installed, you can run ffmpeg without having to install
it, e.g.:
```
$ docker run runsascoded/ffmpeg -version
ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
…
```
Other versions are also available, e.g.:
```
$ docker run runsascoded/ffmpeg:4.2.4 -version
ffmpeg version 4.2.4 Copyright (c) 2000-2020 the FFmpeg developers
…
```
At the moment I've published images for 4.3.1 (which is also
"latest"/default), 4.3, 4.2.4, and 4.1.6. The Dockerfile build commands I'm
using fail on 4.0.6 and 3.4.8, and I haven't looked much at fixing them.
It might be nice to publish images like this under ffmpeg/ffmpeg (I only
see a coverity-related image with one "latest" tag not obviously tied to
any specific release under https://hub.docker.com/u/ffmpeg currently). The
GitHub Action workflow I used here is in principle upstream-able
(`DOCKERHUB_USER` and `DOCKERHUB_TOKEN` "secrets" on the FFmpeg GitHub
repo, as well as the presence of the .github/workflows/ci.yml file and
docker/build.{sh,py} scripts, would cause GitHub to run on every commit and
publish images tagged with every Git commit SHA, branch name, and tag), but
seems incompatible with existing development/release workflows, so I assume
it's not in the cards. Certainly anyone is welcome to take what I've done
and upstream some or all of it.
In the meantime I'll keep an eye out for new releases and push tags to
trigger Docker image builds for them. The /issues page is also open on my
fork in case I miss one: https://github.com/runsascoded/FFmpeg/issues
Thanks, happy to hear others' thoughts on this.
-Ryan
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
