[Bug 705991] Adding support for DASH common encryption to qtdemux and dashdemux

[GStreamer (GNOME Bugzilla)]

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

--- Comment #107 from A Ashley <bugzilla at ashley-family.net> ---
(In reply to Tim-Philipp Müller from comment #104)
> Comment on attachment 300676 [details] [review]
> Adds a new Protection event to GStreamer core
> 
> The event stuff looks mostly fine. I have a question though: the event is of
> type MULTI_STICKY, presumably so we can have multiple types of protection
> data sticky per pad/stream, e.g. some global data plus something that gets
> updated on a regular basis. What parallelism will we require in practice
> though? Only different origins, or do we expect there may be a need for
> events for different system_ids to co-exist for the same stream?
> 

At the moment, dashdemux pushes an event per protection system ID. One option
would be for dashdemux to use the utility function to select a system ID and
only push one protection event per pad.

If the event was not MULTI_STICKY, would a downstream element still be able to
get events from multiple upstream elements?

> I think it would be nicer if the system_id string and the origin string were
> added to the event GstStructure explicitly as fields as well. That would
> also simplify the parsing code in parse_protection() and would allow you to
> return a pointer to the string without making a copy (which is nicer for the
> caller).

Yes, I wondered about doing that. I think it would also make is safer because
it removes the possibility of characters in the origin string causing the
tokeniser to go wrong. Is there a convention about transfer-full vs
transfer-none for the event parsing functions?

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