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

Re: Raw data API - 3 - Encoded data

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 29 May 2018 09:20:03 +0200
To: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <39635dc5-b700-fdb2-e84f-6ec1091b3084@alvestrand.no>
On 05/29/2018 09:12 AM, Bernard Aboba wrote:
> Question: 
>
> For outgoing audio/video, is the goal to obtain access to media after capture but prior to encoding? (e.g. a "raw" form of a MediaStreamTrack that is subsequently processed by an RtpSender)
>
> For received audio/video, is the goal to obtain access to media produced by the decoder (e.g. a "raw" form of a MediaStreamTrack produced by an RtpReceiver).  

Yes, that's the point of the "raw data" APIs presented in the "2 - Raw
data" message. The one presented in this thread is for getting at the
encoded data.

We see applications for both (both separately and together).
>
> Or is the goal to obtain access to RTP packets before they are sent (or after they are received)? 
>
> For outgoing, is the desire to see *all* RTP packets that are actually sent (e.g. including RTX/FEC packets), or to just obtain access to the uncorrected packets? 
>
> Similarly, for incoming, is the desire to see *all* RTP packets that are received (e.g. including repair packets)?  What about concealment? 
I think that's an excellent question. If, for instance, one wishes to
generate FEC in WebAssembly rather than in the browser, access to FEC
packets is necessary; if one wants to turn FEC on and off only, a
control surface is needed, but no packet surface.
But that's part of thread 4 - RTP packet access.


-- 
Surveillance is pervasive. Go Dark.
Received on Tuesday, 29 May 2018 07:20:55 UTC

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