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

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

Thomas,
I already wrote that we need to look at the general case before going to
a specific solution.

Currently for a media stream we have a way to mark a stream using the
label attribute. We have a way to apply semantics to a single stream
using the content attribute. What we are doing here is defining
semantics to a group of streams by using dependency attribute. The
parameter for the dependency does not have to be the same for all cases
and depends on what you want. As for tagging the dependencies it may be
the mid number or use a label.

Now the second part that is needed is to specify the grouping, we have a
grouping attribute but it lacks some parameters for the layered codecs
and the repair stream. 
I would like to add to this the case of simple alternate attributes. For
example I can do G.711 with two H.263 video streams or G.711 with one
H.264 video stream.

I see two cases for the group, one for alternate streams and the other
for a set of streams. The advantage of using the group attribute is that
if the other side does not support it, he will remove it from the
answer.

Here are examples for both

Alternate: here you may use 1 and 2  or 1 and 3


a=group:ALTS:1 1 2
a=group:ALTS:1 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


For a SET here you say that 2 and 3 are a set for layering

a=group:SET 2 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

> -----Original Message-----
> From: Thomas Schierl [mailto:[e-mail]]
> Sent: Friday, June 08, 2007 12:47 AM
> To: Even, Roni; '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 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


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