Re: Call for Consensus (CfC): WebRTC-NV "Low Latency Streaming Use Cases (Section 3.2)

The Game Streaming use case (Section 3.2.1) does not take into account improvements required for utilization of game pad input.  This was brought up in WG discussion of the use case at a previous meeting, so I have filed an issue to track it:
Improvements for game pad input · Issue #94 · w3c/webrtc-nv-use-cases (github.com)<https://github.com/w3c/webrtc-nv-use-cases/issues/94>




================================

I support addition of the "Low Latency Streaming" uses cases in Section 3.2.

However, I also believe the following GitHub Issues need to be addressed:

https://github.com/w3c/webrtc-nv-use-cases/issues/80 Access to raw audio data

Games are implementing increasingly more sophisticated audio functionality, including spatial audio and more advanced codecs. In these applications, raw audio is obtained and encoded by custom codecs.  Today this is not straightforward.

https://github.com/w3c/webrtc-nv-use-cases/issues/86: Is the DRM requirement in the Low latency Broadcast with Fanout use case satisfied by data channels?

Containerized media can today be transported over the data channel, so one can argue that DRM is supported. The issue however has been that lack of worker support has been an issue for a data-channel/MSE approach to support of DRM along with low-latency transport.

So my take is that requirement N36 should be removed, and a requirement for DataChannel in Workers (something along the lines of N13) should be substituted.

https://github.com/w3c/webrtc-nv-use-cases/issues/91 : N15 latency control should be formulated in a technology-agnostic way

In cloud gaming, most media tend to flow from the cloud to the browser endpoint, with game console input going from browser to the cloud.  However, the use case shouldn't preclude peer-to-peer media so that game participants can interact with each other.

So I agree that requirement N15 is formulated too narrowly.