Re: [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit

["Wang, Ye-Kui" <[e-mail]>]

Though I don't think it is not really necessary, I think we can either simply add a note after the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention this as part of the introduction to HEVC.

The addition is not really necessary because the first slice header bit is more expected to be used by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the decoder etc), while for the receivers at RTP level, they can always use the M bit and/or the RTP timestamp.

The semantics of the M bit is clearly specified, thus sender implementations should follow the semantics. Those implementations that do not follow what is specified, e.g. the M bit semantics, when encapsulating NAL units into packets, are bad implementations. It seems to me that the reasoning for your suggestion is that you expect in the future a lot of H.265 RTP payload format implementations would not follow the M bit. Nobody knows the future, but I hope this would not happen, as it is so easy to follow the semantics, and I don't see a reason why implementers would not follow what is being specified. As I explained twice already, not as in RFC 6184, in the context of the H.265 payload draft, there is no reliability issue with the M bit to be used for detection the end of an AU (after de-jittering of course - same for all approaches.

BR, YK

From: [e-mail] [mailto:[e-mail]] On Behalf Of Ross Finlayson
Sent: Thursday, August 08, 2013 8:15 PM
To: [e-mail]; [e-mail]
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit

(I changed the "Subject:" line to make it clear that we're talking about the (future) H.265 RTP payload format specification here; not the (existing) H.264 RTP payload format specification.)



First of all, implementers are expected to have basic knowledge of the video coding specification itself.

Yes.  However, in this case we seem to disagree on what constitutes 'basic knowledge'.  Determining whether or not a NAL unit ends an 'access unit' (in the situation - common for many implementations - where this is not available directly from the encoder) is far from 'basic knowledge' of H.265.  Unless you can point to a specific section in the H.265 specification that describes this (in which case we could add a reference to that section), it seems prudent to add a little text to our RTP payload format specification that clarifies this.


Of course, bad packetization/sender implementations [of the RTP 'M' bit] can make that unreliable - but bad packetization/sender implementations can make anything unreliable - thus they don't count.

I'm not sure what you're saying here.  I hope you're not saying that we shouldn't really care about whether or not implementations set the 'M' bit correctly, because in that case I definitely disagree; that's the whole point of this email thread.



 Lastly, the suggested text is too vague and even incorrect.

Like Mohamed, you're inadvertently making my point for me :-)


For example, in the following copied part: what is "the current NAL unit"?

By this I mean the NAL unit that's being packed in the RTP packet for which we are considering whether or not to set the "M' bit (or the final such NAL unit, if there's more than one).



Also, it is possible for non-VCL NAL unit to be between two VCL NAL units in an AU, the [suggested] language would suggest that the first of the two VCL NAL unit ends the AU - this is definitely incorrect.

Yes, good point - thanks.

Here, then, is new wording for the suggested paragraph (to be added to the H.265 RTP payload format specification, just after the existing 'M bit' text):

----------
Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender implementation whether or not the NAL unit ends an access unit.  Instead, the implementation can obtain this information separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g., because the implementation is sending data that consists solely of a sequence of pre-encoded NAL units), then it must instead inspect subsequent NAL units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:
    A NAL unit ends an access unit if it is a VCL NAL unit, and the next-occurring VCL NAL unit has the high-order bit of the first byte after its NALU header equal to 1.
----------

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/