3 ms·
It seems to me that they would use these HTML5 features and APIs to implement audio and the actual pixel output from the VLC codecs. But this would mean suppor
by lawik 10y ago
It seems to me that they would use these HTML5 features and APIs to implement audio and the actual pixel output from the VLC codecs.
But this would mean support for an incredible number of input formats.
At least that is how I understand their goals.
- matthewbauer 10y agoThis seems right: just perform the conversion in the browser and play the output in a <video> tag. The alternative would be to draw frame-by-frame in a canvas which would be very difficult.
- lawik 10y agoAh, you mean transcode to something the browser actually handles? I think that transcoding might be many variants of terribly slow though. I'm not sure drawing it to canvas frame by frame would be all that hard, VLC already does some kind of frame-by-frame drawing I'm guessing, on the output end. Canvas should be plenty fast enough as long as the decoder can keep up I imagine. I'm thinking this might be a good use of Web Workers to offload decoding to another core to avoid hanging the main thread (UI). I'm mostly guessing. I wonder how heavy different encodings/formats will be to decode in JS. Haven't worked with video on that level of detail, but I imagine that there a plenty of optimizations that can be done in low-level languages to get solid performance that JS might not deliver.