Subject: [payload] #7: Section 7.2.4 Dependency Signaling

From: "payload issue tracker" <[email-masked]>
Date: Tue, 10 Dec 2013 03:49:22 -0000

#7: Section 7.2.4 Dependency Signaling

 If MST is used, the rules on signaling media decoding dependency in SDP as
 defined in [RFC5583] apply.  The rules on "hierarchical or layered
 encoding" with multicast in Section 5.7 of [RFC4566] do not
 apply, i.e., the notation for Connection Data "c=" SHALL NOT be used with
 more than one address.  The order of session dependency is given from the
 RTP session containing the lowest temporal sub-layer to the RTP session
 containing the highest temporal sub-layer.

 [BA] The difference in O/A signaling between MST and SST is something we
 should be striving to eliminate long-term. With RFC 6190, it wasn't
 possible in SST to use RFC 5583 to negotiate layering in SDP since each
 layer was on the same RTP session and we couldn't have multiple m lines
 with the same port value. But now that we have BUNDLE that problem goes
 away, and if we have multiple SSRC on the same RTP session, then RFC 5583
 with BUNDLE may be the preferred way to go.   On the other hand, the SST
 approach has some advantages for a WebRTC application that doesn't use SDP
 at all.  Can we find some common ground, at least for MST unicast uses?

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-payload-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  rtp-h265                 |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/7>
payload <http://tools.ietf.org/payload/>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 18 Dec 2013 23:09:07 +0000

Hi Bernard, all,

> at all.  Can we find some common ground, at least for MST unicast uses?

This is an interesting topic.

I agree in principle that we should eliminate the differences in signaling
for Single Session Transmission (SST) and Multi-Session Transmission MST.
And not only for the reason you cited (the arrival of now widely accepted
transport schemes that are neither full SST nor full MST, and their
associated signaling: BUNDLE), but because, architecturally, a payload
format should be agnostic to such details in the first place.  This is not
an HEVC specific problem, and it wasn¹t an H.264-SVC specific problem
either.  It¹s just so that this area was (and is) underspecified, and
during the SVC payload format design, we had to do something, somewhere,
so we did what we did in the then open document.

We appear to have a number of options:

1. Call this a long-term problem.  Leave this area of the payload draft
³as is² (SST and MST with existing restrictions, that have served us well
in the pre-BUNDLE world).  Deal with BUNDLE and multiplexing issues
if/when they arrive in standardization space.  Webrtc is currently not
overly concerned with H.265, and the rest of the industry has very limited
(if any) experience with BUNDLEing, so this strategy may well be more
palatable that it sounds at the first glance.

2. Add BUNDLE-specific language (potentially as a third mode in addition
to SST and MST as defined today).  BUNDLE specific would here be using
BUNDLE in a single session environment. We would be adding a normative
reference dependency.

3. Essentially option 1, but commit ourselves to wait for the BUNDLE RFC
(and perhaps some initial implementation experience in the intersection of
BUNDLE and layered or multicast codecs), and only then publish something
to address the SSRC mux/BUNDLE use case.  Ideally, that ³something² would
be one or more RFCs that describe layered and/or multicast codec use over
SST classic, MST classic, SST w/ Bundle, MST w/ BUNDLE (does that make
sense?), and whatever else is en vogue at that time.  This RFC would
update the H.265 payload RFC and potentially deprecate some of the
signaling mechanisms and restrictions present therein.  I can promise
personal cycles (to the extent one can promise anything these days), but
note that this is not exactly my center of expertise.

4. Restructure the signaling of this HEVC payload draft such that it
becomes agnostic to the underlying structure of sessions and their
multiplexing.  We would be talking about serious surgery based on limited
(if any) practical implementation experience.   It¹s not the first time
that is done, but it¹s risky nevertheless.  And it would take years...

My personal preference is option 1 or option 3.  Option 4 takes too much
time (we know that 3GPP wants a normative reference soon), and the risk is
too high that we will get something wrong.  Option 2 has the potential of
perpetuating a bad architectural decision of the past, namely to specify
differences between various transport and signaling modes in a payload
format.

Reactions?

Thanks,
Stephan