P2P流媒体概要
简单些一点P2P流媒体方面的东西吧，算是给以后的讨论打底子。所谓的P2P流媒体，字面上说就是用P2P的方式传输流媒体数据。有两个概念组成，P2P指传输方式，流媒体指传输内容。所以归根结底P2P流媒体要解决的问题就是特定目标流媒体的传输，如何用P2P的方式优化。P2P的方式，在于优化资源。何谓资源？带宽是资源，运算力是资源，各个节点的缓冲区也是资源。这些都是可见的，还有一些容易被忽略的资源，比如节点稳定在线时长，各节点间时延、带宽、TTL、物理距离和位置分布（包括相对位置分布和绝对位置分布），甚至可以据此绘制出全局路由表，可以在地图上绘制出节点大概位置。
P2P流媒体的最终目的就是通过资源的优化调度，使得数据块在适当的时间被适当的节点持有（或者说在适当的时间到达适当的地点），达到尽量多的节点能够流畅播放流媒体的效果。
P2P的流媒体可以细分为三种应用模式：直播、点播、下载。这三种模式是可以相互转化的。高性能的P2P文件下载技术已经很成熟了。点播的定义是可以Seek。如果只是切换频道，那不是点播，是轮播，在后面的直播中讨论。点播的实质就是可以使指定文件偏移位置的数据在一定范围内顺序到达，Seek的过程就是重新计算偏移量并重定位的过程。点播再进一步，取消Seek功能，但是对小范围数据块按时到达的要求更加强烈。下载和点播传输的都是静态文件中的数据块，轮播和现场直播传输的都是实时接入系统的数据片断。
很多人对P2P流媒体的优化专注在P2P传输方面，以满足以上需求。但是忽略掉了这个主体的另一个方面，流媒体。
P2P传输可以为了流媒体的特点优化，流媒体也同样可以为了P2P的优化。采用高性能的视频、音频编码算法，可以让P2P的传输压力极大的减轻。索引区块的优化可以让点播的Seek过程更加高效。特殊的数据打包格式可以加入跟随流同步的各类信息，比如字幕、当前播放场景的说明，甚至超级链接、广告、图片、程序动作等等任何你希望和播放区间同步的内容。把静态文件编码成为在网上传输的数据块集合，可以优化从读取文件到发送到网络的过程，如果索引也照此优化，就可以在Seek时直接取得数据块编号。下载、点播、轮播因为可以预先编码，可以使用计算复杂度高非实时的编码算法，而现场直播必须使用实时编码，所以前者理应获得更高的质量。
考虑p2p流媒体，可能需要更多考虑资源（存储、运算、传输）的成本趋势。
暂时写到这，只是把心里所想堆积起来，比较乱，而且在网络编程的论坛说了这么多流媒体编码方面的东西，不知道是不是算文不对题。反正大家凑合看吧。欢迎不同意见！ 以某vodserver机制为例，vod点播seek机制如下
客户端向vodserver提交一个播放请求
vodserver向客户端返回一个带有目标文件时间长度的sdp
客户端根据sdp信息播放目标流
sdp存在与目标内存，客户端seek时根据sdp上的时间信息提交给 vodserver，并指定播放时间，服务器根据客户端返回的时间信息 从目标文件中提取相应时间并返回客户
在p2p点播应用中，利用某个机制将当前众多客户播放时间进行交 互和目标时间的传递将是p2p点播seek机制的重点。 以某vodserver机制为例，vod点播seek机制如下:
1、客户端向vodserver提交一个播放请求
2、vodserver向客户端返回一个带有目标文件时间长度的sdp
3、客户端根据sdp信息播放目标流
sdp存在与目标内存，客户端seek时根据sdp上的时间信息提交给vodserver，并指定播放时间，服务器根据客户端返回的时间信息从目标文件中提取相应时间并返回客户
在p2p点播应用中，利用某个机制将当前众多客户播放时间进行交互和目标时间的传递将是p2p点播seek机制的重点。
我把所有多余的因素排除，考虑一个类似空管的飞机进场机制，把时间形成时间槽，第一个提出进场的飞机加入到时间槽，然后足步递增直到降落离场，所有的进场飞机在正常情况下都会在某一个时间槽内；如果其中某些飞机提出已经没油了，需要尽快离场，那么就按照这台飞机的剩余油量列入到合适的时间槽内以尽快降落。
如果使用这种方式，那么飞机将只会在到达时间槽时向空管提出告知，这样可以避免空管在和飞机通信中占用大量的电波通道，但是其结果是强化了空管的作用，空管在这其中是起决定性作用的，这样便与无中心的概念背道而驰!
可能在二棵树加三个字的算法上或许会找到出路吧，这样的思考将占据我大量的时间，而且很可能会毫无结果甚至误入歧途，为什么上天不给我一个可分布式的大脑？
页:
[1]