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

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Dec 2013 19:14:55 -0500

If implementations could be required to support both SST and MST in H.265, that would be a big win IMHO.  Assuming that implementations correctly handle DON, we should be most of the way there anyway.

Given the inclusion of scalability support in the headers and simplifications, the goal of improved payload interop for H.265 seems attainable and well worth shooting for. So while I can see the potential need for a bitstream profile along the lines of what UCI Forum did for H.264/SVC, it would be great if no transport profile was needed.

On Dec 19, 2013 4:56 PM, Stephan Wenger <[email-masked]> wrote:
Hi Bernard,
Please see inline.
Stephan

From: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Thu, 19 Dec 2013 16:23:25 -0500
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Bernard Aboba <[email-masked]<mailto:[email-masked]>>, payload issue tracker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling

My concern was more about the RTP payload interoperability issues of MST vs. SST, though I certainly do understand the concern over  a BUNDLE dependency (so I would lean more toward option 3 for signalling).

Speaking personally, I have no idea, yet.  First, this is signaling, which is not my center of expertise.  For example, I don’t even recall in all its glory what technical reason made us distinguishing MST and SST in 6190.  And second and perhaps more importantly, my preference is to get some experience with “easy” use cases first, before tackling this potentially thorny issue in a generic way.

In particular, with the good work done to simplify the NAL unit types,  it seems that we are getting closer with H.265 to achieving interop out of the gate, particularly if implementers correctly support temporal scalability so we can take that for granted.

Should implementations be required to handle one (e.g. SST) or both modes at the payload level, or will groups like UCI Forum once again need to create transport profiles as is being done with H.264/SVC?

As I believe I have pointed out in my reply to your ticket #6, I would have no objection to require all receiver implementations to handle both the SST and the MST use case.

As for the more general issue of profiling RFCs with optional code points in the IETF or elsewhere, I rather see that done in forums like UCIF or 3GPP than watch an organization like the IETF, which has little or no experience in dealing with it, to make an attempt.  I see at least three reasons.  First, narrow profiles that serve certain industries only (in contrast to broadly applicable protocol RFCs) allow for cost efficient solutions, without harming interoperability in that respective industry.  If the industry is sufficiently “closed” (in the sense that interoperability to other industry products is not that big an issue—one that can easily be trusted to gateways that may eb required anyway), that is not as bad a solution as it initially sounds.  Second, profiling organizations will create profiles anyway.  Maybe not UCIF, but others almost certainly.  And third, Rtcweb is IMO a very good example why the IETF should not attempt system design and profiling.  We are not good at it.

Stephan

On Dec 18, 2013 6:09 PM, Stephan Wenger <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard, all,

On 12/9/13, 7:49 PM, "payload issue tracker"
<[email-masked]<mailto:[email-masked]>> wrote:

>#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?

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

>
>--
>-------------------------------------+------------------------------------
>-
> Reporter:                           |      Owner:  draft-ietf-payload-
>  [email-masked]<mailto:[email-masked]>          |  [email-masked]<mailto:[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/>
>