[ENHANCEMENT] Handle idr_pic_id in AVC slice header parsing #861

New Issue

claunia · 2026-01-29T16:55:34Z

claunia commented

2026-01-29 16:55:34 +00:00

Originally created by @Harshdhall01 on GitHub (Dec 25, 2025).

Description:

Found a TODO in the AVC slice header parsing that suggests incomplete handling of IDR picture IDs:

Location:src/lib_ccx/avc_functions.c:998

Current code:

if (nal_unit_type == 5)
{
    tmp = read_exp_golomb_unsigned(&q1);
    dvprint("idr_pic_id=            % 4lld (%#llX)\n", tmp, tmp);
    // TODO
}

Issue:
The IDR (Instantaneous Decoder Refresh) picture ID is:

✅ Successfully read from the bitstream
✅ Printed for debugging (dvprint)
❌ Not stored in any context structure
❌ Not used for any further processing

Potential improvements:

Store the value in an appropriate context structure (e.g., dec_ctx->avc_ctx->idr_pic_id)
Use the value for frame identification or ordering if needed
Document why it's read but not used (if intentional)

Questions for maintainers:

Should idr_pic_id be stored in the AVC context?
Is this value needed for caption extraction, or is reading it sufficient?
Are there cases where this ID would be useful for timing or frame ordering?

Research:
According to H.264 spec, idr_pic_id identifies IDR pictures and can range from 0-65535. It's used to identify different IDR pictures when multiple occur in sequence.

Proposed solution:

Add idr_pic_id field to the appropriate context structure
Store the value when read
Add comment explaining its purpose
(Optional) Expose it in debug output or logging

Background:
Working toward GSoC 2026 with CCExtractor. First PR (#1889) merged. Focusing on core video processing and subtitle extraction for the CCExtractor 1.00 release.

Would love to implement this if you can guide me on whether/how the ID should be used!

Originally created by @Harshdhall01 on GitHub (Dec 25, 2025). Description: Found a TODO in the AVC slice header parsing that suggests incomplete handling of IDR picture IDs: Location:`src/lib_ccx/avc_functions.c:998` Current code: ```c if (nal_unit_type == 5) { tmp = read_exp_golomb_unsigned(&q1); dvprint("idr_pic_id= % 4lld (%#llX)\n", tmp, tmp); // TODO } ``` Issue: The IDR (Instantaneous Decoder Refresh) picture ID is: - ✅ Successfully read from the bitstream - ✅ Printed for debugging (`dvprint`) - ❌ Not stored in any context structure - ❌ Not used for any further processing Potential improvements: 1. **Store the value** in an appropriate context structure (e.g., `dec_ctx->avc_ctx->idr_pic_id`) 2. **Use the value** for frame identification or ordering if needed 3. **Document why** it's read but not used (if intentional) Questions for maintainers: 1. Should `idr_pic_id` be stored in the AVC context? 2. Is this value needed for caption extraction, or is reading it sufficient? 3. Are there cases where this ID would be useful for timing or frame ordering? Research: According to H.264 spec, `idr_pic_id` identifies IDR pictures and can range from 0-65535. It's used to identify different IDR pictures when multiple occur in sequence. Proposed solution: 1. Add `idr_pic_id` field to the appropriate context structure 2. Store the value when read 3. Add comment explaining its purpose 4. (Optional) Expose it in debug output or logging Background: Working toward GSoC 2026 with CCExtractor. First PR (#1889) merged. Focusing on core video processing and subtitle extraction for the CCExtractor 1.00 release. Would love to implement this if you can guide me on whether/how the ID should be used!

claunia referenced this issue

2026-01-29 17:18:01 +00:00

[PR #861] [CLOSED] README FILE #1693

claunia referenced this issue

2026-01-29 17:18:01 +00:00

[PR #861] README FILE #1698

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#861