[Bug 701509] New: dashdemux selects first fragment in the manifest for live streams

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701509
  GStreamer | gst-plugins-bad | git

           Summary: dashdemux selects first fragment in the manifest for
                    live streams
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bugzilla at ashley-family.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=245912)
 View: https://bugzilla.gnome.org/attachment.cgi?id=245912
 Review: https://bugzilla.gnome.org/review?bug=701509&attachment=245912

Patch to change first fragment selection for live

When dashdemux selects its first fragment, it always selects the first fragment
listed in the manifest. For on-demand content, this is the correct behaviour.
However for live content, this behaviour is undesirable because the first
fragment listed in the manifest might be some considerable time behind "now".

I have attached a patch that shows one way that the selection of the first
fragment could be achieved. The patch uses the host's idea of UTC and tries to
find the oldest fragment that contains samples for this time of day.

Ultimately I think a more sophisticated selection algorithm will be required,
to allow dashdemux to build up a buffer of fragments. For example maybe
starting 'n' fragments behind "now" or 'm' seconds behind "now".

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.