@MartinMueller2003
I'm not sure that I agree with you.
Suppose the refresh rate is 40 Hz (i.e. 25 ms/update). During this time the pixel output device would need to receive 40 complete output frames worth of data per port (e.g. 750 bytes for a single-port device with 250 pixels). Suppose that of those 40 frames that it receives (in the no-packet-loss scenario) in that second that frame 0 is actually data for the first frame in the next second, frame 8 is actually for the the 8th frame two seconds in the future, frame 16 is for sixteenth frame three seconds in the future, and so forth, with frame 32 is for the 32th frame 5 seconds into the future. This means that the intended output data for those frames was received over the prior seconds and stored in RAM.
The pixel output device has everything that it needs for smooth output in the absence of packet loss.. It has received 35/40 of the frames for this second of output in the immediate time frame, and the other 5/40 was received over the prior 8 seconds. If there was a total blackout for one second, it has 5/40 of the total number of frames that it would otherwise output spread out over that second, and would need to interpolate for the remaining 35/40 of the output frames, and the following second would be missing 1/40 of the frames that would be output. If the blackout lasted two seconds, the first of those seconds would be as before and the second of those seconds would be missing 36/40 of it's output frames (the other four were received over the four seconds prior to the blackout and stored in memory).
The total amount of RAM needed for this scheme is 750 * (5+4+3+2+1) = 11250 bytes, which is hopefully available with the ESP8266 cpu. The net effect of this scheme is that the pixel output device can continue to output data, albeit at a reduced frame rate during an entire 5-second blackout. Having more RAM obviously increases the blackout time that can be overcome, or alternatively the quality of output during and after blackouts.
Since I have my own home-brew controller designs and Linux-based code for sending data to those controllers I'll play around with these concepts. As noted above, it's not likely that this will be feasible in the Vixen3 streaming environment, and is not needed in the local storage situation.