videojs / vtt.js Goto Github PK

Was the license intentionally removed from NPM? Was this done by a member of your team?

Running npm update with a project that includes video.js 7.20.3 changes package-lock.json.

diff --git package-lock.json package-lock.json
--- package-lock.json
+++ package-lock.json
       "version": "0.15.4",
       "resolved": "https://registry.npmjs.org/videojs-vtt.js/-/videojs-vtt.js-0.15.4.tgz",
       "integrity": "sha512-r6IhM325fcLb1D6pgsMkTQT1PpFdUdYZa1iqk7wJEu+QlibBwATPfPc9Bg8Jiym0GE5yP1AG2rMLu+QMVWkYtA==",
-      "license": "Apache-2.0",
       "dependencies": {
         "global": "^4.3.1"
       }

I've cloned the repository and installed it successfully, but when I run npm run test I get the following error:

> [email protected] test C:\Users\jknowles\workspace\vtt.js
> grunt

Running "jshint:files" (jshint) task
Warning: The "path" argument must be of type string. Received type object Use --force to continue.

Aborted due to warnings.

I'm not very familiar with grunt build tools, but I've tried removing the jshint task by deleting "jshint" from the array on line 112 of ./Gruntfile.js. Running npm run test after that also fails, but it gets a bit further:

> [email protected] test C:\Users\jknowles\workspace\vtt.js
> grunt

Running "uglify:dev" (uglify) task
File dev_build/vtt.min.js created: 56.04 kB → 21.3 kB

Running "concat:dev" (concat) task
File dev_build/vtt.js created.

Running "mochaTest:test" (mochaTest) task
>> Mocha exploded!
>> TypeError: Cannot read property 'prototype' of undefined
>> at Object. (C:\Users\jknowles\workspace\vtt.js\node_modules\socket.io\lib\store.js:35:42)
>> at Module._compile (module.js:652:30)
>> at Object.Module._extensions..js (module.js:663:10)
>> at Module.load (module.js:565:32)
>> at tryModuleLoad (module.js:505:12)
>> at Function.Module._load (module.js:497:3)
>> at Module.require (module.js:596:17)
>> at require (internal/module.js:11:18)
>> at Object. (C:\Users\jknowles\workspace\vtt.js\node_modules\socket.io\lib\manager.js:15:13)
>> at Module._compile (module.js:652:30)
Warning: Task "mochaTest:test" failed. Use --force to continue.

Aborted due to warnings.

I've tried running this on node versions 8.11.2, 10.16.3, and 13.0.1, but none of those work. Are the tests supposed to be working for this project at the moment?

Hello
I'm using video.js with HLS videos the subtitles are specified in the m3u8 file.
I'm facing this error every time a cue should appear

In cue-style-box.js, there is a switch statement based on the value of cue.positionAlign (https://github.com/videojs/vtt.js/blob/master/lib/process/cue-style-box.js#L54). However, the values in the switch appear to be possible values for the VttCue lineAlign property, not the positionAlign property.

See https://www.w3.org/TR/webvtt1/#the-vttcue-interface:

enum LineAlignSetting { "start", "center", "end" };
enum PositionAlignSetting { "line-left", "center", "line-right", "auto" };

I'm new to this, so I wonder if these values have perhaps changed over time. If there's another explanation, I'd be interested to hear it, since I'm trying to debug some positioning issues I'm seeing.

We are running into an issue when using video.js in meteorjs because of this library.

This package is failing to load because root.VTTRegion is undefined here:
https://github.com/videojs/vtt.js/blob/master/lib/vttregion-extended.js#L29

If I add a

module.exports.VTTRegion = this.VTTRegion;

at the very end of https://github.com/videojs/vtt.js/blob/master/lib/vttregion.js#L138 it all works nicely.

Would you be open to adding that modules.exports definition if I make a PR?

As far as I know this is implemented and used within videojs. as per our app requirements we need to report back text parsing errors. How can we register onparsingerror callback to use our custom implementation ?

Right now, this breaks when used in strict mode because in createElement it tries to set localName back to the tagName but setting localName on the element isn't allowed in strict mode. Loose mode lets it slide, though.
Making a change to video.js to disable strict mode for now (videojs/video.js#4551) but it should be fixed here ultimately.

Here is the infinite loop.

Example subtitles:

WEBVTT

1
00:00:00.970 --> 00:00:01.000 align:start line:9%,start position:10%

@gkatsev interesting question, ive a cue that literally ends with a <, e.g. "something something <".

I know this is a pretty bad cue and it should probably not have the trailing <, but the bad thing is that it actually crashes pretty badly on https://github.com/videojs/vtt.js/blob/master/lib/vtt.js#L346 - now this code is forked from mozilla's, so it's not something you introduced, but Im wondering if you would accept a PR here, or if I should send one to mozilla and if you would update from them later?

For the record, a cue like "something something <bla <" works fine :)

hi

Your LICENSE file does not include the name of copyright owner and the year.
Please correct your LICENSE.

or you can use the boilerplate written in the end of the page.
https://opensource.org/licenses/Apache-2.0

thank you :)

VTT files with carriage return (CR \r) line endings are rejected by the parser with a ParsingError.Errors.BadSignature error.

Issue seems to be the regex at

Per https://www.w3.org/TR/webvtt1/#webvtt-line-terminator "A single U+000D CARRIAGE RETURN (CR) character." should be supported.

Other notes:

• See videojs/video.js#8367 in https://github.com/videojs/video.js referencing this one, since that is where the ultimate fix would need to be deployed
• We are still trying to figure out why we are getting VTT files mac classic CR line endings, and have a workaround by locally modifying files to fix the regex. But an official build would of course be better.

Desired behavior
Rather than have the cue styles applied as inline styles, they should be applied as a list of styles within a stylesheet. This would allow for clients to easily override cue styles where necessary.

Concerns
It’s paramount that vtt.js continues to provide a way for consumers to get cue styles out of the box as, without them, the cues would not be accessible. Rather than changing the default behavior, we should look to provide new behavior behind an option.
We should make sure that this doesn’t prevent the implementation of the two currently in-flight PRs #35 and #27.

Proposed solution

1. Modify the processCues method’s signature such that it accepts an options object. The object will accept the following options:

• window
• cues
• overlay
• inlineStyles: true // default value. When true, styles will be applied to cues inline.
• [inlineStyles=true] - When true, styles will be applied to cues inline. [onapplystyles=null] - A callback function that is called when styles are applied to the cue. The callback is called with two arguments:
• styleObj - a hash containing a mapping of style names to their respective values.
• displayState - The element to which the styles should be applied

2. By default, cue styles will be applied directly to cue elements.
3. Pass the options object to CueStyleBox, and set the options hash on the CueStyleBox instance (e.g this._processorOptions = options);
4. The consumer is responsible for handling, and implementing, the styles that are sent in the onapplystyle callback.
5. Stretch: Update cues elements to have a class depending on their ids. mozilla/vtt.js#350 can be used for inspiration.

Currently vtt.js displays cues with line positioning offsets for both vertical right-growing-left and vertical left-growing-right offset from the incorrect side of the subtitle overlay.

The following cues are currently rendererd approximately like this:

00:00:06.000 --> 00:00:08.000 line:10% vertical:rl
text
________________________________
|    t                           |
|    e                           |
|    x                           |
|    t                           |
|________________________________|

00:00:06.000 --> 00:00:08.000 line:90% vertical:rl
text
________________________________
|                            t   |
|                            e   |
|                            x   |
|                            t   |
|________________________________|

But their positions should be inverted, and likewise for vertical:lr cues with line positioning percentages.

See this issue on the w3c WebVTT github for more information: w3c/webvtt#481

I believe the issue can be solved for cues where snapToLines is false by swapping the "right" and "left" settings here: https://github.com/videojs/vtt.js/blob/d7dfb66716d1cd9b80eb54aac1ee9b0f10add331/lib/process/move-box-to-line-position.js#L111:L120

I'm planning to trace back https://github.com/mozilla/vtt.js/commits/master , to apply newer commit to this repo

the format for pull request gonna be like:

keepup: 5b09be9, Jan 5 2017

Is this oke, or we just need as current vtt.js now ? (upstream repo doesn't very active develop, I can keep up with that)

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Currently, the build is done using grunt.
To version this plugin, it's standard npm version {{type}}.
Then, to publish it, you'd need to run grunt build locally before running npm publish.

This last step should be automated.