If there's anything that needs audio/video automation, I've always turned to FFmpeg, it's such a crucial and indispensible tool and so many online video tools use it and are generally a UI wrapper around this wonderful tool. TIL - there's FFmpeg.Wasm also [0].
In Jan 2024, I had used it to extract frames of 1993 anime movie in 15 minutes video segments, upscaled it using Real-ESRGAN-ncnn-vulkan [1] then recombining the output frames for final 4K upscaled anime [2]. FWIW, if I had built a UI on this workflow it could've become a tool similar to Topaz AI which is quite popular these days.
Even when I don't use directly ffmpeg, I often use tools that embed ffmpeg. For instance, I've recently upscaled an old anime, ripped from a low quality DVD. I used k4yt3x/video2x, which was good enough for what I wanted, and was easy to install. It embedded libffmpeg, so I could use the same arguments for encoding:
To find the best arguments for upscaling (last line from above), I first used ffmpeg to extract a short scene that I encoded with various parameter sets. Then I used ffmpeg to capture still images so that I could find the best set.
I tried the exact same steps you did with the exact same movie but with Topaz AI and got very bad results which made me abondon the project. I'd be greatful if you could share the upscaled movie.
Happy to hear that they've introduced video encoders and decoders based on compute shaders. The only video codecs widely supported in hardware are H.264, H.265 and AV1, so cross-platform acceleration for other codecs will be very nice to have, even if it's less efficient than fixed-function hardware. The new ProRes encoder already looks useful for a project I'm working on.
> Only codecs specifically designed for parallelised decoding can be implemented in such a way, with more mainstream codecs not being planned for support.
It makes sense that most video codecs aren't amenable to compute shader decoding. You need tens of thousands of threads to keep a GPU busy, and you'll struggle to get that much parallelism when you have data dependencies between frames and between tiles in the same frame.
> Happy to hear that they've introduced video encoders and decoders based on compute shaders.
This is great news. I remember being laughed at when I initially asked whether the Vulkan enc/dec were generic because at the time it was all just standardising interfaces for the in-silicon acceleration.
Having these sorts of improvements available for legacy hardware is brilliant, and hopefully a first route that we can use to introduce new codecs and improve everyone's QOL.
I haven't even had a cursory look at decoders state of the art for 10+ years. But my intuition would say that decoding for display could profit a lot from GPU acceleration for later parts of the process when there is already pixel data of some sort involved. Then I imagine thet the initial decompression steps could stay on the CPU and the decompressed, but still (partially) encoded data is streamed to the GPU for the final transformation steps and application to whatever I-frames and other base images there are. Steps like applying motion vectors, iDCT... look embarrassingly parallel at a pixel level to me.
When the resulting frame is already in a GPU texture then, displaying it has fairly low overhead.
These release notes are very interesting! I spent a couple of weeks recently writing a ProRes decoder using WebGPU compute shaders, and it runs plenty fast enough (although I suspect Apple has some special hardware they make use of for their implementation). I can imagine this path also working well for the new Android APV codec, if it ever becomes popular.
The ProRes bitstream spec was given to SMPTE [1], but I never managed to find any information on ProRes RAW, so it's exciting to see software and compute implementations here. Has this been reverse-engineered by the FFMPEG wizards? At first glance of the code, it does look fairly similar to the regular ProRes.
Impressed anytime I have to use it (even if I have to study its man page again or use an LLM to construct the right incantation or use a GUI that just builds the incantation based on visual options). Becoming an indispensable transcoding multitool.
I think building some processing off of Vulkan 1.3 was the right move. (Aside, I also just noticed yesterday that Asahi Linux on Mac supports that standard as well.)
LLMs and complex command line tools like FFmpeg and ImageMagick are a perfect combination and work like magic…
It’s really the dream UI/UX from sience fiction movies: “take all images from this folder and crop 100px away except on top, saturate a bit and save them as uncompressed tiffs in this new folder, also assemble them in a video loop, encode for web”.
LLMs are a great interface for ffmpeg. There are tons of tools out there that can help you run it with natural language. Here's my personal script: https://github.com/jjcm/llmpeg
FFMpeg is probably not as up high since video processing only needs to be done on the servers that receive media. I doubt most phones are running FFMpeg on video.
Has anyone made a good GUI frontend for accessing the various features of FFMPEG? Sometimes you just want to remux a video without doing any transcoding, or join several video and audio streams together (same codecs).
I have found the best front-end to be ChatGPT. It is very good at figuring out the commands needed to accomplish something in FFmpeg, from my natural description of what I want to do.
Joining videos together sounds easy, but there's tons of ways it can go wrong! You've got time bases to consider, start offsets, frame/overscan crops, fps differences (constant vs variable), etc. And even though your videos might both be h264, one might be encoded with B frames and open GOP, and the other not, and that might cause playback issues in certain circumstances. Similarly, both could be AAC audio, but one is 48kHz sample rate, the other 44.1kHz.
Someone else mentioned Lossless-Cut program, which is pretty good. It has a merge feature that has a compatibility checker ability that can detect a few issues. But I find transcoding the separate videos to MPEG-TS before joining them can get around many problems. If you fire up a RAM-Disk, it's a fast task.
For Mac users, ffWorks [1] is an amazing frontend for FFmpeg that surfaces most of the features but with a decent GUI. It’s batchable and you can setup presets too. It’s one of my favorite apps and the developer is very responsive.
Handbrake and Losslssscut are great too. But in addition to donating to FFmpeg, I pay for ffWorks because it really does offer a lot of value to me. I don’t think there is anything close to its polish on other platforms, unfortunately.
I haven't used a GUI I like, but LLMs like ChatGPT have been so good for solving this for me. I tell it exactly what I need it to do and it produces the ffmpeg command to do it.
The Vulkan compute shader implementations are cool...particularly for FFv1 and ProRes RAW. Given that these bypass fixed-function hardware decoders entirely, I'm curious about the memory bandwidth implications. FFv1's context-adaptive arithmetic coding seems inherently sequential, yet they're achieving "very significant speedups."
Are they using wavefront/subgroup operations to parallelize the range decoder across multiple symbols simultaneously? Or exploiting the slice-level parallelism with each workgroup handling independent slices? The arithmetic coding dependency chain has traditionally been the bottleneck for GPU acceleration of these codecs.
I'd love to hear from anyone who's profiled the compute shader implementation - particularly interested in the occupancy vs. bandwidth tradeoff they've chosen for the entropy decoding stage.
LLMs have really made ffmpeg implementations easy-- the command line options are so expansive and obscure it's so nice to just tell it what you want and have it spit out a crazy ffmpeg command.
I remember saving my incantation to download and convert a youtube playlist (in the form of a txt file with a list of URLs) and this being the only way to back up Chrome music bookmark folders.
Then it stopped working until I updated youtube-dl and then that stopped working once I lost the incantation :<
Nice! Anyone have any idea how and when this will affect downstream projects like yt-dlp, jellyfin, etc? Especially with regard to support for HW-acceleration?
Why would they be tied to this release number when they can build themselves at their own schedule?
> Note that these releases are intended for distributors and system integrators. Users that wish to compile from source themselves are strongly encouraged to consider using the development branch
What changed? I see the infrastructure has been upgraded, this seems like a big release, etc. I guess there was a recent influx of contributors? A corporate donation? Something else?
Not an insider, but I noticed that there is now a filter for using Whisper (C++) for audio transcription [1]. It looks like you provide the path to a model file [2].
Tangentially, 50% of effort goes into assembling long complex CLI commands, and 50% fighting with escaping for the shell. Adding text to a video adds it’s own escaping hell for the text.
Has anyone found a bulletproof recipe for calling ffmpeg with many args (filters) from python?
Use r-strings? Heredocs?
Agree with this, but I think LLM's have been a net positive in helping generate commands? Admittedly, getting working commands is still tough sometimes, and i'm 50/50 on whether ChatGPT saved me time vs reading docs.
This seemed to be interesting to users of this site. tl;dr they added support for whisper, an OpenAI model for speech-to-text, which should allow autogeneration of captions via ffmpeg
Heads up: Whisper support depends on how your FFmpeg was built. Some packages will not include it yet. Check with `ffmpeg -buildconf` or `ffmpeg -filters | grep whisper`. If you compile yourself, remember to pass `--enable-whisper` and give the filter a real model path.
I had a bad experience with chatgpt think maybe 3 and stopped trying. My thought was the training examples were sparse given how hard a time I had finding what I needed via search. You’ve encouraged me to revisit (and yes I know models have made big gains since then).
Kostya did a lot of the RV60/RMHD reverse engineering work for NihAV back in 2018! His blog also talks about the GPL violations from Real.
The old RV40 had some small advantages over H264. At low bitrates, RV40 always seemed to blur instead of block, so it got used a lot for anime content. CPU-only decoding was also more lightweight than even the most optimized H264 decoder (CoreAVC with the inloop deblocking disabled to save even more CPU).
Yeah, basically anytime a video or audio is being recorded, played, or streamed its from ffmpeg. It runs on a couple planets [0], and on most devices (maybe?)
ffmpeg is a treasure to the open source and audio technology communities. The tool cuts right through all kinds of proprietary and arcane roadblocks presented by various codecs and formats and it's clear a tremendous amount of work goes into keeping it all working. The CLI is of course quite opaque and the documentation for various features is often terse, but it's still the only tool on any platform anywhere that will always get you what you need for video and audio processing without ever running up against some kind of commercial paywall.
ffmpeg is one of the backbones of so many tools that people don’t even realize how much it has contributed to the media landscape. It’s my go to tool for any kind of audio/video automation.
Is there an easy way to denoise an audio file using ffmpeg to remove constant hum sound from an old audio recording introduced due to low quality of recording instrument?
Wouldn’t be surprised if Theo did a video about investing in ffmpeg and how he revived it and has been consulting to the developers and we should bow down and praise him for resurrecting ffmpeg.
np1810|6 months ago
If there's anything that needs audio/video automation, I've always turned to FFmpeg, it's such a crucial and indispensible tool and so many online video tools use it and are generally a UI wrapper around this wonderful tool. TIL - there's FFmpeg.Wasm also [0].
In Jan 2024, I had used it to extract frames of 1993 anime movie in 15 minutes video segments, upscaled it using Real-ESRGAN-ncnn-vulkan [1] then recombining the output frames for final 4K upscaled anime [2]. FWIW, if I had built a UI on this workflow it could've become a tool similar to Topaz AI which is quite popular these days.
[0]: https://github.com/ffmpegwasm/ffmpeg.wasm
[1]: https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan
[2]: https://files.horizon.pics/3f6a47d0-429f-4024-a5e0-e85ceb0f6...
idoubtit|6 months ago
pwn0|6 months ago
fleabitdev|6 months ago
> Only codecs specifically designed for parallelised decoding can be implemented in such a way, with more mainstream codecs not being planned for support.
It makes sense that most video codecs aren't amenable to compute shader decoding. You need tens of thousands of threads to keep a GPU busy, and you'll struggle to get that much parallelism when you have data dependencies between frames and between tiles in the same frame.
I wonder whether encoders might have more flexibility than decoders. Using compute shaders to encode something like VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-v...) would be an interesting challenge.
happymellon|6 months ago
This is great news. I remember being laughed at when I initially asked whether the Vulkan enc/dec were generic because at the time it was all just standardising interfaces for the in-silicon acceleration.
Having these sorts of improvements available for legacy hardware is brilliant, and hopefully a first route that we can use to introduce new codecs and improve everyone's QOL.
gmueckl|6 months ago
When the resulting frame is already in a GPU texture then, displaying it has fairly low overhead.
My question is: how wrong am I?
mtillman|6 months ago
dtf|6 months ago
The ProRes bitstream spec was given to SMPTE [1], but I never managed to find any information on ProRes RAW, so it's exciting to see software and compute implementations here. Has this been reverse-engineered by the FFMPEG wizards? At first glance of the code, it does look fairly similar to the regular ProRes.
[1] https://pub.smpte.org/doc/rdd36/20220909-pub/rdd36-2022.pdf
unknown|6 months ago
[deleted]
mappu|6 months ago
pmarreck|6 months ago
I think building some processing off of Vulkan 1.3 was the right move. (Aside, I also just noticed yesterday that Asahi Linux on Mac supports that standard as well.)
Culonavirus|6 months ago
FFmpeg arguments, the original prompt engineering
agys|6 months ago
It’s really the dream UI/UX from sience fiction movies: “take all images from this folder and crop 100px away except on top, saturate a bit and save them as uncompressed tiffs in this new folder, also assemble them in a video loop, encode for web”.
jjcm|6 months ago
larodi|6 months ago
PokestarFan|6 months ago
zvr|6 months ago
GZGavinZhao|6 months ago
_kb|6 months ago
Could be an interesting data source to explore that opinion.
zaik|6 months ago
npteljes|6 months ago
pledg|6 months ago
IshKebab|6 months ago
encom|6 months ago
unknown|6 months ago
[deleted]
xnx|6 months ago
Dwedit|6 months ago
joenot443|6 months ago
It's a great tool. Little long in the tooth these days, but gets the job done.
patapong|6 months ago
neRok|6 months ago
Someone else mentioned Lossless-Cut program, which is pretty good. It has a merge feature that has a compatibility checker ability that can detect a few issues. But I find transcoding the separate videos to MPEG-TS before joining them can get around many problems. If you fire up a RAM-Disk, it's a fast task.
filmgirlcw|6 months ago
Handbrake and Losslssscut are great too. But in addition to donating to FFmpeg, I pay for ffWorks because it really does offer a lot of value to me. I don’t think there is anything close to its polish on other platforms, unfortunately.
[1]: https://www.ffworks.net/index.html
pseudosavant|6 months ago
avhon1|6 months ago
jazzyjackson|6 months ago
mrguyorama|6 months ago
https://www.shotcut.org/
onehair|6 months ago
ricardojoaoreis|6 months ago
AlienRobot|6 months ago
TiredOfLife|6 months ago
qmr|6 months ago
https://youtu.be/9kaIXkImCAM?si=b_vzB4o87ArcYNfq
patchtopic|6 months ago
outside1234|6 months ago
1zael|6 months ago
Are they using wavefront/subgroup operations to parallelize the range decoder across multiple symbols simultaneously? Or exploiting the slice-level parallelism with each workgroup handling independent slices? The arithmetic coding dependency chain has traditionally been the bottleneck for GPU acceleration of these codecs.
I'd love to hear from anyone who's profiled the compute shader implementation - particularly interested in the occupancy vs. bandwidth tradeoff they've chosen for the entropy decoding stage.
oldgregg|6 months ago
instagraham|6 months ago
Then it stopped working until I updated youtube-dl and then that stopped working once I lost the incantation :<
josteink|6 months ago
joshuat|6 months ago
eviks|6 months ago
> Note that these releases are intended for distributors and system integrators. Users that wish to compile from source themselves are strongly encouraged to consider using the development branch
elektor|6 months ago
TeeMassive|6 months ago
oblio|6 months ago
Secondly, just curious: any insiders here?
What changed? I see the infrastructure has been upgraded, this seems like a big release, etc. I guess there was a recent influx of contributors? A corporate donation? Something else?
exprez135|6 months ago
[1]: https://github.com/ggml-org/whisper.cpp
[2]: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/13ce36fef98a...
JSR_FDED|6 months ago
Has anyone found a bulletproof recipe for calling ffmpeg with many args (filters) from python? Use r-strings? Heredocs?
edge17|6 months ago
ElectricalUnion|6 months ago
0xbeefcab|6 months ago
This seemed to be interesting to users of this site. tl;dr they added support for whisper, an OpenAI model for speech-to-text, which should allow autogeneration of captions via ffmpeg
bachittle|6 months ago
Culonavirus|6 months ago
yep, finally the deaf will able to read what people are saying in a porno!
scyzoryk_xyz|6 months ago
When I later wound up managing video post production workflows my CMD line or terminal use dropped a few jaws.
I've since been relying on LLM's to make FFMPEG commands so I don't even think about it.
cogogo|6 months ago
javier2|6 months ago
ok123456|6 months ago
mappu|6 months ago
The old RV40 had some small advantages over H264. At low bitrates, RV40 always seemed to blur instead of block, so it got used a lot for anime content. CPU-only decoding was also more lightweight than even the most optimized H264 decoder (CoreAVC with the inloop deblocking disabled to save even more CPU).
JadoJodo|6 months ago
[0] - https://xkcd.com/2347/
0xbeefcab|6 months ago
[0] https://link.springer.com/article/10.1007/s11214-020-00765-9
aidenn0|6 months ago
It also was originally authored by the same person who did lzexe, tcc, qemu, and the current leader for the large text compression benchmark.
Oh, and for most of the 2010's there was a fork due to interpersonal issues on the team.
_kb|6 months ago
tombert|6 months ago
It’s exceedingly good software though, and to be fair I think it’s gotten a fair bit of sponsorship and corporate support.
zhengyi13|6 months ago
zzzeek|6 months ago
shmerl|6 months ago
Sean-Der|6 months ago
I am curious about adoption and features that would make big difference to users :)
tush726|6 months ago
vismit2000|6 months ago
Ey7NFZ3P0nzAe|6 months ago
ekianjo|6 months ago
renewiltord|6 months ago
pabs3|6 months ago
brcmthrowaway|6 months ago
waihtis|6 months ago
wordofx|6 months ago
y_sellami|6 months ago
cronelius|6 months ago
gyan|6 months ago
jeanlucas|6 months ago
frank000010|6 months ago
[deleted]
praveenhm|6 months ago
[deleted]
ellg|6 months ago
0xbeefcab|6 months ago