>> @@ -1327,6 +1384,19 @@ enum AVPacketSideDataType {
>> */
>> AV_PKT_DATA_A53_CC,
>>
>> + /**
>> + * This side data is encryption "initialization data".
>> + * For MP4 this is the entire 'pssh' box.
>> + * For WebM this is the key ID.
>> + */
>> + AV_PKT_DATA_ENCRYPTION_INIT_DATA,
>
> So its basically like extradata is for a codec ?
> If so it should be defined similarly as opaque encryption scheme specific
> data.
> It should not be container specific.
> Data taken from one container should be storable in another if both support
> the features used
Yes, that's the idea. Unfortunately the data is specific to a
container. This isn't taken from the common encryption spec, but from
the EME spec. The "EME initialization data registry" specifies
several fixed formats for initialization data that are all specific to
a container. <https://www.w3.org/TR/eme-initdata-registry/>
It would be possible to parse the PSSH boxes and just push the generic
data to the app. This would allow new containers to hold the same
data; then the app could wrap it back in a generic PSSH box for EME.
But that would remove the key ID information that exists in v1 PSSH
boxes. Some apps parse the PSSH boxes and filter the initialization
based on whether they already have those key IDs to avoid creating too
many sessions. So I would like to expose the whole PSSH box in the
side data so apps can do that.
I can change this to something that is specific to MP4 instead (e.g.
AV_PKT_DATA_MP4_PSSH). The app could just pull the key ID from the
first sample in the case of WebM.
>
> thanks
>
> [...]
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
