Code Monkey home page Code Monkey logo

vtt.js's Introduction

vtt.js

Build Status npm-version Dependency Status devDependency Status

Implementation of the WebVTT spec in JavaScript. Can be used in NodeJS, on the browser, and many other places. Mozilla uses this implementation for parsing and processing WebVTT files in Firefox/Gecko.

Table of Contents

Spec Compliance

Notes

Our processing model portion of the specification makes use of a custom property, hasBeenReset. It allows us to detect when a VTTCue is dirty, i.e. one of its properties that affects display has changed and so we need to recompute its display state. This allows us to reuse a cue's display state if it has already been computed and nothing has changed to effect its position.

API

WebVTT.Parser

The parser has a simple API:

var parser = new WebVTT.Parser(window, stringDecoder);
parser.onregion = function(region) {};
parser.oncue = function(cue) {};
parser.onflush = function() {};
parser.onparsingerror = function(e) {};
parser.parse(moreData);
parser.parse(moreData);
parser.flush();

The Parser constructor is passed a window object with which it will create new VTTCues and VTTRegions as well as an optional StringDecoder object which it will use to decode the data that the parse() function receives. For ease of use, a StringDecoder is provided via WebVTT.StringDecoder(). If a custom StringDecoder object is passed in it must support the API specified by the #whatwg string encoding spec.

parse(data)

Hands data in some format to the parser for parsing. The passed data format is expected to be decodable by the StringDecoder object that it has. The parser decodes the data and reassembles partial data (streaming), even across line breaks.

var parser = new WebVTT.Parser(window, WebVTT.StringDecoder());
parser.parse("WEBVTT\n\n");
parser.parse("00:32.500 --> 00:33.500 align:start size:50%\n");
parser.parse("<v.loud Mary>That's awesome!");
parser.flush();

flush()

Indicates that no more data is expected and will force the parser to parse any unparsed data that it may have. Will also trigger onflush.

onregion(region)

Callback that is invoked for every region that is correctly parsed. Returns a VTTRegion object.

parser.onregion = function(region) {
  console.log(region);
};

oncue(cue)

Callback that is invoked for every cue that is fully parsed. In case of streaming parsing oncue is delayed until the cue has been completely received. Returns a VTTCue object.

parser.oncue = function(cue) {
  console.log(cue);
};

onflush()

Is invoked in response to flush() and after the content was parsed completely.

parser.onflush = function() {
  console.log("Flushed");
};

onparsingerror(error)

Is invoked when a parsing error has occured. This means that some part of the WebVTT file markup is badly formed. See ParsingError for more information.

parser.onparsingerror = function(e) {
  console.log(e);
};

WebVTT.convertCueToDOMTree(window, cuetext)

Parses the cue text handed to it into a tree of DOM nodes that mirrors the internal WebVTT node structure of the cue text. It uses the window object handed to it to construct new HTMLElements and returns a tree of DOM nodes attached to a top level div.

var div = WebVTT.convertCueToDOMTree(window, cuetext);

WebVTT.processCues(window, cues, overlay)

Converts the cuetext of the cues passed to it to DOM trees—by calling convertCueToDOMTree—and then runs the processing model steps of the WebVTT specification on the divs. The processing model applies the necessary CSS styles to the cue divs to prepare them for display on the web page. During this process the cue divs get added to a block level element (overlay). The overlay should be a part of the live DOM as the algorithm will use the computed styles (only of the divs to do overlap avoidance.

var divs = WebVTT.processCues(window, cues, overlay);

ParsingError

A custom JS error object that is reported through the onparsingerror callback. It has a name, code, and message property, along with all the regular properties that come with a JavaScript error object.

{
  "name": "ParsingError",
  "code": "SomeCode",
  "message": "SomeMessage"
}

There are two error codes that can be reported back currently:

  • 0 BadSignature
  • 1 BadTimeStamp

Note: Exceptions other then ParsingError will be thrown and not reported.

VTTCue

A DOM shim for the VTTCue. See the spec for more information. Our VTTCue shim also includes properties of its abstract base class TextTrackCue.

var cue = new window.VTTCue(0, 1, "I'm a cue.");

Note: Since this polfyill doesn't implement the track specification directly the onenter and onexit events will do nothing and do not exist on this shim.

Extended API

There is also an extended version of this shim that gives a few convenience methods for converting back and forth between JSON and VTTCues. If you'd like to use these methods then us vttcue-extended.js instead of vttcue.js. This isn't normally built into the vtt.js distributable so you will have to build a custom distribution instead of using bower.

toJSON()

Converts a cue to JSON.

var json = cue.toJSON();

VTTCue.fromJSON(json)

Create and initialize a VTTCue from JSON.

var cue = VTTCue.fromJSON(json);

VTTCue.create(options)

Initializes a VTTCue from an options object where the properties in the option objects are the same as the properties on the VTTCue.

var cue = VTTCue.create(options);

VTTRegion

A DOM shim for the VTTRegion. See the spec for more information.

var region = new window.VTTRegion(0, 1, "I'm a region.");
cue.region = region;

Extended API

There is also an extended version of this shim that gives a few convenience methods for converting back and forth between JSON and VTTRegions. If you'd like to use these methods then us vttregion-extended.js instead of vttregion.js. This isn't normally built into the vtt.js distributable so you will have to build a custom distribution instead of using bower.

VTTRegion.fromJSON(json)

Creates and initializes a VTTRegion from JSON.

var region = VTTRegion.fromJSON(json);

VTTRegion.create(options)

Creates a VTTRegion from an options object where the properties on the options object are the same as the properties on the VTTRegion.

var region = VTTRegion.create(options);

Browser

In order to use the vtt.js in a browser, you need to get the built distribution of vtt.js. The distribution contains polyfills for TextDecoder, VTTCue, and VTTRegion since not all browsers currently support them.

Building Yourself

Building a browser-ready version of the library is done using grunt (if you haven't installed grunt globally, you can run it from ./node_modules/.bin/grunt after running npm install):

$ grunt build
$ Running "uglify:dist" (uglify) task
$ File "dist/vtt.min.js" created.

$ Running "concat:dist" (concat) task
$ File "dist/vtt.js" created.

$ Done, without errors.

Your newly built vtt.js now lives in dist/vtt.min.js, or alternatively, dist/vtt.js for an unminified version.

Bower

You can also get the a prebuilt distribution from Bower. Either run the shell command:

$ bower install vtt.js

Or include vtt.js as a dependency in your bower.json file. vtt.js should now live in bower_components/vtt.js/vtt.min.js. There is also an unminified version included with bower at bower_components/vtt.js/vtt.js.

Usage

To use vtt.js you can just include the script on an HTML page like so:

<html>
<head>
  <meta charset="utf-8">
  <title>vtt.js in the browser</title>
  <script src="bower_components/vtt.js/vtt.min.js"></script>
</head>
<body>
  <script>
    var vtt = "WEBVTT\n\nID\n00:00.000 --> 00:02.000\nText",
        parser = new WebVTT.Parser(window, WebVTT.StringDecoder()),
        cues = [],
        regions = [];
    parser.oncue = function(cue) {
      cues.push(cue);
    };
    parser.onregion = function(region) {
      regions.push(region);
    }
    parser.parse(vtt);
    parser.flush();

    var div = WebVTT.convertCueToDOMTree(window, cues[0].text);
    var divs = WebVTT.processCues(window, cues, document.getElementById("overlay"));
  </script>
  <div id="overlay" style="position: relative; width: 300px; height: 150px"></div>
</body>
</html>

Node

You have a couple of options if you'd like to run the library from Node.

vtt.js

vtt.js is on npm. Just do:

npm install vtt.js

Require it and use it:

var vtt = require("vtt.js"),
    WebVTT = vtt.WebVTT,
    VTTCue = vtt.VTTCue,
    VTTRegion = vtt.VTTRegion;

var parser = new WebVTT.Parser(window);
parser.parse();
// etc

var elements = WebVTT.processCues(window, cues, overlay);
var element = WebVTT.convertCueToDOMTree(window, cuetext);

var cue = new VTTCue(0, 1, "I'm a cue.");
var region = new VTTRegion();

See the API for more information on how to use it.

Note: If you use this method you will have to provide your own window object or a shim of one with the necessary functionality for either the parsing or processing portion of the spec. The only shims that are provided to you are VTTCue and VTTRegion which you can attach to your global that is passed into the various functions.

node-vtt

Use node-vtt. Node-vtt runs vtt.js on a PhantomJS page from Node so it has access to a full DOM and CSS layout engine which means you can run any part of the library you want. See the node-vtt repo for more information.

Developing vtt.js

A few things to note:

  • When bumping the version remember to use the grunt release task as this will bump package.json + bower.json and build the dist files for vtt.js in one go.
  • The Grunt Run Task tool is handy for running the library without having to run the whole test suite or set of tests.

Tests

Tests are written and run using Mocha on node.js.

To run all the tests, do the following:

$ npm test

If you want to run individual tests, you can install the Mocha command-line tool globally, and then run tests per-directory:

$ npm install -g mocha
$ cd tests/some/sub/dir
$ mocha --reporter spec --timeout 200000

See the usage docs for further usage info.

Writing Tests

Tests are done by comparing live parsed output to a last-known-good JSON file. The JSON files can be easily generated using vtt.js, so you don't need to write these by hand (see details below about Grunt Run Task).

TestRunner

There's a prebuilt API in place for testing different parts of vtt.js. Simply require the TestRunner module in the lib directory and start writing tests using mocha. See an example of a test file here with its first test's WebVTT file here and its corresponding parsing JSON file and processing JSON file. You can also check out the tests directory for more examples on how to write tests.

jsonEqual(vttFile, jsonRefFile, message, onDone)

First parses the WebVTT file as UTF8 and compares it to the reference JSON file and then parses the WebVTT file as a string and compares it to the reference JSON file.

jsonEqualStreaming(vttFile, jsonRefFile, message, onDone)

Simulates parsing the file while streaming by splitting the WebVTT file into chunks. Will simulate parsing like this n times for a single WebVTT file where n is the length in unicode characters of the file, so use this only on small files or else you will get a timeout failure on your test.

jsonEqualParsing(vttFile, jsonRefFile, message, onDone)

Runs jsonEqual and jsonEqualStreaming in one go.

jsonEqualProcModel(vttFile, jsonRefFile, message, onDone)

Runs the processing model over the VTTCues and VTTRegions that are returned from parsing the WebVTT file.

jsonEqualAll(vttFile, jsonRefFile, message, onDone)

Runs jsonEqualParsing and jsonEqualProcModel. Note that jsonRefFile should contain JSON that is generated from parsing. The processing model test will compare its results to a JSON file located at [vttFile]-proc.json. Therefore, if you have a WebVTT file named basic.vtt the JSON reference file for the processing model tests will be basic-proc.json.

jsonEqualAllNoStream(vttFile, jsonRefFile, message, onDone)

Runs jsonEqual and jsonEqualProcModel use this if you want to do parsing and processing tests, but do not want to simulate streaming because you have too big of a WebVTT file.

Grunt Run Task

You can automatically generate a JSON file for a given .vtt file using the run Grunt task.

To get parsed JSON output from some WebVTT file do:

$ grunt run:my-vtt-file.vtt
$ grunt run:my-vtt-file.vtt > my-json-file.json

To get processed output from the WebVTT file do:

$ grunt run:my-vtt-file.vtt:p
$ grunt run:my-vtt-file.vtt:p > my-json-file.json

By passing the c flag you can automatically copy the output into a JSON file with the same name as the WebVTT file:

$ grunt run:my-vtt-file.vtt:c
$ grunt run:my-vtt-file.vtt:pc

The parsed JSON output now lives in my-vtt-file.json and the processing JSON output lives in my-vtt-file-proc.json.

You can also run it over a directory copying the output of parsing or processing each WebVTT file to a corresponding JSON file like so:

$ grunt run:my-vtt-file-directory
$ grunt run:my-vtt-file-directory:p

This is useful when you've modified how vtt.js works and each JSON file needs a slight change.

The run task utilizes a script called cue2json, but does a few other things for you before each run like building a development build for cue2json to use. It's also a bit easier to type in the CL options for the task. If you want to know more about cue2json you can run it directly like so:

$ ./bin/cue2json.js 
$ Generate JSON test files from a reference VTT file.
$ Usage: node ./bin/cue2json.js [options]
$ 
$ Options:
$   -v, --vtt      Path to VTT file.                                                                                     
$   -d, --dir      Path to test directory. Will recursively find all JSON files with matching VTT files and rewrite them.
$   -c, --copy     Copies the VTT file to a JSON file with the same name.                                                
$   -p, --process  Generate a JSON file of the output returned from the processing model. 

Notes:

  • cue2json utilizes the last development build done. This is why the Grunt run task is good as you don't have to remember to build it yourself. If you don't build it yourself then you could potentially get incorrect results from it.
  • Since cue2json uses the actual parser to generate these JSON files there is the possibility that the generated JSON will contain bugs. Therefore, always check the generated JSON files to check that the parser actually parsed according to spec.

vtt.js's People

Contributors

rickeyre avatar andreasgal avatar humphd avatar rillian avatar gkatsev avatar heff avatar alicoding avatar jespirit avatar akotliar avatar gandriy1 avatar cconcolato avatar johnbartos avatar marcussaad avatar mortonfox avatar mozilla-github-standards avatar pcting avatar coolheinze avatar

Stargazers

Brys avatar Ahmed Mahmoud Azzam avatar JarvisYang avatar ROBERT MCDOWELL avatar  avatar Daniel avatar  avatar Nero Blackstone​ avatar  avatar debuggingfuture (Vincent LCY) avatar leeir.zhu avatar Kuan-Yin Chen avatar Jadson Lucena avatar liudonghua avatar yanyanziii avatar  avatar Lock Phoorichet avatar Herman Ho avatar Andy Qin avatar Daniele Orlando avatar Gerad Munsch avatar  avatar Robin Larsson avatar  avatar Corbin Crutchley avatar wfd2018 avatar Sangram avatar Alexander Schumacher avatar  avatar akac avatar Ricardo Sawir avatar Ippei Suzuki avatar Matt Lewis avatar Jasdeep Khalsa avatar Mark Riley avatar  avatar Alfie Darko avatar Fábio Chiquezi avatar qiyu avatar Erdack54 avatar  avatar Eric Ahlberg avatar  avatar glowinthedark avatar 好吧,你想说啥 avatar  avatar Medson Bernardo  avatar Davide Costantini avatar Uday Kadaboina avatar Quirino Emmanuel Mendes Ramos avatar John avatar  avatar Leandro Daher avatar 樱川流夏立 avatar ya7 avatar Paul F avatar  avatar Bugakov Mikhail avatar Tristan Ross avatar Anthony avatar  avatar grey avatar MJimRenman avatar  avatar Kim Gwan-duk avatar  avatar Rafael Lüder avatar Howard_Lyu avatar 辻 修一 avatar Anthony lee avatar  avatar Keyan Zhang avatar Beaumont Phua avatar Thomas Klemm avatar Paul Kenneth Egell-Johnsen avatar  avatar Star Zou avatar Mohammad Saffari Far avatar Zedro avatar Mostafa avatar Matt Robinson avatar Juan Delgadillo avatar Efim avatar Bryson Treece avatar 小子欠扁 avatar Jeremy Blake avatar  avatar Ryuichi Yasuda avatar  avatar Alejandro Parra avatar  avatar Peter P. Gengler avatar Huminghao avatar acidburn avatar Ryan Warner avatar Arad Alvand (AmirHossein Ahmadi) avatar Burin avatar Stuart Bourhill avatar Kim Björkman avatar Kyle Howells avatar

Watchers

Silvia Pfeiffer avatar  avatar Guillaume C. Marty avatar  avatar James Cloos avatar Kelvin Chin avatar  avatar Michael Anthony avatar Volodymyr Mechkauskas avatar  avatar  avatar Pierre-Anthony Lemieux avatar TAn avatar Aven avatar Wellington Torrejais da Silva avatar  avatar iwyc avatar zhang hong sen avatar Karthick Chinnathambi avatar Gurban Gurbanov avatar  avatar  avatar  avatar  avatar TheLastForTheRest avatar Diego Diaz avatar

vtt.js's Issues

There should be an upper range on the line cue setting

It would make sense for the line cue setting to have some kind of range on the number of digits it can accept. As it is now we are accepting integer values with an indefinite number of digits.

Maybe limiting it to the range of an 32 bit int would be good.

Above quoted from @RickEyre in this bug 22708

I filed this issue so that we can keep track/comment on this and we can work on it once we get the response regarding the specification on this.

Cue2json output and current expected JSON mismatch

So the test harness currently expects JSON like this:

{
  "cue": {
    "id": "",
    "settings": {
      "region": "",
      "vertical": "",
      "line": "auto",
      "position": "50",
      "size": "100",
      "align": "middle"
    },
    "startTime": "000000000",
    "endTime": "000002000",
    "content": "<b>It's a blue apple tree!"
  },
  "domTree": {
    "childNodes": [{
      "tagName": "b",
      "localName": "b",
      "childNodes": [{
        "textContent": "It's a blue apple tree!"
      }]
    }]
  }
}

Cue2json outputs this:

{
  "id": "",
  "settings": {
    "region": "",
    "vertical": "",
    "line": "auto",
    "position": "50",
    "size": "100",
    "align": "middle"
  },
  "startTime": "000000000",
  "endTime": "000002000",
  "content": "<b>It's a blue apple tree!",
  "domTree": {
    "childNodes": [
      {
        "tagName": "b",
        "localName": "b",
        "childNodes": [
          {
            "textContent": "It's a blue apple tree!"
          }
        ]
      }
    ]
  }
}

So cue2json's JSON has no "cue" object in it. Personally I like cue2json's JSON output more so I think we should switch the test harness to expect JSON like cue2json's format.

Update FakeWindow to be able to create actual HTMLElements

The way the WebVTT spec has us create the DOM elements is just to create an element with localName 'b' or 'u', etc. However, this doesn't give us support for these tags in Gecko out of the box. Then, according to the spec, we have to apply CSS to each of theses nodes to get the 'bold' or 'italic' look in the subtitles.

What we were doing before is to instead just construct HTML elements and use that as our DOM tree. This gives us support for 'bold', 'italic', etc, out of the box. To do this we would need to have convertCueToDOMTree be able to call createElement('b'), createElement('u'), etc, on the FakeWindow.

I would recommend going with option 2. It's a lot easier and this part of the spec is all internal so we can go with whatever route we want.

Change size and position cue settings to be stored as an int.

Since we've moved over to storing the cue setting line value as an int it would be good to start storing the size and positions as int since this is what the spec calls for.

This would entail moving over all the JSON files we currently have to check for an int instead of a string.

@alicoding if you want to take this that would be great.

Test Directory Structure

Would you prefer a flat test directory or a tiered one like: tests => cue-settings => [cue setting vtt files] ?

Also, would you rather have many cues testing multiple things in one .vtt file or a single .vtt file for different things. For example would you rather have:

WEBVTT

00:00.000 --> 00:02.000 sze:42%
Text

00:00.000 --> 00:02.000 size;42%
Text

00:00.000 --> 00:02.000 size-42%
Text

Or 3 .vtt files testing each one of those cues?

Setup test harness to output 'pass all' for streaming tests or only ones that fail

We get a lot of clutter on the screen for streaming tests. It would be nice to get a 'pass all' for streaming tests when they pass everything and if they fail they get printed out on a fail-by-fail basis.

Edit
I'm not even sure this is possible as it seems like tape just prints out stuff to the command line automatically. Hopefully, it is possible though.

Move region tests to new test harness

We need to move the region tests over to the new test harness. The region vtt file can be found here.

The tests should live in a new folder called tests/cue-regions. We need to break each one of those separate cues out into it's own file, or in a way that makes sense for the test, and generate JSON files to compare them against. This commit here is a good reference for that.

We'll also have to add as many new tests as makes sense.

More information on how the test harness works can be found in the README.

@Daleee has expressed interest in helping so he's going to start on this issue to begin with.

Set CSS styles on the DOM tree

There are a number of CSS styles that need to be set on WebVTT region objects and the top level Node list object. Check here. The CSS styling for specific tags like b, u, and i we don't need to worry about as we are creating those elements via createElement('u') method. We only really need to worry about the top level stuff and possibly ruby and ruby text styling.

Depends on #86.

Cuetext tags whose end tag has no end '>' are failing

There are a number of tests in cuetext/tag-format/test.list that I've commented out because of this as well as the timestamp test no-end-gt.vtt.

Error is:

# /Users/reyre/Development/vtt.js/tests/cuetext/timestamp/no-end-gt.vtt
ok 78 should be equivalent
not ok 79 TypeError: Cannot read property 'length' of undefined
  ---
    operator: error
    expected: 
    actual:   {}
    at: assertions (/Users/reyre/Development/vtt.js/tests/run-tests.js:102:9)
    stack:
      TypeError: Cannot read property 'length' of undefined
        at consume (/Users/reyre/Development/vtt.js/vtt.js:188:34)
        at nextToken (/Users/reyre/Development/vtt.js/vtt.js:195:12)
        at parseContent (/Users/reyre/Development/vtt.js/vtt.js:229:15)
        at Function.WebVTTParser.convertCueToDOMTree (/Users/reyre/Development/vtt.js/vtt.js:288:10)
        at assertions (/Users/reyre/Development/vtt.js/tests/run-tests.js:98:43)
        at Test._cb (/Users/reyre/Development/vtt.js/tests/util/index.js:15:5)
        at Test.run (/Users/reyre/Development/vtt.js/node_modules/tape/lib/test.js:52:14)
        at Test.<anonymous> (/Users/reyre/Development/vtt.js/node_modules/tape/lib/results.js:108:16)
        at Test.g (events.js:175:14)
        at Test.EventEmitter.emit (events.js:92:17)

Determine correct behaviour for fail-bad-utf8.vtt

Currently fail-bad-utf8.vtt cue times and settings will be parsed correctly, but its cuetext will be thrown away because it has non utf8 characters. I'm not sure if it is correct to throw the cuetext away as the spec says to interpret the data as utf8 and leaves it at that. I think that a better thing to do would be to attempt to parse it anyways. Thoughts?

Tracking for spec bug 23190

Bug filed here.

Reading through the processing model and CSS styling for WebVTT regions I can't find anywhere where 'height' and 'right' are defined.

Append child error when there are multiple nodes at the top level in the cuetext

We're currently breaking on cues with cuetext that have multiple 'nodes' at the top level of the cuetext.

For example this would work:

WEBVTT

00:00.000 --> 00:02.000
<b>That's awesome! <i> Hee </i> </b>

But this wouldn't:

WEBVTT

00:00.000 --> 00:02.000
<b>That's awesome!</b> Hee

Error is:

not ok 13 TypeError: Cannot call method 'appendChild' of undefined
  ---
    operator: error
    expected: 
    actual:   {}
    at: assertions (/Users/reyre/Development/vtt.js/tests/run-tests.js:86:9)
    stack:
      TypeError: Cannot call method 'appendChild' of undefined
        at parseContent (/Users/reyre/Development/vtt.js/vtt.js:259:13)
        at Function.WebVTTParser.convertCueToDOMTree (/Users/reyre/Development/vtt.js/vtt.js:276:10)
        at assertions (/Users/reyre/Development/vtt.js/tests/run-tests.js:84:43)
        at Test._cb (/Users/reyre/Development/vtt.js/tests/util/index.js:15:5)
        at Test.run (/Users/reyre/Development/vtt.js/node_modules/tape/lib/test.js:52:14)
        at Test.<anonymous> (/Users/reyre/Development/vtt.js/node_modules/tape/lib/results.js:108:16)
        at Test.g (events.js:175:14)
        at Test.EventEmitter.emit (events.js:92:17)
        at Test.end (/Users/reyre/Development/vtt.js/node_modules/tape/lib/test.js:85:27)
        at assertions (/Users/reyre/Development/vtt.js/tests/run-tests.js:86:9)

There are a bunch of tests commented out in the cuetext tests right now in regards t to this. We'll have to turn those back on when this is solved.

Implement Regions in the processing model

If a cue is within a VTTRegion then we need to create a region bounding box (div) within which the bounding box of the cue will live.

The way I think we can do this is to pass in an array of regions along with the array of cues to processCues. We'll only pass the regions that are applicable, if any, to the cues about to be processed.

Create some way to check for errors in test harness

Right now we're failing a number of cue-time tests. See here.

This is due to the fact that the times are incorrect and so the cue gets dropped resulting in no cues. We need to have a way to check for errors as well to catch this. Errors are already reported in the util.parse() so it's just a matter of hooking it up to the test harness.

Fix arrows occuring in region ids

According to the current spec arrows.vtt is entirely valid. Even though you cannot have arrows in cue-setting region ids are not valid. See region-arrows.vtt.

So according to the current spec our implementation is wrong, but the spec most likely has a bug so I've filed a bug for that here.

Finish implementing computeLinePos

We need to figure out a way of finding the position of the cue's owning TextTrack in the MediaElement's list of TextTracks as in certain cases it needs to return this value + 1, negated.

TextTrackCue contains a reference to its TextTrack, but TextTrack does not contain a reference to its TextTrackList so this is an issue. Either we can change the spec, or we can possible pass in the textTrackList to processCues as well.

Switch to using underscore.isEqual instead of deepEqual

One of the problems with deepEqual is that it will do compare by using "==" so we're not comparing types, which we want.

Dave has recommended we user the underscore library's isEqual function. It would be as simple as this:

diff --git a/lib/util.js b/lib/util.js
index c8a1ece..7497dde 100644
--- a/lib/util.js
+++ b/lib/util.js
@@ -1,7 +1,7 @@
 var WebVTTParser = require("..").WebVTTParser,
     FakeWindow = require("./fake-window.js"),
     assert = Object.create(require("assert")),
-    deepEqual = require("deep-equal"),
+    deepEqual = require("underscore").isEqual,
     difflet = require("difflet")({ indent: 2 }),
     fs = require("fs"),
     path = require("path");
diff --git a/package.json b/package.json
index df9a6ce..69bdd34 100644
--- a/package.json
+++ b/package.json
@@ -12,7 +12,7 @@
     "grunt-cli": "~0.1.9",
     "grunt-contrib-jshint": "~0.6.0",
     "mocha": "~1.12.0",
-    "deep-equal": "~0.0.0",
+    "underscore": "~1.5.1",
     "difflet": "~0.2.6"
   },
   "main": "vtt.js",

However, I've tried this so far and no luck. Difflet detects no difference between the expected JSON and the parsed cuetext. I'm going to be concentrating on more tests today so I've opened this so someone else can work on it if they get a chance to.

Test harness

Would you take a patch to add node.js based unit tests that drive your parser? I'd use TravisCI for per-commit runs. I'm not sure how you feel about node, and if you have another form you'd rather.

Cue callbacks and parsing in light of DOM construction

@andreasgal , in pull request #8 you asked about how the DOM construction code in Gecko would expect to consume the parsed cues. I was the one who implemented that for the last parser. This might be a better place to discuss the issue as there might be a lot to nail down.

I'm not quite sure what you mean about document.write-style streaming, but in the last version of the Gecko DOM construction code we would wait for a complete cue before initializing a new TextTrackCue and adding it to the the TextTrack's list of TextTrackCues.

We would construct the DOM tree lazily. So we would wait until it's actually needed to be rendered and then at that time construct the DOM tree. We would then store the DOM tree on the TextTrackCue for use later. We were also adding in the ability to detect when the TextTrackCue becomes dirty and needs to have its DOM tree reconstructed as in the case of where the user changes TextTrackCue::Text.

So I think only reporting on completed cues for the DOM construction stuff is fine. We also need a way to pass in text and get back a parsed tree of WebVTT nodes though as well. So something like parser.parseCueText() which returns the the tree of WebVTT nodes.

Create infrastructure for JS-driven testing

In issue #6 @andreasgal suggested that we support JS-driven testing as well as testing based on parsing vtt files.

This would mean that we would be able to test functions and their output directly such as:

assert(parse("WEBVTT\n\n00:00.000 --> 00:02.000 sze:42%\nText\n").cues[0].settings.size == "42%"))

We'll want to be able to test all of the internal and public functions available in vtt.js. It might be useful to hook these up with the new test.list stuff landing in #9.

Parent nodes don't seem to be being added properly

When we parse the cuetext's content it seems like the parent node is not being set properly. The parent node of current will always be undefined. No idea why this is as appendChild() is supposed to add the parent automatically I believe.

Infinite loop on blank file .vtt

So if we have a blank file to check it will get stuck on that test.
I assume it is in an infinite loop because we can't handle such a data at the moment.

Streaming tests are causing the test harness to exceed it's maximum call stack size

I've disabled the parse streaming tests because they're currently causing us to exceed the maximum call stack size when running the test harness.

# /Users/reyre/Development/vtt.js/tests/cue-settings/vertical/capital-keyword.vtt - streaming (n=37)
not ok 3932 RangeError: Maximum call stack size exceeded
  ---
    operator: error
    expected: 
    actual:   {}
    at: assertions (/Users/reyre/Development/vtt.js/tests/run-tests.js:86:9)
  ...
not ok 3933 test exited without ending
  ---
    operator: fail
    expected: 
    actual:   
  ...

We'll have to figure out how to fix this.

Disabled in dbbc693

Fix bug found by minimum-spots-over-sixty.vtt

The time stamp 120:00.000 --> 120:10.000 is valid, but it is being thrown away by the parser. The spec says that the first time spot can be > 60 and in this case will be interpreted as hours.

Edit:
So it's currently not being thrown away, but I think this might be a good bug to figure out how we should be storing timestamp i.e. strings or ints?

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.