[Bug 775132] adaptivedemux: Download fragment only for activated stream

[GStreamer (GNOME Bugzilla)]

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

--- Comment #57 from Seungha Yang <pudding8757 at gmail.com> ---
(In reply to Edward Hervey from comment #56)
> Took longer than I expected :) Anyway, I've put the WIP design doc here :
> https://gitlab.freedesktop.org/bilboed/gst-docs/blob/master/markdown/design/
> scalable-codecs.md
> 
> It's aiming for the *bigger* picture (supporting scalable codecs), but also
> contains design for:
> * offloading stream-selection to any element (and not just decodebin3 itself)
> * Properly notifying of stream selections
> * Being able to inform upstream elements ASAP of incompatible/unusable
> streams
> * Exposing "variants" of streams (like in adaptive demux).

Very interesting doc :) Thanks. Because adpativedemux could expose the
structure of manifest to user with the new APIs,  I just have a suggestion
about  some addition (might not be closely related to *scalable* though). 
Depending on Spec, content provider could suggest associated track group per
view point. For example, 

DASH: The role of ViewPoint element in MPD is to associating each
video/audio/text track per view point (e.g.,
https://github.com/Dash-Industry-Forum/Conformance-Software/blob/master/webfe/mpdvalidator/schematron/examples/ex57.mpd)

HLS: combination of variant stream with GROUP-ID of rendition streams results
to a association group.

ISOBMFF: "alternate_group" in thkd box takes the role.
...

Is there a way to signalling the association of each track in Gstreamer? If
not, (since "group-id" in Gstreamer is representing temporal association of
each track if my understanding is correct), new field for assassination of each
track seems to be required such as
gboolean gst_event_set_association_id (GstEvent *event, guint association_id,
const *gchar nickname (nullable));

gboolean gst_event_parse_association_id (GstEvent *event, guint
*association_id, const **gchar nickname);
And similar APIs for GstStream.

Anyway, I'll take more look at the shared document.

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