Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg 8.0

ffmpeg.org

Post reply on HN
Print view View original

131–140 of 207 posts

Re: FFmpeg 8.0

#131

Post by idoubtit »

np1810 wrote: post #109

Thank you FFmpeg developers and contributors! 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…

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:

    Video2X-x86_64.AppImage -i "$f" \
     -c libvpx-vp9 -e crf=34 -o "${f/480p/480p_upscale2x}" \
     -p realcugan -s 2 --noise-level 1
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.

Re: FFmpeg 8.0

#133

Post by dtf »

fleabitdev wrote: post #81

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 para…

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.

[1] https://pub.smpte.org/doc/rdd36/20220909-pub/rdd36-2022.pdf

Re: FFmpeg 8.0

#134

Post by amenhotep »

Barrin92 wrote: post #67
agys wrote: post #50

Earlier quoted context omitted.

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”.

it can work but it's far from science fiction. LLMs tend to produce extremely subpar if not buggy ffmpeg code. They'll routinely do things like put the file parameter before the start time which needlessly decodes the entire video, produce wrong bitrates, re-encode audio needlessly, and so on. If you don't care enough about potential side effects to read the manual it's fine, but a dream UX it is not because I'd argu…

ffmpeg -i in -ss start -to end out is wrong and bad? You can -ss before -i? TIL!

Re: FFmpeg 8.0

#135

Post by [deleted] »

fleabitdev wrote: post #81

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 para…

[deleted]

Re: FFmpeg 8.0

#136

Post by zvr »

mrandish wrote: post #71
Culonavirus wrote: post #6

Earlier quoted context omitted.

> incantation FFmpeg arguments, the original prompt engineering

I'd also include Regex in the list of dark arts incantations.

I am perfectly at home with regexp, but ffmpeg, magick, and jq are still on the list to master.

Re: FFmpeg 8.0

#137

Post by zvr »

larodi wrote: post #26

Is anyone else on the opinion that ffmpeg now ranks 4th as the most used lib after ssl, zlib, and sqlite... given video is like omnipresent in 2025?

Curl should be up there, and "SSL" might be lower because of different implementations would split the numbers.

Re: FFmpeg 8.0

#138

Post by averne_ »

dtf wrote: post #133
fleabitdev wrote: post #81

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 para…

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 neve…

Do you have a link for that? I'm the guy working on the Vulkan ProRes decoder mentionned as "in review" in this changelog, as part of a GSoC project.

I'm curious wrt how a WebGPU implementation would differ from Vulkan. Here's mine if you're interested: https://github.com/averne/FFmpeg/tree/vk-proresdec

Re: FFmpeg 8.0

#139

Post by larodi »

zvr wrote: post #137
larodi wrote: post #26

Is anyone else on the opinion that ffmpeg now ranks 4th as the most used lib after ssl, zlib, and sqlite... given video is like omnipresent in 2025?

Curl should be up there, and "SSL" might be lower because of different implementations would split the numbers.

Curl perhaps yes, but it employs zlib and libssl to operate, right so?

Re: FFmpeg 8.0

#140

Post by 1zael »

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.

Post reply on HN