RE: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed
Dave Singer <singer@apple.com> Thu, 07 June 2007 17:49 UTC
Return-path: <mmusic-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM7A-0001xI-0r; Thu, 07 Jun 2007 13:49:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwM78-0001wk-0o; Thu, 07 Jun 2007 13:49:38 -0400
Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwM77-0003DB-E8; Thu, 07 Jun 2007 13:49:38 -0400
Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out3.apple.com (Postfix) with ESMTP id 5F3CB82384E; Thu, 7 Jun 2007 10:48:39 -0700 (PDT)
Received: from relay7.apple.com (unknown [127.0.0.1]) by relay7.apple.com (Symantec Mail Security) with ESMTP id 12EA8300AE; Thu, 7 Jun 2007 10:49:37 -0700 (PDT)
X-AuditID: 11807125-9f763bb000000801-29-4668453059cf
Received: from [17.202.35.52] (unknown [17.219.197.38]) by relay7.apple.com (Apple SCV relay) with ESMTP id 4F5B730044; Thu, 7 Jun 2007 10:49:36 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0624084bc28df52e0342@[17.202.35.52]>
In-Reply-To: <000001c7a92a$f3aefac0$595c40ab@ipam040189>
References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com> <p0624081ac28b3247e073@[17.202.35.52]> <000001c7a92a$f3aefac0$595c40ab@ipam040189>
Date: Thu, 07 Jun 2007 10:49:08 -0700
To: Thomas Schierl <thomas.schierl@hhi.fraunhofer.de>
From: Dave Singer <singer@apple.com>
Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48
Cc: "'Even, Roni'" <roni.even@polycom.co.il>, Stephan.Wenger@nokia.com, mmusic@ietf.org, avt@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org
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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] New draft: multiple times problem descri… Miguel Garcia
- RE: [MMUSIC] New draft: multiple times problem de… Dan Wing
- Re: [MMUSIC] New draft: multiple times problem de… Miguel Garcia
- RE: [MMUSIC] New draft: multiple times problem de… Christer Holmberg (JO/LMF)
- Re: [MMUSIC] New draft: multiple times problem de… Miguel Garcia
- Re: [MMUSIC] New draft: multiple times problem de… Colin Perkins
- [MMUSIC] Moving draft-marjou-behave-app-rtp-keepa… Colin Perkins
- [MMUSIC] RE: Moving draft-marjou-behave-app-rtp-k… Dan Wing
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Lars Eggert
- [MMUSIC] questions about grouping media streams i… Dave Singer
- [MMUSIC] Re: [AVT] RE: Moving draft-marjou-behave… Cullen Jennings
- [MMUSIC] RE: Moving draft-marjou-behave-app-rtp-k… Even, Roni
- [MMUSIC] RE: [BEHAVE] RE: Moving draft-marjou-beh… Dan Wing
- RE: [MMUSIC] questions about grouping media strea… Even, Roni
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Xavier Marjou
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Colin Perkins
- AW: [AVT] RE: [MMUSIC] questions about grouping m… Kalleitner, Franz
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Lars Eggert
- RE: [MMUSIC] questions about grouping media strea… Dave Singer
- RE: [MMUSIC] questions about grouping media strea… Even, Roni
- [MMUSIC] Re: [AVT] questions about grouping media… Andrea Lorenzo VITALI
- [MMUSIC] Re: [AVT] questions about grouping media… 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
- [MMUSIC] Re: [AVT] Moving draft-marjou-behave-app… 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