Re: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP andSDP (RFC3388 etc), advice needed

[Stephan Wenger <[e-mail]>]

Yes, and if this were a non-exotic use case, we would need such a  
type.  As it IS an exotic use case, I guess we can survive with 3GPP  
specifying the "normal" stream having a lower port number than the  
"repair" stream, or something like this.
(Now go out and blast me for unclean design choices. :-)
Stephan

On Jun 7, 2007, at 2:47 PM, Thomas Schierl wrote:

> Hi Roni,
>
> Then it would be something like we call 'mdc'. But I would like to  
> put that
> into an extra dependency type, since the characteristics of the  
> streams are
> different, even if they could be used exchangeable. But there is  
> one main
> stream, let us say. And that one should be identifiable.
>
> Thomas
>
>> -----Original Message-----
>> From: Even, Roni [mailto:[e-mail]]
>> Sent: Thursday, June 07, 2007 1:07 PM
>> To: Thomas Schierl; Dave Singer; mmusic; IETF AVT WG
>> Cc: [e-mail]; Clinton Priddle (KI/EAB)
>> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media  
>> streams in
>> RTP andSDP (RFC3388 etc), advice needed
>>
>> Hi,
>> My view is that you have similarity in the need for dependencies  
>> between
>> streams but the grouping logic is different.
>> In the layered codec the grouping is for a group that you can use  
>> all or
>> part of while in the repair case you may take one or the other.
>>
>> Roni Even
>>
>>> -----Original Message-----
>>> From: Thomas Schierl [mailto:[e-mail]]
>>> Sent: Thursday, June 07, 2007 8:46 PM
>>> To: 'Dave Singer'; Even, Roni; 'mmusic'; 'IETF AVT WG'
>>> Cc: [e-mail]; 'Clinton Priddle (KI/EAB)'
>>> Subject: RE: [AVT] RE: [MMUSIC] questions about grouping media  
>>> streams
>> in
>>> RTP andSDP (RFC3388 etc), advice needed
>>>
>>> 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.tx
>> t
>>> 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. There is not requirement, that the part of the media is
>>> independently decodable. It would be easy to integrate your  
>>> needs, if
>> they
>>> should not be already covered.
>>>
>>>
>>> Thomas
>>>
>>>> -----Original Message-----
>>>> From: Dave Singer [mailto:[e-mail]]
>>>> 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:[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
>>>>
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt


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