it seems quite straightforward in terms of setup. just tried again with the default values and it behaves the same. it is very unrealistic how fast the frame gap grows between server and client. i would be very happy to use it if worked.
would you suggest different settings? still think the offset growing so fast is weird
Edit: Sorry my mistake about the offset. The server was not up to 60fps.When the server runs smooth 60, the offset does not grow so fast. See it now at a constant value in the positive, that is also weird. And adapts trigger still pretty frequently and spike big in the mainloop
My guess: one of the frames simply takes too long. Image in in the 1. render frame the server tells us to load frame 1. With a preload count of two we will start loading frames 1, 2 and 3. But (and thatās maybe not expected here) we will also wait/block until frame 1 is fully loaded. Depending on the wait time thereāre now two scenarios how the game continues:
a) It was short enough so that in the 2. render frame the server will ask for frame 2 or 3. Since we had both of them in our preload list already thereās a good chance we will fetch the reqested frame quick enough and start loading frame 4 (or 5).
b) It took ages to grab frame 1, and since the server doesnāt wait on the client(s) it already requests a frame much higher than we thought. Weāll not have that frame in our preload list, and therefor thereās a high chance we end up in the same situation as in the 1. render frame.
That the ImagePlayer waits on the result it should display was a change last year in March. Canāt remember exactly what the test setup was, but for sure it wasnāt done just for fun. Here is the relevant commit message:
Adds blocking method to
TextureReader (Async)which in turn is used by image player to wait for the display frame
- No white flashes, because the frame we want to see will always be there - we wait on it
- Better resource utilization - the default pre-load count of 2 now leads to correct results
- A pre-load count of zero means we always wait on the frame, we see exactly how long it takes to load one video frame. With a count of one we already do most of the work async, but might still see some higher numbers whenever the video frame synchronizes with the render frame.
- Increases the read buffer size from 128 KB to 8 MB (vs 2 MB in vvvv beta) thereby reducing overall disk usage
Now this part could easily be undone on your end by making a copy of the node, name it MyImagePlayer and modify it to this:
Iād image doing so will lead to white flashes in your playback, but at least it gives your client a chance to catch up. The white flashes could probably be compensated by displaying the last frame, but still, it will lead to visual glitch.
If all of that helps your case we should probably add some config option to the node whether or not it should wait on the display frame or not.
Getting rid of the white flashes is on us last year. Would be pretty ironic if this particular change we were happy about led to this sync issue one year later. Anyway very interesting and we will try that for sure. Thanks for the detailed answer.
i tried this way, this results obviously in white flashes and surpringly in even worse performance. the FPS is down to even lower numbers than before.
we call it a day for now and will sync from internal framecounter to anything else. maybe we find the time in berlin to look at this together detail.