Dash dynamic manifests from edgeware are giving wrong seekRange data

[veronicamirada]

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

What version of Shaka Player are you using? 4.2.1.

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

Can you reproduce the issue with the latest code from main? Yes

Are you using the demo app or your own custom app? My custom app

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

What browser and OS are you using? Chrome 109.0.5414.87, macOS Monterey 12.6

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

What are the manifest and license server URIs?
It must be a dynamic manifest so we should provide it at the moment to try

What configuration are you using? What is the output of player.getConfiguration()?

On the mail

What did you do?

I played a startover content from edgeware

What did you expect to happen?
Content should start from the begining, progress bar should show correct time info, trickplays should work

What actually happened?
Content starts from the begining, progress bar shows incorrect information, trickplays don't work

We have been going deep to find out what is happening. Startover manifests from edgeware are different from the rest as they include a mediaPresentationDuration field which contains the expected duration of the stream.
When this field is found, the manifest is not considered as a 'Live' one, but an 'In Progress' one.

Then, when it constructs a segment list it checks if the manifest is live

const shouldFit = periodEnd != Infinity;

and if the manifest is not live (shouldFit==true), it runs a fitting function:

      if (segmentIndex) {
        if (shouldFit) {
          // Fit the new references before merging them, so that the merge
          // algorithm has a more accurate view of their start and end times.
          const wrapper = new shaka.media.SegmentIndex(references);
          wrapper.fit(periodStart, periodEnd, /* isNew= */ true);
        }

This sets the last segment to run from the declared start time to the end of the duration window

For an ‘in progress’ manifest, that does not have all the segments yet, this creates one enormous segment covering the rest of the playback (for example >30minutes, compared to a normal size of 4s).

This breaks the player_.seekRange() function that is critical for us to work out the progress bars and start point of playback (because the end range calculation uses the size of the largest segment).

Changing the ‘shouldFit’ definition to const shouldFit = !context.dynamic; - i.e. do not fit if the manifest is dynamic - seems to fix the problem for us.

[avelad]

@veronicamirada I can work on it this afternoon, can you share me one stream? Thanks!

[baffinch]

Hi Alvaro,

I'm not sure the stream is actually accessible publicly - this should be valid for another hour or so, if it is : https://streamer01.digital.com.bo/session/f1d9346a-981d-11ed-ab90-00505683ffaa$h1.0$default/2ap337/__cl/cg:sworigin/__c/CINEMAXHD/__op/dash/__dci/402/__f/manifest.mpd?startTime=20230119T171400Z&stopTime=20230119T191900Z

If not, these are two manifests, taken about 20s apart, a few minutes ago

mpd2.mpd.txt
mpd1.mpd.txt

If that doesn't work, we'll need to find a valid public stream - let us know

Martin

[avelad]

@veronicamirada you are right shouldFit it's the problem with your stream...