How can an application get protection information

[Juergen Sachs]

Can anybody help to understand how a GStreamer-application gets informed about protected streams?
The use case:
Our application uses playbin2 to read and play "all kind of content". Now we got a DASH stream with protected video and audio. Looking into the code, it seems the DASH demux detects the protection from the manifest and send the GST_EVENT_PROTECTION downstream to qtdemux. The qtdemux queues the event to send it further downstream to its source pads. But if the demuxer does not find a protection handler, it does not create any source pad at all. So the event is lost.

In our use case additionally we have implemented the sink elements for video and audio, so if the sinks would be connected, we could evaluate the event. But we´re not connected because qtdemux does not have any source pads (see attached pipeline)

Any idea how to handle this or a hint, where to find information?
In case of protection we want to display a message to the user and stop the playback.

Kind regards
Juergen Sachs
Labor-TV/Software Development
Metz Consumer Electronics GmbH

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Enrique Ocaña González]

El jueves, 31 de agosto de 2017 14:21:55 (CEST) Jürgen Sachs escribió:

> [...]
> GST_EVENT_PROTECTION downstream to qtdemux. The qtdemux queues the event to
> send it further downstream to its source pads. But if the demuxer does not
> find a protection handler, it does not create any source pad at all. So the
> event is lost.
>
> In our use case additionally we have implemented the sink elements for video
> and audio, so if the sinks would be connected, we could evaluate the event.
> But we´re not connected because qtdemux does not have any source pads (see
> attached pipeline)
>
> Any idea how to handle this or a hint, where to find information?
> In case of protection we want to display a message to the user and stop the
> playback.

When patch "2/3 qtdemux: add context for a preferred protection (review
suggestions applied)" on https://bugzilla.gnome.org/show_bug.cgi?id=770107 is
finally merged, you will be able to subscribe to the "need-context" bus
message and notice the existence of a protection system there.

We do it using a sync message[1] handler[2] which runs on the qtdemux
streaming thread (beware of concurrency issues with code in your main
thread!). If you don't actually want to manage encryption negotiation and only
want to listen for the message in the main thread (no concurrency issues), I
guess a regular[3] handler[4][5] might be enough.

Cheers.

[1] https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/master/Source/
WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L2195
[2] https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/master/Source/
WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp#L404
[3] https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/master/Source/
WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L2208
[4] https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/master/Source/
WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L82
[5] https://github.com/WebPlatformForEmbedded/WPEWebKit/blob/master/Source/
WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp#L1026

--
Enrique Ocaña González
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel