4 ms·
Not sure where you're getting that "~100x50" figure, do you literally mean they're transferring a 100-pixel-wide image 50 times per second? The closest thing I
by erinaceousjones 8y ago
Not sure where you're getting that "~100x50" figure, do you literally mean they're transferring a 100-pixel-wide image 50 times per second?
The closest thing I can see them mention in that paper is their adoption of the "zig-zag scanning" rather than raster scanning. But how many pixels that skips over is very variable dependent on the input image.
There's also the "super-pixels" thing, but that's pretty standard for video compression right? Macro-blocks and B/P-frames, corrected with occasional full-resolution I-frames...
They also note the effect of distance, both in the abstract and in the results.. 720@60 at 10 feet, but only 480@10 at 16 feet. Not remarkable results, but they're not lying in their abstract...
- rasz 8y agoSupposed 1080 video would require ~100x50 resolution image (20x20 super-pixels) transmitted 30 times per second, rest of the ~3Mbit of bandwidth would be dedicated to actual video data. 3Mbit is enough for one "I" frame every 5 seconds, paper speaks of sending I frames every 8 seconds. That leaves 140KB per second for your magic compression, incidentally LESS than required by 100x50@30 L frames alone, and what about actual useful data? We didnt even mention color (~3x the data). Lets try 720@10fps. Budget is 3MB per 8 seconds. 64x36@10 L frames = 184KB, 921KB I frame, leaves us with 236KB/s, enough BW to transfer at max only ~20% of changed super-pixels per second. Even their simulated demo video doesnt appear to be real. Things just dont add up.