Re: [MMUSIC] H.264 SVC and BUNDLE

[Harald Alvestrand <[e-mail]>]

On 08/31/2012 10:53 AM, Christer Holmberg wrote:
>
> Hi,
>
> One question is of course whether we are going to move ahead with the 
> m=bundle proposal. In that case, I guess the m=video lines would look 
> like they do today, and the question is how we describe the 
> multiplexed SVC within the m=bundle line.
>

The SVC session is simple - just use the same lines (except rtpmap 
H.264/ -> mime-type-map video/H.264, or whatever we decide to call it).
The MVC additional session can't be bundled, so it remains outside the 
BUNDLE line.


> Regards,
>
> Christer
>
> *From:*[e-mail] [mailto:[e-mail]] *On 
> Behalf Of *Harald Alvestrand
> *Sent:* 31. elokuuta 2012 9:13
> *To:* Bernard Aboba
> *Cc:* [e-mail]
> *Subject:* Re: [MMUSIC] H.264 SVC and BUNDLE
>
> On 08/31/2012 03:30 AM, Bernard Aboba wrote:
>
>     Harald said:
>
>     I lack the background to think about this... in existing
>     equipment, if you want to do SST, but would be willing to do MST
>     if the other end did not support SST, how would your offer look
>     (without BUNDLE)?
>
>     My head hurts a little when trying to guess, but from your
>     question it sounds like you've done it, so it's better if you just
>     paste an example.
>
>     (BTW, this is really an MMUSIC discussion)
>
>     [BA] RFC 6190 gives several examples of SST and MST offers:
>
>
>             7.3.1 <http://tools.ietf.org/html/rfc6190#section-7.3.1>. 
>             Example for Offering a Single SVC Session
>
>
>             7.3.2 <http://tools.ietf.org/html/rfc6190#section-7.3.2>. 
>             Example for Offering a Single SVC Session Using
>             scalable-layer-Id
>
>
>             7.3.3 <http://tools.ietf.org/html/rfc6190#section-7.3.3>. 
>             Example for Offering Multiple Sessions in MST
>
>
>             7.3.4 <http://tools.ietf.org/html/rfc6190#section-7.3.4>. 
>             Example for Offering Multiple Sessions in MST Including
>             Operation with Answerer Using scalable-laye
>
>
>             r-id
>
>       
>
>
>             7.3.5 <http://tools.ietf.org/html/rfc6190#section-7.3.5>. 
>             Example for Negotiating an SVC Stream with a Constrained
>             Base Layer in SST
>
>     I believe that the answer to your question is closest to example
>     7.3.5 (SST) with a bit of 7.3.4 (MST) thrown in. Notice that
>     Payload types 97 and 99 are similar but not the same (97 is SST,
>     99 is MST):
>
> Aha - so you'd send 3 video M-lines, an SST-only application would 
> zero out the second and third, while an MST-only application would 
> zero out the first, and one capable of doing both would accept all 3? 
> and one could look at the payload type (96/97 vs 98 or 99) to decide 
> which one a particular video stream belonged to?
>
> It makes no sense (to my mind at least) to multiplex L1 and L2 
> together, but one could multiplex SST with L1 and save one port in the 
> "both are supported" case:
>
> a=group:BUNDLE SST L1
>
> I think this would create sessions that would not create an unsolvable 
> problem; if all were accepted, the decoder would have to look at the 
> payload type of the first packet on an SSRC to figure out whether a 
> particular SSRC was using SST or MST for that particular payload.
>
>
> Offer:
>
>        a=group:DDP L1 L2
>        m=video 20000 RTP/AVP 97 96
>        a=rtpmap:96 H264-SVC/90000
>        a=fmtp:96 profile-level-id=53001e; packetization-mode=0;
>        a=rtpmap:97 H264-SVC/90000
>        a=fmtp:97 profile-level-id=53001f; packetization-mode=1;
>        a=mid:SST
>        m=video 20002 RTP/AVP 98
>        a=rtpmap:98 H264/90000
>        a=fmtp:98 profile-level-id=4de00a; packetization-mode=0;
>         mst-mode=NI-T;
>        a=mid:L1
>        m=video 20004 RTP/AVP 99
>        a=rtpmap:99 H264-SVC/90000
>        a=fmtp:99 profile-level-id=53001F; packetization-mode=1;
>         mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
>        3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
>        a=mid:L2
>        a=depend:99 lay L1:98
>
> On 08/30/2012 11:19 PM, Bernard Aboba wrote:
>
>     Harald said:
>
>     > My assumption has always been that if you were operating on a
>     network
>     > that could only apply diffserv to separate 5-tuples, you would
>     allocate
>     > the SSRCs comprising a multilayer encoding to different 5-tuples.
>
>     [BA] RFC 6190 Section 1 says:
>
>         This memo defines two basic modes for transmission of SVC data,
>
>         single-session transmission (SST) and multi-session transmission
>
>         (MST).  In SST, a single RTP session is used for the transmission of
>
>         all scalability layers comprising an SVC bitstream; in MST, the
>
>         scalability layers are transported on different RTP sessions.
>
>
>     [BA] So it is possible either to use multiple 5-tuples (MST) or a
>     single 5-tuple (SST).  However, my understanding
>     is that the SST approach is more popular than MST.
>
>     > This choice seems to be a choice that the application writer
>     should take
>     > before deciding whether or not to use BUNDLE, so it's a little
>     hard to
>     > see what the relationship to BUNDLE is.
>
>     [BA] The open question has been how to indicate the desire for
>     both layered coding and BUNDLE in SDP,
>     given the backward compatibility issues we have talked about.  For
>     example, if it is desired to do SST and
>     BUNDLE, do you signal MST and BUNDLE on different ports in the
>     offer and then if SST and BUNDLE are
>     supported by the answer, have the answer respond with BUNDLE as
>     well as dependency groups using
>     the same port?  That would seem to imply an assumption that every
>     MST implementation can also do SST.
>     Or do do you signal SST and BUNDLE on the same port, and then if
>     the response indicates that the SDP
>     was rejected, formulate an alternative offer (MST with BUNDLE? 
>     H.264/AVC with BUNDLE?
>     SST without BUNDLE??)
>