Hacker News new | ask | show | jobs
by kig 29 days ago
This is cool and minimalistic!

I've been noodling on https://qr-send.com which is a slightly more polished version of the "erasure fountain codes + stream of QRs"-idea, inspired by divan's Txqr posts but using Wirehair FEC for the fountain code (basically: you receive ~file size bytes via QR codes and it magically assembles them into the source file regardless of missed codes).

It's an offline-first progressive web app and there are native & wasm builds for the sender. The browser-to-browser transfer falls up to WebRTC when possible because 30 MB/s over wifi beats a 100 kB/s QR stream. The QR scanner is a heavily-optimized WASM build of zbar, scanning at 60 fps on mobile & multiple QRs per frame (but it's finicky! Work in progress.)

3 comments

That sounds amazing!

The WebRTC "fallback" basically means the QR code is just a handshake when both devices are on the same network?

The handshake details are passed alongside the data so that if a direct connection is successful, the network races the optical transfer.
This looks like a nice polished implementation of the idea, but when I try and use it, I get to "file complete" but then.. nothing? And I see no way to report a problem or bug.
Thanks for trying it, sounds like a bug I've been running into for a couple days where the wasm stream decoder does a bad memory access. I made some buffer lifetime fixes, next up a more complete stress test and fuzzing to see if I can pinpoint it.
It's working for me now! Multiple QR codes at once is kinda wild.
What is the fastest you can transfer data from ~10 meters away using a modern phone front camera and screen? Surely 100 kB/s is slow?
Depends on the zoom. With this setup you can transfer about 0.1 B/s per pixel of 60 FPS video. So a 65" screen and 1080p camera at 10 meters away would max out at 2 kB/s with the normal lens (26mm equiv) or 45 kB/s with the tele lens (120mm equiv.)

I'm cooking something faster but depends on the job situation and funding whether I have time to spend on it.

Napkin math: QR codes encode 0.75 bits per module, each module needs about 3 pixels of camera resolution, and the temporal resolution is quite dodgy as well, maybe 0.25 * min(cameraHz, screenHz). So if everything is perfect, 44 kB/s at 60Hz per a 500x500 pixel patch. I've seen ~250 kB/s when a 1920x1080@60 transfer is working well. At 4k@30, you might reach 0.5 MB/s. If you throw in the 2x subsampled UV channels to transfer data as well, you might get an extra 50%.

That's worse that I thought! I was thinking about holding up two phones facing each other at 10 meters, but using something smarter than QR codes.