cpillsbury

3 ms·

1.
by cpillsbury 7mo ago
Oh I definitely misunderstood! VJS is designed to have a "why not both?" approach for all of these things. Though, to your point, we will never build a core player or set of core functionalities that are not intended to work with
2.
by cpillsbury 7mo ago
Core contributor here! FYI these kinds of cases are definitely on my mind. One of the nice things about our overarching architecture is we (or someone else, even you!) can add/extend for these kinds in a way that doesn't deeply &q
3.
by cpillsbury 7mo ago
Hey, core contributor here! If a plain video element plus hls.js is all you need to accomplish your goals, we wouldn't ever try to convince you otherwise. In fact, our "HlsVideo" media renderer is backed by hls.js, and Rob Wa
4.
by cpillsbury 7mo ago
Core VJS contributor here and builder of players and playback engines for too long (aka before HLS and MPEG-DASH were a thing). As others mentioned, the support matrix for HLS is very typically the proximate, pragmatic reason why folks will
5.
by cpillsbury 7mo ago
Hey there, core contributor here! Starting with the last one first, since that's the easiest - VJSv10 is basically a completely new player, so no backwards compatibility planned (think Mac <=OS9 vs. OSX). We're aiming to port s
6.
by cpillsbury 7mo ago
Hey there, core contributor here! This came up during our beta effort. We very likely will be having an opt-in, non-native subtitles rendering implementation. I know at least a few team members that really want it, which adds to the likelih
7.
by cpillsbury 7mo ago
One other thing to note: because the features are "composed", we at least have a lot of flexibility here that makes me feel pretty good about the fundamentals and not "coding ourselves into a corner" here.
8.
by cpillsbury 7mo ago
Hey VJS core contributor here. We definitely feel that concern and we also don't yet have a silver bullet formalized. I suspect we'll need some kind of alternate implementations or feature augmentation at some point. We're cu