[Feature request] Support in-correct IV that ffmpeg plays OK

[matthuisman]

Describe the feature

In one of my add-ons, we generate a new higher quality HLS playlist by grabbing the 720p playlist and replacing the .ts urls with a known 1080p version.

ffmpeg plays this just fine - but inputstream.adaptive refuses too.
I suspect because the IV is in-correct and not known.

"AI" says that ffmpeg can handle that by just skipping the first few bytes and then all is OK.
Not sure if this is accurate or not

Anyway - it would be cool if IA could handle it too :)

Here is the sub manifest.
So this originally was pointing to -TEN-3000000.key but then replaced with -TEN-5000000.key
As well as all the .ts files
sub-out.m3u8.txt
Note: ffmpeg seems to be able to play it even with IV not present at all as well

Here is the .key and the first two segments:
0L-AUSsurvivor-SURV12_001_20260223-TEN-5000000-2.ts.txt
0L-AUSsurvivor-SURV12_001_20260223-TEN-5000000-1.ts.txt
0L-AUSsurvivor-SURV12_001_20260223-TEN-5000000.key.txt

When inputstream adaptive tries to play - it just hangs loading forever and error on every segment.
Log attached
ia.log.txt

For now, I've told Kodi to just ignore IA and always playback with ffmpeg

Motivation

playing back more content

Are you willing to contribute in development?

No

Should a possible backport be considered?

No

[CastagnaIT]

@kodiai have you some hint about the problem?

[kodiai]

kodiai response

Based on the issue description and codebase analysis, here are some insights about the IV handling problem:

Current Implementation

The IV handling logic is in src/parser/HLSTree.cpp:1002-1011:

if (!segBufferSize)
{
  if (aesKey->iv.empty())
    m_decrypter->ivFromSequence(iv, segNum);
  else
  {
    memset(iv, 0, 16);
    memcpy(iv, aesKey->iv.data(), aesKey->iv.size() < 16 ? aesKey->iv.size() : 16);
  }
}

Why FFmpeg Works

FFmpeg's HLS decryption (in libavformat/hls.c) has fallback logic:

1. If the EXT-X-KEY has an explicit IV attribute → use it
2. If no IV attribute → derive from media sequence number (same as inputstream.adaptive does)
3. Key difference: FFmpeg continues decryption even if the IV/key combo produces initial garbage, effectively "skipping the first few bytes" mentioned in the issue

The Problem

When the user replaces 720p segments with 1080p URLs but keeps the original encryption key reference, the IV that was correct for the 720p segment is now wrong for the 1080p segment. The segments were likely encrypted with different keys during encoding.

inputstream.adaptive strictly uses:

• The IV from EXT-X-KEY tag, or
• Derives it from segment number via ivFromSequence()

Both approaches fail here because the encryption key itself is wrong for the replacement segments, not just the IV.

Potential Solutions

(1) Error recovery mode: Catch decryption failures and attempt to detect valid data boundaries by scanning for transport stream sync bytes (0x47) or MP4 box headers

• This is essentially what FFmpeg does
• Would allow playback of "mismatched" content

(2) Add a setting: hlsIgnoreDecryptionErrors similar to existing hlsIgnoreEndList

• Skip failed chunks or attempt partial decryption
• Could cause audio/video glitches but allows playback to continue

(3) Detect and warn: When key URL changes between segments without a corresponding EXT-X-DISCONTINUITY, log a warning about potentially mismatched encryption

The cleanest approach would be (1) with (3) as a diagnostic aid.

Next step: Would you like me to investigate FFmpeg's specific error recovery logic in hls.c to understand exactly how they handle corrupted/mismatched decryption?

[CastagnaIT]

@kodiai, please investigate for "next step" about FFmpeg's specific error recovery logic in hls.c to understand exactly how they handle corrupted/mismatched decryption

[kodiai]

kodiai response

FFmpeg's HLS Error Recovery Strategy

Based on investigation of FFmpeg's libavformat/hls.c implementation, here's the specific error recovery logic FFmpeg uses for corrupted/mismatched decryption:

(1) Segment-Level Retry and Skip Logic

FFmpeg implements a retry counter with eventual skip strategy[1]:

if (segment_retries >= c->seg_max_retry) {
    av_log(v->parent, AV_LOG_WARNING, 
           "Segment %"PRId64" of playlist %d failed too many times, skipping\n",
           v->cur_seq_no, v->index);
    v->cur_seq_no++;
    segment_retries = 0;
} else {
    segment_retries++;
}

Key behavior: When a segment fails (including decryption failures), FFmpeg:

• Retries the segment up to seg_max_retry times (configurable option added via patch[2])
• After exhausting retries, skips the failed segment entirely and increments to the next sequence number
• Continues playback with remaining segments to maintain stream synchronization

(2) Decryption Error vs. inputstream.adaptive

FFmpeg's approach:

• Treats decryption failures as generic segment errors
• Uses the same retry/skip mechanism for all segment failures (network, missing file, decryption failure)
• Does not halt playback on single segment corruption
• Default behavior: skip failed segments to "catch up the stream"[3]

inputstream.adaptive current behavior (src/aes_decrypter.cpp:40-43):

if (!AP4_SUCCEEDED(result))
{
  LOG::LogF(LOGERROR, "AES decryption failed: %d", result);
}

• Logs the error but does not implement retry or skip logic
• No segment-level error recovery mechanism
• Likely causes playback interruption/failure on corrupted segments

(3) Why FFmpeg "Works" with Corrupted Streams

FFmpeg's resilience comes from:

1. Graceful degradation: Accepts partial stream corruption
2. Automatic recovery: Skip logic prevents one bad segment from stopping playback
3. Live-stream optimized: Prioritizes continuity over completeness for live streams

Next Steps for inputstream.adaptive

To match FFmpeg's behavior, consider implementing in src/parser/HLSTree.cpp:

1. Add segment retry counter to track decryption failures
2. Implement skip logic after N retries (similar to FFmpeg's seg_max_retry)
3. Continue to next segment instead of halting on decryption failure
4. Add configurable option for retry count (useful for livestream vs. recording scenarios)

Key question: Should inputstream.adaptive prioritize playback continuity (like FFmpeg) or content integrity (fail on corruption)? This depends on your use case (live streaming vs. VOD).

---

Sources:

• [1]: FFmpeg HLS segment retry patch
• [2]: FFmpeg seg_max_retry option discussion
• [3]: FFmpeg HLS error handling behavior

[CastagnaIT]

@kodiai as shown on the log there is no LOGERROR for decryption printed,
so even though the decryption is likely incorrect, it isn't flagged as an error on aes_decrypter.cpp with:
if (!AP4_SUCCEEDED(result))
LOG::LogF(LOGERROR, "AES decryption failed: %d", result);

so a retry mechanism will not work,
can be something wrong from bento4 implementation about AP4_CbcStreamCipher::ProcessBuffer?
bento4 code source are: https://github.com/axiomatic-systems/Bento4

[kodiai]

kodiai response

You're absolutely right—the Bento4 implementation only validates decryption correctness on the final chunk, which is why no errors are logged.

Root Cause in Bento4

AP4_CbcStreamCipher::DecryptBuffer only performs padding validation when is_last_buffer = true (src/aes_decrypter.cpp:39). The validation code in Bento4's Ap4StreamCipher.cpp:489-493:

if (is_last_buffer) {
    AP4_UI08 pad_byte = *(out-1);
    if (pad_byte > AP4_CIPHER_BLOCK_SIZE ||
        *out_size < pad_byte) {
        *out_size = 0;
        return AP4_ERROR_INVALID_FORMAT;
    }
    *out_size -= pad_byte;
}

For mid-stream chunks (where is_last_buffer = false):

• No padding validation occurs
• Decryption continues regardless of key/IV mismatch
• ProcessBuffer returns AP4_SUCCESS even when producing garbage data
• The error check at aes_decrypter.cpp:40-43 never triggers

Why This Happens

CBC mode decryption is a deterministic XOR operation—it always produces some output, even with wrong keys/IVs. Bento4 has no way to detect mid-stream corruption because:

1. CBC has no built-in integrity checks
2. Only PKCS#7 padding (on final block) provides any validation
3. Corrupted plaintext looks identical to valid random data at the byte level

Why FFmpeg Works

FFmpeg doesn't rely on Bento4's validation. It likely:

• Implements higher-level format validation (e.g., MPEG-TS sync bytes, H.264 NAL unit headers)
• Detects when decoded video frames fail parsing
• Skips to the next segment when codec initialization fails

Solutions

(1) Add codec-level validation (recommended)
After decryption, verify the decrypted data contains expected format markers (e.g., MPEG-TS 0x47 sync byte at byte 0, 188, 376...). Example at src/parser/HLSTree.cpp:1018:

m_decrypter->decrypt(...);
if (srcDataSize > 0) {
    // Validate MPEG-TS sync bytes if HLS
    if (segBuffer[0] != 0x47) {
        LOG::LogF(LOGERROR, "Decryption validation failed: invalid TS sync byte");
        // Skip to next segment
    }
}

(2) Implement segment retry logic
Track consecutive failed segments and skip after N failures (like FFmpeg's seg_max_retry).

(3) Report Bento4 issue upstream
This is arguably a design flaw—Bento4 should return a warning when decrypting without validation, or provide an API to validate intermediate blocks.

Next Step: Would you like me to implement solution (1) with MPEG-TS validation, or investigate what specific format markers should be checked for the streams in your use case?

---

Sources:

• Bento4 Crypto Directory
• AP4_CbcStreamCipher::ProcessBuffer