QuickeR: Using video QR codes to transfer data

Recently I attended Over the Air, which (to borrow from their website) is:

a great vibe of bean bags, gadgets, knowledge sharing, hacking & lots of good geekery.

Or, to be more specific:

a unique tech-agnostic event for and by the developer community, featuring technical workshops where attendees can roll up their sleeves and tinker with new platforms, operating systems, APIs & SDKs; and tutorial sessions that feature real business cases, new insights and a healthy dollop of inspiration. Attendees are invited to stay overnight so that they can work on ideas, apps and hacks on the fly – to be entered into the various hack-athon competition categories and demo’ed on the second day.

And it was awesome. I met some really cool people, was fantastically well looked after and this year it was held in Bletchley Park; which is an amazing place and somewhere I’ve always wanted to visit.

One of the more fun parts of the event was the traditional overnight hack; with people seeing what cool things they could cobble together (often involving some of the tech & APIs shown off at the event), which then got shown off the next day, with the best winning prizes.

This is what I came up with:

QuickeR

The basic idea was to transfer data between ‘devices’ using ‘video’ QR codes, i.e. by splitting the data over multiple QR codes, which are then presented one after another as a video. Another device can then capture this video, split it into the separate QR codes, process them and recombine their contents to reproduce the original data.

So, as an example, I took the following four QR codes:

1This 2is 3a 4test

And combined them into the following video (gif):

Note: the numbers are there to denote the order of the elements, as the video will repeat endlessly and we don’t know where it started.

I then created an Android app that could read the video and reconstitute the data:

Now, not to sound too full of myself, but I think is a pretty cool idea and it’s something that I don’t think I’ve seen anywhere before. The initial use case I came up with was for transferring data between mobile phones, particularly in situations when network connectivity wasn’t available or was unreliable (which was unfortunately the case at Over the Air). However it could work between any device that can display a video and any device that can capture that video and run a bit of software. So for example, you could communicate between a TV and a mobile phone – maybe to download a sample app while the advert is on?

Also, theoretically, it has a moderately high transfer rate (for what it is):

15 FPS x ~2,953 bytes per frame = ~43 KB/s.

Comparable to a modem of old :)

Now, the app as it is today is fairly cludgy, as you’d expect for something thrown together in the space of 5 hours, and so I’m not going to shove the code up here – yet. There’s a load of cool things I want to do first:

  • Add video creation to the app – allowing you to select a file on the device for transfer.
  • Use smarter encoding schemes and maybe data compression.
  • Auto-stop & error checking – by adding information about how many frames should be in the data set.
  • Harden the code – it has a unfortunate tendency to fall over with out of memory errors at the moment :)
  • General UI improvements – creating one for a start.

Who knows, I may even release it as an app on the marketplace.

P.S. I did get some comments about the name. To be honest, I started with the Q & R and worked backwards from there; however I do argue that it’s quicker than scanning multiple QR codes separately and trying to put the stuff back together yourself.

10 Comments

  • 10/03/2011 - 8:54 pm | Permalink

    … just don’t tell Roo Reynolds! :-)

    Seriously, this sounds awesome – really glad you made it to OTA and made a name for yourself there – you are definitely one of my “top mobile devs” to watch for the future!

  • Pingback: And that’s a wrap. « Over the Air

  • Pingback: Audience Vote – The results are in! « Over the Air

  • 10/05/2011 - 2:04 pm | Permalink

    Very interesting. And congratulations for OTA prize.

    Seems to me that more bandwidth can be achieved by larger QR codes, no? And why stop at 15fps? Is that the top speed for scanners, currently? As that number increases, the animations would be able to go faster and faster until the code looks static again (like a grey square with the 3 markers).

    Temporal CRCs should also be considered in the future, I imagine, since resistance to noise is one of the strong points of QR codes but just animating them doesn’t provide it for the time dimension.

    • 10/20/2011 - 9:41 pm | Permalink

      Hi Max,

      Thanks! It’s turned out to be a much more popular idea than I expected, not that I’m complaining :)

      I’ve not tried using larger QR codes yet. They’d definitely allow more data per frame, but I imagine they’ll be a point at which the phone camera has trouble making them out. It’ll be interesting to see what the threshold is.

      As for the speed, 15 FPS is the capture rate of my phone (a HTC Desire). I’m currently experimenting with the app and getting it working reliably at the full 15 FPS, as the QR I initally used was nowhere near this rate; it’s looking really promising. I know that newer phones are capable of higher capture rates (the Nexus S can capture at ~30 FPS) and the idea that a really fast QR code could look like a static one is pretty cool.

      The Temporal CRCs are also a good idea. I’ve been thinking about the possible ways of error checking and there’s some really interesting possibilities. I’ve also got some interesting ideas about compressing data and the best way to split it. I’m keeping these a little close to my chest for now though :)

      Steve

  • Pingback: OTA11 Hackday Categories & Prizes « Over the Air

  • Pingback: Hackdays= NSA. AKA: one day at Over the Air | francopapeschi.com

  • vasile
    07/11/2012 - 9:03 am | Permalink

    Hi,
    This application is very interesting. Congratulations for OTA prize.
    Can you help me with the source code? i want to try on my phone with different encoding algorithm, not only qr code, witch transfer rate is limited by size of qr-code.
    Thanks and good luck.

  • MikuroK
    12/13/2012 - 7:37 am | Permalink

    Just so you know, 43KB/s is much faster than a 56k modem, the “56″ is in kilobits, not kilobytes, so they max out at only 7KB/s. and 43KB/s in kilobits is 344.

  • Shaun Hey
    04/28/2013 - 4:59 pm | Permalink

    Like most things I think of, someone else has already done it :). Kudos to you on this cool project. I had the same idea, just a couple years too late…

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>