W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

Re: To Stream or not to Stream

From: youenn fablet <yfablet@apple.com>
Date: Thu, 14 Jun 2018 21:23:30 -0700
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-id: <65478DC7-F1E9-4E71-81E5-55DE7366BE92@apple.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
The dual encryption use case is also interesting to study.

The Web Crypto API could be used if there is access to raw encoded bytes.
This API is promise based, usually the encryption happening in a separate thread. This creates a potential performance issue.
An alternative might be WASM which would require web developers, to reimplement crypto which is not great in terms of security.

Let’s say now that we still find a good way to let the user encrypt data in this pipeline.
There is still a need to determine which parts of the data are to be encrypted and which are to be left unencrypted to help sending the data up to the other client.

With all of this, it seems very easy to get it wrong.
If this use-case is of enough value, it seems to require a better solution, built directly in the browser and configurable by some API.

As of the streaming of media content, I agree there might be some convergence, especially with live content.
That said, access to raw decodable content/raw decoded frames goes against EME-based solutions.


> Le 14 juin 2018 à 6:35 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> a écrit :
> 
> Youenn said: 
> 
> "I agree with the use cases and the idea to move away from SDP.
> It is unclear yet how that would translate into APIs, probably lower level than WebRTC current APIs for some of the use-cases."
> 
> [BA] An important step toward understanding the low-level/high-level issue is to think critically about the use cases. 
> 
> One of the reasons to go into the use cases in detail is to enable participants to imagine themselves arguing with management for the resources necessary to implement the APIs that enable those use cases. 
> 
> If when imagining that situation there is a lack of confidence in whether the case is convincing (for some company you can imagine yourself working for), then that is an indication that the use case has not cleared the bar. 
> 
> In practice, that bar is pretty high at most companies - functionality is not free, particularly with today's increasing emphasis on reliability, security, privacy and performance. 
> 
> So unless a use case can enable a quantum leap in the user experience (for improvements) or an entirely new class of applications (for new use cases), the argument for resources may not go well.
> 
> Youenn also said: 
> 
> "I do not think we reached consensus on the idea of splitting senders/receivers in smaller bricks.
> There are some use cases that would benefit from this.
> 
> There has been concerns in the cost, complexity and feasibility of this approach.
> We should also investigate alternatives to fulfil these use cases than going the splitting way.""
> 
> [BA] The Funny Hats use case requires access to raw media, but as far as I can tell it does *not* require splitting the sender and receiver into smaller bricks, nor does it require codecs implemented in Javascript. 
> 
> I'm not clear that the entertainment/sports use cases requires splitting or JS codecs either, since that use case could potentially be handled by a QuicSender/QuicReceiver. 
> 
> There is also the basic question of whether the entertainment/sports use case is compelling at all. 
> 
> IMHO, that argument rests on the desirability of convergence of the technology used for streaming and real-time communications. 
> 
> Since streaming media is typically transported over HTTP, and HTTP/2 over QUIC is likely to be widely deployed, there is an argument that HTTP/2 over QUIC will eventually be widely used in streaming such as HLS. 
> 
> If media over QUIC is likely to be popular in streaming, the argument is that there would be engineering benefit to converging streaming and RTC by supporting RTC over QUIC as well. 
> 
> I have little experience in streaming media, so I cannot evaluate that claim, but it would be good to hear from people who understand that business and whether the benefits would be sufficient to motivate
> the technical work. 
> ,
Received on Friday, 15 June 2018 04:23:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC