[Bug 705991] New: 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

           Summary: Adding support for DASH common encryption to qtdemux
                    and dashdemux
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bugzilla at ashley-family.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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 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.

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.

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 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.