首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 其他教程 > 互联网 >

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

2012-09-25 
“乒乓”前行策略在还原高清视频网络数据的应用在前些日子,本人就讲过,要将“乒乓”前行策略和大家分享一下,但

“乒乓”前行策略在还原高清视频网络数据的应用
    在前些日子,本人就讲过,要将“乒乓”前行策略和大家分享一下,但一直都未成文,今日实现之。本应配以示意图,就更能清晰的说明问题,但试了几次都未能在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传输,丢失同一数据包的概率只怕只有彗星撞地球的概率,与此相当。但是大家可以有精益求精的精神,再来完善这个容错策略。)

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

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

热点排行