Ralph,
I assume you meant mozilla/webvtt repo when you said "we'll merge into
the mozilla/webrtc repo and work can continue there"? I like this plan.
My goal with all of the track element bits, plus this parser, is to try
and get things landed and hidden behind a pref so we don't have to
maintain patches against m-c long term, and then fix things in follow-up
bugs.
Dave
P.S. I've got other students taking on different aspects of the track
element spec work, see bugs 833386, 833388, 833385, 833382, 833403. You
will likely encounter them in #medai on irc (or here), and their
names/nicks are:
Kyle Barnhart (kmbarnhart)
Shayan Zafar (ShayanZafar)
Rick Eyre (reyre)
Jordan Raffoul (jbraffoul)
Marcus Vinicius Saad (MarcusSaad, msaad)
Dale Karp (daleee)
Caitlin Potter (caitp, caitato)
Jesse Silver (JSilver99)
On 13-01-22 8:08 PM, Ralph Giles wrote:
Thanks for the summary, Caitlin and Richard. Moving the thread here
where it's more generally visible.
We've been working through build system issues the past two days, and
are very close to having it pass 'make distcheck' with most of the tests
disabled. I'd like to get as many of those tests re-enabled as possible
before we merge into mozilla/webvtt.
My plan is for Chris Pearce and I to read all the code in the
humphd/seneca branch, asking questions and filing issues as we go.
Hopefully the authors can also respond and/or fix as we go along. When
we're happy we at least understand the state of the code, we'll merge
into the mozilla/webrtc repo and work can continue there, with ongoing
review of smaller pull requests. Until then I'd like us to keep feeding
into the seneca branch as the best version to merge.
One thing I'm concerned about is parser security. It's hard to write
secure string parsing in C (or C++) but this code will be fed files from
the wild, wild web, and it's important that we do all we can to not be
become an pwnage path. Unit tests, scan-build and fuzzing are all
important parts of that, but I think it's still going to take some time
to mature.
Because of that I propose we merge with mozilla's github tree and import
into m-c after filing, but not necessarily resolving all the issues we
find in review, relying on the pref to protect users. I fear anything
else will take too long to get the integration done. Chris and David,
what do you think?
-r
On 13-01-17 3:08 PM, Caitlin Potter wrote:
Thank you for subscribing to the mailing list, Chris and Ralph. We
haven't done a very good job of using the tool as of yet, but certainly
for communications with people many timezones away it should be
invaluable and very helpful.
As you likely are aware, our implementation of WebVTT will soon be
undergoing a review and thorough grilling in the near future, and I
wanted to give an indication of the current state of it so that we might
get some feedback on things to focus on before the initial review.
If you have not seen the source tree, our current work can be seen here
<https://github.com/humphd/webvtt/tree/seneca>
In summary:
* Autotools build system
/which may not be desirable for Mozilla integration/
* Lexical scanner ( src/libwebvtt/lexer.c )
/Simple state machine for scanning symbols from the main file, such
as keywords like "NOTE" or "WEBVTT"/. /Reentrant./
* Main parser ( src/libwebvtt/parser.c )
/Larger, buggier state machine. Currently does not actually call the
cuetext parser when a cue is available. Nor does it do a very good
job of reading multiple cues./ /Reentrant./
* Cuetext parser ( src/libwebvtt/cuetext.c )
/Currently operates on UTF16 strings collected from the "main" parser./
* Unit tests ( test/unit )
/M//ost of these will fail because of bugs in the parser which cause
segfaults and lea//ks//./
* Not thread-safe at all.
That's a very simplistic look at the tree, but those are the things
which stand out a lot to me personally, and these are problems that I'm
hoping to solve in the next few weeks. It hasn't been much of a tour,
but I would appreciate any and all comments and suggestions that will
assist me in solving some of these problems in a timely manner.
Some current goals that myself and Rick Eyre are working on:
* Call cuetext parser from main parser, once a cue has been read.
* Remove UTF16 string object, deal exclusively with UTF8/8bit encodings.
* Separate main parser into smaller (but still reentrant) routines.
* Resolve as many memory issues as possible, as quickly as possible.
I'll leave it at that for now, hopefully it gives a good idea of what
those of us working closely with the parser itself are contending with
at this time. If there are any questions or comments regarding the code
and decisions, we are all looking forward to your comments on the
mailing list and IRC.
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
