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

[Dave Singer <singer at apple.com>]

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