Re: [payload] Benjamin Kaduk's No Objection on draft-ietf-payload-rtp-vc2hq-06: (with COMMENT)

[James Barrett <[e-mail]>]

I think adding the following to the start of Section 4 would help here:

  In this specification each RTP packet is used to carry data
  corresponding to a single Parse Info Header and its following data
  unit (if it has one).  A single packet MAY NOT contain data from more
  than one Parse Info header or data unit and a single Parse Info
  Header and Data Unit pair MUST NOT be split accross more than one
  packet.

--
James P. Weaver (né Barrett)
Research Engineer
BBC R&D North Lab,
Floor 5 Dock House, MediaCity,
M50 2LH
Tel: [phone]
e-mail: [e-mail]



> On 27 Jun 2018, at 07:56, Roni Even (A) <[e-mail]> wrote:
>
> Hi,
>
> About " A single RTP packet MUST NOT    contain coded data for more than one coded picture, so there is     no ambiguity here."
> I assume that it is not allowed to have more than one frame/picture in an RTP packet and this is the change from RFC3550
> Roni Even
>
> -----Original Message-----
> From: Benjamin Kaduk [mailto:[e-mail]]
> Sent: Tuesday, June 19, 2018 10:06 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-payload-rtp-vc2hq-06: (with COMMENT)
>
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-payload-rtp-vc2hq-06: No Objection
>
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-vc2hq/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for the clear Security Considerations section.
> I am a little uncertain about the privacy properties of the padding data, though, largely due to my uncertainty about the details of how the padding works.  (This is, perhaps, in a similar vein to Eric's general concerns on interoperability.)
>
> In particular, Section 4.2 says that the Data Length for a Padding Data Unit "may have any value" and "indicates the size of the recommended padding".  There is also an "Optional Payload Data" in Figure 6, and I failed to find a description of what its contents are for padding data units.  Section 4.5.1's coverage of the Padding Data Parse Info Header suggests that the "native VC-2" and RTP padding elements are essentially distinct, with the RTP one being essentially a recommendation to add a VC-2 one, but giving no mandatory guidance on how much padding to apply.  In this scenario I don't know what the purpose of the "optional payload data" in Figure
> 6 be, though.  Padding is of course ignored by the actual VC-2 decoder, so the concern would mostly be if the (RTP) bits on the wire include a side channel or "stegangraphic channel" (not exactly the normal meaning of that one) where identifying information could be inserted, unbeknownst to the recipient.  This could come into play if media encryption is not used, or when a middlebox/mixer is used, or probably in other scenarios as well.  The specification of all-zeros padding along with the Padding Data Parse Info Header of course removes any such channel at that point, but I didn't see a real confirmation that there was no channel in the RTP bits on the wire.
>
> Some additional section-by-section comments follow.
>
> Section 4.1
>
>   Timestamp: 32 bits  If the packet contains transform parameters or
>         coded slice data for a coded picture then the timestamp
>         corresponds to the sampling instant of the coded picture.  A
>         90kHz clock SHOULD be used.  A single RTP packet MUST NOT
>         contain coded data for more than one coded picture, so there is
>         no ambiguity here.
>
> Is this a new requirement or quoting a preexisting one?  If a new requirement, I suggest replacing "so there is no ambiguity here"
> with "in order to eliminate any chance for ambiguity".
>
> Section 4.2
>
>         If the receiver does not receive a transform parameters packet
>         for a picture then it MAY assume that the parameters are
>         unchanged since the last picture, or MAY discard the picture.
>
> Those seem like two very different options!  How would I choose between them?
>
>
> We only get the starting x- and y-coordinates of a slice for the first slice in a packet; it sounds like the main VC-2 spec specifies the order in which the following slices are laid out?
> (Do we need to say anything about what "x coordinate" and "y coordinate" mean?  I seem to recall that over history there have existed pixel identifying schemes that put the origin at both the top left and bottom left of the display.)
>
> Section 4.5.1
>
> There is some text here and elsewhere that seems to imply reusing a Parse Info Header for various data received in different RTP packets, potentially even from different coded pictures.  The Parse Info Header contains "next" and "prev parse offset"s, though -- when would those offsets need to be updated?
>
>   o  A receiver MAY combine all fragment data units (with parse code
>      0xEC) and the same picture number into a single picture data unit
>      with parse code 0xE8.  If the stream is required to comply with
>      major versions 1 or 2 of the VC-2 Spec then this MUST be done.
>
> The "and" in "and the same picture number" seems to be an editing error; maybe "with" is better?
>
>   o  Once a data unit has been assembled, whether a Sequence Header,
>      Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the
>      next parse offset and previous parse offset values in its Parse
>      Info Header should be filled with the offset between the start of
>      the header and the start of the next or previous.
>
> This text could probably be tightened up with respect to which next/previous fields are updated when, and what values go in them.
> E.g., do we have enough information to fill in the "previous" field when we start assembling a data unit, and the "next" when we finish assembling that data unit?
>
> Section 6.1
>
> Perhaps "RFC XXXX" makes more sense as the "published specification"
> than ST 2042-1?  That is, this is where the (mandatory) RTP framing is required, so it may be a better starting point for an implementor.
>
>



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------