关于视频播放性能测试（MediaPlayer/realplayer/flash/……）

peaksoftchen

两个解决方法：
1、并发去下载视频文件，测试下载速度。
理由：播放视频是本地行为先下载，然后解码再播放，实际下载速度够了就可以正常播放，因此根据下载速度和码流对比就知道效果了。
2、并发播放，自己写程序。
一台主机创建多个播放器真正播放，实际程序没有多少，播放就是调用ocx控件，非常简单。

我在《LoadRunner性能测试实战》一书第八章中讨论了wmp播放器并发测试视频性能的方法，有兴趣的可以看看。
flash/realplay等都是标准空间，查API同理很容易实现。

amirfly

不错哈

LC_CIA

顶一下

正在关注你的书，想听听大家的意见

peaksoftchen

原帖由 LC_CIA 于 2007-10-18 16:11 发表
顶一下

正在关注你的书，想听听大家的意见

我的帖子半宣传书了。

确实是看到有人写了flash，但是讨论的很糊涂。。。。。。。

peaksoftchen

刚刚和一个朋友讨论，传言支持flash，大家可以自己试试看。

Zee

你实验了没有？支持flex的是哪个版本？支持的flex是哪个版本？

peaksoftchen

原帖由 Zee 于 2007-10-23 11:36 发表
你实验了没有？支持flex的是哪个版本？支持的flex是哪个版本？

刚才我和你老板打电话讨论的。。。。。。。
我也是听他说的。。。

peaksoftchen

我们现在自己开发了并发架构，自己重写了播放器来记录播放效果。

已经放弃lr来测试视频。我们需要真正的播放。。。

Zee

原帖由 peaksoftchen 于 2007-10-23 11:51 发表


刚才我和你老板打电话讨论的。。。。。。。
我也是听他说的。。。

他也不确定的。我现在在证实。
我以为你验证过了呢。

qiguojie

个人理解，参与讨论一下。

流媒体播放的性能测试，主要压力应在流提供端，也就是通常所说的源服务器（当然，P2PSTREAM主要压力在中继端服务器；这里的P2P STREAM 可以分为2种，一个是P2PSTREAM，一个是P2SPSTREAM）；

对应不同的复杂结构，测试的侧重点说相同也相同，说不同也不同。相同的是，同样测试大量数据获取时，流提供端（服务器及服务）各项性能指标；不同的是复杂的服务架构(多提供端等情况)，会导致测试跟随复杂设计，就是麻烦，呵呵。

对于楼主的并发播放测试，主要是测试播放器或者解码器本身的压力测试，一般对于普通的播放应用来说，下载的数据不会重复，既每次下载的序列包都不会重复，因此并发好像无从谈起；而且本身在各位进行视频播放时，不会有同时打开多个播放器看多个节目的吧？？画中画电视为什么昙花一现？

其他，P2PSTREAM的服务器端程序(也就是提供IP资源列表的服务程序)也有一定的压力，需要着重测试，而且是重点。同理，普通的流媒体播放服务(例如ms的wms)，在固定的硬件资源环境下，如果提交的请求够多，也会有处理的瓶颈。

欢迎批评指正。

wangyh

原帖由 qiguojie 于 2007-10-23 12:15 发表
个人理解，参与讨论一下。

流媒体播放的性能测试，主要压力应在流提供端，也就是通常所说的源服务器（当然，P2PSTREAM主要压力在中继端服务器；这里的P2P STREAM 可以分为2种，一个是P2PSTREAM，一个是P2SPSTREAM ...

说的挺好，你就原谅楼主的无知吧！

peaksoftchen

原帖由 qiguojie 于 2007-10-23 12:15 发表
个人理解，参与讨论一下。

流媒体播放的性能测试，主要压力应在流提供端，也就是通常所说的源服务器（当然，P2PSTREAM主要压力在中继端服务器；这里的P2P STREAM 可以分为2种，一个是P2PSTREAM，一个是P2SPSTREAM ...

对于楼主的并发播放测试，主要是测试播放器或者解码器本身的压力测试，一般对于普通的播放应用来说，下载的数据不会重复，既每次下载的序列包都不会重复，因此并发好像无从谈起可能我说的不大明白，绝对不是是对播放器或者解码器本身进行压力测试。主要压力应在流提供端没错，但是不是流提供端没有问题就行了，最终的目标是用户能看视频（这一点不管是不是p2p），我们需要测试一下系统效果以及用户的观赏效果。；而且本身在各位进行视频播放时，不会有同时打开多个播放器看多个节目的吧？？（并发的时候是每个播放器随机去播放频道，播放的节目可能会重复，这个与参数文件记录数有关系。这么做和lr的原理一样——实际中也不会一台主机打开上百个网页）画中画电视为什么昙花一现？不太理解为什么这么说？测试和实际总会有些差别


我的做法是是一台主机上模拟多个客户端来真正播放——每个播放器和一个peer绑定，用播放器向peer要数据，更接近真实行为，这种方法对于非P2P系统一样。这一点和lr一台主机上模拟多个用户原理一样。
不过存在的问题是一台主机只能模拟10个左右用户（CPU、带宽限制）。如果只用解码器要服务器要数据——实际根据解码速度基本就知道播放效果了，能模拟的更多一些。如果再配上限速工具，能稍稍接近一些公网测试。

我们项目测试时候的真正做法比这个还会复杂些，仍然会用lr来像服务器施加压力，但是lr模拟peer之间的行为就不能为力了，得写更多更复杂的程序，不亚于写个peer。

[ 本帖最后由 peaksoftchen 于 2007-10-23 13:31 编辑 ]

qiguojie

原帖由 peaksoftchen 于 2007-10-23 13:11 发表
可能我说的不大明白，绝对不是是对播放器或者解码器本身进行压力测试。主要压力应在流提供端没错，但是不是流提供端没有问题就行了，最终的目标是用户能看视频（这一点不管是不是p2p），我们需要测试一下系统效果以及用户的观赏效果。

我还是认为，如果单个用户播放效果是否OK，取决于码流数据提供的是否足够，当然，这是在2个前提下，一个是可以获取到足够的数据，另外一个就是解码器和播放器功能没有问题；个人感觉还是不属于性能测试范畴，也许我的理解有误区？？ 是否能取到足够的数据，可能和穿透以及带宽利用率等等很多因素有关，当然也可能和源(流提供端)的性能有关。

实际上我了解这些，是因为曾经为前一公司调研过这个性能测试的可能性，并且研究过一段时间，但是实际上公司最后没有实施，我的意见也是要自己开发对应的测试工具，公司嫌开销太大，呵呵。

[ 本帖最后由 qiguojie 于 2007-10-23 14:06 编辑 ]

peaksoftchen

原帖由 qiguojie 于 2007-10-23 14:01 发表


我还是认为，如果单个用户播放效果是否OK，取决于码流数据提供的是否足够，当然，这是在2个前提下，一个是可以获取到足够的数据，另外一个就是解码器和播放器功能没有问题；个人感觉还是不属于性能测试范畴，也许 ...

我这个帖子倾向于探讨：如何在实验室模拟测试公网上的视频点播系统。。。
单个用户播放效果几乎没有问题，对于P2P的根本没有P2P效果。
那测试意义就没有了。。。
我们在实验室能模拟到1000个左右的用户，借助100多台主机。
是真正的并发播放测试。。
然后还要限速什么的，以接近公网。

[ 本帖最后由 peaksoftchen 于 2007-10-23 14:23 编辑 ]

girl04

1、并发去下载视频文件，测试下载速度。
理由：播放视频是本地行为先下载，然后解码再播放，实际下载速度够了就可以正常播放，因此根据下载速度和码流对比就知道效果了。
2、并发播放，自己写程序。
一台主机创建多个播放器真正播放，实际程序没有多少，播放就是调用ocx控件，非常简单。
______________________________________________________________________
第2点非常赞同，我也非常成功地做到。
第1点我是做摄像头发过来实时码流的，不知道与普通的下载视频流有没有区别。
我想差不多。
我觉得单用下载速度和码流对比来证明能正常播放还是有所欠缺的。
A、你提到的解码程序、播放的效果是一个方面。
B、图像的流畅度和清晰度来说，我觉得最好还是通过并发一实时流，真实显示出来，用人眼去判断，才是最准确的。
当然弊端是人不能24小时实时监控。
另外，可以写脚本，实时监控并发流的平均码流数，可以反映一定并发量下，一定时间内的视频流播放质量。
如有不对，请各位,特别是楼主指出！
to 楼主，我的MSN有你，有机会讨论。哈哈。。。。

Jifucy1010

学习中

peaksoftchen

原帖由 girl04 于 2007-12-12 16:03 发表
1、并发去下载视频文件，测试下载速度。
理由：播放视频是本地行为先下载，然后解码再播放，实际下载速度够了就可以正常播放，因此根据下载速度和码流对比就知道效果了。
2、并发播放，自己写程序。
一台主机创建 ...

说的不错，并发下载是最土、但是也是最容易实现的一种方式。
相当于把问题用一种简单化一下，而且很容易做到。
呵呵。

kate1

留个脚印

xuyan_8707

大家都是用什么测试工具去做播放器测试的呢

monstergod

P2P可否理解为将码流当成文件，拆分成若干小文件，然后用户随机概率进行优先传输，然后在用户组中进行多方交换传输？
那么P2P的并发应该可以视为按照一定几何级数增加速度的传输过程，系统的压力应该主要体现在按照特定序列提供码流片段（服务器的文件处理能力），如果播放器是主动向服务器索取码流，那么播放器也会有成为瓶颈的可能，但是如果是等待服务器把码流发过来再进行本地解码的话，就不会成为瓶颈了。

我这里曾经使用Avalanche进行视频测试，但是主要是评估服务器处理能力，涉及系统瓶颈的不多