shaka-project / shaka-player Goto Github PK

This should help in debugging, logging, or differentiating network errors for display.

We already have a timeout mechanism in AjaxRequest, but it is unused at the moment. Create an API on Player to allow the application to set the timeout for LicenseRequest, RangeRequest, and MpdRequest individually.

The MPD parser expects the @startNumber attributes to be strictly positive (shaka.dash.mpd.SegmentList.prototype.parse and shaka.dash.mpd.SegmentTemplate.prototype.parse when computing firstSegmentNumber).
This is incorrect, as the DASH schema specifies:
<xs:attribute name="startNumber" type="xs:unsignedInt"/>

The default value is correctly set to 1, but values of 0 should be accepted.
Here's an example MPD with @startNumber=0:
http://www.bok.net/dash/tears_of_steel/cleartext/stream.mpd

(If the change is made to allow for 0, the stream plays correctly)

NOTE: I think this bug hides a second bug: if the stream is played starting from segment index 1 (instead of 0), as is the case when @startNumber=0 isn't accepted, the segments, starting from index 1, are correctly downloaded and sent as source buffers, but nothing is played. Instead, it would be expected that the video would play, except that the first segment (index 0) would be skipped.
It is likely that the player assumes that the media timestamps in the segments always start at 0, so starting with segment 1 (with a non-0 timestamp) is buffered but never starts playing (the decoder probably still waits for timestamp 0 to be sent).
However, it is perfectly legal for media segments to have timestamps that don't start at 0.

To reproduce:

1. Disable adaptation.
2. Play at least three segments.
3. Manually switch video tracks.
4. Seek to 0.
5. Play up to the point in the timeline when adaptation happened.

Playback will hang. It appears that the old data needs to be removed from the buffer during adaptation.

Chrome 41+ now has a stricter JWKSet parser. The kty and alg parameters on a JWK are now required. The test app should be updated to provide these parameters, and the v0.1b polyfill should require them. This is necessary before a fix for issue #7 can be validated.

The Role element with @schemeIdUri="urn:mpeg:dash:role:2011" and @value="main" should be used to indicate the "main" AdaptationSet, according to DASH IOP v2.90.

We currently ignore the Role element. We take the 0th video AdaptationSet and the 0th audio AdaptationSet (from the list of audio sets with matching languages). We should use the "main" set from either of these lists, if present.

"Failed to execute 'endOfStream' on 'MediaSource': The 'updating' attribute is true on one or more of this MediaSource's SourceBuffers."

It seems that we need to synchronize this call better. To reproduce, load a very short video clip (just tried with a 10s clip), let it finish playing, then either hit play again or try to seek to the beginning.

When the data buffered by the browser is dropped, and the user seeks backward to the range of content that was dropped, Shaka Player does not re-request it as it should.

The library supports trick play (fast-forward / rewind style of seeking) via Player.setPlaybackRate, but this is not well-documented, nor is an example given in the test app.

Create an abstract interface for AbrManager and allow injection of a custom implementation at runtime. (Similar to a change that just went in for BandwidthEstimator.) This will allow applications to write custom adaptation rules without modifying the library.

Player.enableTextTrack() only affects track visibility for the current video source. Calls made before Player.load() will have no effect. This is not currently documented.

We should refactor start-up in such a way that we can resolve segment indices for all representations before our first adaptation. This should be done without negatively impacting start-up latency. This will allow for further refactoring and improvement of adaptation mechanisms.

Some indication of how much content is buffered would be a really useful tool when debugging.

If you try to setRestrictions on a player instance before you provide a video source, you'll get an error: Cannot read property 'setRestrictions' of null.

I propose that we either:

1. Throw a more descriptive error such as 'There is no video source available to set restrictions on.'
2. Or, check if the video source is defined and if not, don't call videoSource.setRestrictions, and instead make sure that when a videoSource is instantiated it calls setRestrictions on itself. This way if someone tries to setRestrictions before a video source is loaded, they'll get set the way they expect.

Player.setPreferredLanguage() only affects default tracks selected by subsequent calls to Player.load(). This is not currently documented.

Stream has the constant BUFFER_SIZE_SECONDS, but this could be a configurable value with an API on Player to allow the application to change it at any time.

EmeManager creates configurations that are not compatible with the current EME Editor's Draft. In particular, it can create empty lists for initDataTypes, audioCapabilities, and videoCapabilities; these are rejected in the current draft. If there are no requirements, the members should not be present in the configuration dictionary at all.

Somewhat trickier is that sessionTypes must now be specified for createSession() to operate. This isn't necessary if only "temporary" sessions are created, but Shaka will try to create "persistent-license" sessions without asking for them.

player.js still reports as v1.2.0

Line 118:
goog.define('GIT_VERSION', 'v1.2.0-debug');

This should be v1.2.1.

I've noticed that if you lose your network connection during playback and then it reconnects, the player won't continue to buffer new data. However, the video element will still send 'playing' events if you press play. Is there any intention to add support for recovering form a network failure? And if not, is there any recommendation for determining when playback is actually happening because clearly the 'playing' event is not a reliable indicator of playback.

Thanks for the hard work guys. Cheers.

Shaka Player should support DASH live content.

It would be nice to be able to cancel the "cycle" feature in the test app, so converting the buttons into checkboxes would be a nice improvement.

The PSSH parser in lib/util/pssh.js should skip any box with an unrecognized version number. It should skip the entire box, not the data payload.

MediaKeys.isTypeSupported is deprecated and has been removed in Chrome 41. Until we have stopped relying on it (issue #2) we should polyfill it with some reasonable assumptions about Chrome's capabilities. This is a stop-gap measure for v1.1. Application developers should upgrade to v1.2 when it becomes available.

Shaka Player should support persistent/offline licenses

We currently rely on MediaKeys.isTypeSupported, which is deprecated and has been removed from recent drafts of the EME spec. This should not be used to check for key system support.

This will only cause problems IF:

1. you are running Chrome 41 (canary)
2. AND you have flipped the "Enabled Encrypted Media Extensions" flag
3. AND you have flipped the "Disable prefixed Encrypted Media Extensions" flag

Users running a typical configuration of Chrome will not see any issues with this.

If the first segment for audio and the first segment for video start at slightly different times (less than one second) then the audio and video streams will be unsynchronized.

The Player should handle differing start times gracefully.

AbrManager is not being destroyed by DashVideoSource. AbrManager may or may not be garbage-collected by the browser when the video source is torn down.

Add bufferingStart and bufferingEnd events so that the application can signal appropriately in the UI.

Hi there, I'm trying to play back content generated by following along this tutorial. I run into the following error:

CuesElement does not exist. webm_segment_index_parser.js:121

Is this an element that is missing from my mpd manifest?

<?xml version="1.0" encoding="UTF-8"?>
<MPD
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="urn:mpeg:DASH:schema:MPD:2011"
  xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011"
  type="static"
  mediaPresentationDuration="PT10.033S"
  minBufferTime="PT1S"
  profiles="urn:webm:dash:profile:webm-on-demand:2012">
<Period id="0" start="PT0S" duration="PT10.033S" >
<AdaptationSet id="0" mimeType="video/webm" codecs="vp9" bitstreamSwitching="true" subsegmentAlignment="true" subsegmentStartsWithSAP="1">
<Representation id="0" bandwidth="124382" width="160" height="90">
<BaseURL>video_160x90_250k.webm</BaseURL>
<SegmentBase
  indexRange="132303-132369">
<Initialization
  range="0-429" />
</SegmentBase>
</Representation>
<Representation id="1" bandwidth="266837" width="320" height="180">
<BaseURL>video_320x180_500k.webm</BaseURL>
<SegmentBase
  indexRange="313960-314026">
<Initialization
  range="0-430" />
</SegmentBase>
</Representation>
<Representation id="2" bandwidth="579451" width="640" height="360">
<BaseURL>video_640x360_750k.webm</BaseURL>
<SegmentBase
  indexRange="797366-797432">
<Initialization
  range="0-431" />
</SegmentBase>
</Representation>
<Representation id="3" bandwidth="767450" width="640" height="360">
<BaseURL>video_640x360_1000k.webm</BaseURL>
<SegmentBase
  indexRange="1055472-1055538">
<Initialization
  range="0-431" />
</SegmentBase>
</Representation>
<Representation id="4" bandwidth="1110647" width="1280" height="720">
<BaseURL>video_1280x720_500k.webm</BaseURL>
<SegmentBase
  indexRange="1544015-1544081">
<Initialization
  range="0-431" />
</SegmentBase>
</Representation>
</AdaptationSet>
<AdaptationSet id="1" mimeType="audio/webm" codecs="vorbis" audioSamplingRate="44100" bitstreamSwitching="true" subsegmentAlignment="true" subsegmentStartsWithSAP="1">
<Representation id="5" bandwidth="60219">
<BaseURL>audio_128k.webm</BaseURL>
<SegmentBase
  indexRange="86666-86731">
<Initialization
  range="0-4700" />
</SegmentBase>
</Representation>
</AdaptationSet>
</Period>
</MPD>

This is primarily for using the test player on browsers without input devices (e.g. Chromecast), where the primary input source is the URL.

I would like for you to create a file index.js in the root of the project that contains the proper module.exports for all of the major classes for shaka-player.

Currently the NPM dependency requires google closure compiler in order to be used and the individual namespaced classes are only available after including the script in head or .

Exposing module.exports would allow this lib to be used in a CommonJS environment more easily.

Shaka Player should support storage and retrieval of content for offline playback.

We're currently using some outdated version of jasmine-ajax. It looks like it has improved a lot, so we should upgrade to the latest release version and remove hacks and workarounds we applied on top of the version we originally adopted.

If the stream's segment index is skewed with respect to the media timestamps, then the Player can get stuck in a buffering state. This is because Player uses media timestamps to monitor buffering, and Stream uses segment index to decide how far ahead to buffer.

This generally doesn't happen with static content, since static content tends to use a SIDX and the SIDX tends to be accurate.

In Chrome 44 (Canary), all playback is failing; when executing navigator.requestMediaKeySystemAccess in shaka.player.Player.prototype.buildKeySystemPromiseChain_ , the following error is raised:
DOMException: None of the requested configurations were supported.

This is happening in the test app using the "Car/CENC" (YT DASH EME test) - MP4, ClearKey" test manifest. Tested on version 1.2.1

Currently, bandwidth restrictions are only effective if they are set prior to loading content. Setting them after content is playing appears to be setting the restrictions object fine but the restrictions are not limiting which variants are getting played.

Shaka version: v1.2.0-154-g5f063f0

The MPD parser insists on finding an @duration attribute for a Period when the SegmentTemplate has a segment duration.
For simple static MPDs with only one Period element, the Period@duration attribute is optional. The Period duration can be inferred from the MPD@mediaPresentationDuration attribute

The DASH spec, section 5.3.2.1 indicates:
"...The Period extends until the PeriodStart of the next Period, or until the end of the Media Presentation in the case of the last Period..."

The shaka code that throws the error is:
mpd_processor.js, line 555
shaka.log.error(
'SegmentTemplate provides a segment duration but the ' +
'Period's duration is unknown.');

If there is a gap between two segments in a SegmentTimeline, e.g.,

<S t="0" d="10" />
<S t="11" d="10" />

then the player should attempt to play the content instead of rejecting the MPD.

Player.selectTextTrack() causes the text track to be disabled regardless of its previous setting.

To work around this bug, call Player.enableTextTrack() after Player.selectTextTrack() to restore the previous setting.

Because Player.getCurrentResolution() corresponds to what is currently on screen, this resolution may lag behind the data in an AdaptationEvent. This is to be expected, but was not documented.

Currently there does not appear to be a way to listen to any HDCP errors raised by Widevine DRM.

On certain hardware, playback of Widevine protected content has failed to start without any errors being thrown. Turning off the Widevine output protection enables playback on the affected hardware.

It would be very useful to listen to HDCP errors so that an appropriate message can be displayed when these occur.

I can't see a way to check if adaptation is enabled or not. I think it would be useful to have a method player.getAdaptationEnabled() that just returns the value of adaptationEnabled_.

Clock synchronization and related cross-origin issues should be documented.

In #29 you mentioned these use cases:

1. Adaptation always enabled or disabled, and therefore set once programmatically.
2. Adaptation always controlled by some application UI element, and therefore set on interaction with that element.

I have a third use case that I am trying to figure out how to accommodate:

1. Adaptation enabled for some subset of all possible tracks

For instance, I need to be able to cap the bandwidth so that I can specify no tracks above a certain bandwidth are played. But there may be several available tracks below the given bandwidth and I would like adaptation to stay enabled so that switching can continue between those tracks.

It seems this can be done by disabling certain tracks based on bandwidth inside the StreamVideoSource#getVideoTracks method but I'm not sure this is the right place to do this.

Although the library can be built on Windows using cygwin, the process is not documented.

Cloning the repository on cygwin with the git config variable core.autocrlf set to true results in shell scripts which can't be executed (due to CRLF line endings).

The auto-update script at cdnjs is not working consistently, so sometimes it fails to update certain libraries.

http://localhost/shaka2/third_party/closure/goog/deps.js Failed to load resource: the server responded with a status of 404 (Not Found)
base.js:413 goog.require could not find: shaka.player.DashVideoSourcebase.js:413 goog.logToConsole_
base.js:448 Uncaught Error: goog.require could not find: shaka.player.DashVideoSource
http://localhost/shaka2/assets/poster.jpg Failed to load resource: the server responded with a status of 500 (Internal Server Error)
3app.js:450 Uncaught ReferenceError: shaka is not defined
app.js:450 Uncaught ReferenceError: shaka is not defined

The fields in Player.getStats().streamStats should show information about the video track, but sometimes show information from the audio track instead. This means videoWidth & videoHeight come out as null.

Have the latest change to master been published to npm? Updating/Installing through npm is not picking up the latest changes.