Closed Bug 891661 Opened 11 years ago Closed 11 years ago

Implement WebVTT (subtitles) in JS

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mreavy, Unassigned)

References

(Blocks 1 open bug)

Details

We're reimplementing WebVTT in JS.  The previous implementation was in C++, tracked in meta Bug 629350.
See Also: → webvtt
I uploaded an initial draft here: https://github.com/andreasgal/vtt.js

More to follow soon. If anyone has existing .vtt test files, I would love to have those. So far extracted all the examples from the spec. Please attach anything you can get your hands on here.
Blocks: webvtt
Andreas, you asked about API.

I think our needs are pretty simple. We want to pass partial buffers in sequence and get a callback returning some tree-like thing we can traverse to build the DOMFragment for display. In the spec errors just mean to drop that cue and continue, so all we need for error handling is way to reject files with bad headers.
If possible I'd really like to help with writing this new parser. Is there any area in particular that you'd like help on Andreas?
Rick, I have no desire to own this implementation. I am just moving things along until all pieces are owned by someone else. Grab any piece you like. The moment we have all parts covered my job is done. You are much more experienced with WebVTT parsing than I and much more qualified anyway.

Ralph: understood. I will have an onerror API that can be used for console feedback, and we will reject the cue but keep parsing.
(In reply to Andreas Gal :gal from comment #5)
> Rick, I have no desire to own this implementation. I am just moving things
> along until all pieces are owned by someone else. Grab any piece you like.
> The moment we have all parts covered my job is done. You are much more
> experienced with WebVTT parsing than I and much more qualified anyway.

Great! I'll try to help in as many ways as I can. As to whose more qualified than you or I, I wouldn't say that would be me, but thank you for your vote of confidence :).
If you want a simple place to start, I'd like a script which loads vtt.js in the command-line js or v8 interpreters and runs all the files in the 'tests' directory through it. A sort of 'make check' to help us find problems going forward.

See https://developer.mozilla.org/en-US/docs/SpiderMonkey/Introduction_to_the_JavaScript_shell for the load() and read() methods you can use to set that up if you're not familiar with the command-line interpreter.
(In reply to Ralph Giles (:rillian) from comment #7)
> If you want a simple place to start, I'd like a script which loads vtt.js in
> the command-line js or v8 interpreters and runs all the files in the 'tests'
> directory through it. A sort of 'make check' to help us find problems going
> forward.

Dave and I have set up an initial test suite that uses Grunt http://gruntjs.com/. The plan is to keep this as the way to test locally with travis as well. If we want to run the tests on the try-server or anything like that we can also have something that hooks into the JavaScript shell. Is that something we'd want?
I think we can lean on travis to check hat upstream works and then on the try server focus on integration testing. Ralph, do you agree?
That's what we did previously as well, so seems to make sense.
I think that's fine.

There's a general need for a spec testsuite, so something like the parsing validation tests you've written which could be run independently, whether on try or just as a public page is something it would be useful to produce. So I'd like to see a port to testharness.js or similar in the medium term. See dom/encoder/test for an example of how we do this in-tree currently.

Testing the parser in travis and the integration in m-c is fine in the meantime.
Blocks: 895091
So it turns out Anne already wrote a WebVTT parser in JS, in the public domain:  https://github.com/annevk/webvtt  It might be worth looking at whether his is further advanced and we should use it instead.
I looked at that code and closely modeled the new code after it. Its not a streaming parser and its meant to be used for a validator, not as an actual aprser.
Kudos on making it streaming, looking forward to seeing that :-) I think there's still benefit in doing validator-like-things to allow developers to debug through the browser, but that doesn't seem particularly high priority.
I think a validator with good error and warning support is important too, but our experience with the C implementation is that supporting both uses added a lot of complexity. I happy to see separate implementations.
No longer blocks: 895091
Blocks: 895091
Is this bug still needed? See Bug 887978.
I think we can close it. The initial implementation has been done. There's still more work to be done, but the WebVTT spec will be changing for a while so I don't think it makes sense to keep this open.
OK then, marking this as fixed for now. 

Would you mind going over the WebVTT bugs[1] (and dependencies of Bug 629350) and see if they still apply (and resolve otherwise)? Some may still come from the previous, non-JS implementation of WebVTT.

[1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=vtt&list_id=8706348



(In reply to Rick Eyre (:reyre) from comment #17)
> […] but the WebVTT spec will be changing for a while
> so I don't think it makes sense to keep this open.

Can you give me some info about that? Does the current implementation cover a baseline WebVTT version, or is it possible that the current implementation will have incompatibilities with a future version of WebVTT?
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Florian Bender from comment #18)
> OK then, marking this as fixed for now. 
> 
> Would you mind going over the WebVTT bugs[1] (and dependencies of Bug
> 629350) and see if they still apply (and resolve otherwise)? Some may still
> come from the previous, non-JS implementation of WebVTT.
> 
> [1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=vtt&list_id=8706348
> 

All the currently open bugs are valid as far as I know. Most of them have to deal with the DOM API and loading algorithms for the HTML5 track spec. 

> 
> (In reply to Rick Eyre (:reyre) from comment #17)
> > […] but the WebVTT spec will be changing for a while
> > so I don't think it makes sense to keep this open.
> 
> Can you give me some info about that? Does the current implementation cover
> a baseline WebVTT version, or is it possible that the current implementation
> will have incompatibilities with a future version of WebVTT?

The current implementation does cover a baseline implementation which is display of basic subtitles with bold, italic, and underline styling. There is no coverage for positioning (which I'm currently working on and should be done soon) or CSS styling.

Backwards incompatibility shouldn't be an issue for our implementation. There are some changes being made to things that we've already done, mostly VTTRegions, but there all being done in a backwards compatibility mindset.
Thanks a lot for the info!
You need to log in before you can comment on or make changes to this bug.