jbk

For those interested in the work being done, with a bit more details that just the Changelog, I wrote a longer blogpost about the work here: https://jbkempf.com/blog/2026/ffmpeg-9.0/

More details about the ongoing work on Swscale rewrite, on the various Vulkan changes, the assembly detailed and a bit of statistics about this release.

Read the list of patents left: a lot of them are on SVC (no one uses this) and on higher profile.

For a lot of use cases, including Basic and Main profile, H.264 is already free.

> AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.

Yes, this is going to be fun to watch.

Because it's 5 times more complex, you need to get the maximum performance available. Therefore more ASM than ever.

Rust does not bring more performance. Just more safety.

> I'm not sure what these two lines mean or if we can compare them, any help?

AV2 saves 25% bandwidth at the cost of 5x more decoding complexity.

It was difficult to find a nice name, with av2 :(

It works in French d2vid (Deuvid)

So you can scrobble and it gets you new music? But so, how can you listen to that new music?

No, since the format is not final.

This is amazing. I started doing the same, but I did not have the time to polish it.

Questions: why no X? Do you have a feature to resize (summarize?) to the text to fit into short boxes?

Kyber | Low-level Developers and Sales | Paris area (hybrid) and Remote in Europe | Full-time | kyber.media

Kyber is an open-source SDK and platform to control remote machines, from Remote Desktop to Robots Teleoperation/Teleobservation.

Kyber is a multi-stream and multi-actuator transport in extremely-low latency, over Quic; it encloses the server, the client and the protocol.

One could use Kyber to control robots, drones, desktop, servers in the cloud or just remote rendering of interactive 3D programs. Kyber is done for Remote RealTime, where every millisecond matters.

Kyber is developed by engineers from the VLC and FFmpeg community, and we code in Rust, in C and in assembly. We have some development in Go too.

We're a quite technical team, but cool to work with.

Contact: jobs -- at -- kyber.media (subject: “HN job”)

Kyber | Low-level Developers | Paris area (hybrid) and Remote in Europe | Full-time | kyber.media

Kyber is an open-source SDK and platform to control remote machines, from Remote Desktop to Robots Teleoperation/Teleobservation.

Kyber is a multi-stream and multi-actuator transport in extremely-low latency, over Quic; it encloses the server, the client and the protocol.

One could use Kyber to control robots, drones, desktop, servers in the cloud or just remote rendering of interactive 3D programs. Kyber is done for Remote RealTime, where every millisecond matters.

Kyber is developed by engineers from the VLC and FFmpeg community, and we code in Rust, in C and in assembly. We have some development in Go too.

We're a quite technical team, but cool to work with.

Contact: jobs -- at -- kyber.media (subject: “HN job”)

How so?

> Can't imagine any valid reason for that...

Depends of your paranoia level: either because laziness or because of evil intentions...

> But who needs debugging right? ;)

Debugging and testing is just for the non-believers.

Unless they use Android TV, for example: See https://dev.to/npomepuy/vlc-for-android-updates-on-the-play-...

> Since when do you have to hand over your signing keys to Google?

Since it requires App Bundles, which is mandatory, as soon as you have Android TV support, for example.

https://android-developers.googleblog.com/2022/11/app-bundle...

See https://dev.to/npomepuy/vlc-for-android-updates-on-the-play-...

> I haven't and I don't think it is required.

It is required, as soon as you have Android TV support, for example.

https://android-developers.googleblog.com/2022/11/app-bundle...

See https://dev.to/npomepuy/vlc-for-android-updates-on-the-play-...

And all this article is "just" about the building of the Java/Kotlin application :)

Native NDK is another can of worms, with updates linked to SDK or sometimes not, unclear documentation about device and API compatibilities, compiler behavior changes and other requirements (like the 16K one) that impact so many 3rd party native libraries.

But, of course, the rules on the uploading and the changes of the Console, that changes so often is what makes it painful.

The absolute nightmare is about giving Google the root signing key of your application, the unfinished business about app bundles (which should reduce the size of the downloaded app, and more often than not, make it bigger), the changes in compliance, letters to sign for different countries, the compatibility for Google form factors (XR, TV, Auto, Automotive), Inline installs and other Teacher Progams, Play for family and so on.

All of this changes non-stop and is very poorly documented :)

At least, the Play Store is still GPLv2 compatible, so for now, we're saved (VLC)

(President of VideoLAN here).

So far, VideoLabs is hiring most of the VLC core developers and those people are the main force of development of VLC. It's setup this way so that if the Videolabs company does not live forever, VLC stays forever free, and the non-profit lives.

This is quite classic of open source projects, and in the case of VideoLAN, there are 3 or 4 companies doing consulting.

VideoLAN here.

Same for us, our forum and our Gitlab are getting hammered by AI companies bots.

Most of them don’t respect robots.txt…

Are you happy with the speed with your 8GB GPU?