Dan Sanders

WebCodecs is also interested in read-only ArrayBuffers, for providing access to YUV planes in CPU memory that remain owned by decoders. Is there any previous work on this request?

Just some quick notes on Chromium Android's current HLS implementation for ``: - We fetch the manifest (following redirects) once before handing off to the platform player. The mode depends...

It is not correct. We set `android-allow-cross-domain-redirect: 0` on the platform player, but this is after fetching and following redirects the first time. There is no origin restriction on the...

That should work, and the resources must be on origin B. It's worth noting explicitly that this is an incomplete implementation. A feature-complete HLS implementation would presumably support the full...

A nit: there is also `application/x-mpegurl` and `audio/x-mpegurl`. Parsing the manifests seems a bit extreme to me. The manifest resources are going to be one of (A) more manifests, (B)...

That works fine for Chromium Android's current implementation. I can't guarantee that Chromium Android will never include its own HLS player implementation, though.

> Given that media manifests are currently recognized by file extensions(!) and such as I understand it I somewhat doubt that would be web compatible I share your suspicions about...

Just wanted to post an update based on Chrome's now in-progress HLS experiment. We still expect that manifest files will be best identified by the magic string above (#EXTM3U) as...

I've been asked to present to this group about WebCodecs' experience using `Streams`. The discussion in this thread does not seem to be primarily about technical aspects of `Streams` vs...

```webidl interface VideoTrackReader { constructor(MediaStreamTrack track); void start(OutputCallback callback); void stop(); }; ``` At the time `VideoTrackWriter` was abandoned it was (still) using a `WritableStream`, so it looked very much...