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

["Even, Roni" <[e-mail]>]

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