[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 #53 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-02-04 11:57:32 UTC ---
(In reply to comment #52)
> (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?

Indeed it would... you would need to have an internal copy for that in qtdemux
then.

Reason for suggesting to put it into bad first is that it would allow
integrating this much faster, while still allowing some changes to the API. I
don't think we will otherwise get this integrated before 1.4.

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

Yes, that should work.


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

Yes, I think that makes sense then.

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