fast rendering?

I do wrote myself my own timeline, which has a cursor to move the playhead. When the cursor is changed, I call: ctx.currentTime = newTime. I have enabled the visualiseVideoContextTimeline. I can see the cursor in the visualization is the same as my own one, so the sync here is good. What lacks behind is the video. There is always some lag on the web, yet the video basically only changes, when I stop moving the cursor around or slow down my cursor movement drastically. I’m only on a local machine, so there is bandwith limit for me at the moment. I was wondering how speed up rendering the video in “time-critic” situations.

There was a talk at jsconf eu this year as well adressing this issue: https://youtu.be/NpKLt_YO3o8?list=PL37ZVnwpeshFmAPr65sU2O5WMs7_CGjs_&t=722 I think this is a solution to this. Although there is a drawback of using tons of RAM. Maybe as an opt-in option? Ref #58

[MatthewShotton]

hey @gossi I’ve just pushed v0.51.1 which should help speed up the rendering while seeking.

The problem was the videonode was waiting for the underlying video elements readyState to be greater than the HAVE_FUTURE_DATA value before it started updating the texture rather than the HAVE_CURRENT_DATA value which would’ve been enough to render the current frame.

It might still not be quite as fast as a standard video element as there’s a number of extra operations happening under the hood when a seek take place. But it should be a fair bit faster than it was previously.

[gossi]

Wow @MatthewShotton you are awesome!

Seeking now is up to the same speed as with <video> before. So I thought I give it test. Here is what I found:

1. Memory isn’t faster I tried using the load-the-video-into-memory-first-hack from jsconf again, however I could see no difference. I should be trying to use this on rare <video> element first to see if this makes a difference I guess and if, how and if this could be applied onto VideoContext - I skipped that part.

2. Initial loading Give the most simple example, that one video is connected to the VideoContext taking the whole timeline of VideoContext, on initial loading it takes unexpectedly long until the first frame is painted. This is something where the <video> element is faster at the moment. It kinda displays the first frame immediately. It feels like, the VideoContext is waiting for the whole video loaded until it will display the first frame. Maybe also something like the readyState thing as before? (Since I’m working with local videos, the videos are loaded instantly for me and because of that a delay immediately attracts attention and results in negative perception)