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

I support the addition of the "One-way media" use cases.

On Mon, Jan 30, 2023 at 12:30 PM Youenn Fablet <youenn@apple.com> wrote:

>
>
> 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) <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
>
>
>