RE: [AVT] RE: [MMUSIC] questions about grouping media streams inRTP andSDP (RFC3388 etc), advice needed
"Thomas Schierl" <schierl@hhi.fhg.de> Thu, 07 June 2007 21:33 UTC
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPby-0006qw-4E; Thu, 07 Jun 2007 17:33:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPbw-0006qn-RX; Thu, 07 Jun 2007 17:33:40 -0400
Received: from mail.hhi.fraunhofer.de ([193.174.67.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPbu-0005kf-4t; Thu, 07 Jun 2007 17:33:40 -0400
Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 7C4C91D88F65; Thu, 7 Jun 2007 23:33:37 +0200 (CEST)
Received: from ipam040189 (DNab423247.Stanford.EDU [171.66.50.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id BA85C1D88F74; Thu, 7 Jun 2007 23:33:33 +0200 (CEST)
From: Thomas Schierl <schierl@hhi.fhg.de>
To: 'Dave Singer' <singer@apple.com>
References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com><p0624081ac28b3247e073@[17.202.35.52]><000001c7a92a$f3aefac0$595c40ab@ipam040189> <p0624084bc28df52e0342@[17.202.35.52]>
Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams inRTP andSDP (RFC3388 etc), advice needed
Date: Thu, 07 Jun 2007 14:33:30 -0700
Organization: HHI/FhG
Message-ID: <009501c7a94b$807c7570$473242ab@ipam040189>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcepLDjNiJ1Dz8PBQVaRnZeaFE0EbAAHmvmQ
In-Reply-To: <p0624084bc28df52e0342@[17.202.35.52]>
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail.hhi.fraunhofer.de
X-Spam-Level:
X-Spam-Status: No, hits=-104.9 required=5.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.64
X-alterMIME: Yes
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
Cc: "'Even, Roni'" <roni.even@polycom.co.il>, Stephan.Wenger@nokia.com, mmusic@ietf.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org
Hi Dave, I think the grouping type DDP fits, but we should talk about an extra type of dependency for that. Thomas > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Thursday, June 07, 2007 10:49 AM > To: Thomas Schierl > Cc: Stephan.Wenger@nokia.com; mmusic@ietf.org; 'Even, Roni'; avt@ietf.org > Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams > inRTP andSDP (RFC3388 etc), advice needed > > At 10:40 -0700 7/06/07, Thomas Schierl wrote: > >Hi Dave, > > > >I think there is a strong relation of your problem and the > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.txt > . > >In this draft, we described media dependency in general, not only for > >scalable video. Currently, two types of dependencies are defined: layered > >and mdc assuming the media is partially transported in different RTP > >sessions. It would be easy to integrate your needs, if they should not be > >already covered. > > > > > >Thomas > > Thank you. I agree the problems are identical, or close to it. > > Do you think we should use 'lay' or 'mdc', or a new dependency type? > Or integrate a new group type into the draft (is 'DDP' right for our > application)? > > > > >> -----Original Message----- > >> From: Dave Singer [mailto:singer@apple.com] > >> Sent: Tuesday, June 05, 2007 8:34 AM > >> To: Even, Roni; mmusic; IETF AVT WG > >> Cc: Clinton Priddle (KI/EAB) > >> Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in > RTP > >> andSDP (RFC3388 etc), advice needed > >> > >> At 10:03 +0300 5/06/07, Even, Roni wrote: > >> >Dave, > >> >For layered encoding there is a proposal for a new grouping attribute > in > >> >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec- > 03.tx > >> >t > >> > >> I don't think this is a layered coding issue, either, alas. > >> > >> >I looked at RFC3388 and I think that FID is not the answer to your > >> >requirement as you mentioned > >> > > >> >To me it looks like what you are looking for is a way to specify > >> >alternate offers. > >> > >> No, these streams are not alternatives to each other in the regular > >> sense. Nor is this really used in offer/answer; it's more an issue > >> for multicast. In multicast, you open the tune-in stream and the > >> base stream, grab the first I-frame that arrives (in either) and then > >> drop the tune-in stream. > >> > >> Yes, we're aware that the recipient needs to be able to tell which is > >> the base and which is the tune-in. > >> > >> >If this is the case I have similar requirements and > >> >would be happy to support such work. > >> > > >> >You also need a way to give semantics to the "repair" stream, this > can > >> >be done based on the content attribute from RFC 4796 or using a > >> >dependency attribute see in Schierl's draft. The mid tag is not > enough > >> >for the receiver to know what you meant by this offer and which > stream > >> >is the repair. > >> > > >> >Here is an example for a solution using a new Alternatives grouping > >> >attribute and giving semantics to the repair stream > >> > > >> >By using the grouping attribute in the offer you can know if the > >> >answerer understood the grouping since if he does not than he will > send > >> >an answer with no a=group > >> > > >> >v=0 > >> >o=bob 280744730 28977631 IN IP4 host.example.com > >> >s= > >> >t=0 0 > >> > > >> >a=group:ALTS 1 2 > >> >a=group:ALTS 1 3 > >> > > >> >m=audio 6886 RTP/AVP 0 > >> >c=IN IP6 2001:0600::1 > >> >a=mid:1 > >> > > >> >m=video 9000 RTP/AVP 100 > >> >c=IN IP4 192.0.2.2 > >> >a=rtpmap:100 H263-1998 > >> >a=mid:2 > >> > > >> >m=video 9002 RTP/AVP 101 > >> >c=IN IP4 192.0.2.2 > >> >a=rtpmap:101 H263-1998 > >> >a=mid:3 > >> >a=content:repair=2 or a=depend:repair=2 > >> > > >> > > >> >Roni Even > >> > > >> >> -----Original Message----- > >> >> From: Dave Singer [mailto:singer@apple.com] > >> >> Sent: Monday, June 04, 2007 7:19 PM > >> >> To: mmusic; IETF AVT WG > >> >> Cc: Clinton Priddle (KI/EAB) > >> >> Subject: [MMUSIC] questions about grouping media streams in RTP > and > >> >SDP > >> >> (RFC3388 etc), advice needed > >> >> > >> >> Hi > >> >> > >> >> we have a need to group together two media streams, in the style > of > >> >RFC > >> >> 3388 <http://www.ietf.org/rfc/rfc3388.txt> but we're unsure > whether an > >> >> existing group type is suitable or not, and if it's not, we'd like > to > >> >> agree on a new one, and document it (presumably in an RFC). > >> >> > >> >> What we have is a normal media stream, and a separate 'repair' or > > > >> 'entry' stream, that can be used when tuning in, or after loss, > but is > >> >> otherwise un-needed. An example might be a video stream with a > low > >> >> I-frame interval (say every 15 seconds), with a repair stream > which > >> >has > >> >> only I-frames that are equivalent to the time-parallel non-I > frame, at > >> >a > >> >> frequency of say 1 per second. > >> >> > >> >> It's not clear to us whether this is "one media flow" in the sense > of > >> >> FID, or not. The example offers AMR and GSM audio, which are > >> >> alternatives, and DTMF tones along with audio, which are > supplementary > >> >> to each other. Perhaps we fall afoul of this restriction: > >> >> > >> >> "An application that encodes the same media using different codecs > >> >> simultaneously MUST NOT use FID to group those media lines." > >> >> > >> >> or this one, for layered encoding: > >> >> > >> >> "FID MUST NOT be used to group "m" lines that do not represent the > >> >same > >> >> information." (Though how DTMF tones and their associated audio > pass > >> >> this test is not clear). > >> >> > >> >> Nor is it clear that the FEC group of RFC 4756 is right, either. > For > >> >a > >> >> start, we may wish to use this new ID in combination with FEC, and > >> >> secondly this tune-in stream has different characteristics. For > >> >> example, one can typically ignore all FEC and (as long as there > are no > >> >> errors) decode the stream correctly. Ignoring the tune-in stream > >> > > entirely may mean that you will never find a tune-in point, > making > >> the > >> >> normal stream useless. > >> >> > >> >> So, can we use FID for associating a repair stream with its base > (we > >> >tag > >> >> the streams so we know which is which, of course)? > >> >> > >> >> p.s. RFC 4756 claims in the IANA section that the FEC group is > >> >> registered under SDP characteristics, but actually I can find no > >> >> registry anywhere in IANA of group types. > >> >> > >> >> > >> >> -- > >> >> David Singer > >> >> Apple/QuickTime > >> >> > >> >> _______________________________________________ > >> >> mmusic mailing list > >> >> mmusic@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > >> > >> -- > >> David Singer > >> Apple/QuickTime > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > > > -- > David Singer > Apple/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] Moving draft-marjou-behave-app-rtp-keepaliv… Colin Perkins
- [AVT] RE: Moving draft-marjou-behave-app-rtp-keep… Dan Wing
- [AVT] Re: [BEHAVE] RE: Moving draft-marjou-behave… Lars Eggert
- [AVT] questions about grouping media streams in R… Dave Singer
- [AVT] RE: [MMUSIC] questions about grouping media… Even, Roni
- AW: [AVT] RE: [MMUSIC] questions about grouping m… Kalleitner, Franz
- [AVT] RE: [BEHAVE] RE: Moving draft-marjou-behave… Dan Wing
- Re: [AVT] RE: Moving draft-marjou-behave-app-rtp-… Cullen Jennings
- [AVT] RE: Moving draft-marjou-behave-app-rtp-keep… Even, Roni
- [AVT] Re: [BEHAVE] RE: Moving draft-marjou-behave… Colin Perkins
- [AVT] Re: [BEHAVE] RE: Moving draft-marjou-behave… Lars Eggert
- [AVT] RE: [MMUSIC] questions about grouping media… Dave Singer
- [AVT] RE: [MMUSIC] questions about grouping media… Even, Roni
- Re: [AVT] questions about grouping media streams … Andrea Lorenzo VITALI
- Re: [AVT] questions about grouping media streams … Dave Singer
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Dave Singer
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Even, Roni
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- Re: [AVT] RE: [MMUSIC] questions about grouping m… Stephan Wenger
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Even, Roni
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- Re: [AVT] RE: [MMUSIC] questions about grouping m… Stephan Wenger
- Re: [AVT] Moving draft-marjou-behave-app-rtp-keep… Colin Perkins
- Re: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Even, Roni
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer
- Re: AW: [AVT] RE: [MMUSIC] questions about groupi… Randell Jesup
- Re: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Even, Roni
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Even, Roni
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer