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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Oct 9 11:39:16 CEST 2013


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

--- Comment #5 from Chris Bass <floobleflam at gmail.com> 2013-10-09 09:39:12 UTC ---
Created an attachment (id=256792)
 View: https://bugzilla.gnome.org/attachment.cgi?id=256792
 Review: https://bugzilla.gnome.org/review?bug=705991&attachment=256792

Add cenc support

Here's an initial patch that extends qtdemux to handle common encryption. It's
quite a big patch, so I'll point out a couple of design decisions:

1. Src pad caps

For cenc-protected content, the src pads will have the following caps format:

[video|audio]/x-cenc,
   protection-system-id=(string)<URN of protection system>,
   protection-system-data=(buffer)<protection system private data>,
   original-caps=(GstCaps)<caps of original unencrypted stream>

So the caps structure of the orignal unencrypted stream is nested within the
src pad caps; the thinking behind this is that this would make it easy for the
downstream cenc decryptor to set it's src caps - all it would have to do is to
extract original-caps from its sink pad caps and set that on its src pad.

2. Cenc metadata type

I've created a metadata type to attach to the buffers of encrypted media that
qtdemux pushes downstream. This is called GstCencMeta, and it includes IV, KID,
and information about which bytes in the data are encrypted and which are clear
(i.e., all the information needed to decrypt the data in the buffer).

Since both qtdemux and cenc decryption elements outside of libgstisomp4 would
need to link to the GstCencMeta code, we separated it into its own library in
gst-libs/gst/isomp4. (Any thoughts on whether this is the right thing to do, or
not?)


The code in the patch has a few simplifications/restrictions that can be
addressed by future updates:

- The cenc spec allows sample properties (IsEncrypted flag, IV_Size and KID) to
be set for a group of samples, as specified in the sgpd and sbgp box types.
This code does not include support for this feature - it simply uses the
default sample properties (contained in the tenc box) for all samples.

- According to 14496-12, the sample auxiliary data (which in cenc includes the
IVs for each sample) can be stored anywhere in the same file as the sample data
itself. This code, however, is a bit more restrictive - it only handles
auxiliary information that is contained within the moof box holding the size &
offset information of the auxiliary data (i.e., the same moof box that contains
the sai[z|o] boxes).

- Cenc allows the same protected content to be decrypted via multiple
protection systems. The information specific to each protection system is
included in a pssh box (so, a piece of content might have a pssh box for
Playready, and another for Marlin, etc.). The protection system ID and data
that qtdemux sets on its src pad should depend upon which downstream cenc
decrypt elements are available on the system, which implies that there will be
need to be some caps negotiation; but as a simple initial implementation this
code just chooses the first protection system that it's parsed and uses that to
set the src pad caps.


Bugs:

The one issue that I'm aware of occurs only when qtdemux is given a single file
to play containing multiple movie fragments, rather than being passed separate
fragments (as would happen in the case of DASH).

The code maintains cenc metadata for all the samples in a single fragment; when
a new moof box is parsed it will overwrite its currently stored cenc metadata
with that from the new fragment. For the mode of operation where fragments are
being pushed (e.g., the DASH case), this works fine; however, when qtdemux
plays a single file it parses the next moof box just prior to outputting the
last sample of the current fragment, with the effect that when it does then
output the last sample of the current fragment it will actually attach the cenc
metadata of the last sample of the next fragment (since it's just overwritten
all of the cenc sample metadata with that of the new fragment).

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


More information about the gstreamer-bugs mailing list