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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #58 from Edward Hervey <bilboed at bilboed.com> ---
(In reply to Seungha Yang from comment #57)
> Very interesting doc :) Thanks. Because adpativedemux could expose the
> structure of manifest to user with the new APIs,

  Note that exposing the structure of the manifest is more for the other
elements/pipelines/apps than for the end-user. An end-user shouldn't have to
care about which codec/bitrate/... is available.

>  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.
> 

  Having some kind of "association" system in collections was in the original
design of GstStreamCollection ... but never implement because more basic things
had to be fixed first :)

  I'd say this kind of association information should be in the collection
also. 
It's *slightly* similar to the idea of "stream components" (where you specify
which streams should be used together to produce another (richer) stream).
Except in this case it's not producing "one" stream the end (but a collection
of streams).

  Just adding an association id system in the collection would make it work,
but I'm wondering whether we shouldn't have a more "end-user-friendly" system
in the end. Ex: The user can simply view "oh, I can choose viewpoint 1 or
viewpoint 2". And what meanings those "association" have (it's a different
angle, or it's a different mixing, ...).

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