| Roger Chen's profileLearningBlogLists |  Tools  Help |
|
|
11/30/2005 Helix DNA Producer 11已发布Helix DNA Producer 11已经可以在Helix Community上下载到了，但是看它的更新日志，发现相对Producer 10的改进非常小，不知道为什么当作一个大的版本发布。
New Features：
9/13/2005 DirectShow TV Tuning近期采集器方面问题不断。放在机房采集器上的采集卡和我们这边测试用的采集卡型号不同，测试出来没有问题的程序，传到机房后就出现各种奇怪的问题；也由于这个原因，后来干脆就停了机房一台采集器，我这边修改程序，然后直接上传到采集器测试，修改，再上传……
最后终于找到了问题所在，Helix DNA Producer（包括Real系列的Real Producer和Helix Producer）和Pinnacle的某一系列的采集卡存在兼容性问题。测试用的采集卡型号比较老，PCTV Rave系列的，和Helix DNA Producer相安无事，而采集器上的PCTV Pro系列的，由于驱动支持Stereo音频，导致了一系列的问题，要么是全部噪音，要么就是右声道是噪音，很少有左右声道都正常的情况出现。
顺便继续总结一下DirectShow调台的步骤：
另外保证DirectX的版本在9.0c以上即可，否则在调台程序退出，Producer调用前，Tuner的状态不会保存。 8/9/2005 通过Helix DNA Server进行直播Helix DNA Server的管理界面上不能直接进行直播的配置（注意，Helix DNA Server和Real出的Real Server和Helix Server是不一样的，前者是Real公司开放源代码出来的一个开源项目，而后者是商业产品，版权限制上不一样）。
另外，Helix Communication上有RMFF文件格式的较新版本，比我从Real网站上下载的SDK里的RMFF文件格式要新。 8/1/2005 DirectShow TV Tuner Tips(2)通过前文提到的步骤调台后，再开启Helix DNA Producer进行录制有可能出现暴音现象，即视频输入正常，但音频不正常。可以在Helix DNA Producer开始录制后再调台一次，这次音频就会恢复正常。
但是该方法总有美中不足的地方，即录制的前一小段总存在暴音，虽不影响正常观看，但给用户一个不太好的心理感觉。
目前发现的比较完美的做法是：
经过测试，这样可以消除暴音现象。 如果要分析调试DirectShow程序，可以试试DirectSpy这个程序，它可以通过GraphEdit来查看其他程序运行期生成的图。 7/12/2005 RDT格式资料我以前分析过RDT的格式，但是没有任何来自官方的信息，所以分析出来的格式只是够用而已。但是现在搜索了一下，由于著名的开源协议分析软件Ethereal在发布的0.10.11版本中已经加入了对RDT格式的分析（0.10.11中的格式解析还非常简单），并且有Real公司的人在更新这个解析代码，所以RDT的格式资料相当于有“官方版”了。
可以访问Ethereal的SVN获取最新的解析代码：http://anonsvn.ethereal.com/ethereal/trunk/epan/dissectors/packet-rdt.c
RDT的基本分析可参见我以前的Blog：
7/6/2005 Microsoft Media Service Tips在RTSP生成的SDP文档pgmpu:data:application/x-wms-contentdesc属性中，记得将WMS_CONTENT_DESCRIPTION_PLAYLIST_ENTRY_URL设置为真实的URL地址，否则在数据发送完毕后，Media Player还会认为数据没有接收完毕，会出现缓冲等待。
这个该死的地方耗费了我三天的时间，抓包、分析、更改、继续尝试……
觉得俺最近干的活还真是辛苦啊，象MSN协议、Real/Microsoft流媒体协议分析这些都是靠猜的，每天都在玩找规律的游戏…… 6/28/2005 Helix Server Tips
Helix Server对RM系列文件支持的非常好，不管设置为多大的下载带宽，都不会出现问题。但是对非RM系列的文件，早期的Helix Server支持的最大下载带宽有限，最多不应超过Real Player中的“10M带宽”的设置，即10*1024*1024，如果超出该带宽进行下载，则可能出现发送了一定的数据包后停止响应。 最新版本的Helix Server（9.06）已经修复了该问题，但是在早期的Helix Server（9.02）上测试该问题仍然存在。因此建议下载早期版本Helix Server上非RM系列的流媒体，下载带宽不应超过10*1024*1024。
在发送第一个OPTIONS命令时，User-Agent的不同可能引起随后生成的SDP文件的不同，尤其针对非RM系列的流媒体。 根据目前的检测，Helix Server会检测User-Agent中是否包含“RealMedia”字段，如果包含，则按照RealMedia的Agent进行处理，否则会认为是未知的User-Agent，在随后DESCRIBE中生成的SDP会有所不同，可能导致一些奇怪的问题，如时间总长度判断错误等等。
用于判断客户端类型，在服务器端可以限制只运行某些类型的客户端访问，如只允许Real Player Plus用户访问等等。该字段就是用于确定客户端类型的。 6/24/2005 ASF流化基本流程
遵照RFC 2326 10.12节，Channel Id常为0，后跟整个RTP包的长度。
遵照RFC 3550 5.1节，其中sequence number字段从RTSP协议的RTP-Info属性的audio seq开始，依次递增；timestamp字段来源于负载的ASF Data Packet的Send Time属性；SSRC属性为任一随机生成的固定数。
第1-2字节 尚未确切明白其用途，第一字节的首位表示该负载是否包含了关键帧，因此如果包含关键帧，则常为C0 00，否则常为40 00。 第3-4字节 整个RTP包负载长度，包括第1-4字节。 其余 ASF Data Packet，但是对文件中的ASF Data Packet做了一些小的修改，去掉了padding data，加入了packet length，详细可对照ASF Specificaition 5.2节。 如文件中为： 82 00 00 09 5D 01 00 00-00 00 00 00 则流化后变为：82 00 00 41 5D EE 05 00 00 00 00 00 00 （红色为Error correction data，蓝色为Payload parsing information） 文件中09表示存在着padding data，01代表padding data长度为1；流化后41表示不存在padding data，但存在packet length，EE 05表示整个RTP包的长度为1518字节。 6/22/2005 高速流媒体下载一般情况下，流媒体服务器根据请求内容的比特率来确定传送速率，这样才能充分服务于多个用户。但是大部分的流媒体服务器也可以通过配置来提高传输速率，这个功能对于在线观看意义不大，但是对于下载观看而言的确可以缩短等待时间。 对于Helix系列服务器而言，客户端可以通过SET_PARAMETER命令，加上SetDeliveryBandwidth属性来设置传输速率。如：
上面设置带宽为整型的最大值，即代表以最高速率传输。 服务器端可以在服务器设置中选择连接控制，更改最大带宽来限制服务器使用的带宽。 对于微软流媒体服务器而言，客户端可以通过PLAY命令，加入Speed属性来设置传输速率。如：
上面设置Speed: 10即是以10倍的速率传输。 服务器端可以在发布点属性中选择“限制”－“限制内容传递速率“中更改最大传递速率，默认值是5，即最多可以超过5倍的速率传输。 另外在Microsoft Media Service 9系统中，增加了”快速启动“这一功能，其实就是在开始的时候以很高的速率传递，等到缓冲了一部分内容后开始以正常速率传递，降低了客户端的等待时间，该项可以通过X-Accelerate-Streaming属性来设置。 6/21/2005 Microsoft media service 9 SDP analyse其实在几个月前就已经分析过Microsoft Media Service 9系列的SDP格式以及微软的ASF文件格式，可是中间公司放弃该项目，现在重新拾起，忘也忘的差不多了，好记性不如烂笔头啊…… 准备工作就不详细叙述了，起码得了解啥是SDP（基本上RFC 2327就可以了，RFC 3266是支持IPv6的更新版），或是简单了解在RTSP中SDP的应用（RFC 2326 Appendix C）；对ASF格式有一个大体的认识（ASF Specification）；最好从微软网站下载ASF Viewer用于对照查看。 微软Media Service 9对RTSP和SDP规范支持不错，但是稍微在SDP上做了一点点的修改，SDP中本来规定的是a属性不能分别出现在t属性的两侧的，但是微软单独将a属性中maxps提到了t属性前面，如下所示：
所以如果是严格针对标准SDP协议写的解析器，在这个地方可能要稍微做一些修改。 以下是一些名称所代表的含义： b=AS:value：value代表bitrate，单位kbps，如b=AS:310代表比特率是310kbps a=maxps：Max packet size，每个包负载信息的最大长度，如a=maxps:1444代表包负载信息最长为1444字节 a=range:npt=value1-value2：value1代表preroll，缓冲时间，value2代表duration，持续时间，如a=range:npt=3.000-13.007代表缓冲3秒钟影片后开始播放，影片总长度是13.007秒 a=pgmpu:data:application/x-wms-contentdesc：后面带有内容描述信息，包括ASF规范中Content Description Object中所带信息，以及当前Media Service的一些环境变量，按健长度,健,值类型,值长度,值,这种格式划分开。如
可以划分成：
目前发现的值类型有两种，31代表字符串，3代表整型。 a=pgmpu:data:application/vnd.ms.wms-hdr.asfv1：BASE64编码字符串，包含ASF规范中Header Object以及其内嵌对象，包含Data Object。客户端可以通过分析该字符串得到整个ASF的信息，非常重要。 其余属性都是SDP中定义的标准属性，参照SDP规范即可。 6/13/2005 DirectShow TV Tuner Tips
MSDN中相关示例的步骤是
这种方法的缺点是如果某程序正在使用Tv Tuner，比如Helix Producer正在采集视频，则第4步无法生成整个图，在第5步中也无法查找到IAMTVTuner接口。 一种简单的改进步骤是：
这种方法并没有生成完整的图，所以在第四步查找的时候第一个参数应该赋为NULL，这样才能搜寻到IAMTVTuner接口
IAMTVTuner提供了一些方法用于切换频道，切换信号来源（天线/有线）等等，但是并没有提供方法用于微调。 DirectX中唯一提到了微调的文档列举了一种通过注册表来进行修改的方法，通过改变注册表中的值来达到微调的目的。这个方法比较简单，但是其不足的地方就是更改是全局性的，无法针对单个程序来进行调节。 我发现通过Windows Driver Development Kit中的文档可以来针对单个程序进行调节，可参照示例http://www.codeproject.com/audio/DShowFineTVTuning.asp
如果在运行采集程序前先调节频道，则Helix DNA Producer 9.x版本会忽略频道的调节，直接使用默认频道；而Helix Producer 10.x版本则会使用调节后的频道，但是音频无法正常采集。Window Media Encoder则由于兼容问题未在测试范围中。 出于最大兼容性的考虑，调台程序应该加入一延时调节选项，延时若干时间，等采集程序真正运行后才开始调台，这样才能正常的采集音频和视频，同时最大程度的兼容现有的若干采集程序。 6/3/2005 DirectShow进行时一不小心就进入了一个新的领域：） 使用Helix DNA Producer从电视卡采集模拟信号有一个非常大的问题就是无法通过命令行参数来换台，如果是某些芯片的电视卡，如BT8xx这类的还有其他的软件可以解决，如WinTvCap，通过这类软件可以先转换到某个台，再调用producer进行采集；但是其他类型的电视卡的话，就无法进行类似的操作。 实际上Helix DNA Producer是支持通过DirectShow TV Tuner来进行频道转换的，如在基于Helix DNA Producer的Real Producer和Helix Producer的界面中，可以选择DirectShow TV Tuner，调台，再进行录制，但是在其提供的命令行程序中并没有提供该参数的选择。 我首先考虑到的是采用Helix DNA Producer的ActiveX控件，看看其是否提供了换台的函数。非常可惜，其仅仅提供了
这么几个函数，并没有实现换台操作，也没有将内部持有的实例返回给我。 于是想到了非常取巧的方法，在LoadVideoDeviceDialog前另开一个线程，该线程就是查找系统的DirectShow TV Tuner设置窗体，然后模拟发送一系列的消息给该窗体，相当于一位用户“手工”换台。目前这个程序已经通过了，但是美中不足的是弹出这个对话框实在是比较不雅，虽然时间非常短。 我原本没有想到过通过DirectShow编程来直接操作，因为在Helix DNA Producer的文档中有这么一段：
不过实践中发现，如果先通过DirectShow换好台，播放再关闭，这时通过Helix DNA Producer录出来的就是换台后的节目（但是录完该节目后，再进行录制，就会变成默认台）。即默认情况下，Producer录出来的是：默认台节目、默认台节目；如果通过DirectShow换台后再进行录制，录出来的是：换台后节目、默认台节目。 于是花了两天的时间研究DirectShow，找到了不少资源：
目前已经有了不错的进展，估计再过两个工作日，这个比较完美的换台程序应该OK了。呵呵，一不小心掉进了DirectX这个泥潭，在爬上来之前，总得捞点什么东西回来：） 5/23/2005 Video Capture Information3/9/2005 Real Player 10.x的BugReal Player安装完成后，默认是自动设置网络，Real Player所有版本的默认网络传输规则都是：
如果执行前一条规则后在若干秒内未收到数据，则自动转向后一条规则。 可是Real Player 10.x会在访问时先建立若干UDP监听端口，即使服务器选择了使用TCP传输，它还是会使用第二条规则，由于收不到UDP数据，在Real Player中配置的Server timeout时间一过，Real Player就报告连接超时，关闭TCP RTSP连接。（可是在这段时间内，通过TCP已经收到数据并且正在流畅播放） 估计Real Player 10的兼容性测试只在Helix Server上进行过，根据Real Player 10.x的RTSP请求，Helix Server会优先使用UDP传输，所以Real Player 10在播放Helix Server上文件时是不会重现这个问题的。 这里有三种解决方法：
唉，用人家的玩意就是难搞定，现在调程序，居然得同时使用抓包分析工具和防火墙。抓包工具用于分析Real Player在不同的情况下发送的不同协议，自定义防火墙规则用来做Real Player逻辑覆盖测试。 这个Bug目前只在Real Player 10.x中出现，8/9/Enterprise系列（RealOne也归于9系列）都没有这个问题。 |
|
|
