[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-good | git

--- Comment #21 from Chris Bass <floobleflam at gmail.com> 2013-11-14 09:52:21 UTC ---
(In reply to comment #20)
[...] 
> This section is not super small and duplicated, can you make it into a separate
> function?h

Yes, sure - I'll do that.

[...]
> I'm a bit concerned that we're ignoring the case where there is more than one
> PSSH box in the file. We should design something that works if we don't have a
> decrypter for the first PSSH, but only for the second. I think we should design
> that in before we're stuck with these caps until 2.x.

I agree - the intention was not ultimately to ignore this, only that it seemed
complex enough that it would take a fair amount of time to implement, and I
wanted to share the code done so far to get some feedback on the overall
approach.

It's worth saying that the patch currently does parse and store the information
from all PSSH boxes in the file; it's just that, when it comes to choosing
which one to use when setting the src pad caps, it picks the first one as an
initial quick solution (one that allowed testing of the code with suitable 
content).

I'm currently trying to figure out how to implement something that will work
with autoplugging. I guess what we want is for qtdemux to have some initial
unfixed caps set on its src pads that include an array of values for the
protection-system-id, one per PSSH box, e.g., 

    application/x-cenc, protection-system-id={A, B, C}

...such that the autoplugger can then select the right cenc decrypter element
from the registry (one that has sink pad caps application/x-cenc,
protection-system-id=B, for instance) and link the two. Following that there
would be some caps negotiation resulting in the caps on qtdemux's src pad being
fixated, etc.

However, I'm currently struggling to work out how to implement this in such a
way that it works with decodebin.

It doesn't look like qtdemux currently does any caps negotiation - it just
figures out the caps of the traks within the input file and sets these fixed
caps on its src pads. The process of how decodebin links a new demuxer src pad
with unfixed caps to a downstream element, and how the caps negotiation code in
qtdemux would then subsequently be triggered, is a little bit of a mystery to
me at the moment...

Any thoughts or guidance would be welcome! :)

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