Daemon404

There's quite some time until the next release, I believe, so it should be.

The biggest thing missing right now is NACK support, and one of the authors has said they intend to do this (along with fixing old OpenSSL version support, and supporting other libraries). Until that is done, it isn't really "prod ready", so to speak.

For some context, there has been a history of half-supported things being pushed to FFmpeg by companies or people who just need some subset of $thing, in the past, and vendors using that to sell their products with "FFmpeg isn't good enough" marketing, while the feature is either brought up to standard, or in some cases, removed, as the original authors vanish, so it's perhaps a touchy subject for us :) (and why my post was perhaps unnecessarily grumpy).

As for the git / premature push stuff, I strongly believe it is a knock-on effect of mailing list based development - the team working on this support did it elsewhere, and had a designated person send it to the list, meaning every bit of communication is garbled. But that is a whole different can of worms :D.

(long time FFmpeg dev here)

You are being downvoted, but you are entirely correct. This is also explicitly not allowed in FFmpeg, but this was pushed after many months, with no heads up on the list, no final review sign off, and with some developers expressing (and continuing to express) reservations about its quality on the list and IRC.

You have that backwards - it must be dynamically linked. Static linking without providing your source would violate the LGPL.

This is a constant issue for me (Chrome on Android) on GMail's Web UI (yes, I insist on using the Web UI...). So many emails are entirely unreadable since they go right off the right side, and you can't zoom.

Pretty much everyone (including my $dayjob) seems to do some webm parsing, rewiting, and/or remuxing in JS, or on the backend post-record. There are half a dozen ad hoc webm parsers floating around GitHub for this reason, and a few more minimal WebM or ISOBMFF muxers.

And half the tools don't work on Safari, which makes ISOBMFF in their MediaRecorder implementation.

It really seems to me, as a user (not invloved in the standards) like it was some intenal Chrome functionality that got an API slapped on top and made into a spec. Nothing seems well designed, or... designed at all, tbh.

(Can you tell I've had to work with MediaRecorder? When I read 'The skater punk’s guide to MediaRecorder' I thought it would be one sentence: 'Put it in the trash.')

Apologies for the salt.

I can only speak for myself here, but why would step 1 be "become a user"? I ask because I don't fully grok why I would want to contribute to a project I don't use (either in my personal time, or work time)?

The demo seems to never load for me on Android Chrome? It sits with an off-center spinner forever.

Chrome does seem to save the JPEG version on some WebP or AVIF URLs where there is also a JPEG version available too, although it seems to be 'clever' about it rather than explicitly offering the option, which can make saving the actual WebP or AVIF mildly annoying.

It's been my experience that part of the reason browsers get stuff wrong even when it's clear what to do, is that entirely different teams work on parts of the browser that all need a poper color pipeline, and while one team will learn and do it correctly, the new team working on the diffrent part has to go through the same process again.

You can see this, for example in Firefox's image pipeline which seems to assume everything is 601 (because JPEG), and this means 709 AVIFs won't render correctly (and are thus off by default currently).

Or in Chrome, the MediaRecorder API will create HD H.264 streams that are untagged, and are 601. Which Chrome then assumes is 709 based off the res.

Or, also in Chrome, the WebCodecs team not having talked to the Media Team, seemingly (?) before starting work on what kind of buffer gets returned to the user, and what the semnatics of its color are. (I think this is resolved now, though - this was a year or two back when they engaged with VideoLAN over this API)

This is one place the ISOBMFF spec really screwed up, in my opinion. They should have included semantics for the colr box, i.e. which takes precedence.

Intead we get: "Colour information may be supplied in one or more ColourInformationBoxes placed in a VisualSampleEntry. These should be placed in order in the sample entry starting with the most accurate (and potentially the most difficult to process), in progression to the least. These are advisory and concern rendering and colour conversion, and there is no normative behaviour associated with them; a reader may choose to use the most suitable."