when the indices come from LTC, midiclock, UDP or AbletonLink, the imageplayer kills the performance with high ticks.
to analyze the problem, we queued the frames from the framecounter source and in comparison from the external sync source. both spreads showed 100% identical values. just like 0 1 2 3 4 5 6 7 8 9, each mainloop loop, the imageplayer received the same indices.
only difference, the internal framecounter values work, the “external” numbers don’t. the external frame indices where even filtered with Filter(Animation) to even out any jumps. but as the queue analyses showed, there wasn’t any difference.
only conclusion, the framecounter is somehow handled differently than the values originally coming from somewhere else. although, using the filter node, should align the calculation of the external source value to the mainloop of the patch.
digging deeper showed the waitfortexture is causing the issue. hence it has something to do with the task within imageplayer. i’m wondering if the framecounter is handled first in the order of execution of a mainloop loop and everything else at another point within the loop.
as i said, the input indices are frame perfect identical to the framecounter, as tested with the queue node. i recorded the indices at the same time from both sources and the result was 100% the same, frame by frame, number by number. it just doesn’t make sense that the integer which came orginally from outside the patch, causes such issues.
this is the synthetic test, but int values look fine over time. it makes no sense that the imageplayer goes mental when connecting the integer coming from any sync.
as i said, we testet basically all ways of syncing until we realized, its not the sync input but the player doing things.
create right imagesequence by starting the batchfile
you need a very fast SSD and 3-4 GB per second readspeed
you need a very fast PC (GPU and CPU)
you need beta and gamma to run the demo
a beta patch sends a framenumber to localhost
the gamma patch receives the data and runs the imageplayer
connect either the framecounter in gamma or the frameounter via OSC/UDP, internal framecounter should result in smooth playback while the frames indices from UDP will break the system.
I have been playing a bit with mainloops on the sending and receiving patch. I think it is due to framerate miss match.
If I up the receiving patch to 60fps and the sending to 45fps, I get solid 60fps
it seems to be the limit on my machine.
I would try to put the OSC receiver in an async region, I tried it, but i have never done it before and I don’t have time to figure out how they work. so I didn’t get that to work.
I have on other occasions experienced improved performance when tweaking mainloop framerates
i still think you don’t get the problem. i also used a filter node and an offset to make sure that 0 1 2 3 4 5 6 from internal framecounter and the int coming from UDP, LTC…whatever is exactly the same at the moment in time, when it is fed into the imageplayer. when filtering values from whatever source, you make them depended to the internal mainloop.
björn did a test on his machine and can’t reproduce it. that introduces more tests with another machine.
what i did not mention, the problem appears on a dual quadro A6000 setup, with mosaic (8x 4k) with a quadro sync card. which might have an impact on this. i’m currently testing on a similar machine.
it’s an edge case and i’m aware that we are pushing the limits. i just want to know whats going wrong here. :)
Two cents (not sure it’s relevant for you but one might read that in a moment of distress in the future) : we had issues in the past reading DDS stacks with M2 NVME drives that had poor Random Read performance.
Looks like when reading a big file, the hard drive uses Sequential Read, but when reading multiple “small” files (like a DDS stack), it uses Random Read.
Turns out that even though being an M2 NVME (that we assumed to be supercrazyfast), this drive had super bad Random Read perfs, which lead to it being maxed out 100% of the time (you could see the graph caping at 100% constantly in the performance monitor), resulting in our patch randomly dropping to 2/3 FPS.
Changing the hard drive to one that had good Random Read perfs magically solved the issue.
actually, you are up to something in terms of a solution. i tried 30 sending and 60 fps receiving, that seems to work quite well. i tried interpolating the frame up to 60fps again, that worked.
Thanks for plan B !
regarding the original problem, it is still not clear why this happens in the first place.
just added a video, please ignore the queue recording in the video. there was a glitch. the video is just for demonstrating purposes.
I think it might be due the two instances need to be perfectly synchronised if running at the same framerate, to avoid receiving two integers per frame. at least that is what I think.
It is also why I think it might work if you receive the integers in an async region
the vvvv UI tells me, the values are perfectly synchronized, when looking at the queue output. under the hood, things might look different and vvvv might choked on the fast UDP input. but then i tried LTC, which was just 30fps by default and i experienced the same behaviour.
i still suspect the execution order of vvvv, which we only have limited control over via patching.
Without having wrapped my head around your setup…what strikes me in your screenshots is that you’re not using a FramePlayer node. Have you read this? Video Synchronization | vvvv gamma documentation
I wonder if what you’re missing is a custom implementation of the FramePlayer thats using your custom sync mechanism.
I have tried the built in sync of the frameplayer briefly. it was running out of sync immediately and readapting to server was constant. That meant also huge spikes in the mainloop. really thought it is just broken
