CCExtractor version: master (post-#2359 / commit c1043ca)

Necessary information

• Is this a regression (i.e. did it work before)? NO
• What platform did you use? All (Linux / macOS / Windows)
• What were the used arguments? Standard H.264 / MPEG-TS extraction (ccextractor input.ts)

Summary

In commit c1043ca7 (#2359), MAX_CC_COUNT and HDCC_MAX_TRIPLETS_PER_SLOT were raised from 31 to 310 so that H.264 access units carrying multiple SEI messages can buffer all their caption triplets without discarding the frame.

However, avc_ctx->cc_count is typed as unsigned char in C (src/lib_ccx/avc_functions.h:6) and u8 in Rust (src/rust/src/avc/common_types.rs:7). Because an 8-bit unsigned integer caps out at 255, the buffer accumulator wraps around whenever an access unit carries dense or multiple SEI packets totaling between 256 and 310 triplets.

Root Cause Analysis

1. In C (src/lib_ccx/avc_functions.c:442-453):

struct avc_ctx
{
    unsigned char cc_count;  // <--- uint8_t: range 0..255
    unsigned char *cc_data;
    ...
};

void copy_ccdata_to_buffer(struct avc_ctx *ctx, char *source, int new_cc_count)
{
    ...
    memcpy(ctx->cc_data + ctx->cc_count * 3, source, new_cc_count * 3 + 1);
    ctx->cc_count += new_cc_count; // <--- Wraps modulo 256 on overflow
    ctx->cc_buffer_saved = CCX_FALSE;
}