[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 #110 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
> If the event was not MULTI_STICKY, would a downstream element still be able
> to get events from multiple upstream elements?

Yes, event stickiness is not really about that though.

Imagine the demuxer sends out events before the decryptor plugin was linked.
Now that decryptor gets linked afterwards. It will receive all sticky events
that have accumulated on the peer pad. If it's a normal sticky event, the
decryptor would only receive one single event (the last one sent, as each new
one would replace the previous one). If it's a MULTI_STICKY event, the
decryptor would receive all sticky events with unique structure names (and
every event with the same structure name would replace the previous one on the
pad).

So I think MULTI_STICKY is what we want, since we probably need to prime the
decryptor with multiple pieces of protection info from various origins, not
just whatever was the last one. I guess my question was more about the multiple
system IDs. The current implementation would be the most future proof one
though, and we can still make the demuxer send only events for one system if we
want to.



> Is there a convention about transfer-full
> vs transfer-none for the event parsing functions?

Not really, it's a bit inconsistent unfortunately, but I'd say 'transfer none'
is more common (see parse_caps or parse_tags). I would opt for all
transfer-none where possible. It's nicer for the caller, and taking a ref /
making a copy  for stuff that needs to be kept around is easy enough.

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