[AVTCORE] Comments on draft-ietf-avtcore-rtp-v3c-04

[Jonathan Lennox <[e-mail]>]

I read over the V3C RTP Payload format draft, and I had some comments.  (These are comments as an individual, not as a chair.)


First of all, it’s not clear to me from the draft how the 2-D video streams (H.264, H.265, and H.266) are encapsulated or associated with the V3C stream.  Are these streams’ NAL units encapsulated inside V3C NAL units, or are the streams sent separately and then somehow correlated?  I think from reading the document that it’s the former, but this could definitely be clearer.

I’d question whether you actually want the complexity of three transmission modes (SRST, MRST, and MRMT).  In practice, as I understand it, for the 2-D video codecs MRST and MRMT have not been used.  This is the reason why the MRST and MRMT modes were removed for the VVC/H.266 and EVC payload formats (RFC 9328 and draft-ietf-avtcore-rtp-evc).  Unless you have specific use cases that would require these other modes, I’d strongly suggest you simplify the RTP payload format by removing them, and modeling the V3C payload on VVC or EVC’s payload specifically.  I believe this would also let you remove the grouping framework.

I’d also question whether you need out-of-order decoding (i.e. decoding order number, DON), though VVC/EVC kept this feature, so there may be a use case for them that I’m not aware of.

For the SDP encoding, the description in section 9.1.2 for the V3C video components doesn’t work.  When you send the SDP
       m=video 49170 RTP/AVP 99
       a=rtpmap:99 H265/90000
       a=fmtp:99 sprop-max-don-diff=0;
                 v3c-unit-header=EAAAAA==
you are negotiating the payload “video/H265”, not “video/V3C”, and that payload is defined by RFC 7798.  Unless you are updating the existing RFCs, this document can’t add parameters to video/H264 et al, only define video/V3C and its parameters.

For the other V3C parameters, it definitely seems that some of them are meant to indicate send properties and some receive capabilities, but it’s unclear to me which are which.  I suggest adopting the convention that the H.26* codecs have used, and name the send property parameters such that they start with “sprop-“.

I hope this is helpful!

Jonathan