[AVTCORE] VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)

[Stephan Wenger <[e-mail]>]

All:
We have a few editor’s notes open in the current vvc draft (https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/), and here is how we suggest to deal with some of them.  Please comment within a week or so.  Absent comments/discussions, we will rev the draft incorporating the changes.  These should be relatively easy…

Editor-note 24:  We recently had consensus on this change.  Therefore, we plan to rename the bit (“Reserved” would be a bit misleading :-) and remove the note.

Editor-note 11: the sub-profile ID, in VVC, is a 32 bit unsigned binary.   The current text suggests that binary to be represented by a base 16 RFC4648 representation.  Similar fields (binaries in VVC, such as sprop-vps, sprop-sei etc.) use base64.  Therefore, we suggest using base164 here also (it saves a byte or so) and to remove the editor’s note.

Editor-note 19: I believe we had an agreement (at least in spirit) that packetization level buffer management is unnecessary.  Based on this decision, we should remove this note, and also “condition B” in the tenth paragraph of section 6.
However, please note that the buffer management here is not related to memory usage—which I think we said is a non-issue nowadays.  Instead, it’s related to minimizing startup delay, and that’s definitely not a non-issue.  Then again, the mechanism described here has been present in the HEVC payload format for many years, and I have not seen a single system that uses it.  It could also be trivially bolted on later, in case we figure out that removing the mechanism was a mistake.  Therefore, we suggest to remove it from this draft.

Editor-note 20: we will update the example for the next revision and remove that note.

With these editor notes taken care of, we have only two left: #14 and #21