[Bug 706774] qtdemux: handle multiple sample descriptions per track

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Edward Hervey <bilboed at bilboed.com> ---
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.