5 ms·

The paper isn't self-evidently fradulent to me. Since it wasn't part of the discussion in the dedicated hn thread it seems like you just have some special insig

The paper isn't self-evidently fradulent to me. Since it wasn't part of the discussion in the dedicated hn thread it seems like you just have some special insight to be able to make such a strong statement?

rasz 8y ago
Oh, so claiming "60 fps 720p and 1080p" and later mentioning you are actually transferring ~100x50 and throwing out the rest is ok with you. Read that paper again.
- 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 ago
    Supposed 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.

rasz 8y ago

Oh, so claiming "60 fps 720p and 1080p" and later mentioning you are actually transferring ~100x50 and throwing out the rest is ok with you. Read that paper again.

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 ago
  Supposed 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.