DaleCurtis

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.

Comment · 1 year ago

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

Comment · 2 years ago

What a fun excursion :) You can also use the ImageDecoder API: https://developer.mozilla.org/en-US/docs/Web/API/ImageDecode... and VideoFrame.copyTo: https://developer.mozilla.org/en-US/docs/Web/API/VideoFrame/... to skip canvas entirely.

Comment · 2 years ago

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!

Comment · 2 years ago

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

Comment · 2 years ago

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.

Comment · 2 years ago

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.

Comment · 3 years ago

Often Chrome doesn't know when more frames are needed either, so it's not something we could add an API for unfortunately.

Yes, just feeding inputs 1 by 1 for each dequeue event until you get the number of outputs you want in your steady state is the best way. It minimizes memory usage. I'll see about updating the MDN documentation to state this better.

Comment · 3 years ago

> Ideally I'd like to be able to set the CBR / VBR bitrate

What's wrong with the existing VBR/CBR modes? https://developer.mozilla.org/en-US/docs/Web/API/VideoEncode...

> I don't think you need a shader...

Ah I see what you mean. It'd probably be hard for us to standardize this in a way that worked across platforms which likely precludes us from doing anything quickly here. The stuff easiest to standardize for WebCodecs is stuff that's already standardized as part of the relevant codec spec (e.g, AVC, AV1, etc) and well supported on a significant range of hardware.

> ... instead of round-tripping into a CPU buffer

We're working on optimizing this in 2024, we do avoid CPU buffers in some cases, but not as many as we could.