RE: Summary of replace track status

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!