Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-payload-rtp-jpegxs-16: (with COMMENT)

[Martin Duke <[e-mail]>]

I agree that this is not a dealbreaker. However, if there is another edit,
it would be good if the introduction expanded the definitions a bit to
clarify what you mean.

On Thu, Jun 17, 2021 at 12:18 PM Tim Bruylants <[e-mail]> wrote:

> Yes, I see now what you are referring to. The end-to-end latency
> definition that we refer to is the latency introduced by the
> compression-decompression cycle of applying XS to a video sequence. It is,
> as you state, evident that the network path (and other factors) introduces
> additional latency in to total grand scheme of things. But it is not
> exactly what the introduction is trying to convey.
>
>
>
> I updated the draft to -17 and did not really clarify this in more detail,
> as it is simply introductory text which is not essential for the RTP
> payload specification itself. If you insist, we can still edit this, but
> otherwise we prefer to keep it as is.
>
>
>
> Best regards,
>
> Tim
>
>
>
> *From:* Martin Duke <[e-mail]>
> *Sent:* Thursday 17 June 2021 21:05
> *To:* Tim Bruylants <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; Ali Begen
> <[e-mail]>; [e-mail]
> *Subject:* Re: Martin Duke's No Objection on
> draft-ietf-payload-rtp-jpegxs-16: (with COMMENT)
>
>
>
> Thanks! But how is this guaranteeing end-to-end latency, which is a
> property of the path?
>
>
>
> On Thu, Jun 17, 2021 at 11:59 AM Tim Bruylants <[e-mail]> wrote:
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > In the abstract and intro, it promises "end-to-end latency confined to a
> fraction of a frame".
> >
> > I am not sure what to make of this guarantee. Latency is a measure of
> time and a frame is measured in ... bytes?
> >
> > Moreover, end-to-end latency is mostly a property of the path, and not
> something an encoding format can promise.
>
>
> Indeed, in the context of an RTP protocol specification, the word "frame"
> is ambiguous. In this case, we refer to "video frames" and we have modified
> the text accordingly. It is common to express latency in terms of video
> frames, as this translates to a time (given the video frame rate). We have
> updated the text to use "video frame" instead.
>
>