Subject: [video-codec] Testing draft text for low latency modes

From: Thomas Daede <[email-masked]>
Date: Tue, 13 Oct 2015 11:23:27 -0700

Due to concerns about the high variability and relative codec
independence of closed loop CBR rate control, I've split apart the "low
latency" use case into two cases. I currently have both in the draft,
which means that the requirements draft will need to be updated to
reference the correct scenario. My suggestion would be to have quality
requirements for the High Latency and Unconstrained Low Latency
scenarios, but only require that the Constrained Low Latency test does
not fail.

Unconstrained Low Latency is also useful for applications where average
bandwidth is more expensive than short peaks of bandwidth.

Note that none of these scenarios forbid rate control, but they impose
limits on what knowledge the rate control has. This means that none of
them require exposing inner workings of the codec.

The new text is below:

### 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. One
parameter is provided to adjust bitrate, but the units are arbitrary.
Example configurations follow:

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

### Unconstrained Low 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), but no frame delay, buffering, or lookahead is allowed.
One parameter is provided to adjust bitrate, but the units are arbitrary.

### Constrained Low Latency

The encoder is given one parameter, which is absolute bitrate. No frame
delay, buffering, or lookahead is allowed. The maximum achieved bitrate
deviation from the supplied parameter 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.