Fix seekable range on VOD HLS streams with minimum timestamp

[mikrohard]

I noticed that some of our VOD HLS streams don't start playback from 0 position when using shaka player. What is more you can't even seek to 0 position. After some debugging I found out that seekable range isn't correct (e.g. for one content the range was from 4200 seconds to 2700 seconds, 2700 seconds was the duration of the content and shaka player immediately seeked to this position & only played a few seconds before the end). I noticed that presentation timelines first segment start time is set before segments are offset back to 0 in hls parser. Calling notifySegments after applying the offset instead of before fixes this issue for me. One warning at this point... we just started using shaka player & I'm not familiar with the codebase... which means that I'm not sure if this can affect anything else.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[mikrohard]

I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[mikrohard]

I signed it!

[googlebot]

CLAs look good, thanks!

[TheModMaker]

Thanks for finding this. But I don't think this is the correct fix. notifySegments_ uses a stored array of segments, which may not be edited by offsetting the segments (and if it is, we shouldn't assume it). I think a better fix would be to add an offset method to PresentationTimeline to adjust the timeline like we adjust the segments. Also please update the tests and ensure this is handled by a test (e.g. editing the sets maxFirstSegmentTime test from test/hls/hls_parser_unit.js).

Or if you would prefer, I could implement this instead.

[mikrohard]

It would be probably best if you do it because you know better how & why it works as it does. If I add the offset to the PresentationTimeline to fix the seek range it would actually break the sets maxFirstSegmentTime test (where you expect the getSeekRangeStart to be greater than 0... but this exactly is the root issue I'm trying to fix).

[joeyparrish]

Fix released in v2.5.0-beta2.

[joeyparrish]

Cherry-picked to v2.4.x for release in v2.4.7.