[Bug 785531] appsink: forward the Protection Event to the application

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=785531

--- Comment #9 from y.bandou <bandou.yacine at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #8)
> Why do you split it up into two different pipelines?
> 

It is the webkit/Gstreamer architecture

> There's nothing technically wrong with posting messages from the demuxer,
> and it would also be required probably (see the qtdemux patch about
> selecting between multiple DRM systems). 

OK I'll do that

> Overall this nonetheless looks like
> you have a misunderstanding about how the protection API is supposed to be
> used.
> 
> 
> Basically, everything should be handled by the decryptor element. The
> demuxer and parser before that extracts the "common" knowledge from the
> streams and provides it downstream via the buffers/events/metas/caps. It
> might have to ask the application to do some kind of decision (see above),
> but that's about it. The decryptor then makes use of this information and
> does everything that is needed for actually decrypting the stream. This
> might include asking the application for further information and blocking
> any processing until that information is available. Such information could
> involve asking the application to do its stuff to contact any DRM/license
> servers for example so that decryption can happen, 

I agree

> or it sounds like in your
> case the application is actually responsible for doing decryption ("buffer
> manager"?) so it would pass the buffers to the application (CDM?), get
> buffers back from the application and pass them onwards.

No it isn't doing the decryption, the buffer manager (Source Buffer) is a part
of the application, responsible for implementing the MSE (Media Source
Extension) algorithmic, regardless of media platform, Gstreamer or others

The First pipeline (Append Pipeline) is responsible to puting the content in a
packets (GstBuffers) with a metadatas like timestamp, duration and size, that
are needed for MediaSource implementation (Buffer Manager).

> 
> There should be no reason to split the pipeline for this, and it could all
> be relatively self-contained in the decryptor element (which then does the
> communication with the app).

I'll remove the current patch and I'll add a mechanism in Demux (MatroskaDemux
and Qtdemux ) to send a message on the bus when detecting encrypted content or
any change in encryption metadata like a new KeyID in run time.

What do you think ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.