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 many developers expressing (and continuing to express) reservations about its quality on the list and IRC.

The WebRTC folks do not miss a chance to spin the narrative though, and you can see all the expected faces on this thread.

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

But, speciically the bit in the LGPL that matters, is secton 5: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html#S... - particularily paragraph 2.

As always, IANAL, but I also have worked with a lot of FOSS via lawyers.

Also, this is and always has been the view of upstream FFmpeg. (Source: I work on upstream FFmpeg.)

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

> discontinuing RD in to the browser space

Not just the browser space; they axed e.g. all their people involved in AOM and video R&D, despite being a founding member.

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.

An easy (and problematic) example is decimal separators (radix characters) being parsed or written differently based on locale.

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.

Not a commit but from the same author, so you may enjoy: https://github.com/wm4/dingleberry-os/blob/master/README.rst

It does go off on a few tangents, but it's an interesting read.

Based on the rest of the blog, I can't actually tell if this is tongue-in-cheek or not...

Possibly, yes.

Although, having a usable QUIC library and/or adding it to libcurl would have been less controversial.

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.

Part of the problem is that the documentation is so vast (the page you link is only one of many, many pages; the documentation has been split out into multiple pages for a while now) that as a user, it's fairly insane to try and consume and comprehend it all, especially if all you want to do is something quick.

You've got cause and effect backwards there (mostly; it goes both ways).

Disclosure: FFmpeg contributor and Vimeo employee.

> In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++).

This is less true when you try and support many versions of many compilers, however, in my experience.

> It will get there, I remember a collegue saying about 10 years ago "software encoding SD in realtime is fine, but you won't be able to do it reliably in HD"

As an aside, you could already do realtime H.264 HD encoding 10 years ago without a ton of hardware, with x264; Avail Media, at least, was doing this in 2008 (probably earlier).

The slice approach should be pretty readily doable today with e.g. libx264 (which you can force exactly N rectangular (full-row) slices with, using i_slice_count), and calculating N based on the resolution of the eleven vertically and horziontally stitched clips and their boundaries. (And with VP9 using some craft tile-column/tile-rows setup, maybe...)

This is assuming the videos are stitched pre-encode, of course... From the post, it almost sounds as if the idea would be to stitch independent H.264 streams into a new unified one using slice mangling + slices... which would be pretty crazy stuff.

(As a side note, it's a shame flexible macroblock ordering is only in the baseline and extended profiles... I still don't understand that decision at all.)

EDIT: Dawned on me that the hard part is on the client/decode side. D'oh.