From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Harald Alvestrand <harald@alvestrand.no>
Thread-Topic: How does mmt grouping work with multiple streams of the same
 type?
Thread-Index: AQHNp7X7oltmMsfNQpqK/fTAiq3/VZe0IqpA
Date: Thu, 11 Oct 2012 14:13:23 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE120128BD71@MCHP04MSX.global-ad.net>
References: <F81CEE99482EFE438DAE2A652361EE120128BCF2@MCHP04MSX.global-ad.net>
 <5076CC50.7000103@alvestrand.no>
In-Reply-To: <5076CC50.7000103@alvestrand.no>
Accept-Language: de-AT, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic WG <mmusic@ietf.org>,
 Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] How does mmt grouping work with multiple streams of the
 same type?
Precedence: list

Harald,

thanks for the reply.
It helps for my second question, but not for my main question.
How can the answerer recognize (from the m=3Danymedia line alone) that mult=
iple video streams need to be set up in the same RTP session?

Regards
Thomas =20

> -----Urspr=FCngliche Nachricht-----
> Von: Harald Alvestrand [mailto:harald@alvestrand.no]=20
> Gesendet: Donnerstag, 11. Oktober 2012 15:41
> An: Stach, Thomas
> Cc: Christer Holmberg; Jonathan Lennox; mmusic WG
> Betreff: Re: How does mmt grouping work with multiple streams=20
> of the same type?
>=20
> On 10/11/2012 03:12 PM, Stach, Thomas wrote:
> > Christer, Harald, Jonathan,
> >
> > I have the impression that the=20
> draft-holmberg-mmusic-sdp-mmt-negotiation is based on=20
> Jonathan's proposal
> > to have an explicit desrciption for the bundled streams as=20
> proposed in
> > http://www.ietf.org/mail-archive/web/mmusic/current/msg09454.html
> >
> > Among other points the following is stated:
> > * The m=3Dbundle is a complete description of an entirely=20
> separate m-line; if it's used, the other m-lines in the group=20
> are rejected and the information they carry is ignored.
> > I think this a desirable property
> >
> > Now, consider a case were you have 4 streams, i.e. 4=20
> m-lines (e.g. 2 audio and 2 video).
> > How would that be mapped to the m=3Danymedia line?
> > How does mmt grouping work with multiple streams of the same type?
> >
> >  From the currently proposed syntax for the m=3Danymedia line=20
> I cannot deduce that multiple audio or video streams are offered.
> > I would have to look into the "legacy" m-lines to recognize this.
> > In case that e.g. the video stream use different codecs, I=20
> could also learn that only from the legacy m-lines.
>=20
> In the case where it's desirable to carry multiple video=20
> streams in one=20
> RTP session, and have different descriptions in SDP for the different=20
> video streams, there has to be some signalling that tells the=20
> recipient=20
> which description applies to which video stream.
>=20
> The video streams will have different SSRCSs. Therefore, the only=20
> reasonable answer in the MMT grouping case seems to be=20
> SSRC-associated=20
> signalling.
>=20
> In the other variants, it's actually unclear to me how the=20
> video streams=20
> described by the different m=3D lines would be detected by the=20
> recipients;=20
> I'd been assuming SSRC-associated signalling for other=20
> reasons, so only=20
> when this discussion resurfaced, I started thinking about this again,=20
> and discovered that I didn't have an answer.
>=20
> That is, in the description
>=20
> a=3Dgroup:bundle foo bar baz
> m=3Dvideo 4270
> a=3Dmid:foo
> a=3Dproperty-x:1
> m=3Dvideo
> a=3Dmid:bar
> a=3Dproperty-x:2
> m=3Dvideo
> a=3Dmid:baz
> a=3Dproperty-x:3
>=20
> one would expect a single RTP stream to be set up; when the recipient=20
> gets 3 video streams with SSRCS 234, 235 and 236, how does he=20
> know which=20
> stream should have which value for "property-x"?
> One can solve it with SSRC-associated signalling in this case too:
>=20
> a=3Dssrc:234 property-x:1
>=20
> but then you're back to doing SSRC-associated signalling, and=20
> if you're=20
> already doing that, we're not very different from the MMT description=20
> anyway.
>=20
> That's how I think of it at the moment, anyway - YMMV.
>=20
>=20
>=20
> =