If you’re looking to manipulate video, FFmpeg is one of the most powerful tools out there. But with this power comes a considerable degree of complexity, and a learning curve that looks suspiciously like a brick wall. To try and make this incredible tool a bit less obtuse, [Sam Lavigne] has developed a web interface that lets you play around with FFmpeg’s vast collection of audio and video filters.
To try out a filter, you just need to select one from the window on the left and it will pop up in the central workspace. Here, the input, output, and any enabled filters will show up as boxes that can be virtually “wired” together. Selecting a filter will populate its options on the right hand side, with sliders and input boxes that allow you to play around with their parameters. When you want to see the final result, just click “Render Preview” and wait a bit.
If there was any downside, it seems like whatever box the site is running on the overhead of running in the browser doesn’t provide it a lot of horsepower. Even with the relatively low resolution of the demo videos available, the console output at the top of the page shows FFmpeg sometimes flirts with a processing speed measured in single-digit frames per second. Still, for a filter playground, it gets the job done. Perhaps the best part of the whole tool is that you can then copy your properly formatted command right out of the browser window and into your terminal so you can put it to work on your local files.
FFmpeg is one of those programs you should really be familiar with because it often proves useful in unexpected ways. The ability to manipulate audio and video with just a few keystrokes can really come in handy, and we’ve seen this open-source tool used for everything from compressing podcasts onto floppy disks to overlaying real-time environmental data onto a video stream.
I spent a good hour googling how to recode a movie so it had the right playback speed. Somehow I ripped it (from a legally owned DVD) with 25fps, but the movie had to play at 23.94 fps to be the right length and match with the subtitles – and then the subtitles needed to be delayed by another 6s.
Will use this webpage next time that happens.
Most movies are shot at 24/23.976fps – but European DVD releases (and TV broadcasts) speed this up by 4% to 25fps (and the run time reduces). TV Movies shot for Europe, and European TV series, are shot 25fps. (When they are shown in the US they are usually frame rate converted, but sometimes they are slowed down to 24fps for US BD releases, and/or 3:2-ed from 24fps for TV broadcast)
You will often find multiple subtitle files for different movie releases – as not only are there two frame rates to worry about, you may also find that different DVD or Blu-ray releases have different distribution stings before the main feature – and so there is a different offset on different releases.
The weird thing was that the movie played shorter than what Wikipedia and IMDB listed, but the subtitles fron that DVD were progressively more out of sync, about 3mn towards the end.
This was both on the ripped video and played from DVD with VLC. I had no other devices (old school DVD player) to test this disc on.
I have some version of Media Player Classic (maybe the MPC Black Edition?) that would keep nagging me about non-descript problems and kept suggesting I install FFmpeg (this is/was Windows 10 Home 64), so I did – and voila – everything would be in-sync again, especially in real-time playback. I presume the process includes FFmpeg inline somehow and maybe the MPC version intervenes with some FFmpeg switch settings during playback(?) I’m sorry I cannot be verbose about the solution, but at the time it was easy and it just worked. I’ve never touched it since except for the occasional MPC-what or FFmpeg upgrade. Everything is stand-alone in the same subdirectory, no installers. Warning – YMMV.
chatGPT is really good at figuring out ffmpeg args – try it out
The box on which FFmpeg runs is your own :D It’s based on ffmpeg.wasm, which is a Webassemble/JS port of FFmpeg.
Ah yeah, good call. Updated the post.
ffmpeg is a marvel. solving several complex problems and used on a planet scale.
do you remember the mess that ~2000-2010 era was when dealing with video codecs? sure, that was the “beginning” but still.
It’s also the core of several commercial media converter programs, all of which are in violation of the GPL.
ffmpeg uses LGPL (unless built with GPL components) which allows one to use ffmpeg dynamic libraries in commercial apps without any restrictions
This kind of interface is mad popular in Linux circle it seems, it’s used on many open source packages and recent software… and I don’t get it, I find it annoying and clearly not the solution and have no idea why the coders think it’s the bee’s knees.
But I have the same feelings towards web-based software, or in fact worse, I dislike it and feel it’s a silly pointless thing for the end-user.
I mean making things visual can be useful, but this kind of ‘software intuitive for 6 year olds’ approach aint it IMHO.
I look at this and see a VERY good way to get some example ffmpeg command lines – when first using it for things, I had a LOT of trouble figuring out how to construct the various pipelines for data (and my application had multiple output destinations, making it that much harder). I don’t think this is the be-all-end-all of how to get things done, but as a playground to show you how to construct the kind of command you want? Awesome!
i might be projecting incorrectly here, but i am reminded of how i learned tar from the sunos man page for it, back in 1995. i now know, the only options of interest are c x z v f t. if i want anything else, i’ll type keywords into the “/” search. but the sunos manpage gave me all the options, and in no particular order. maybe it was alphabetical? so in order to find the 6 options that might conceivably be of interest to me, i had to read dozens that were absolutely irrelevant (and downright confusing, too).
i’ve worked with ffmpeg a little bit, and basically i think the learning curve problem there is the same? and it’s compounded by the fact that googling for it yields fantastically outdated resources.
i’m just trying to say that the real trouble with ffmpeg is people trying to use reference documentation, obsolete reference documentation, and obsolete examples in place of a proper maintained tutorial. i’m with shod here, i hate drag and drop pipelines…commandline / programming language / algebraic descriptions of these processes do not leave room for improvement. the thing you’re looking for is called a “tutorial”.
i mean, i used LyX (WYSIWYG latex frontend) as a latex toturial back before i could afford to buy a book about latex. i understand it can serve that role. it can be useful. but man, what i really wanted is a tutorial.
No doubt, FFMpeg can be really confusing for people, and yeah, not unlike basically all of linux, you often find outdated and wrong explanations and tutorials, as well as some very impottant need-to-know stuff that is not in the documentation, it’s all very discouraging.
But there’s also a difference with showing it in a graphical manner and having that graphical node based thing as the actual interface. And if I for instance see the interface of Meshroom then I don’t think it’s more convenient or more clear than other ways to present an interface. and if there are more than a certain amount of nodes and patch lines it just get almost unusable since you have to constantly zoom and follow lines and zoom out again when it gets cmplex.
The flowchart (node based) interface is wholly appropriate for this use… It’s analogous to patch-built signal flows. In the old days, we used physical patch cords to lash together discreet devices.
Later on, that analogy was used in early composting tools for editing video on high-end SGI workstations (any of the Discreet Logic family of tools now owned by Autodesk).
Node based workflows make sense for signal processing.
A lot of DAW interfaces still use that metaphor of patch cables.
A lot? I can only think of Reason, but no other daw has that afaik. Maybe some modular synth plugins.
Yes ” It’s analogous to patch-built signal flows. In the old days”
But just to jump the gun and skip to the end of the plotline: Nope I don’t want a little shovel that I have to use to push little coals under a steamkettle icon to start my programs.
And I yeah get the concept, and I get it’s very visual and possible a step on a road to a usable interface. But, how about we develop the idea to something less.. flawed and THEN use it.
The graph-based approach was what I was shooting for way back in 1999 when I started the GStreamer project. The very first demo I gave to my co-workers consisted of “drawing” an mp3 player in an editor. FWIW GStreamer has literally thousands of available plugins (many of them device/environment-specific), with libffmpeg providing many dozens of them.
thanks! i’ve used gstreamer (a while ago). only thing that frustrated me was (IIRC) some API drift. but i generally found it to be better than a lot of other APIs i’ve used (less than 2 pages of code to initialize a 44100/stereo/16/signed output channel!), and, like you say, such a huge variety of plugins! the modularity kind of reminds me of the apple coreaudio, but without any of the drawbacks that turned me off of coreaudio.
i think it’s a good example of how organizing your API to make its graph explicit was useful even without a visual representation of it. the structure is what’s important, not the picture. it helps that the gstreamer documentation is pretty good! (or was, when i learned it the first time in 2009 i guess).
I played with GraphEdit many years ago. This looks so close to that
Thanks for creating GStreamer (GST).
The only problem that i have is that there is no so much demo code (i use python) for GST and i like to see that a similar tool be create for GST.
edit:
This was as a response to the post of omegacs
“..a learning curve that looks suspiciously like a brick wall” That made me laugh out loud. That really is true for ffmpeg. I feel like I’m using it for the first time, every time.