Git Product home page Git Product logo

dash-industry-forum / dash.js Goto Github PK

View Code? Open in Web Editor NEW
5.0K 252.0 1.7K 200.2 MB

A reference client implementation for the playback of MPEG DASH via Javascript and compliant browsers.

Home Page: http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

License: Other

JavaScript 99.43% HTML 0.30% CSS 0.27%
javascript dash drm cmaf eme media-source-extensions encrypted-media-extensions mss smooth-streaming video

dash.js's Introduction

Build status (CircleCI): CircleCI

Join #dashjs on Slack!

Migration from v3.x to v4.0

If you are migrating from dash.js v3.x to dash.js v4.x please read the migration document found here.

Overview

A reference client implementation for the playback of MPEG DASH via JavaScript and compliant browsers. Learn more about DASH IF Reference Client on our wiki.

If your intent is to use the player code without contributing back to this project, then use the MASTER branch which holds the approved and stable public releases.

If your goal is to improve or extend the code and contribute back to this project, then you should make your changes in, and submit a pull request against, the DEVELOPMENT branch. Read our CONTRIBUTION.md file for a walk-through of the contribution process.

All new work should be in the development branch. Master is now reserved for tagged builds.

Demo and reference players

All these reference builds and minified files are available under both http and https.

Samples

Multiple dash.js samples covering a wide set of common use cases.

Reference players

The released pre-built reference players if you want direct access without writing any Javascript.

The nightly build of the /dev branch reference player, is pre-release but contains the latest fixes. It is a good place to start if you are debugging playback problems.

CDN hosted files

The latest minified files have been hosted on a global CDN and are free to use in production:

In addition, all the releases are available under the following urls. Replace "vx.x.x" with the release version, for instance "v3.1.0".

Documentation

Full API Documentation is available describing all public methods, interfaces, properties, and events.

For help, join our Slack channel, our email list and read our wiki.

Tutorials

Detailed information on specific topics can be found in our tutorials:

Getting Started

The standard setup method uses javascript to initialize and provide video details to dash.js. MediaPlayerFactory provides an alternative declarative setup syntax.

Standard Setup

Create a video element somewhere in your html. For our purposes, make sure the controls attribute is present.

<video id="videoPlayer" controls></video>

Add dash.all.min.js to the end of the body.

<body>
  ...
  <script src="yourPathToDash/dash.all.min.js"></script>
</body>

Now comes the good stuff. We need to create a MediaPlayer and initialize it.

var url = "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd";
var player = dashjs.MediaPlayer().create();
player.initialize(document.querySelector("#videoPlayer"), url, true);

When it is all done, it should look similar to this:

<!doctype html>
<html>
    <head>
        <title>Dash.js Rocks</title>
        <style>
            video {
                width: 640px;
                height: 360px;
            }
        </style>
    </head>
    <body>
        <div>
            <video id="videoPlayer" controls></video>
        </div>
        <script src="yourPathToDash/dash.all.min.js"></script>
        <script>
            (function(){
                var url = "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd";
                var player = dashjs.MediaPlayer().create();
                player.initialize(document.querySelector("#videoPlayer"), url, true);
            })();
        </script>
    </body>
</html>

Module Setup

We publish dash.js to npm. Examples of how to use dash.js in different module bundlers can be found in the samples/modules directory.

MediaPlayerFactory Setup

An alternative way to build a Dash.js player in your web page is to use the MediaPlayerFactory. The MediaPlayerFactory will automatically instantiate and initialize the MediaPlayer module on appropriately tagged video elements.

Create a video element somewhere in your html and provide the path to your mpd file as src. Also ensure that your video element has the data-dashjs-player attribute on it.

<video data-dashjs-player autoplay src="https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd" controls>
</video>

Add dash.all.min.js to the end of the body.

<body>
  ...
  <script src="yourPathToDash/dash.all.min.js"></script>
</body>

When it is all done, it should look similar to this:

<!doctype html>
<html>
    <head>
        <title>Dash.js Rocks</title>
        <style>
            video {
                width: 640px;
                height: 360px;
            }
        </style>
    </head>
    <body>
        <div>
            <video data-dashjs-player autoplay src="https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd" controls>
            </video>
        </div>
        <script src="yourPathToDash/dash.all.min.js"></script>
    </body>
</html>

Quick Start for Developers

  1. Install Core Dependencies
  2. Checkout project repository (default branch: development)
    • git clone https://github.com/Dash-Industry-Forum/dash.js.git
  3. Install dependencies
    • npm install
  4. Build, watch file changes and launch samples page, which has links that point to reference player and to other examples (basic examples, captioning, ads, live, etc).
    • npm run start

Other Tasks to Build / Run Tests on Commandline.

  • Build distribution files (minification included)
    • npm run build
  • Build and watch distribution files
    • npm run dev
  • Run linter on source files (linter is also applied when building files)
    • npm run lint
  • Run unit tests
    • npm run test
  • Generate API jsdoc
    • npm run doc

Troubleshooting

  • In case the build process is failing make sure to use an up-to-date node.js version. The build process was successfully tested with node.js version 20.10.0.

License

dash.js is released under BSD license

Tested With

Browser Stack Logo

dash.js's People

Contributors

aescarcha avatar bbert avatar boushley avatar bwidtmann avatar davemevans avatar dmitriychernenko avatar dsilhavy avatar dsparacio avatar epiclabsdash avatar gontran-molotov avatar greg80303 avatar jeffcunat avatar jeoliva avatar jeremco avatar jontyusborne avatar kenthmobitv avatar kozhinm avatar nicosang avatar nweber avatar piersoh avatar robertbryer avatar sandersaares avatar spiterikevin avatar squarebracket avatar stschr avatar tobbee avatar tobbemobitv avatar tomjohnson916 avatar vrosenberg avatar wilaw avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dash.js's Issues

Enhance ABR rules to better support a more wide variety of connections.

The current ABR rules are lacking in support for a wide range of connection types. It is common for the player to want to switch up to a higher bitrate when there is not enough bandwidth to do so. Worse, the player continues to desire, and make, this change when it has already failed on playing the higher bitrate multiple times.

This is in part due to the conflicting nature of the current, simple rules. The fragments download in a timely manner in regards to their length (it takes less time to download a fragment then it takes to play out the fragment). However, at the same time, the download length is so long that it causes dry buffers.

At the end of the day we require a more robust set of ABR rules.

Remove JQuery

In discussion it was suggested that JQuery may not be necessary for the player. Remove of this library will significantly reduce the size of the player.

Audio and/or Video Total Index is not correct in support player

With certain streams the Audio and/or Video Rep for the total Index is not correct in the support player. Example : Envivio stream shows 1/5 for audio when there is just 1/1 - Microsoft #1 shows 8/1 for video Rep Index when it should be 8/8

I have confirmed that the data.Representation_asArray.length is correct within dash.js so something in the metrics extension must be missing

Dash should have a proper cleanup process (dispose)

Right now if dash needs to be torn down, there isn't a way to properly clean up everything:

Pause video
Disconnect the video element error event listener and remove all references to the video element
Cancel currently executing XHR requests
Cancel intervals and timers doing things

In particular, I've seen a number of exceptions bubble from dash in scenarios where the video element is removed, yet processes continue to execute and interacting with the buffer and the browser starts throwing exceptions.

I'd like to see a mediaPlayer.dispose() of some sorts.

I tried using attachView(null) to remove the video element on teardown, and it does NOT remove the old element and eventhandlers to it. So right now I don't know of a way to disconnect dash from a video element.

Static noise while switching audio bitrates

While testing the different versions of dash-if js players that can be found on http://dashif.org/reference/players/javascript/ , I could observe static noise while switching audio bitrates encoded with HE-AAC. The issue could not be observed until version 0.2.4 of the player. The last working one was 0.2.3. The used browser was the latests stable and canary version of chrome on linux, mac and windows. IE11 on Windows 8.1 Preview played OK.

I cloned the github repository and tried to find a clue what could have introduced the problem. I also tried the most recent player version by getting the master and dev-tree of the github repository. The audio static noise was still present. After a while I stumbled across a commit from

"> 14.06.2013 kirkshoop 26518ba <"

If I undo this commit, the audio issue is gone. Could someone please have a look at it? I'll give a short summary and a link to the mpd I used for testing.

  1. Issue: Static noise while switching audio bitrates encoded with HE-AAC after player version 0.2.3 with Chrome as a browser.
  2. Found a commit that seems to somehow introduce the observed issue: 26518ba
  3. Test item as an example: http://dash.edgesuite.net/dash264/TestCases/3b/fraunhofer/heaac_stereo_with_video/Sintel/sintel_480p_heaac_stereo_sidx.mpd

Many thanks and best regards

Use parallel XHP requests to fetch segments

In competitive tests with other DASH players, the dash.js suffered poorer performance than other players which aggressively fetched segments using parallel TCP requests. It is well known that parallel requests, under standard TCP congestion algorithms, enable a client to utilize more of the available bandwidth and our client should take advantage of this behavior to maximize the client playback experience.
Some items to be considered during this work

  1. Do we request sequential segments in parallel, or do we break a single segment in to chunks and then request those chunks in parallel?
  2. Should the start-up (buffering) behavior be different to the steady-state behavior?
  3. Can we provide a simple API to turn this behvior on/off and perhaps modify its agressiveness?
  4. Can we dynamically test the benefit of additional parallel requests and select the optimal request scheme as playback conditions change?

Chrome test Failure

While testing the code always get the javascript alert telling that the Media Source API is not supported, tests are done with Chrome latest version and also with the Chromimum

Minify JS libraries

The size and download speed of the player is important. We should create a build script that will minify the needed libraries and deliver them in a single request.

Issues when segment durations vary

We're testing with some DASH media where segment duration can vary. Some will be shorter the the specified duration, some will be longer. But the average will be what we specified in the MPD.

In the MPD we've tried specifying SegmentTemplate.duration=X, and also spelling out all each of the segments and in both cases, the dash.js client appears to get confused at times, and skips a segment or errors out. (I assume this is because it's mapping directly from play time to segment index from the duration.)

From what I understand in the spec, the requirements on the segment duration aren't too tight, so I'm filing an issue here because it appears, at first blush, at least, that it's a bug inside dash.js.

Dash.js not working on client machine?

Just downloaded Dash.js from GitHub.

On Chrome 27.0.1453.110, the JS works properly from http://dashif.org/reference/players/javascript/0.2.3/index.html,
however the video does not start if run from the local "index.html" file.

Here is the console log:

Playback initiated! 
Stream start loading. 
Start loading manifest: http://dash.edgesuite.net/envivio/dashpr/clear/Manifest.mpd 
manifest = http://dash.edgesuite.net/envivio/dashpr/clear/Manifest.mpd | isLive = false 
Doing parse. 
Converting from XML. 
Setting baseURL: http://dash.edgesuite.net/envivio/dashpr/clear/ 
Flatten manifest properties. 
Parsing complete. 
Manifest has loaded. 
Object
BaseURL: "http://dash.edgesuite.net/envivio/dashpr/clear/"
Period: Object
Period_asArray: Array[1]
__cnt: 12
__text: Array[2]
availabilityStartTime: Wed Sep 05 2012 11:00:00 GMT+0200 (ora legale Europa occidentale)
maxSegmentDuration: 4.08
mediaPresentationDuration: 260.266
minBufferTime: 5.001
mpdUrl: "http://dash.edgesuite.net/envivio/dashpr/clear/Manifest.mpd"
profiles: "urn:mpeg:dash:profile:isoff-live:2011"
toString: function () {
type: "static"
xmlns: "urn:mpeg:DASH:schema:MPD:2011"
xmlns:xsi: "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation: "urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd"
__proto__: Object

MediaSource created. 
MediaSource should be closed. (closed) 
MediaSource attached to video.  Waiting on open... 
Not allowed to load local resource: blob:null/bc3955a5-23cd-4ff3-a1d6-80c886a8593c 

Any help? ;-)
Thanks!

Video never begins playing if minBufferTime is longer than video duration

  1. Create an MPD manifest that has a minBufferTime="6S" and a mediaPresentationDuration="P4.121S"
  2. Play in dash.js

Result:
Video never begins playing; dash.js continues waiting forever for the buffer.

In the log, you'll see:
Waiting for more video buffer before starting playback.
[...]
Waiting for more audio buffer before starting playback.
[...]
Buffered audio Range: 0 - 3.967665910720825
[...]
Buffered video Range: 0 - 4.00399923324585

Add version to code base and player implementation.

We should add the version somewhere inside the player so that it is visible and accessible from somewhere other than the URL under which it is hosted. If the player is moved or copied to another site, we have no easy way to tell by inspection which version of the player we are looking at. The build version should be a JS var which any player implementation can easily access and display.

Video/Audio quality is not initialized when ABR is off.

The quality is not initialized correctly when a new manifest is loaded and the ABR is off. Here is how you can reproduce the issue:

1)  Make ABR off
2)  From the Stream pull down menu choose 'Envivio' (first item).  Click Load button.
3)  Allow it to start and change the video rep. index to 2 by clicking '+' next to video menu
4)  From the Stream menu choose 'DASH-AVC/264 - test vector 4b - Sony' (last item). Click Load.
5)  The video does not load.

Captioning support - out-of-band captions

Support the

  1. Parsing of caption data from the manifest (not 608/708 in-segment data)
  2. Loading and parsing of SMPTE-TT caption files (per DASH-AVC/264 guidelines)
  3. UI component to display and synchronize captions with video.

Per DASH-AVC/264, the captions can be signalled either as a xml file, or a ISOBMFF file. See the table below. We should supoort both types. A test vector forstpp exists at http://dash.edgesuite.net/dash264/TestCases/4b/sony/SNE_DASH_CASE4B_SD_REVISED.mpd .

captions

Support multiple BaseURL elements correctly

Many universities (including Telecom ParisTech and UniKlu) are hosting a "Distributed DASH Dataset" (see [1]). The content in the data set uses multiple BaseURL elements so that a player can choose the server it prefers among the currently 7 registered servers. The DASH IF player weirdly concatenates the content of all BaseURL elements at the same level in the MPD to determine the location of the segments. An example MPD with multiple BaseURL elements is here [2] and the same without BaseURL (which works fine in v.0.2.5) is available here [3].

Feel free to forward to the appropriate person,

Cyril

[1] http://www-itec.uni-klu.ac.at/dash/?page_id=958
[2] http://download.tsi.telecom-paristech.fr/gpac/dataset/dash/mmsys13/redbull_10sec.mpd
[3] http://download.tsi.telecom-paristech.fr/gpac/dataset/dash/mmsys13/redbull_10sec_nobaseurl.mpd

ABR does not work on MASTER

Apparently I don't have enough bandwidth to stream the streams at highest bit rates but in ABR mode it keeps on switching back to the highest bit rate

Support for LIVE (type == dynamic) streams

DASH IF has released the following test vectors for live streams

Live from VOD (will always be available):

http://dasher.eu5.org/statodyn.php?type=mpd&pt=1377268418&tsbd=10&origmpd=http%3A%2F%2Fdash.edgesuite.net%2Fdash264%2FTestCases%2F1b%2Fos%2Fcase1b.mpd&php=http%3A%2F%2Fdasher.eu5.org%2Fstatodyn.php&mpd=&debug=0&hack=.mpd

http://dasher.eu5.org/statodyn.php?type=mpd&pt=1376172180&tsbd=120&origmpd=http%3A%2F%2Fdash.edgesuite.net%2Fdash264%2FTestCases%2F1b%2Fthomson-networks%2F2%2Fmanifest.mpd&php=http%3A%2F%2Fdasher.eu5.org%2Fstatodyn.php&mpd=&debug=0&hack=.mpd

http://dasher.eu5.org/statodyn.php?type=mpd&pt=1376172390&tsbd=120&origmpd=http%3A%2F%2Fdash.edgesuite.net%2Fdash264%2FTestCases%2F2a%2Fthomson-networks%2F2%2Fmanifest.mpd&php=http%3A%2F%2Fdasher.eu5.org%2Fstatodyn.php&mpd=&debug=0&hack=.mpd

Live from encoders:

http://dashdemo.edgesuite.net/mediaexcel/live/ch1/dash.mpd

http://tvnlive.dashdemo.edgesuite.net/live/manifest.mpd

http://dash-live-path1.edgesuite.net/dash/manifest.mpd

http://dashdemo.edgesuite.net/mediaexcel/live/ch2/dash.mpd

The LIVE implementation should not require the user to select the LIVE checkbox in the UI and in fact this component should be removed.

The following use cases should be supported (1-7):

Use Case 1: Live Content Offered as On-Demand
In this case content that was distributed as live is offered in a separate Media Presentation as On-Demand Content.

MPD Data
MPD@type="static"
MPD@profile="…live…"
MPD@availabilityStartTime="0BC"

Consequence:
All segments get available at the same time and you can access all the data. If the content was live some years ago is irrelevant.

Use Case 2: Scheduled Live Service known duration, Operating at live edge
In this case a live service started a few minutes ago a lasts 30 minutes. The duration is known exactly and also all segment URLs are known. The timeshift buffer is short. This may for example be a live service for which the service provider wants to ensure that only a small window is accessible. The content may be pre-canned or may be generated live.

MPD Data:
MPD@type="dynamic"
MPD@profile="…live…"
MPD@availabilityStartTime="a few minutes ago"
MPD@mediaPresentationDuration="30 min"
MPD@timeShiftBufferDepth="30 seconds"
MPD@minBufferTime="5 seconds"
MPD@suggestedPresentationDelay="10 seconds"

Consequence:
Segments get available over time, but MPD is not updated and contains already the entire service until the end. However, the Time Shift Buffer window is short forcing the client into the live edge. It is also suggested to have a presentation delay of 10sec compared to the segment availability start time.

Use Case 3: Scheduled Live Service known duration, Operating at live edge and time shift buffer
In this case a live service started a few minutes ago a lasts 30 minutes. The duration is known exactly and also all segment URLs are known. The timeshift buffer is long. This may for example be a live service for which the service provider wants to ensure that the content is made available only at the live edge, for example a new show, but the content is available for 24h. The content may be pre-canned or may be generated live.

MPD Data:
MPD@type="dynamic"
MPD@profile="…live…"
MPD@availabilityStartTime="a few minutes ago"
MPD@mediaPresentationDuration="30 min"
MPD@timeShiftBufferDepth="24h"
MPD@minBufferTime="5 seconds"
MPD@suggestedPresentationDelay="10 seconds"

Consequence:
Segments get available over time, but MPD is not updated and contains already the entire service until the end. However, the Time Shift Buffer window is long enabling the client may operate in the time shift buffer. It is also suggested to have a presentation delay of 10sec compared to the segment availability start time for those operating at the live edge.

Use Case 4: Scheduled Live Service known duration, Operating in time-shift buffer
This includes the same MPD as the one in 3, but the client has accessed it later. It shows that the content is no longer available as live content and is already terminated. It is not recommended to maintain such an MPD on the server, but replace it with one according to use case 1. However, a client may have the MPD in its internal buffers.

MPD Data:
MPD@type="dynamic"
MPD@profile="…live…"
MPD@availabilityStartTime="1 hour ago"
MPD@mediaPresentationDuration="30 min"
MPD@timeShiftBufferDepth="24h"
MPD@minBufferTime="5 seconds"
MPD@suggestedPresentationDelay="10 seconds"

Consequence:
In this case the segment are all available and the Media Presentation is terminated. Some information is no longer relevant such as MPD@type="dynamic" and MPD@suggestedPresentationDelay="10 seconds".

Use Case 5: Scheduled Live Service known duration, but unknown Segment URLs
In this case a live service started a few minutes ago and lasts 30 minutes. The duration is known exactly but the segment URLs are unknown, as for example some advertisement may be added on the fly. Otherwise this service is similar to use case 3.

MPD Data:
MPD@type="dynamic"
MPD@profile="…live…"
MPD@availabilityStartTime="a few minutes ago"
MPD@minimumUpdatePeriod="0"
MPD@mediaPresentationDuration="30 min"
MPD@timeShiftBufferDepth="24h"
MPD@minBufferTime="5 seconds"
MPD@suggestedPresentationDelay="10 seconds"

Consequence:
Segments get available over time, MPD is updated, but the duration of the service is already known. This requires MPD update in this case basically with every downloaded Segment. The minimum update period may be increased to avoid this regular fetching.

Use Case 6: 24/7 Live Service
In this case a live service started that may have started a long time ago is made available. The MPD update may be done with a 30sec pre-warning. The duration is unknown exactly but the segment URLs are unknown, as for example some advertisement may be added on the fly. Otherwise this service is similar to use case 3.

MPD Data:
MPD@type="dynamic"
MPD@profile="…live…"
MPD@availabilityStartTime="January 1st, 1900"
MPD@minimumUpdatePeriod="30s"
MPD@timeShiftBufferDepth="24h"
MPD@minBufferTime="5 seconds"
MPD@suggestedPresentationDelay="10 seconds"
Period@start="Now - a few minutes - January 1st, 1900"

Consequence: Segments get available over time, MPD is updated and the duration of the media presentation is unknown (e.g. a 24/7 channel).

Use Case 7: Live Service with undetermined end
In this case a live service started that may have started a long time ago is made available. The MPD update may be done with a 30sec pre-warning. The duration is unknown exactly but the segment URLs are unknown, as for example some advertisement may be added on the fly. Otherwise this service is similar to use case 3.

MPD Data:
MPD@type="dynamic"
MPD@profile="…live…"
MPD@availabilityStartTime="July 16th, 2013, 6pm"
MPD@minimumUpdatePeriod="30s"
MPD@timeShiftBufferDepth="24h"
MPD@minBufferTime="5 seconds"
MPD@suggestedPresentationDelay="10 seconds"
Period@start="Now - a few minutes - July 16th, 2013, 6pm "

Consequence: Segments get available over time, MPD is updated and the duration of the media presentation is unknown (e.g. a 24/7 channel).

Use Case 7: 24/7 Live Service with canned advertisement
In this case a live service started that may have started a long time ago is made available. The MPD update may be done with a 30sec pre-warning. The duration is unknown exactly but the segment URLs are unknown, as for example some advertisement may be added on the fly. The advertisement itself is not a dynamic service, but available on a server.

multi-audio tracks support

Adding support for multiple audio tracks that the user can select from (will enable multiple language tracks for globalization)

Test-vector playback issues

Dear experts,

Several of current test vectors couldn't be played back. For several of them, the issue seems to be the one reported by issue#40: HE AAC v2 doesn't seem to be playable, though a fake codec identifier lets it to work (strange, seems like an initialization issue and not a decode capability issue).

Second category of the issue is vector with time-based template, those cant be played as well. I cant post the xls here, so I will try pasting my screenshot here, hope this works.

image 1
image 2
image 3
image 4

Expose an event for when the manifest is updated with a curated model of the content described by the manifest

A player using dash.js should be notified when the manifest is updated and be able to access a subset of the data in the manifest.

The player should be able to enumerate; periods, adaptation sets and representations. Properties like the bandwidth of each representation should be available. Scenarios include; displaying a progress bar with marks for each period transition, displaying a list of camera angles, displaying a list of language tracks and displaying lists of bandwidths available for each track.

The event can be built using the eventbus that Nathan added recently.

The vocabulary for the objects and their properties should not be dash specific. They should exist in the streaming directory and should use vocabulary that is releated to that and the MSE and HTML5 video element wording.

using dash.min/all.js in pages that use Require.js

At least one of the libraries used in dash.js detects require.js and changes it's behavior.

Consuming dash.min.js or dash.all.js when the “define” function exists dash.js throws null refs everywhere on “Q” not being defined.

Q.js has this blurb:

// Montage Require
if (typeof bootstrap === "function") {
    bootstrap("promise", definition);

// CommonJS
} else if (typeof exports === "object") {
    module.exports = definition();

// RequireJS
} else if (typeof define === "function") {
    define(definition);

// SES (Secure EcmaScript)
} else if (typeof ses !== "undefined") {
   if (!ses.ok()) {
        return;
    } else {
        ses.makeQ = definition;
    }

// <script>
} else {
    Q = definition();
}

If you aren’t using any of these module libraries, you fall to the last else statement, assigning window.Q to the definition. All the dash code assumes this, because it does not use any module library (like: var Q = require(“q”)).

In a merge scenario where q.js is merged into dash.min.js, I don’t think that having dash.js pick any one of the module libraries to reference Q.js would make sense either.

The only way to consume dash when one of these module systems is included is to build my own merge of dash.js that does not contain Q.js and load the Q.js module separately.

Even worse - because the test for require.js is too general any other code that creates a function named 'define' will cause Q.js to take the wrong path (it will try to create a require.js module but require.js is not being referenced). This issue in Q.js has been improved in Q.s repo, but our copy of it does not have that change.

Options:

  • We can try to copy the Q approach in dash.js where we have code for each module system that fixes these issues up
    • We can ensure that dash.min/all.js does not include any libraries that support module systems (either by removing the module support code from Q.js etc.. or by removing Q.js etc.. from the minified files. The second is a breaking change)
    • others?

Add feature detection for MediaSource support in reference player

v0.0.7 of the reference build fails silently if loaded in a browser that does not support MSE.
Player should perform a feature check when loaded and verify that MSE APIs are available. If available, load player UI and instantiate all page elements. If not available, display a clear UI message about which browser APIs are necessary for the correct operation of the player and some type of helpful suggestion as to where to obtain (or update) such a browser.

Use feature detection to make this decision, versus inference through browser version checking. Create check code in a separate reusable class that may one day be used as a basis for MS feature categorization i.e if (when :) )there is browser fragmentation, be able to branch player code based on deterministic feature support.

404 (Not Found) for "DASH-AVC/264 – test vector 5a - Thomson/Envivio" video stream

It seems there is some problem with "DASH-AVC/264 – test vector 5a - Thomson/Envivio". There is the following error in console log and video does not play.

Failed to load resource: the server responded with a status of 404 (Not Found)
http://dash.edgesuite.net/dash264/TestCases/1b/thomson-networks/video_2_900000bps.mp4
XHR finished loading: "http://dash.edgesuite.net/dash264/TestCases/1b/thomson-networks/video_2_900000bps.mp4".

It previously worked with the same code so I expect there is something wrong with server where video chunks are stored.

Repro steps:

  1. Open player in Chrome Canary
    http://dashif.org/reference/players/javascript/0.2.4/index.html?version=canary
  2. Select 'DASH-AVC/264 – test vector 5a - Thomson/Envivio' from the dropdown and click Load
  3. Observe: video playback is about to be started, then the error above occur

PS. Same problem with "DASH-AVC/264 – test vector 5b - Thomson/Envivio" manifest file

Provide a meaningful error for Multiplexed MP4s

Hi all,

GPAC/MP4Box seems to create multiplexed mp4 segments ( dash 'main' and 'full' profile ). Something like this...

<Representation id="1" mimeType="video/mp4" codecs="avc1.42c01e,mp4a.40.2" width="1024" height="576" frameRate="25" sar="16:11" audioSamplingRate="48000" startWithSAP="1" bandwidth="1208404"/><AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>

Chrome launches the 'Error creating source buffer' alert, however it then goes on to play the content.

Digging a bit deeper it looks like Chrome doesn't like adding two source buffers of the same codec and throws an exception. It looks like the video buffer is added ok, addSourceBuffer("video/mp4;codecs="avc1.42c01e,mp4a.40.2""), but when addSourceBuffer("video/mp4;codecs="avc1.42c01e,mp4a.40.2"") is called for the audio track an exception is thrown and the alert appears.

One way round it I thought would be to pass it something like "video/mp4;codecs="avc1.42c01e"" for the video and "audio/mp4;codecs="mp4a.40.2"" for the audio track however I then get an encoding error which is probably to do with this https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#sourcebuffer-init-segment-received (The note near point 5)

IE11 doesn’t seem to mind. However it is requesting the same file once for video and then again for audio when presumably it could just make a single request per segment… and add only one buffer?

I'm not sure if this is a problem with MP4Box creating a bad manifest, with MSE in Chrome or dash.js any thoughts?

In the short term it would be nice the 'Error creating source buffer' alert could be suppressed as Chrome is actually capable of playback using a single source buffer in this case?

Handle non-integer durations correctly

Currently, the media presentation duration is rounded to an integer in isMediaFinished to determine whether the media has finished. Reason given in comment is "The logic breaks if we don't do this...".

Under certain circumstances (final segment < 1s, starting and finishing in the final second of the presentation) this causes the last segment to be skipped - e.g. in one media set we are using segment length of 3.84s and media duration 9m32.52. The last segment starts and finishes in the 572nd second and is therefore never loaded.

I presume the comment alludes to floating-point manipulation and comparison? I have done a quick hack which seems to work but before issue a pull request I'd like to understand a bit more about what the author meant.

Issues in Running dash.js

I just downloaded dash.js project.
Followed the instructions on how to build and run mentioned at link:
https://github.com/Dash-Industry-Forum/dash.js

After downloading I did:
install nodejs
npm install -g grunt-cli
npm install grunt-template-jasmine-istanbul --save-dev
npm install grunt-contrib-connect grunt-contrib-watch grunt-contrib-jshint grunt-contrib-uglify
grunt --config Gruntfile.js --force

I get lot of TypeErrors as follows:

Fragment Controller Suite:: process with bytes as null: failed
TypeError: 'undefined' is not a function (evaluating 'Q.when(result)') in http
://127.0.0.1:8000/.grunt/grunt-contrib-jasmine/app/js/streaming/FragmentControll
er.js (line 6) (1)
timeout: timed out after 5000 msec waiting for something to happen (2)
Manifest Loader Suite:: manifestLoader returns a valid mpd: failed
TypeError: instanceof called on an object with an invalid prototype property.
in http://127.0.0.1:8000/.grunt/grunt-contrib-jasmine/phantom-polyfill.js (line
16) (1)
164 specs in 34.374s.

228 failures
Warning: Task "jasmine:tests" failed. Used --force, continuing.

Running "uglify:min" (uglify) task
File "dash.min.js" created.

Running "uglify:all" (uglify) task
File "dash.all.js" created.

Done, but with warnings.

Whn I open F:\MPEG-DASH-JavaScriptClient\dash.js-master\index.html on my PC, and type an MPD file path and select Load, it takes me to:
https://github.com/Dash-Industry-Forum/dash.js.

Pls let me know how to run the sample player from the dash.js I build.

HeAACv2 codec string (mp4a.40.29)

If I use an HeAACv2 audio file with the @codec parameter set to "mp4a.40.29", the audio will fail to play on both Chrome and IE11. Chrome will fail with an error message saying "Error creating source buffer", however the video will play (silently) after the error is cleared. IE11 will simply fail silently. Changing @codec to "mp4a.40.5" cures the problem.

Streams halt on first frame

As of version 0.2.4, there are a handful of streams that appear to halt on the first frame:

  • Envivio
    • http://dash.edgesuite.net/envivio/dashpr/clear/Manifest.mpd
  • DASH-AVC/264 - test vector 1b - Envivio
    • http://dash.edgesuite.net/dash264/TestCases/1b/envivio/manifest.mpd
  • DASH-AVC/264 - test vector 2a - Envivio
    • http://dash.edgesuite.net/dash264/TestCases/2a/envivio/manifest.mpd
  • DASH-AVC/264 - test vector 2a - Thomson
    • http://dash.edgesuite.net/dash264/TestCases/2a/thomson-networks/manifest.mpd

With all of these, if you nudge the scrubber a bit to the right the stream will begin playing normally. Note that all of these minus the Thomson stream would play automatically when loaded in 0.2.3, although they would skip the first few seconds of the media.

Tested at http://dashif.org/reference/players/javascript/0.2.4/index.html?version=all with 30.0.1550.1 canary.

Seeking failing on Envivio test stream under Chrome

Testing playback of http://dash.edgesuite.net/envivio/dashpr/clear/Manifest.mpd under Chrome 27.0.1453.93 and 29.0.1524.0 canary, Playback starts fine but if I seek to approximately mid-stream, playback stalls. Debug trace shows video and audio segments continue to be requested through to the end of the file, but no video or audio is rendered by the player. This bug is consistent under older versions of Chrome too. Other reference streams seek correctly.

In the debug trace, it looks as though the seek event is firing multiple times as the scrub bar is being dragged. Perhaps this is confusing the segment request logic? It would be better to issue the seek when the scrub bar is dropped, and not on some update interval while it is being dragged.

Playback rate: 1 dash.min.js:2
Working time: 6.995308876037598 dash.min.js:2
Video time: 6.995306968688965 dash.min.js:2
Working time is video time: 6.996603012084961 dash.min.js:2
BufferController.validate() | state: READY dash.min.js:2
Playback rate: 1 dash.min.js:2
Working time: 6.996603012084961 dash.min.js:2
Video time: 6.996601104736328 dash.min.js:2
Current video buffer length: 5.016690254211426 dash.min.js:2
Current audio buffer length: 5.0195207595825195 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 6.635676860809326 dash.min.js:2
BufferController seek: 6.635676860809326 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 8.110273361206055 dash.min.js:2
BufferController seek: 8.110273361206055 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 16.220544815063477 dash.min.js:2
BufferController seek: 16.220544815063477 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 23.59351921081543 dash.min.js:2
BufferController seek: 23.59351921081543 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 36.1275749206543 dash.min.js:2
BufferController seek: 36.1275749206543 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 47.92433547973633 dash.min.js:2
BufferController seek: 47.92433547973633 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 58.983795166015625 dash.min.js:2
BufferController seek: 58.983795166015625 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 67.09407043457031 dash.min.js:2
BufferController seek: 67.09407043457031 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 75.94163513183594 dash.min.js:2
BufferController seek: 75.94163513183594 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 84.05191040039062 dash.min.js:2
BufferController seek: 84.05191040039062 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 90.68758392333984 dash.min.js:2
BufferController seek: 90.68758392333984 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 95.84867095947266 dash.min.js:2
BufferController seek: 95.84867095947266 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 99.53515625 dash.min.js:2
BufferController seek: 99.53515625 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 102.48434448242188 dash.min.js:2
BufferController seek: 102.48434448242188 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 104.69623565673828 dash.min.js:2
BufferController seek: 104.69623565673828 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 106.17082977294922 dash.min.js:2
BufferController seek: 106.17082977294922 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 108.38272857666016 dash.min.js:2
BufferController seek: 108.38272857666016 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 111.33191680908203 dash.min.js:2
BufferController seek: 111.33191680908203 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 113.54380798339844 dash.min.js:2
BufferController seek: 113.54380798339844 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 116.49299621582031 dash.min.js:2
BufferController seek: 116.49299621582031 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 118.70488739013672 dash.min.js:2
BufferController seek: 118.70488739013672 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 120.91677856445312 dash.min.js:2
BufferController seek: 120.91677856445312 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 122.3913803100586 dash.min.js:2
BufferController seek: 122.3913803100586 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 123.86597442626953 dash.min.js:2
BufferController seek: 123.86597442626953 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 126.07786560058594 dash.min.js:2
BufferController seek: 126.07786560058594 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 129.0270538330078 dash.min.js:2
BufferController seek: 129.0270538330078 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 133.45083618164062 dash.min.js:2
BufferController seek: 133.45083618164062 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 137.87461853027344 dash.min.js:2
BufferController seek: 137.87461853027344 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 140.8238067626953 dash.min.js:2
BufferController seek: 140.8238067626953 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 143.77301025390625 dash.min.js:2
BufferController seek: 143.77301025390625 dash.min.js:2
Got seeking event. dash.min.js:2
BufferController seek: 145.2476043701172 dash.min.js:2
BufferController seek: 145.2476043701172 dash.min.js:2
Working time is seek time: 145.2476043701172 dash.min.js:2
BufferController.validate() | state: READY dash.min.js:2
Playback rate: 1 dash.min.js:2
Working time: 145.2476043701172 dash.min.js:2
Video time: 145.2476043701172 dash.min.js:2
Working time is seek time: 145.2476043701172 dash.min.js:2
BufferController.validate() | state: READY dash.min.js:2
Playback rate: 1 dash.min.js:2
Working time: 145.2476043701172 dash.min.js:2
Video time: 145.2476043701172 dash.min.js:2
Current video buffer length: 0 dash.min.js:2
Current audio buffer length: 0 dash.min.js:2

Start in Period results in negative time

Hi, I am writing a DASH packager and I'm trying to set a presentation time offset. In version 0.2.5 of this player, using presentationTimeOffset worked for both segment list and segment template MPDs. Now in 1.0.0, the attribute seems to be ignored.

In any case, I instead tried using the Period "start" attribute. However, doing so seems to result in a negative starting time. For instance if I add start="PT5S" to the Period, it results in a -5 start time.

Here is a test manifest you can try it on: https://gist.github.com/stephenbasile/bf62477d3759b246e0d2

You don't need the segments because it can't get the names right anyway due to the time problem.

That is a segment template example, but the problem also exists on segment lists. It thinks the time is negative and thus cannot match it with any of the "t" attributes listed on the segments, so it does not download or play anything. The console gives the error "Couldn't figure out a time! " which after browsing the source code, I see is logged when the current time matches none of the segments in the manifest.

If I leave off the start attribute entirely, the video plays back normally from the beginning on the segment template. On a segment list, it does not play back unless a segment with "t=0" is in the list, since it assumes the time is zero instead of looking at the "t" attribute of the first segment in the list. You can see an example of that behavior in this live MPD from Unified Streaming: http://live.unified-streaming.com/loop/loop.isml/loop.mpd?format=mp4

I'm not particular about how to solve this problem, I'd just like a method for properly setting a start time offset. If there is already a way that is working and I'm unaware of it, please let me know.

Add the D-DASH dataset URLs to the testing URLs available in the player

D-DASH is a dataset of content for the Dynamic Adaptive Streaming over HTTP (DASH) standard from MPEG. It is mirrored over different sites at different locations to perform, e.g., CDN-based scientific evaluations.

http://www-itec.uni-klu.ac.at/dash/?page_id=958

TRhe mpd generator is available here

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php

and it takes two parameters

  1. segmentlength= … n = 2, 4, 6, 10, 15 seconds of lenght for the media segments
  2. type={full, URLTemplate}

We should add the following URLs to the dash.js debug player

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?segmentlength=2&type=full

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?segmentlength=4&type=full

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?segmentlength=6&type=full

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?segmentlength=8&type=full

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?segmentlength=10&type=full

http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?segmentlength=15&type=full

MediaPlayer autoplay not working correctly

There are a number of problems here

  1. The baseline.html sample calls player.autoPlay = true; when autoPlay is not a property of MediaPlayer. The correct call is player.setAutoPlay(true);
  2. If you use mediaPlayer.setAutoPlay(false), then playback does not autoplay, however it also does not start if the play button is pressed on the video controls.
  3. In MediaPlayer.js, the attachView function hard codes the element autoplay to true. This means that if player.attachView is called after player.setAutoPlay, then the previous autoplay setting is overridden. The order in which the following calls are made against a MediaPlayer instance should not matter

player.attachView
player.setAutoPlay
player.attachSource

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.