After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752721 - dashdemux: index uri is not set when only the index range is provided
dashdemux: index uri is not set when only the index range is provided
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-07-22 13:10 UTC by Florin Apostol
Modified: 2018-11-03 13:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Florin Apostol 2015-07-22 13:10:22 UTC
For the index@SegmentURL attribute, the standard mentions:

"If not present and the @indexRange present, then the @media attribute is mapped to the @index. If the @media attribute is not present either, then any BaseURL element is mapped to the @index attribute and the @indexRange attribute shall be present."

The implementation does not set the index uri in this scenario. The code is at the end of gst_mpd_client_get_next_fragment function:

  if (indexURL != NULL) {
    frag_url = gst_uri_make_writable (gst_uri_from_string_with_base (base_url,
            indexURL));
    gst_uri_set_query_string (frag_url, stream->queryURL);
    fragment->index_uri = gst_uri_to_string (frag_url);
    gst_uri_unref (frag_url);
    g_free (indexURL);
  } else if (indexURL == NULL && (fragment->index_range_start
          || fragment->index_range_end != -1)) {
    /* index has no specific URL but has a range, we should only use this if
     * the media also has a range, otherwise we are serving some data twice
     * (in the media fragment and again in the index) */
    if (!(fragment->range_start || fragment->range_end != -1)) {
      GST_WARNING ("Ignoring index ranges because there isn't a media range "
          "and URIs would be the same");
      /* removing index information */
      fragment->index_range_start = 0;
      fragment->index_range_end = -1;
    }
  }

The "else if" checks to see if it will retrieve the same data for index and media segment. But it fails to set the fragment->index_uri in case it wants the segment index to be downloaded. Because  fragment->index_uri remains null, no segment index will be downloaded.

On the other hand, in chapter "5.3.9.5.4 Index Segment information" the standard mentions: 
"The @indexRange attribute may also be used to provide the byte range for an index within a Media Segment, where this is allowed by the Media Segment format. In this case the @index attribute shall not be present and the range specified shall lie completely within any byte range specified for the Media Segment."

So, in this case the index will be completely inside the media segment. If we really do not want to download and provide the same data twice (in index and in media segment) the whole "else if" should be removed and an appropriate comment describing the situation should be added instead.
Comment 1 Thiago Sousa Santos 2015-07-24 00:02:06 UTC
Your analysis seem to make sense, are you working on a patch? Do you have example of playlists using those different possibilities?
Comment 2 Florin Apostol 2015-07-29 13:13:02 UTC
Due to another bug (https://bugzilla.gnome.org/show_bug.cgi?id=752714) it is hard to test this one because no matter how we set it, it is unused!
Comment 3 GStreamer system administrator 2018-11-03 13:38:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/278.