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

121–130 of 207 posts

Re: FFmpeg 8.0

#121

Post by refulgentis »

droopyEyelids wrote: post #110
mtillman wrote: post #84

Earlier quoted context omitted.

Exciting! I am consistently blown away by the talent of the ffmpeg maintainers. This is fairly hard stuff in my opinion and they do it for free.

Could you explain more about it? I assumed the maintainers are doing it as part of their jobs for a company (completely baseless assumption)

Reupvoted you from gray because I don't think that's fair, but I also don't know how much there is to add. As far as why I'm contributing, I haven't been socially involved in the ffmpeg dev community in a decade, but, it is a very reasonable floor to assume it's 80% not full time paid contributors.

Re: FFmpeg 8.0

#122

Post by Sean-Der »

shmerl wrote: post #118

Nice! Looking forward to try WHIP/WebRTC based streaming to replace SRT.

What are you using WHIP against today?

I am curious about adoption and features that would make big difference to users :)

Re: FFmpeg 8.0

#123

Post by bobsmooth »

yieldcrv wrote: post #69
Culonavirus wrote: post #11

Earlier quoted context omitted.

these days most movies and series already come out with captions, but you know what does not, given the vast amount of it?... ;) yep, finally the deaf will able to read what people are saying in a porno!

And also pirated releases are super weird and all over the place with subtitles and video player compatibility This could streamline things

There's websites where you can download subtitles. Usually from very obviously pirated released.

Re: FFmpeg 8.0

#124

Post by happymellon »

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…

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

Re: FFmpeg 8.0

#125

Post by PokestarFan »

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?

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.

Re: FFmpeg 8.0

#126

Post by gmueckl »

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…

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.

My question is: how wrong am I?

Re: FFmpeg 8.0

#127

Post by PokestarFan »

yieldcrv wrote: post #69
Culonavirus wrote: post #11

Earlier quoted context omitted.

these days most movies and series already come out with captions, but you know what does not, given the vast amount of it?... ;) yep, finally the deaf will able to read what people are saying in a porno!

And also pirated releases are super weird and all over the place with subtitles and video player compatibility This could streamline things

This is because blurays ship their subtitles as a bunch of text images. So pirates have 3 options:

1. Just copy them over from the Bluray. This lacks support in most client players, so you'll either need to download a player that does, or use something like Plex/Jellyfin, which will run FFMpeg to transcode and burn the picture subtitles in before sending it to the client.

2. Run OCR on the Bluray subtitles. Not perfect.

3. Steal subtitles from a streaming service release (or multiple) if it exists.

Re: FFmpeg 8.0

#128

Post by shmerl »

Sean-Der wrote: post #122
shmerl wrote: post #118

Nice! Looking forward to try WHIP/WebRTC based streaming to replace SRT.

What are you using WHIP against today? I am curious about adoption and features that would make big difference to users :)

I'm not using it yet, I'm using SRT for LAN streaming, and it was hard to reduce latency. I managed to bring it down to just a bit below 1 second, but supposedly WHIP can help to make it very low which would be neat.

Re: FFmpeg 8.0

#129

Post by beagle3 »

CamperBob2 wrote: post #74
tombert wrote: post #33

Earlier quoted context omitted.

Yeah I never really understood why people complain about tar; 99% of what you need from it is just `tar -xvf blah.tar.gz`.

What value does tar add over plain old zip? That's what annoys me about .tar files full of .gzs or .zips (or vice versa) -- why do people nest container formats for no reason at all? I don't use tape, so I don't need a tape archive format.

The zip directory itself is uncompressed, and if you have lots of small files with similar names, zipping the zip makes a huge difference. IIRC in the HVSC (C64 SID music archive), the outer zip used to save another 30%.
Post reply on HN