用二维码传输数据方法的设想

现在是QR二维码铺天盖地的时代。

外面街头海报，网站，火车票上到处能见到QR二维码。

 

扫描二维码成了一种免去用户输入简单信息的方法。

某天上课我突然像到 

如果把二维码 看出一种输入到设备

能否用定义一种特别二维码 来传输大的 数据。比如像 文件之类的？

由于我并不了解 各种类型的二维码编码与解码的程序 。所以我只能把这个想法说出来 。

据我个人所知 目前智能手机大多数显示屏刷新率都是 60-70HZ

而手机的摄像头的最大帧率 一般为 30fps (视频录制帧率)。

能否在一台设备的显示屏 连续播放二维码动画,另 一台设备用摄像头连续识别二维码。

大概是这样

这样做有几个问题.

1.就是输出设备(连续播放二维码动画的设备)必须要有一个输入设备(用摄像头连续识别二维码的设备)能接受的 帧率。

所以为了使 输入设备 能达到用摄像头读取达到 30fps(最大帧率)  [不是必须]]的速度，必须每张二维码的识别速度要小于 33ms .

这在PC上实现似乎不难。 我曾经接触过一个DataMatrix 二维码的 识别软件 在噪声及其严重的情况下 能达到 10ms 。

但是要在移动设备上 恐怕是个问题。

所以新的算法优化很重要。

 2.传输速率的问题
就拿Qr二维码来说.在8bit模式下Qr 10版本的二维码 最大能达到 2953B 
差不多 3k 的数据 这是 Qr 二维码的最大容量。
为了考虑识别效率 我们可以考虑把数据分成 每 2kb 一个数据块。  就是一个数据帧
并每个数据块加上64bit的校验头。
前32位用于表示当前帧的序列号 。
后32位表示当前帧校验信息。

这样的话最大 传输的文件最大为信息量为 2^(32+1) Kb . = 2^(23)MB  = 2^13 GB = 8TB.

  

那么我们来计算一下最大的传输速率
30fps•2kb=60kB/s=480kbps
这个速度实在有点慢。
由于二维码是二值图，所以我们可以用一些特殊的方法来调制以增加传输速率。
1. RGB 调制。就是将3个数据块分别置于RGB 三个通道

 这样一帧就可以传输6kB

看一下这位大神的帖子:http://blog.csdn.net/onezeros/article/details/7394530

2.位深调制。由于摄像头不可能 真实的还原输出设备的所有颜色。加上外界因素。
所以一个像素的 24bit 不可能全部使用
但是我们至少可以使用里面的3-18bit。

我们再来算一下 最大传输速率

18•2kB/s•30fps=1080kB/s=1MB/s=8Mbps
这是蓝牙传输速率的8倍。是NFC的17倍左右。在wifi下传输速率的0.4倍


虽然现在可以通过wifi热点传输。但是打开wifi热点到打开软件连接完毕 起码耗时2-3min 甚至有时候会出现不灵的情况。

对于一般用户分享音乐 图片等这个方法的实效性应该要比其他方式高。

3.. 没有明确的反馈验证问题。

现在有一个问题 

如果当 输入设备的 识别速度跟不上 输出设备时候 怎么办。

因为输入设备 不可能用同种方式去把 识别到的每帧时 的验证去反馈给输入设备。可以说这个过程是单向的。

这有点像UDP 协议。

 输出设备把 一帧发送出去后，你根本不知道，输入设备能否接受到你的数据块。

当然可以通过校验头来判断 每个数据块的序列，但是 只要有数据块 一旦丢失 ，整个文件就不完整了。

下面有几种解决的办法

1.用输入设备扬声器播放 反馈音效，来给输出设备验证信息。

虽然 音频可被解调出来的数据量 远小于用显示屏传输。但是用 扬声器播放音效来作为每个数据块的验证 还是绰绰有余的。

 

 

2.当数据传输结束时，在输入设备上生成一张二维码给输出设备来验证。然后输出设备再将缺失帧率 传输给 输入设备

 

3.一个文件播放多遍 。

这虽然是一种很好的办法 。但是每多播一遍 将会牺牲 50%的时效。但是对于小文件的发送还是可行的 。

 

 

总之 这个设想 在低达到 1Mbps的传输速率应该是没有问题的。

 

但是介于我只是一个高中生，只是课余爱好计算机视觉和人工智能的小菜。

在二维码的解码和编码方面 并不了解。  有什么不对的地方希望各位大神指正。