[Bug 705991] Adding support for DASH common encryption to qtdemux and dashdemux

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=705991
  GStreamer | gst-plugins-bad | git

Thiago Sousa Santos <thiago.sousa.santos> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago.sousa.santos at collabo
                   |                            |ra.co.uk

--- Comment #1 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2013-08-14 15:52:14 UTC ---
(In reply to comment #0)
> I would like to add support for encrypted ISOBMFF DASH streams that have been
> encrypted using the DASH common encryption format (ISO/IEC 23001-7). When a
> DASH MP4 file is encrypted using DASH common encryption (CENC), the
> initialisation segment is modified as follows:
> * The avc1 or avc3 box (path /moov/trak/mdia/minf/stbl/stsd/) gets renamed to
> “encv” and a protection scheme information box (“sinf”) is added that contains
> the original data format (e.g. “avc1”)
> * one or more DRM-specific (“pssh”) boxes are added to the moov box
> 
> Each fragment is modified as follows:
> * Each sample in the MDAT is encrypted using AES in CTR mode. Each sample has a
> mix of encrypted parts and clear-text parts.
> * A sample encryption box (“senc”) is added that contains the key ID (KID) and
> the lengths of the encrypted and clear sections for each sample, plus the IV
> for each sample.
> 
> To decrypt the stream, a DRM system uses the protection specific boxes, key ID,
> IV, codec_data and clear/encrypted region information to decrypt each sample.
> 
> I was thinking of modifying qtdemux to create a pad for each encrypted stream
> with a new mime type (e.g. video/x-cenc,
> protectionScheme=”urn:uuid:69f908af-4816-46ea-910c-cd5dcccb0a3a”) plus a 

This makes sense, it is a different type of media.

sticky
> message on this pad for the protection specific boxes. Dashdemux would also
> need to be modified to create a sticky message for any protection specific data
> in the manifest.

I'm assuming you meant 'event' instead of 'message'.

> 
> As each sample is demultiplexed by qtdemux it would add the clear/encrypted run
> information, the IV and the KID as metadata attached to the source buffer.
> 

I haven't read this spec or know much about DRM implementations, so forgive me
for naive questions.

Is this information changing for every buffer? If not, events could be used
here, too.

> A DRM implementation could then use the information attached to each buffer,
> plus the messages from its sink pad to decrypt the sample and either output the
> unencrypted data to a source pad or directly display the content (e.g. if the
> DRM system required a secure pathway to the display).

I agree to have an element dedicated to the decryption, makes it easier to
reuse and debug, also keeps demuxers less complex. About the
decrypt+decode+display thing, if the restriction is the use of a special
memory, bufferpool allocation could be used to have multiple elements doing
smaller tasks instead of a single larger element.

> 
> I am interested in the opinion of the gstreamer developers of this approach,
> and also I would like to find out if anyone else was thinking of implementing
> DASH CENC.
> 
> Alex

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.