[Bug 607471] decodebin3: Race with caps changing in stream

[GStreamer (GNOME Bugzilla)]

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

--- Comment #32 from Edward Hervey <bilboed at bilboed.com> ---
(Copying my latest comment from Bug #706774 which I'll mark as a duplicate of
this one).

So I generally agree on the fundamental problem which is that whoever creates
the collection and streams can updated them *separately* from what actual data
flow is currently happening at the multiqueue level.

Furthermore I'm working on adding more collection/stream emission in upstream
elements (demuxers, adaptive demuxers, ...) for which this will be even more
TRUE.

==> So yes, decodebin3's handling of caps should be done using the *actual*
caps travelling through multiqueue.

Regarding the "multiple stsd entries" in qtdemux, this corresponds to "stream
variants". i.e. it's the same "stream" per-se (from a human audio/visual point
of view) but the nature of it (codec, resolution,...) can change throughout
time.

It's a bit like adaptive streaming. The bitrate, resolution, framerate,... can
change throughout time, but from a human perspective it's still the same
"stream". (Note that DASH uses this multiple stsd-entry system extensively for
exactly that purpose).

I'm working on an API extension of GstStreamCollection to be able to specify
such streams and variants. I'll keep this updated.

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