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

[Ross Finlayson <[e-mail]>]

(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/