“乒乓”前行策略在还原高清视频网络数据的应用

    在前些日子，本人就讲过，要将“乒乓”前行策略和大家分享一下，但一直都未成文，今日实现之。本应配以示意图，就更能清晰的说明问题，但试了几次都未能在JaveEye实现成功，我尽量在文字上，更加详尽点，帮助大家更好的理解。

    “乒乓”前行策略实质是解决，在“非保证数据完全的协议”中，完成服务器到客户端数据的“全还原”。有点绕口，我来解释一下：设想一下，影视节目视频服务器，用HTTP、RTMP（或其变种，RTMPT RTMPS RTMPE RTMPTE）发布节目，通过这些协议的确可以将影视节目数据发送到用户的浏览器中，但是用户在观看过程中，会出现花屏、跳屏等现象。其原因并非服务器端影视节目有误，而是所用的应用层协议，不能保证数据的完整性，普通用户可以忍受由于数据损失所带来的不满。但是我们却要找到一个方法，100%的拿到服务器端的高清视频。所以也就有了，在“非保证数据完全的协议”中，完成服务器到客户端数据的“全还原”。

    今日只讲HTTP的情况，暂不讲RTMP及其变种的情况。并非有所保留，而是因为RTMP的数据定位贯穿整个视频文件。若无图示，只怕是懂的人，不讲也懂；不懂的人，讲了也不懂。起不到好的效果，改日在发一篇有关RTMP的配图说明。

    我们之所以将这个策略，取名为“乒乓”前行，由这“乒乓”两个字就能看出来。无论是‘乒’还是‘乓’，都有缺失。好在‘乒’所缺失的内容在‘乓’中，反之亦然。那对于用“非保证数据完全协议”传输的视频文件，会有缺失；但是各个文件所缺失的部分，会出现在另一份文件中，这样做一个文件的加法，就能将各个缺失的部分都还原。最终实现，从客户端来看，视频文件的数据是完整无缺的。

    讲了策略，再来讲实现。我们都知道HTTP的下层是TCP协议，在TCP的每个数据包中有两个字段“发送ID”和“确认ID”。这两个ID是“乒乓”策略保证客户端视频文件框架等同的关键。因为这两个ID的数值是由服务器修改的，服务器又是针对一个完整的视频文件，所以服务器取了多少视频数据，已经发送了多少视频内容，都是可知的、无误的。所以由这两个ID，就能将网络视频流数据，对应到原视频文件的相应位置。这是整个实现的基础。其后的工作就是，唤起服务器，提供视频服务，对于同一段视频，拿到不少于两份的网络视频数据。我们是用C++实现的，大家想用Java、C#都行，具体开发工具，视自己具体情况而定。但是有一点，一定要拿到TCP数据包的发送ID和确认ID，并以此作为网络视频数据定位到视频文件的偏址，空白处用缺省值填充。

    由于我们拿到不少于两份的网络数据数据，并且每份视频文件又是同一结构，剩下的工作就好办了，顺次比较这些文件相同位置的内容。若相同，则通过；若不同，取非缺省值。（还可有更好的容错策略，但考虑到实际情况，网络传输确有丢失，但是两个独立的TCP传输，丢失同一数据包的概率只怕只有彗星撞地球的概率，与此相当。但是大家可以有精益求精的精神，再来完善这个容错策略。）

    “乒乓”前行的一个核心就是：用我拥有的来补充你所没有的，用你所具备的来完善我所缺失的，共同完成一个无缺失的完整体。

    我们之所以这么关心完整性，这就要回到我的标题中来：“乒乓”前行策略在还原高清视频网络数据的应用。就目前的情况来看，拿到有损的视频数据是容易实现的，但是要做到无缺失就难了。所以这里就是一个机会：只有能完成大家都想要，与此同时，还能比别人做得更好，那么这样的产品就有市场价值。其次，我们提到了高清，这是我所一直关注的。我们没有提“乒乓”策略在（普通清晰）视频的应用，不是讲“乒乓”策略不适用于它，而是（普通清晰）视频内容不具备像高清一样的价值，这就是我们的着眼点。
   
    任何指正，联系邮箱： [e-mail]