search

shaka-project / shaka-player

JavaScript player library / DASH & HLS client / MSE-EME player
Apache License 2.0
7.14k stars 1.34k forks source link

Segments are fetched from original BaseURL after switching location using MPD.Location #1795

Closed mad-gooze closed 2 years ago

mad-gooze commented 5 years ago

Have you read the FAQ and checked for duplicate open issues? Yes

What version of Shaka Player are you using? 2.4.6

Can you reproduce the issue with our latest release version? Yes

Can you reproduce the issue with the latest code from master? Have not tried yet

Are you using the demo app or your own custom app? This can be reproduced with demo app

If custom app, can you reproduce the issue using our demo app?

What browser and OS are you using? Latest stable chrome, macos or windows

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

I use http://livesim.dashif.org/livesim/testpic_2s/Manifest.mpd and mock mpd with proxy.

What did you do?

Add <Location> tag to the mpd like this

<?xml version="1.0" encoding="utf-8"?>
<MPD availabilityStartTime="1970-01-01T00:00:00Z" id="Config part of url maybe?" maxSegmentDuration="PT2S" minBufferTime="PT2S" minimumUpdatePeriod="PT2S" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash-if-simple" publishTime="2019-02-05T13:40:38Z" timeShiftBufferDepth="PT5M" type="dynamic" ns1:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">
   <Location>http://test.org/livesim/testpic_2s/Manifest.mpd</Location>
   <ProgramInformation>
      <Title>Media Presentation Description from DASHI-IF live simulator</Title>
   </ProgramInformation>
   <BaseURL>http://livesim.dashif.org/livesim/testpic_2s/</BaseURL>
<Period id="p0" start="PT0S">
      <AdaptationSet contentType="audio" lang="eng" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1">
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" />
         <SegmentTemplate duration="2" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s" startNumber="0" />
         <Representation audioSamplingRate="48000" bandwidth="48000" codecs="mp4a.40.2" id="A48">
            <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2" />
         </Representation>
      </AdaptationSet>
      <AdaptationSet contentType="video" maxFrameRate="60/2" maxHeight="360" maxWidth="640" mimeType="video/mp4" minHeight="360" minWidth="640" par="16:9" segmentAlignment="true" startWithSAP="1">
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" />
         <SegmentTemplate duration="2" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s" startNumber="0" />
         <Representation bandwidth="300000" codecs="avc1.64001e" frameRate="60/2" height="360" id="V300" sar="1:1" width="640" />
      </AdaptationSet>
   </Period>
</MPD>

Mock http://test.org/livesim/testpic_2s/Manifest.mpd using proxy to answer the following MPD (it has BaseURL pointing to test.org):

<?xml version="1.0" encoding="utf-8"?>
<MPD availabilityStartTime="1970-01-01T00:00:00Z" id="Config part of url maybe?" maxSegmentDuration="PT2S" minBufferTime="PT2S" minimumUpdatePeriod="PT2S" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash-if-simple" publishTime="2019-02-05T13:40:38Z" timeShiftBufferDepth="PT5M" type="dynamic" ns1:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">
   <Location>http://test.org/livesim/testpic_2s/Manifest.mpd</Location>
   <ProgramInformation>
      <Title>Media Presentation Description from DASHI-IF live simulator</Title>
   </ProgramInformation>
   <BaseURL>http://livesim.dashif.org/livesim/testpic_2s/</BaseURL>
<Period id="p0" start="PT0S">
      <AdaptationSet contentType="audio" lang="eng" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1">
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" />
         <SegmentTemplate duration="2" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s" startNumber="0" />
         <Representation audioSamplingRate="48000" bandwidth="48000" codecs="mp4a.40.2" id="A48">
            <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2" />
         </Representation>
      </AdaptationSet>
      <AdaptationSet contentType="video" maxFrameRate="60/2" maxHeight="360" maxWidth="640" mimeType="video/mp4" minHeight="360" minWidth="640" par="16:9" segmentAlignment="true" startWithSAP="1">
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main" />
         <SegmentTemplate duration="2" initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/$Number$.m4s" startNumber="0" />
         <Representation bandwidth="300000" codecs="avc1.64001e" frameRate="60/2" height="360" id="V300" sar="1:1" width="640" />
      </AdaptationSet>
   </Period>
</MPD>

What did you expect to happen? I expect that after switching location new segments are fetched from test.org

What actually happened? Segments are fetched from livesim.dashif.org - BaseUrl is not changed which should be done according to spec. Dash.js player changes BaseUrl in this case.

mad-gooze commented 5 years ago

We are using this patch https://gist.github.com/toshic/ff57c9004fdc18010894bfb86daf86de to fix this issue in our build now.

Maybe there is a better solution for that?

TheModMaker commented 5 years ago

First, the <Location> element only specifies where to query the MPD, not really where the segments are. However, it comes up when the segment URLs are relative, then they are relative to the <Location>. The URLs in your manifest are absolute, so that is the URL we fetch. <BaseURL> specifies where to fetch the segments and shouldn't be changed.

If this isn't the correct interpretation of the elements, can you point to where in the DASH spec it specifies that <Location> should change <BaseURL>? The only references to <Location> I see are when referring to manifest updates.

mad-gooze commented 5 years ago

If segments url is relative it should be resolved from <BaseURL>

The problem is that after manifest is updated with a new <BaseURL>, segments url are still resolved from old <BaseURL>.

mad-gooze commented 5 years ago

this is described in https://dashif.org/docs/DASH-IF-IOP-v4.3.pdf 3.2.15. MPD Location and Reference Resolution

TheModMaker commented 5 years ago

So the problem is that the new manifest specifies different URLs for segments than the original? So the first manifest looks like this:

<Location>: https://test.org/foo.mpd <BaseURL>: https://livesim.dashif.org/base Segent: init.mp4

This results in fetching a segment for https://livesim.dashif.org/base/init.mp4. Then we update the manifest by making a request to https://test.org/foo.mpd which results in the following:

<Location>: https://test.org/foo.mpd <BaseURL>: https://test.org/base Segent: init.mp4

Which should result in a segment request to https://test.org/base/init.mp4. Is this your situation? In your original question the two manifests you post both have the same <BaseURL> so we would resolve the segments the same way.

If that's the case, I think the problem has to do with how we merge segments here. We just use the old segments if the times match, but if the URLs change, we will still fetch the old segments. Note that this is allowed by the DASH spec since the segments at the old URL need to remain valid until they fall outside the availability window. Even if we change this, we may fetch the old URL for a few segments after the update.

mad-gooze commented 5 years ago

Which should result in a segment request to https://test.org/base/init.mp4. Is this your situation?

Correct! Now shaka ignores <BaseURL> update and still fetches segment from https://livesim.dashif.org/base/init.mp4

TheModMaker commented 5 years ago

Ok. So I'm marking this as a bug since what we are doing is less than ideal. But I've put this on the backlog since we are already behind v2.5 and v2.6 has already been scheduled and doesn't fit in. If you need this fixed sooner, we'd be happy to review a PR based on my comment above.

avelad commented 2 years ago

@mad-gooze Can you check if it happens with version 4.0.0?

github-actions[bot] commented 2 years ago

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.