Re: Call for Consensus (CfC): WebRTC-NV "One-way media" Use Cases (Section 3.10))

> On 26 Jan 2023, at 15:43, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> What issues are filed?

I will them this week.

> 
> 
> n 1/26/23 11:42, Youenn Fablet wrote:
>>> On 17 Jan 2023, at 21:30, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>>> 
>>> This is a Call for Consensus (CfC) on the WebRTC-NV "One-way media" Use Cases described in Section 3.10:
>>> 
>>> 3.10.1     Live encoded non-WebRTC media
>> This use case seems like a potential optimization to remove the need to decode/encode the content at the RTCPeerConnection level.
>> It is also unclear whether there is an issue where the application could try to go largely above the available bandwidth.
>> This is something that would be useful to evaluate.
>> In terms of requirements:
>> - N40 is already feasible. It should probably be precised.
>> - N41 is not really a requirement but already an API proposal. It should probably be rewritten in a more agnostic way. The underlying requirement would probably be solved by an API that would directly send/receive RTP packets.
>> - N42 is already feasible via WebRTC stats. It should probably be precised.
>>> 3.10.2     Transmitting stored encoded media
>> The requirements for this use case are not complete enough.
>> In particular, there would be a need to handle PLI or FIR, which might not be possible to answer without either reencoding or having a stream with key frames only.
>> In addition, this use case seems already implementable with existing web APIs.
>> It would good to evaluate what the expected benefits are of this approach compared to solutions using existing web APIs.
>>> 3.10.3      Decoding pre-encoded media
>> This use case is mainly based on the assumption that JS based processing via WebCodecs is not optimal for speedy processing.
>> It would be good to have measurements to understand what perf improvements we are talking about.
>> Ditto for MSE, which is already able to support media-over-datachannel, DRM and file playback.
>>> 
>>> The use cases are available for inspection here:
>>> https://w3c.github.io/webrtc-nv-use-cases/#one-way-media <https://w3c.github.io/webrtc-nv-use-cases/#one-way-media>
>>> 
>>> The GitHub repo Issues list is here: Issues · w3c/webrtc-nv-use-cases (github.com <http://github.com/>) <https://github.com/w3c/webrtc-nv-use-cases/issues>
>>> 
>>> In response, please state one of the following:
>>> 
>>>  * I support addition of the "One-way  media" use cases
>>>  * I object to addition of the "One-way media" use cases, due to
>>>    issues filed in <link to GitHub issues> 
>> I do not support these use cases in their current form.
>> There were past discussions where WebTransport was initially thought as a potential solution for similar use cases.
>> IIRC, it was said that WebTransport was not able to match all RTP based transport functionalities.
>> It would be good to further dive into this area and extract corresponding requirements.
>> In general, my hunch is that exposing an API to do direct RTP packet handling would be a better fit.
>> Web applications could then either go with RTCPeerConnection, WebCodecs+WebTransport or WebCodecs+RTPTransport.
>>> The CfC will last until midnight Pacific Time on February 6, 2023.
>>> 
>>> Bernard
>>> For the Chairs