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