1765246 - firefox falsely expects SAIO and SAIZ boxes in AES-CTR protected audio streams in mp4

Status: UNCONFIRMED

(Core :: Audio/Video: Playback, defect)

Description

[rjbean]

Steps to reproduce:

We encrypted dash (CENC) with AES-CTR using subsample for video, full sample for audio, and we omitted the saio+saiz boxes in audio. This is allowed (we argue, even required) by the specification

we then tried to play this content in firefox

Actual results:

playback does not progress, does not play a single segment

it appears FragmentedMp4Extractor.java parseTraf correctly checks that saio and saiz are not null before reading them, but leaving the dataPosition and aux data position at baseDataPosition appears to stall the work.

Expected results:

ISO-23001-7
10.1 ‘cenc’ AES-CTR scheme
Non-video encrypted tracks SHALL be protected using full-sample encryption as specified in 9.4

• 9.4 details the aes-ctr can encrypt blocks smaller than the cipher. the entire audio data stream is encrypted
• this contains no subsample data, no pattern

DASH CENC with AES-CTR encryption uses full sample for audio tracks, but firefox (unlike chrome) expects saio and saiz atoms with the senc. senc is always required

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jim Mathies [:jimm]]

Can you provide a test case / test stream we can use to test the issue?