RE: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed

[Dave Singer <[e-mail]>]

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:[e-mail]]
>>  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
>>  [e-mail]
>>  https://www1.ietf.org/mailman/listinfo/mmusic


-- 
David Singer
Apple/QuickTime

_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic