Subject: Re: [MMUSIC] [rtcweb] Draft on Multimedia concepts and relations for Intermim

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 5 Feb 2013 02:28:08 +0000

Hi Magnus and Bo,

Thanks for putting this together, and more importantly, for attaching a copy in the e-mail so I was able to access it on the plane without internet.
I agree with most of the reasoning in the various sections; however, there are a couple related concepts for which I'd like more clarification.

1) MediaStream
Is a MediaStream restricted to a single source? I did not think it was, but the description on page 8 seems to imply this restriction. For example, could I have a single MediaStream with the following 4 MediaStreamTracks, where source 1 and source 2 are two video cameras from the same endpoint, or a mic and an camera from the same endpoint:

Source 1 - encoding 1
Source 1 - encoding 2
Source 2 - encoding 1
Source 2 - encoding 2

2) PeerConnection
Later, on page 18, a related restriction of a single encoding per PC is suggested. In the case of a layered encoding, this seems to imply each layer being in its own PC. Is that the recommendation being suggested?

Thanks,
Charles 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Sent: Thursday, January 31, 2013 2:46 AM
> To: mmusic (E-mail); [email-masked]
> Subject: [rtcweb] Draft on Multimedia concepts and relations for Intermim
> 
> Hi,
> 
> Attached is a draft on multimedia concepts and relations that we believe
> relevant for the upcoming interim. This includes commonalties between
> WebRTC and CLUE and other RTP usages.
> 
> Sorry for the late submission, i do hope you have time to review it. At
> will also be properly submitted to IETF as soon as we figure out why the
> submission tools refuses to process it.
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Feb 2013 16:07:17 +0100

Hi Charles,

Lets respond to your questions.

On 2013-02-05 03:28, Charles Eckel (eckelcu) wrote:
> Hi Magnus and Bo,
> 
> Thanks for putting this together, and more importantly, for attaching
> a copy in the e-mail so I was able to access it on the plane without
> internet. I agree with most of the reasoning in the various sections;
> however, there are a couple related concepts for which I'd like more
> clarification.
> 
> 1) MediaStream Is a MediaStream restricted to a single source? I did
> not think it was, but the description on page 8 seems to imply this
> restriction. For example, could I have a single MediaStream with the
> following 4 MediaStreamTracks, where source 1 and source 2 are two
> video cameras from the same endpoint, or a mic and an camera from the
> same endpoint:
> 
> 
> Source 1 - encoding 1 
> Source 1 - encoding 2 
> Source 2 - encoding 1 
> Source 2 - encoding 2

No, MediaStream is definitely not restricted to a single Media source.
In fact a common MediaStream will contain one MediaStreamTrack with an
audio source, and another MediaStreamTrack with Video. Thus two
different media sources.

Your example above gets us into I think land where discussion is ongoing
and agreement needs to be established. From my perspective there need to
be a way of dealing with control of encoding and and a plan for
different encodings of the same media source. If that is achieved by
having multiple MediaStreamTracks of the same media source, having
multiple MediaStreams with the same set of MediaStreamTracks but
different encoding settings, or explicit encoding settings within a
MediaStram and MediaStreamTrack or having them tied to the
PeerConnection is a choice that needs to happen. They have different
impact on differnt parts, but we really need to make a choice here.

> 
> 2) PeerConnection Later, on page 18, a related restriction of a
> single encoding per PC is suggested. In the case of a layered
> encoding, this seems to imply each layer being in its own PC. Is that
> the recommendation being suggested?

For layered encoding this proposal is far from optimal. It works for
simulcast where having different RTP streams each carrying a different
encoding is fine. Thus we proposed it as a solution which appeared to
require minimal impact with some simple restrictions regarding usage of
CNAME, i.e. same CNAME for both SSRC, even if they are in different RTP
sessions due to the different PeerConnections. I assume for layering
that one like to be able to send the layers in a single RTP stream.

When it comes to layering and simulcast I think the first step is
actually to agree on requirements level. Are we supporting it from
start, are we at least having it on the future road-map to avoid
solutions which makes it difficult to add in the future?

I have gotten the impression that a number of different people have
interest in it. Maybe not to implement it immediately, but at least have
a plan for how it should be included.

Cheers

Magnus Westerlund