youennf

https://www.w3.org/TR/webrtc-nv-use-cases/#decent already covers some of those scenarios (P2P and service workers).

> I think `0` per track source is what makes most sense. That seems indeed better compared to per track. > The usages we found would work great if MSTP...

> we could prepare for that by adding an |offset| We could consider that MSTP is receiving a VideoFrame object and use https://w3c.github.io/webcodecs/#videoframe-initialize-frame-from-other-frame to create a new VideoFrame with an...

> it doesn't seem to me the actual origin of presentation timestamp in the UA matters and hence don't need to be strictly defined? Agreed. > Wdyt we just add...

> e [=presentation timestamp=] of local video capture, either same value as [=capture timestamp=] Only for local tracks of course.

The number of request per process might be difficult to handle for developers and might never be interoperable anyway. Number of requests per browser might be interoperable but one can...

I think this captures where we want to go. We should be able to update the spec so that: - keep alive requests attached to a browsing context do not...

A side note: if we decide to remove the 64KB restriction for attached keep alive requests, we might still want to warn developers that long keep alive uploads have higher...

This point was actually discussed at last editor's meeting. The spec does not mandate to make the default output device second in the list (after the default output device) but...

See also https://github.com/w3c/webcodecs/pull/841 that adds a registry entry. It would be nice to do a PR for that metadata here.