RE: AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed

["Even, Roni" <roni.even at polycom.co.il>]

Dave,
I understand that you intend to send two media streams using two m lines
without grouping and any specific semantics to identify the stream.
Our experience is that if you have two video m lines you can not know
which one the other will pick if he does not understand the relation
between the streams.
Roni

> -----Original Message-----
> From: Dave Singer [mailto:singer at apple.com]
> Sent: Saturday, June 09, 2007 1:56 AM
> To: Kalleitner, Franz; Even, Roni; mmusic; IETF AVT WG
> Cc: Clinton Priddle (KI/EAB)
> Subject: Re: AW: [AVT] RE: [MMUSIC] questions about grouping media
streams
> in RTPand SDP (RFC3388 etc), advice needed
> 
> At 11:54  +0200 5/06/07, Kalleitner, Franz wrote:
> >hi, dave,
> >
> >you can find some work and ideas on how to handle a "repair" stream
> >in parallel to an orignal RTP stream in RFC4588 too.
> >
> >cheers, franz
> 
> Thank you.  This has the rather useful paragraph:
> 
>     A special case of the SDP description is a description that
contains
>     only one original session "m" line and one retransmission session
"m"
>     line, the grouping is then obvious and FID semantics MAY be
omitted
>     in this special case only.
> 
> Since this exactly describes our current situation -- the normal and
> repair streams are indeed easily identified, and we currently only
> allow one normal stream per session -- perhaps we will take this
> route, and let the standards catch up to where we need to be, if
> anyone has a need for multiple base streams in the future.
> 
> And indeed, not doing grouping means avoiding having to insist that
> any audio or video streams in the same SDP also have a media ID (as
> the grouping RFC requires)., even though those IDs are not grouped.
> 
> At 14:42  -0700 7/06/07, Stephan Wenger wrote:
> >Hi all,
> >Yes, i agree with Roni: This is not a layered codec case in any
> >sense, as there is no directed use hierarchy between those two
> >flows.  Under certain conditions (i.e. in the absence of packet
> >loss), both are valid, usable streams.
> 
> Is an SI AVC stream really a usable stream in its own right?
> 
> >But, IMHO, this may be not a bad example for multiple description
> >coding.  The two streams represent essentially the same media, and
> >(under certain conditions such as packet loss) it is advantageous to
> >use both of them, not only one.  It may not be a direct hit on the
> >Schierl draft MDC use case, but it's close enough to be documentable
> >in a 3GPP spec.
> >I'm not sure that the use case in question warrants a new I-D.  If
> >the analogy to video transmission would be a bit more solid, I would
> >have a different view.  But, a it stands, you could not use the
> >mechanism envisioned with any predictive video codec (possible
> >exception: H.264 extended profile, utilizing SI/SP technology), as
> >it is at present close to impossible to generate identical reference
> >pictures from two different streams, using different encoding
> >methods.
> 
> Actually I would have agreed with you until I found someone doing it
> in AVC successfully using I frames, not SI frames.
> 
> At 14:47  -0700 7/06/07, Thomas Schierl wrote:
> >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.
> 
> As I say, the rtpmap declarations and parameters identify the two
> streams, we have that in hand.  We just wondered how we should group
> them -- and all that is needed is a group.  Happily the quote above
> provides the short-term answer -- don't!
> --
> David Singer
> Apple/QuickTime

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt