[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 #47 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-01-15 21:28:10 UTC ---
(In reply to comment #46)

> I don't like this very much. The only way I can see this being flexible enough
> is if this cencdecrypt offers some kind of API to register decrypting modules
> (something similar to typefind) and as we don't need typefind-mp4 element we
> would never have to write a cenc-A-decrypt element. If this is the case, I
> think it is an ok solution.

I don't like it that much either if that helps, but the other solution is not
so great too ;)


The idea here would be that this cencdecrypt element *understands* the special
meaning of the encryption-scheme field. It would the look for an element of the
right classification that matches *any* of the encryption-schemes inside that
field, and modify the caps accordingly. It wouldn't be normal autoplugging as
in decodebin but with some additional knowledge about the caps.

Of course this is not nice because we break here the generic way of how caps
work. A GstSimultaneousList or similar thing seems like an incredible amount of
new complexity and confusion, as you can already see from your intersection
example :)

If we want to do it right with the way how caps work generically, I would vote
for just having "encryption-scheme-A=TRUE, encryption-scheme-B=TRUE" fields in
the caps. Not much uglier than codec_data in caps when transformed to a string
;)

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