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

RE: Summary of replace track status

From: Shijun Sun <shijuns@microsoft.com>
Date: Wed, 27 May 2015 20:37:26 +0000
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>, Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <BLUPR03MB405AE2FCF99737F4DA3F67BB1CB0@BLUPR03MB405.namprd03.prod.outlook.com>
On Wednesday, May 27, 2015 3:29 AM
Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] wrote: 
>> On 26/05/15 22:50, Bernard Aboba wrote:
>> [BA] Looking through the Media Capture specification, I do not see 
>> mention of a track having an encoding constraint or codec attribute.
>> Can you point out to me where this is described?
> It is not described. I tried to clarify the use case described by Adam 
> in https://lists.w3.org/Archives/Public/public-webrtc/2015May/0130.html
> I think it is valid, don't you agree?

Based on my knowledge of the media capture design, the captured data format is a device/platform internal decision, for example, whether the video data are uncompressed (e.g. RGB, YUV 420, etc.) or compressed (MJPEG is typical).  It is up to the browser/platform implementation to make sure to be able to internally consume the streams by the consumer objects.  In case of the RtpSender object, it can be an internal logic/implementation as to how to consume the data accordingly based on the encoding params.  In practice, it is very likely we have to re-encode (or transcode) anyway to meet the networking bandwidth condition, error recovery, etc. - all based on the encoding params and the RTP runtime decision.

Please let me know if I'm missing anything.  Thanks!
Received on Wednesday, 27 May 2015 20:38:01 UTC

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