ISOBMFF Multiple transforms and sample auxiliary information

[dwsinger]

CENC allows inheriting the aux_info_type of saiz/saio from the ProtectionSchemeInfoBox, rather than explicitly defining it. For compatibility with existing practices, we think this inheritance should be extended to ScrambleSchemeInfoBox.

[dwsinger]

suggest to Replace in 8.7.8.1: “then the implied value of aux_info_type is either (a) in the case of transformed content, such as protected content, the scheme_type included in the ProtectionSchemeInfoBox or otherwise (b) the sample entry type.” With “then the implied value of aux_info_type is either (a) in the case of transformed content, such as protected content, the scheme_type included in the ProtectionSchemeInfoBox or ScrambleSchemeInfoBox or otherwise (b) the sample entry type.”

We note that this inheritance might be problematic with multiple transformation. If a protected track is transformed into a restricted track, what is the implied value ? Perhaps we should say that aux_info_type and _parameter shall be explicitly signaled in the case of multiple transformations (and the same sentence attaches to scrambling spec., if a scrambling scheme needs aux_info, then the type is always explicitly signaled).

[jeanlf]

Agree with both

• first one was my proposal :)
• "If multiple transformations are used on any sample entry in the track, aux_info_type and aux_info_type_parameter shall be explicitly signaled"

[dwsinger]

alrrady covered in the 7th edition, closing