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.
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.
It is widely known and accepted that you need to dynamically link to satisfy the LGPL (you can static link if you are willing to provide your object files on request). There is a tl;dr here that isn't bad: https://fossa.com/blog/open-source-software-licenses-101-lgp...
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.')
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)?
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."
I would perhaps wait until rav1e 0.4, because there is a bug in the FFmpeg wrapper (of which I am the author) right now that breaks timestamps. If you wish to build with rav1e master, you can apply this to fix it: https://github.com/dwbuiten/FFmpeg/commit/ac4cf898c1960d72bc... (removing the configure check)
It hasn't made it upstream yet since I can't bump the minimum required version in FFmpeg git until rav1e tags 0.4.
Sounds mostly like the issue is nobody has bothered to submit a proposal for it then? (There is so much in-the-wild experience and code dealing with this issue, I cannot imagine the second point being problematic.)
On the third point, I have trouble thinking of any technical objections to such proposal.
What has been the rationale or hinderance for not adding locale-independent versions of various stdlib functions?
Practically every second C codebase on earth has their own implementations of these at some point, and it remains a huge problem for e.g. writers of libraries, where you don't know how/where your library will be used.
Their motivation isn't really made clear in the bug (easier for developers to switch to is a little too vague), but if I had to guess, I'd bet the actual reason is that they want the debug/insight/whatever features from cronet available to all the third party dependencies in their monorepo, and a shim was the easiest way.
Doesn't make it a good look, though.
As an aside: Given history with Google's other OSS libs, I have absolutely no faith in them having a concept of a stable ABI, or even API. This is anecdotal of course.
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.