Closed
Bug 891661
Opened 12 years ago
Closed 11 years ago
Implement WebVTT (subtitles) in JS
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
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.
Comment 2•12 years ago
|
||
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.
Comment 3•12 years ago
|
||
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.
Comment 4•12 years ago
|
||
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?
Comment 5•12 years ago
|
||
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.
Comment 6•12 years ago
|
||
(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 :).
Comment 7•12 years ago
|
||
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.
Comment 8•12 years ago
|
||
(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?
Comment 9•12 years ago
|
||
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?
Comment 10•12 years ago
|
||
That's what we did previously as well, so seems to make sense.
Comment 11•12 years ago
|
||
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.
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.
Comment 13•12 years ago
|
||
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.
Comment 14•12 years ago
|
||
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.
Comment 15•12 years ago
|
||
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.
Comment 16•11 years ago
|
||
Is this bug still needed? See Bug 887978.
Comment 17•11 years ago
|
||
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.
Comment 18•11 years ago
|
||
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
Comment 19•11 years ago
|
||
(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.
Comment 20•11 years ago
|
||
Thanks a lot for the info!
You need to log in
before you can comment on or make changes to this bug.
Description
•