Prevent zero-latency mode from creating very large keyframes

[wreuven]

I am using zero-latency encoding.
In my test case, the encoder input does not change.

The first frame of first GOP was allocated about 20% of our 4mbps budget. This seems reasonable.

The first frame of the second GOP however is allocated 80%(!!) of our 4mbps budget. Even if the connection speed is double (8 mbps), this still means we've introduced a latency of 400 milli?

Is there some way to adjust this by configuration?

bandwidth 4000000 (4 mbps)
preset ultrafast
tune zerolatency
slices 4
x264opts no-mbtree:sliced-threads:sync-lookahead=0
gop_size 100
max_b_frames 0
refs 0

[benwaggoner]

I am using zero-latency encoding.
In my test case, the encoder input does not change.

The first frame of first GOP was allocated about 20% of our 4mbps budget. This seems reasonable.

The first frame of the second GOP however is allocated 80%(!!) of our 4mbps budget. Even if the connection speed is double (8 mbps), this still means we've introduced a latency of 400 milli?

Is there some way to adjust this by configuration?

bandwidth 4000000 (4 mbps)
preset ultrafast
tune zerolatency
slices 4
x264opts no-mbtree:sliced-threads:sync-lookahead=0
gop_size 100
max_b_frames 0
refs 0
Is the content pretty static? If it's a reasonably complex, relatively still image, a really big IDR followed by small P frames would be expected.

You could try setting --minqp 8 or something, which would cap the worst case frame size. Reducing --ipratio might help if that was insufficient.

Using something slower than --preset ultrafast can help as well. Unless you're running on some low-powered embedded system or something, even --faster is really fast on reasonably current hardware. And using --slices 4 suggests you have multiple cores available.

If performance is so tight as to require ultrafast, I'd also see if there is some kind of HW encoder that could be used instead. Those often have low-latency modes that can provide quality as good or better quality as --preset ultrafast, and are probably better-tuned for videoconferencing like scenarios.

Some more info on content and scenario likely would enable more focused suggestions ;).

[benwaggoner]

Also, have you set --maxrate and --vbv-bufsize to properly conservative values for your secenario? That's essential! Otherwise x264 is going to target a specified ABR without worrying much about how those are distributed over the file.

[wreuven]

Hi Ben.

Thanks very much. Your response mentioning the VBV and asking about the slices reminded me that Dark Shikari spelled it all out in this blog post. http://x264dev.multimedia.cx/archives/249

I had configured for multiple slices because I had remembered that slices is what allows X264 to distribute refreshes accross multiple frames. But I forgot the –intra-refresh flag and the VBV limits.