FWIW, the getUserMedia() portion of such a setup remains the same, so you don't lose AEC or anything else coupled there.

FWIW, you can do this with a few lines of JS in the browser using canvas.drawImage() from an img element followed by canvas.toBlob().

Firefox now adds random noise to all canvas readback operations (getImageData, toDataURL, and toBlob).

Ah, I didn't realize that always happened. I thought it was only if you did something that might have OS specific rendering characteristics (text-draws, etc).

Maybe having an ImageEncoder API might be worthwhile after all then https://github.com/w3c/webcodecs/issues/204.

That would require a browser that supports WebP

...which is, like, all of them released over the past 5 years: https://caniuse.com/webp

Thanks for writing this! It skips my favorite edgy product name though, the X-Fi Fatal1ty cards: https://en.wikipedia.org/wiki/Sound_Blaster_X-Fi :)

Unfortunately canvas (rgb'ish) can't overlay as efficiently as <video> (yuv'ish), so there is some power cost relative to the lowest power video overlays.

It really only matters in long form content where nothing else on the page is changing though.

> It really only matters in long form content where nothing else on the page is changing though.

Did you not just describe at least 99% of all web video?

If only that were true, battery usage would be much better :) Just consider the prominence of content like tiktoks/shorts/reels/etc alone.

The code in Chromium which handles this suspension is here: https://source.chromium.org/chromium/chromium/src/+/main:med...

Basically after detecting silence for 30 seconds or so it switches from a sink backed by the OS audio device to a null sink.

Note: Since this uses a different clock than the audio device we have received some reports that when the context is finally used there can be some distortion at specific tones. The workaround is for sites to use the suspend resume API mentioned in the article.

Chrome supports HEVC with transparency on macOS since VideoToolbox does. Other platform decoders don't support it though.

It's unfortunately Chromium-only for now, and I wanted to keep code simple. I've got a PoC lying around with VideoFrame and whatnot, but I thought this would be better for a post.

I still remembered my id from all those years ago, 1569200. I was excited to read others were logging in with their old numbers, so I tried the password I thought I had used, but no luck.

Feeling adventurous, I dug through my archives and found my old ICQ database and followed https://sec.sipsik.net/tuts/net/icq.txt and used the code at https://web.archive.org/web/20070209002044/https://rejetto.c... to decrypt my password...

Sadly it was the one I had tried :( It was a fun trip through nostalgia at least!

Very cool! I think it's missing some entries though. I'm pretty sure we've had at least one in third_party/ffmpeg. Those fixes often land upstream first which might make tracking difficult.

It's using whatever Git Watcher comments on the monorail bugs.

IIRC, that bot used to be called bugdroid. I forget when it switched over, probably somewhere in 2020.

Even if you have crash reporting disabled there should be a .dmp generated somewhere in the user profile directory. Manually uploading that to a bug at https://crbug.com/new would allow a Chrome developer to debug it.

If you can't share the dump for similar reasons to why you have crash reporting disabled, you can build minidump_stackwalk from Chromium and use it to generate an unsymbolized stack trace that you can post to the bug. A Chrome developer can then symbolize it.

https://www.chromium.org/developers/decoding-crash-dumps/ has some more details.