Re: [video-codec] draft-filippov-netvc-requirements-01

I see a much simpler distinction between high/low latency modes.
Low latency is zero frame delay, i.e. no reordering, lookahead, etc.
High latency is unrestricted, i.e. all tools / techniques enabled
to maximize quality or minimize bitrate / file size.

I don't think the definition of these modes should be tied to rate control
modes like VBR or CBR. While I agree interactive applications often have
constraints on both latency and peak bitrate (to remain below available
bandwidth), I think it is confusing to conflate them by defining low
latency in terms of bitrate control.

For example, under the current definition of low latency as CBR with a 300
ms rate control buffer (similar to MPEG VBV model), and no further
constraints, encoders could reorder 18 frames of 1080p60 and still claim
"low latency". I think this violates our goal. The true goal should be
absolute minimum delay, which means zero frame delay restrictions within
the encoder.

Mo (as individual)

On 7/22/15, 4:03 AM, Thomas Daede <tdaede@mozilla.com> wrote:

I have pending updates for a -02 version of the testing draft that
better machines the slides that I presented. I have pasted the revised
selection below. Note that the encoder parameters haven't been updated
yet, and I also plan to incorporate rate-control-less operating modes,
as per consensus in the room.

## Operating Points

Two operating modes are defined. High latency is intended for on demand
streaming, one-to-many live streaming, and stored video. Low latency is
intended for videoconferencing and remote access.

### High Latency

The encoder should be run at the best quality mode available, using the
mode that will provide the best quality per bitrate (VBR or constant
quality mode). Lookahead and/or two-pass are allowed, if supported.
Example configurations follow:

- x264: --crf=x
- x265: --crf=x
- daala: -v=x
- libvpx: --codec=vp9 --end-usage=q --cq-level=x

### Low Latency

Codecs should be run in CBR mode. The maximum allowed bitrate variance
is determined by a buffer model:

- The buffer starts out empty.
- After each frame is encoded, the buffer is filled by the number of
bits spent for the frame.
- The buffer is then emptied by (bitrate * frame duration) bits.
- The buffer fill level is checked. If it is over the limit, the test is
considered a failure.

The buffer size limit is defined by the bitrate target * 0.3 seconds.

On 07/21/2015 06:36 PM, Mo Zanaty (mzanaty) wrote:
> 300 ms (* bitrate) refers to the rate control buffer not coding latency.
> 
> I think the testing draft should define low latency as zero frame delay,
>i.e. no reordering. The high latency condition can be unrestricted.
> 
> Mo (as individual)
> 
> On Jul 21, 2015, at 6:28 PM, Ali C. Begen (abegen) <abegen@cisco.com>
>wrote:
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Thomas Daede
> Date: Tuesday, July 21, 2015 at 6:21 PM
> To: "Ali C. Begen", "video-codec@ietf.org"
> Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
> 
>> On 07/21/2015 06:14 PM, Ali C. Begen (abegen) wrote:
>>
>>>>>> - All of the use cases should specify either a high latency or low
>>>>>> latency requirement.
>>>>> And where is the borderline?
>>>>
>>>> What is a borderline use case? I would much rather keep the number of
>>>> configurations as low as possible.
>>>
>>> I mean what is low latency vs high latency. And who decides that?
>>
>> It is defined in draft-daede-netvc-testing-01 [1]. And some of the
>> definition should probably be moved into the requirements draft, though
>> individual codec parameters still belong in the testing draft.
>>
>> https://datatracker.ietf.org/doc/draft-daede-netvc-testing/
> 
> I searched for latency and delay, nothing showed up. The only time
>related number seems to be 300ms in section 5.3.
> _______________________________________________
> video-codec mailing list
> video-codec@ietf.org
> https://www.ietf.org/mailman/listinfo/video-codec
> 