[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 #52 from Chris Bass <floobleflam at gmail.com> 2014-02-03 09:23:06 UTC ---
(In reply to comment #51)
> I think to get started it would make sense to get this into gst-plugins-bad
> first until we're really sure about the API. And then have elements use that
> for some time.
> 
> 
> Also maybe we can have a "drm" library, that contains both the cenc and the
> dtcp-ip stuff... and whatever else comes in the future?

I don't particularly mind where it's located. But would there be any problems
linking qtdemux to it if it's in gst-plugins-bad?

> Wouldn't it be better to have these events as metas on the buffers to which
> they apply?

One of the reasons for choosing events is that you can have initial pssh
information in DASH MPDs as well as in ISOBMFF files. So it seemed simpler to
pass this information downstream using events, which might originate from
dashdemux or from qtdemux.

> Also you can't make custom events like this, you have to use the
> generic "custom downstream" event type and then your custom element would only
> have a different name in the structure. See how the force-keyunit element for
> example is implemented

Ah, OK.

The behaviour I was seeking was for the most recent initial pssh event for each
system-ID to be stuck to the src pad, and, similarly, the most recent
non-initial pssh event for each system ID to be stuck to the src pad. That's
why I went for two separate event types, setting the structure name of each
event to GstCencEvent-<system UUID>. 

But I guess we could get the same behaviour if they are both
CUSTOM_DOWNSTREAM_STICKY events, with the initial events named
GstCencEventPsshInit-<system UUID> and the non-initial events named
GstCencEventPssh-<system UUID>. That would hopefully give the same sticky
behaviour, while allowing downstream elements to distinguish initial and
non-initial pssh data.

> Also wouldn't the PSSH_INIT be possible to just put into the caps (because
> there is only one, right?), and the PSSH one as a meta (because there can be
> many, one per buffer in the worst case)?

First of all, there's one per pssh box in the media, so if you took that route
you might have multiple pssh boxes in the caps (which may or may not be an
problem - I guess the main drawback would be potentially lots of data in the
caps).

Secondly, there's not necessarily only one initial pssh event. In the case of
DASH streams that have separate initialisation segments for all representations
there will be new initial pssh information parsed from the moov of the
initialisation segment each time the client switches to a different
representation. If the initial pssh information is carried in the caps, then I
guess in this scenario you'd need to send new caps events each time the
representation changes (there's probably already a new caps event sent in this
scenario on representation switches, so maybe this wouldn't be too much of an
issue.)

However, wouldn't it be more consistent to pass pssh data via the same
mechanism, regardless of whether it's initial pssh data or not, and regardless
of whether it originates from dashdemux or qtdemux?

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