low latency usage

[totaam]

How do I configure the API for low latency usage?
Ideally, I want the encoder to buffer at most N frames (N<2).
I thought that the pred_structure parameter would let me do that, but verify_settings does this:

    if (config->pred_structure != 2) {
        SVT_LOG("Error instance %u: Pred Structure must be [2]\n", channel_number + 1);
        return_error = EB_ErrorBadParameter;
    }

============================
PS: it would be nice if the encoder limits were part of the header file.
ie:

#define MIN_LUMA_WIDTH 64
#define MIN_LUMA_HEIGHT 64
#define MAX_LUMA_WIDTH 8192
#define MAX_LUMA_HEIGHT 4320

Also, the "enc_mode" and how it relates to the input_resolution could be documented a bit better I think.

[tianjunwork]

Hi @totaam,

1. The low latency usage(N<2) you are expecting is not supported by all SVT encoders by now.
   You can lower the look ahead value to reduce the number of frames being buffered.
2. EbEncHandle.c line 2078 will show the error msg if input goes over the limits.
3. Sorry that the table is not in user guide yet. You could refer to below one first. We will add it later. Thx.
   https://github.com/OpenVisualCloud/SVT-HEVC/blob/master/Docs/svt-hevc_encoder_user_guide.md#encoding-presets-table

[totaam]

Hi @tianjunwork,

1. Based what I saw in compute_default_look_ahead I've tried setting a low value for intra_period and rate_control_mode=1. It still buffered around 40 frames - am I doing something wrong?
2. Sure, #defines just makes the code that uses the lib more future proof, in case those values ever change, and makes it possible to support building on distros that may ship with different versions without having to resort to the lowest common denominator.
3. That helps, thanks.

I'm now hitting a completely different issue on my side, it looks like some python threading problem causing corruption and I am completely stumped. I don't think this is a bug in SVT-VP9 at all, but if you have any ideas at all, I'll take gladly them:
http://xpra.org/trac/ticket/2152#comment:5
(running the same code standalone without the full GTK and X11 server code works fine..)

[tianjunwork]

Hi @totaam, input_output_buffer_fifo_init_count decides the buffering number. hierarchical_levels(rc=0); intra_period(rc=1) will determine the lookahead value. So what you did is correct to lower buffering number.
set_parent_pcs() which uses fps also affects input_output_buffer_fifo_init_count value.

[totaam]

set_parent_pcs() which uses fps also affects input_output_buffer_fifo_init_count value.

That's what I feared, the fps value is capped between 24 and 120 fps, and the return value is 1.25 seconds worth:

    fps = fps > 120 ? 120 : fps;
    fps = fps < 24 ? 24 : fps;
    return ((fps * 5) >> 2); // 1.25 sec worth of internal buffering

With the minimum value of 24, that's still 30 frames buffered - way too much compared to my desired usage (N<2).
I'll take another look once the low latency functions are implemented.
Thanks.

[tianjunwork]

Sure.
There is a trello board to track HEVC features: https://trello.com/b/PgF6uoa7/svt-vp9.
You can track the status of coming features.