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

[Ross Finlayson <[e-mail]>]

> If you are able to set the RTP timestamp reliably, then you must already have some sort of frame boundary identification.

Yes, we have a reliable way of determining when *VCL* NAL units cross a frame boundary: Look at the first slice header bit.  The one remaining problem (that I identified at the end of my last message) is: How to classify any *non-VCL* NAL units that appear between one VCL NAL unit and another VCL unit that has the first slice header bit.  Which of these belong to the last frame, and which belong to the next frame.

But perhaps this doesn't really matter?  Perhaps it's OK (from the point of view of receivers that check and try to optimize for the 'M' bit) if we always set the 'M' bit for the last VCL NAL unit of a frame, even if some subsequent non-VCL NAL units (appearing before the first VCL NAL unit of the next frame) also belong logically to the current frame??


> But you should realize that, in doing this, you have defeated the marker bit optimization. You have just shifted the latency from the receiver to the sender

No, not necessarily.  If the encoded video comes from a file (i.e., pre-recorded), then the latency involved in requiring the sender to examine the 'next' frame will usually be negligible.  But in any case, the situation we're talking about here (senders working from a sequence of pre-encoded NAL units) is one that usually occurs only in non-interactive environments, for which latency isn't crucial.


> So there is not much benefit in making the marker bit reliable in this case, and there is even the risk that it will add unnecessary latency.

That's certainly another possibility, I suppose: Recommend that if a sending implementation cannot determine whether or not a NAL unit ends an 'access unit' (frame) without having to scan subsequent NAL units, then it should not set the 'M' bit at all.  I don't like this, though (especially because it adds receiver latency without necessarily reducing sender latency (note above)).  But it's a possibility to consider...

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