怪怪 | Nothing, Everything

#1楼    回复  引用  查看    

第三个，如果这些ts文件本身就是连续的，被不明原因分成了几个，那么不需要做什么虚拟驱动器，只要做个SourceFilter就可以，我半天就能完成该任务。如果这些ts本身不连续，前一个ts文件尾的包数据和后一个ts文件头的包数据必然连接不上，想平滑太难了，我想向怪怪讨教下你打算如何做。

#2楼 [楼主]   回复  引用  查看    

我是这么打算的： 用插件式的方法选取不同情况下的插件来连接各文件， 先做出这个虚拟驱动器的框架， 然后配置哪些文件能连到一起， 特殊情况是什么。 比如TS本身是连续的， 仅仅是分成几个， 这样属于特殊情况。

如果TS本身是不连续的， 那么就经过插件处理，通过虚拟驱动器读盘时， 模拟成连续的。 至于两个不同的TS间如何统一， 属于特殊知识，放到插件内部处理， 咱不能处理也有能处理的不是？ ：） 唯一的问题是， 如果这种转化必须借助解码器的(这一块我没啥知识)， 恐怕效率不能接受。

另外像这个虚拟驱动器写盘时， 我希望做到的是连续的写一个文件时， 在底层也能自动按大小分割， 这样对于磁盘空间不够的用户， 就可以用几个盘的目录模拟成一个盘。所以我并不是完全针对TS， 而是所有这种需要分割， 需要合并的情况。

不过说实话， 同一个的TS分割成几个， 虽然是“特殊情况”， 但是却是最普遍的情况。 我的想法是提供这样一个统一的框架。 比如在网上下载比较大ISO什么的，地方不够用，这些； 所以我并不担心比如不同的TS链接时效率如何， 因为这种应用不是最广泛的， 留下插件接口只是为了最大限度的解决可以解决的问题。

你说的SourceFilter咋做呢？ 能不能详细的说一下，或者你就给做出来(示例也可， 我来完善)。 如果是解决同一个TS、AVI分割的问题， 只需要半天时间的话， 我觉得也是值得一做的。 因为据我了解， 那些高清坛上的用户还是很需要这个的， 也可以先按你的思路， 针对性的解决这个问题。

#3楼    回复  引用  查看    

我想了一下，几个文件无停顿或者至少短停顿的连续播放，靠一个虚拟驱动器是不够的，因为编码格式会有不同，比如一个mpeg2文件，一个h.264文件，从前一个切到后一个就必须停止播放，换解码器，继续播放，这种步骤省不掉的。
暴风影音之类的播放器切换文件时之所以会慢有两个原因：1是因为他们做了“销毁原有的graph, 重建一张graph”这样的操作，这种操作可以想象的是非常非常之慢，况且他们创建graph还是用Render File的方式，属于＊试错＊型连接，最坏情况下要把机器里注册过的所有filter都试一遍，所以看上去就更慢了。2是他们用的SourceFilter过于“强大”，加载文件的过程中就分析PMT，PAT表，还自带同步时钟，导致文件加载这一步就很慢。
其实Open File之类的api，从打开一个文件到打开另一个文件，速度是足够快的，甚至都快的让人不好意思了。慢是慢在分析PAT,PMT和重新连图这两步。我的想法是：1找一个短小精悍的SourceFilter,或者自己写一个，只需要基本功能就行，别随便给我分析这分析那的，不过还得附带读取到文件尾时自动跳到下一个文件头的功能 2但是PMT和PAT总得有人分析阿，所以在图中加入PsiParser filter，这个filter可以实时分析vid和pid，分析出来后由程序负责在Demux上动态map pid 3解码器一次性加全，有多少编码格式就加载多少个解码器，想要时间嘛，总得牺牲点空间 4切换文件不重新加载整个filter, 只要Demux之后的部分重新连接就可以。
采用这种方案的话，所有的事情都在DirectShow middleware层做，没有很多额外工作。同一个TS文件分割出来的文件列表的话，可以无缝播放，肉眼看不出来停顿。同一种编码方式的不同TS文件的话，不会停顿，最多换文件时有一到两秒的黑屏，这是可以接受的。不同编码方式的话，会停顿，但已经把停顿时间尽量缩小了，恐怕换解码器这种事情，无论采用什么技术都是没法避免的。
博主可以加我smn crazyender@hotmail.com ， 不过我白天都不上的。。

#4楼    回复  引用  查看    

还有一种是专门针对玩高清那批人定的方案，这些人的机器配置普遍不错，所以可以采用这样的方法：借鉴显卡中“缓冲翻转”的技术，一个性建立两个graph，一个为前端播放的graph，一个为后台准备的graph。第一个graph在播放的时候，第二个graph就可以在准备了。当第一个graph快播放完的时候，第二个graph开始偷偷播放，但不设置播放窗口；第一个graph真正播放完的时候，把播放窗口转给第二个graph。此时第二个graph变成主graph，开始正常播放；前一个graph变为后台graph，继续准备第三个。这样作确确实实属于无缝播放，而且和文件的编码方式无关，和各文件是否原本就连续无关。但是在一个文件切换到下一个文件的过程中，资源消耗会有一点大。

#5楼 [楼主]   回复  引用  查看    

"几个文件无停顿或者至少短停顿的连续播放，靠一个虚拟驱动器是不够的"

我想如果是一个文件直接分割的，肯定没问题。 关键是两个文件或者干脆编码格式不同的文件。 所以我说， 用插件的方式解决。 我的构想是这样的， 对于比如媒体类型的文件， 有专门的插件， 这个插件负责这样的工作(假设一个稍微复杂点的情况)： 比如第一个文件是TS， 第二个文件是AVI， 那么就装载一个AVI->TS文件流的部件，当播放器请求文件操作时， 它得到的就是“合并”后的那个TS中的Position。

我的想法是这样的方案在层次上有很好的分割， 所以可以一点一点的扩展： 最开始我们可能什么功能都没有， 就只能针对那种Copy /b可以合并的情况， 然后咱们就可以慢慢的扩展更丰富的功能。

你的想法我觉得也可行， 大不了让最开始变得更慢一些， 所有的都在最初准备好； 即使是你第二个方案， 也可以让第二个， 第三个文件处于暂停但是就绪的状态。 考虑到别人可能会有拖动的需求， 可能还非得这么做不可。

事实上， 我说的那种方式， 也肯定得做你说的这些工作， 不过我的想法是把这些都隐藏在插件中实现。 这样这个东西不止能解决媒体播放的问题， 也能解决任何大文件分块的问题。 尤其是如果这个东西用的人多了， 很可能变成一个比较通用的软件：

凡是有可能被分块传输的大文件， 可以直接写到这个虚拟盘(然后它就按照预先设定的大小分割并存在指定的目录中)， 然后对方用Copy /b就能合并， 如果不想合并， 也装这么个东西就直接读取了； 或者在下载文件时， 所有硬盘都没有足够的空间， 模拟成一个大盘， 存的时候就自动分配了。 同时， 通过插件扩展， 对已知的文件格式可以连接， 转换， 转换后链接， 等等。

只是这个虚拟驱动器解决不了刻录到多盘片的问题， 除非人家装了n台光驱 -__-。

#6楼    回复  引用  查看    

我现在了解你的想法了。其实我们讲的是同一个事情，不过我又陷入到细节的泥潭中了^_^ 看来我功力还不够，以后还得多多想你学习才行。

#7楼 [楼主]   回复  引用  查看    

@gussing
不能这么说， 分工不同...， 你会的那些我也搞不清楚的。 总得给我留个活儿干吧？

已经加你了， 有机会交流～

#8楼    回复  引用  查看    

好像没加成功。。
我的qq 110879298
email gussing@126.com
你的msn是多少，我加你好了

#9楼 [楼主]   回复  引用  查看    

我比较少上QQ的， MSN我给你发站内短消息了～