Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different behavior between compiled and uncompiled versions. #341

Closed
sanbornhilland opened this issue Apr 17, 2016 · 8 comments
Closed

Different behavior between compiled and uncompiled versions. #341

sanbornhilland opened this issue Apr 17, 2016 · 8 comments
Labels
status: archived Archived and locked; will not be updated status: duplicate A duplicate of another issue; should be closed after linking to the original issue type: bug Something isn't working correctly
Milestone

Comments

@sanbornhilland
Copy link
Contributor

I'm doing some testing to see what it will take to integrate V2 into our project and I'm running up against so weird inconsistencies.

Using v2.0.0-beta-21-ga700705 prod and debug versions in our project I can play some of our content. However, loading this same content into the hosted sample app gives me a Shaka Error STREAMING.SEGMENT_DOES_NOT_EXIST and I can see that only the manifest is downloading, no chunks are getting downloaded.

The reason I came across this was that I was trying to play content from a different server of ours and it seems to just be stalling. The manifest gets downloaded but no chunks start getting downloaded. However, in the debug and prod versions of the library I'm also not getting any errors in this situation (can I change the log level?). I haven't tried incorporating the uncompiled library into our project because I think it will be pretty awkward and hacky to do with our build. When I load this content into the hosted sample app I get those same errors as above though I'm also getting the following: Assertion failed: lastReference cannot begin after the end of the Period.

There may be several different issues here but to summarize:

  1. Content A and B throw similar errors in the hosted sample app and neither play.
  2. Content A and B do not throw any errors when the library is bundle into our app.
  3. Content A plays in our app. Content B does not.

This doesn't really seem like a consistent set of errors so I'm not convinced this isn't due to some human error on my part. But if you guys have any ideas to point me in the right direction that would be helpful. Specifically, why am I not getting any errors in our app? I'm subscribed to error events on the player and I'm catching any promise errors that come from Player.load()

@tdrews
Copy link
Contributor

tdrews commented Apr 18, 2016

From the compiled library you will not see SEGMENT_DOES_NOT_EXIST or Assertion failed: ... errors logged; however, you should definitely see SEGMENT_DOES_NOT_EXIST errors dispatched (from the beta version).

We recently landed d2a812c, which changes some of the internal streaming logic. What type of behavior do you see from master?

@tdrews tdrews added the type: bug Something isn't working correctly label Apr 18, 2016
@tdrews tdrews added this to the v2.0.0 milestone Apr 18, 2016
@tdrews tdrews self-assigned this Apr 18, 2016
@tdrews tdrews added the type: question A question from the community label Apr 18, 2016
@sanbornhilland
Copy link
Contributor Author

On Saturday I was using the latest from master so I think this is still the latest. I ended up bundling in the uncompiled library so I could get more detailed logs. I can see that the problematic content is giving me : Assertion failed: lastReference cannot begin after the end of the Period. This looks like a content problem to me but I don't believe it actually affects the startup of the stream (correct me if I'm wrong) because it's not throwing any errors, it's just logging the assertion failure.

However I can see I'm also getting currentPeriod.startTime=0 lookupTime=0 for audio and video, repeatedly. It looks like the first chunk is starting at 1.0390625 so it's never being found and then no requests for chunks are going out. This also appears to be a content problem but I haven't had an issue playing this content in Shaka 1.6.x so I'm curious what the change is. Can I configure the player to just pick the first chunk if it doesn't have something that starts at 0? I've been looking through the docs but it's not clear to me if this is possible or not.

@tdrews
Copy link
Contributor

tdrews commented Apr 18, 2016

You're right, Assertion failed: lastReference cannot begin after the end of the Period is not a critical error, so it should not prohibit playback.

One of the main differences between Shaka v2 and Shaka v1 is that v2 treats segment metadata (e.g., SegmentTimeline) and the presentation timeline as orthogonal concepts. In v2 all presentations are assumed to begin from t=0 and either continue to t=MPD@mediaPresentationDuration or continue indefinitely. So, for VOD presentations, v2 attempts playback from t=0, and for live presentations, v2 attempts playback from the live-edge. If segment metadata is missing, v2 does not modify the presentation timeline. This is in contrast to v1, which intermingles these two concepts. In v1 the presentation timeline is essentially adjusted to match the segment metadata. There are merits to both approaches, but the logic in v2 is much simpler, which has allowed us to reduce the number of corner cases and to support multi-Period content.

That being said, we have found that some valid content doesn't start exactly at t=0, and we have attempted to support such content by "fitting" the segment metadata to the presentation timeline (https://github.com/google/shaka-player/blob/5a064d0abd555aa4af4336ea5deec6e8676b642b/lib/dash/mpd_utils.js#L294)... However, it's beginning to look like we'll need a more general approach.

I would suggest double checking that your content is being packaged correctly, i.e., if your content starts at 0, does the segment metadata start at 0? And on our side we'll re-evaluate how we can best support content whose first segments don't start at t=0, e.g., by automatically jumping ahead to the first segment or by exposing an API to do so manually.

@tdrews tdrews removed the type: question A question from the community label Apr 18, 2016
@sanbornhilland
Copy link
Contributor Author

Okay, great. I'll look into our content.

shaka-bot pushed a commit that referenced this issue Apr 26, 2016
* Permit non-zero presentation start times for VOD: some
  presentations have segments which start too far from 0 to
  allow the video element to begin playback; now the player will
  start VOD presentations from the start of the first segment.
  However, segments of the 2nd, 3rd, 4th, etc., Period of a
  multi-Period presentation must still start close to 0 (the
  player will not jump any gaps in the presentation).
* Prohibit seeking to regions at the beginning of the segment
  availability window if segment information is missing from
  that region: sometimes live manifests do not contain all the
  segments in the segment availability window; now the player
  will prohibit seeking to these regions.
* Update definition of live in DashParser to match Player and
  Playhead.
* Simplify PresentationTimeline's constructor by just using setter
  functions.

Issue #341
Closes #348
Issue #357

Change-Id: I96c22774448476bea89ff4014f03b87bdb51ba07
@tdrews
Copy link
Contributor

tdrews commented Apr 26, 2016

Hi, we pushed a change to fix #348. Does that resolve the issue? Do you still see different behavior between compiled/uncompiled? Thanks.

@tdrews tdrews changed the title Question: Hosted Debug App vs. Compiled Library Different behavior between compiled and uncompiled versions. May 2, 2016
@tdrews
Copy link
Contributor

tdrews commented May 12, 2016

Hey, are you still encountering issue? (From master.) If not, I'll close it out.

@tdrews tdrews added the type: question A question from the community label May 12, 2016
@sanbornhilland
Copy link
Contributor Author

Yes it looks like you can close this.

@joeyparrish joeyparrish added status: duplicate A duplicate of another issue; should be closed after linking to the original issue and removed type: question A question from the community labels May 16, 2016
@joeyparrish
Copy link
Member

Thanks!

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated status: duplicate A duplicate of another issue; should be closed after linking to the original issue type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

4 participants