Issues with rav1e C-API: Bitrate, rdo_lookahead_frames, Tiles, and Threads Not Behaving as Expected

[TimYao18]

Hi all,

I'm using the rav1e C-API wrapper into Xcode to encode camera frames, but I've encountered some unexpected behavior with several settings: bitrate, rdo_lookahead_frames, tiles, and threads.

1. Bitrate Issue:
   I set the bitrate to 200 kbps and input 1080p frames (1920x1080). However, the encoded packets I receive can exceed 50 KB (around 400 kbps if calculated per frame at 15 FPS), which is much higher than the target bitrate. Shouldn't the bitrate constraint limit the packet size more effectively? Is there something I might be missing in how bitrate control works in rav1e?

2. rdo_lookahead_frames Issue:
   When I set the resolution to 640x480 and configure rdo_lookahead_frames = 5, I notice that at the start of encoding, it takes up to 13 input frames before the first encoded packet is output. I expected that with rdo_lookahead_frames = 5, it would only buffer 5 frames before producing output. Does this indicate a misunderstanding of how rdo_lookahead_frames functions, or could it be a configuration issue?

3. Tiles and Threads Issue:
   I’ve experimented with different tiles (0, 2, 4) and threads (6) settings to improve encoding speed or efficiency, but they don’t seem to have the expected impact. For example, with tiles=2 and threads=6, I still see high encoding latency (e.g., 0.84s for the first key frame) and significant frame dropping (42% of frames dropped in one test). Increasing tiles to 4 or keeping it at 0 doesn’t consistently improve performance either. Shouldn’t these parameters enhance parallelism and speed up encoding? Could this be related to my hardware or how I’m using the API?

Here’s my configuration for reference:

• Resolution: 1920x1080 or 640x480
• Bitrate: 200 kbps
• FPS: 15
• rdo_lookahead_frames: 5
• Other settings: low_latency=true, quantizer=130, threads=6, tiles=0/2/4 (tested separately)

My use case involves real-time streaming over Bluetooth with a 512-byte MTU, so low latency and consistent packet sizes are critical. I’ve attached a log snippet where a key frame reached 84,513 bytes despite the 200 kbps bitrate setting, and 56 out of 133 frames were dropped with tiles=2.

I’d appreciate any insights into what might be causing these issues or suggestions on how to debug them further. Are there specific parameters I should adjust, or is there a known limitation in the C-API I should be aware of? I’m using rav1e version [insert version, e.g., 0.6.6]—could this be related to a specific release? Thanks in advance for your help!

rav1e version [0.7.1]