来讨论一下视频处理的计算机速度问题吧
年前买了DV，又装了一台新机器来做视频处理，配置大抵如下：CPU: P4 4.0 （超的）
Mem: Kinston DDRII 667 2G
HD:Seagate SATA 200G+320G
目前用下来，发现ULead10不能把CPU用满，不知道瓶颈出在哪个地方:(
操作系统中我没有用任何硬盘空间做页面交换，全用内存。ULead开起来吃的内存也不算高，昨晚看系统缓存已经用到了1.6G，也就是说我的2G内存全用上了(加上内存分配)，读写硬盘的频率似乎也不算高，是哪里花时间呢？
这里头好像有很多人都有视频处理的经验，大家一块儿来讨论讨论吧，为我们以后节约时间。 我猜原因是windows的时间分配器（scheduler）不把所有空余资源都用上。内核调优在windows上怎么弄我不清楚。linux应该可以。
另外，Ulead可能也不把所有超线程都用上。我用virtualdub压，它的XViD插件有使用多线程选项，不用时效率60%，用时90%。
另外你的应用中（ulead中）是否在汇编一级被手工优化过也很重要。 关掉超线程。
超线程一般只会起反作用 >关掉超线程。
>超线程一般只会起反作用
是吗？
但我在工作中，实测数据证明了超线程是有效的，不过是在我们自己的Linux平台下。
难道说Windows对超线程支持不好？ 我的Ulead工作起来是8条线程，理论上讲应该是有优化的。 我们在linux下测试结果正好相反 不谈测试细节光说测试结果是没有意义地~~~
基本说，多进程/线程对可以并行化的处理有帮助，对串行处理帮倒忙。
图象处理本质上可以并行化，但前提是软件设计人员把并行设计进去。
不管怎么说，windows除server版的版本进程管理肯定很中庸，经常因为一个
任务使整个系统都忽然慢下来，这很显然因为很多系统调用是不能被其他进程打断的。
好的进程管理需要低级调用具有可再入(re-entry)性，这种设计要从内核写起，
可再入性越贴近cpu越好。这样，当scheduler需要一个进程休眠另一进程继续，
那前者就能立即停下来给后者让路。不好的系统就不能保证前者能在任意执
行状态停，使得后者不能立刻开始。表现就是系统反应迟缓，占用不同资源的
进程不容易彼此让路。
不这方面讲linux也不太好，它的内核有不少操作地方是"单任务”的。能完全
保证需要开始的进程能在规定时间内开始是实时操作系统（realtime os）。 >不谈测试细节光说测试结果是没有意义地~~~
我说的意思是HT技术确实可以提高性能，当然前提是你的系统必须做并行优化。
这一点可能我们单位得出的结论和WP他们单位得出的结论不太一致，因此我想提出来。
mh，
至于你后面讲的这些，以我们自己优化Linux的经验来看，它在进程调度的效率上只能算是中下水准，不过如果系统内进程数目得当，并行计算效率提升还是可观的，所以说，它在并行支持方面也还是有一定适用范围，不能一棍子打死。
并行计算的性能提升牵扯到的因素太多，这方面也是我们近期研究的重点，由于Intel的内存控制没有集成到CPU内部，因此Intel非常关心Cache命中率，我现在这颗CPU是2M L2 Cache。包括他们给我们的一些性能调优软件，也有很多是把重点放在这个方向上，他们甚至提出采用CPU绑定的方式来减小Cache污染，以提高性能。
今天下午14:00，我正好要和Intel某部门谈合作事宜，其中一方面就是在我们的平台上，提供针对Intel CPU的优化方案，因为他们一直不满意自己的CPU实战性能。
扯得有点远了，还说视频处理，还说Windows平台吧，毕竟我现在只能用它。
除了并行方面我想还有其他因素，这两天我再看看关闭HT的效果。
过几个月等内存价格降一些，我还会把内存加到4G，但现在没有想清楚这些内存是用来做ramdisk划算还是都交给Windows管理(用作系统缓冲)划算，谁有这方面的经验？ 这么说罢，我们在2CPU的机器linux环境下打开超线程，跑两个耗费CPU的进程，于是，一个进程分配了CPU0的超线程0，另一个进程分配了CPU0的超线程1，长时间占用。而CPU1则完全休息。操作系统不能区分逻辑CPU和物理CPU。
于是我得出结论，关掉超线程，机器快一倍。因为没有逻辑CPU了，两个线程完全跑在两个物理CPU上，不用一个物理CPU在两个逻辑CPU中平均分时间片了。两个CPU都跑满总比一个跑满一个闲置快。
这个结论至少在运行的线程数大于1并且小于逻辑CPU数的情况下是正确的。两种极端情况，线程数是1，还有线程数正好等于逻辑CPU数的情况下例外（这个情况下，假定每个线程所需运行的时长一样）。 呃，我知道区别了。你说的单处理器，我说的是SMP的情况。老实说，单处理器的超线程情况我没有测试过。
也许是我的偏见，HT确实没什么用。想并行处理快，还是直接上双核或多核吧。还有多CPU。 有一点不同，我们测试过单CPU+HT和双Xeon+HT的情况，内核都是SMP。
其实关键就是你说的线程数目，如果不如逻辑CPU多，肯定不行。
双核现在值得用的是Core 2，我初步打算过一年换6700，今年不用的原因是太贵，一块CPU要4K，赶上我整机的价格了，而现在这块631只要515元，可以超到4.2G，目前当作P4 4.0用;)
不选P4 D8xx和 D9xx的原因是Cache不比631占优，而且发热量是个大问题。 操作系统里除了你的视频应用外还有几十进程/线程要跑，所以如果不作手工绑定很难控制线程数与CPU比值。视频转码时最大瓶颈是算法没办法自己优化，只能在各种参数之间选择试验。
这大概和我使用avisynth和virtualdub这种非商业软件有关，也许商业软件优化更好些。我做 去交错->改图象大小->XViD 的处理过程中，好的去交错算法要用30%CPU,改大小10,转XViD50%以上。如果不计质量，那大概XviD会到80%。这种方式，加内存不会有什么作用，因为磁盘IO不花什么CPU时间。
我用的常见的商业软件将DV文件转为mpeg4性能速度最快的是Nero Recode.比别人快30%
夏天一干这个我的房间就要开空调。 除了计算量很大的，其他的线程、进程基本上是Idle状态，不消耗什么cpu时间的，可以忽略。 >夏天一干这个我的房间就要开空调。
还好我买的是631，得益于65nm工艺，发热量还能够承受，用TT的火星九就能把超频的CPU温度控制在60度以内。
我目前问题也出在Xvid转换上，其他方面基本不占多少时间，这是大内存的好处。你说的去交错是什么意思？我不太了解。
>磁盘IO不花什么CPU时间
但是它会花费CPU的等待时间，而且有些情况下减少IO也确实可以减少CPU占用，比如在页面管理中，缺页中断肯定要耗费额外的时间。
其实我现在就担心这些多媒体处理软件自作聪明，硬要拿一块硬盘空间做缓冲处理，没有想到我已经给他提供了足够的内存。PhotoShop就是一个例子，不知道新版本有没有改善。 >除了计算量很大的，其他的线程、进程基本上是Idle状态，不消耗什么cpu时间的，可以忽略。
对！
所以mh大可不必在意那些系统中闲置的进程，除非数量太多。 去交错-->deinterlace
是这么拼写吧？ >去交错-->deinterlace
还是没有完全搞清楚这个东西，查了一下，感觉它是传统视频技术的产物，好像在我的DV上没有这个问题，不知道理解的对不对。
我压缩mpeg4格式时，有三个选项，包括上场优先、下场优先和基于帧，现在我都是选择帧的方式。 interlace就是隔行扫描（从电视遗传下来的）。隔行扫描的视频直接编码，会有一些难堪的黑色横条，尤其是在图像颜色变化的边界处。 DV机上的文件，除了直接注明的，一般都是有交错(interlaced,也叫隔行扫描)的，每一"帧"有两个"场"组成。你要是以后肯定用能处理交错的播放器看（VLC，电视机，还有别的什么）,那你就可以不走去交错这一步。但电脑上绝大多数播放器都是无交错的（progressive, u-interlated, 逐行扫描)，这样你要是看有交错的视频，那动的物体都会有个模糊边，定格时看有锯齿。这有个比较详细的网页 http://www.100fps.com/
去交错的过程就是把有交错的转成没交错的视频。这个过程看似乎简单但奥妙很多。最普通的办法是每隔一场就丢掉一场，或者平均一下，效果都不好。我找到的效果最好的是mvbob，产生的结果基本完全没有交错痕迹，但速度极慢，是一般去交错算法的1/15 - 1/20。其他的介于中间的有leakkerneldeint, tdint等供选择，比较见 http://heptium.sh.cvut.cz/~integra/deint/
（注意图中划线的地方和文字地方）
另外，要想完全保存含交错的视频的动作流畅性，那就要转成2倍fps的无交错视频(25fps->50fps)。可惜我家的DVD机+电视组合看不了50fps，所以我现在只转成25fps的逐行视频。
另外，我发现往硬盘上写3MB/s和0.3MB/s完成速度差不多，就是说写盘不是瓶颈，很可能
压缩和写盘是两个线程，并不互相撞车(至少对于virtualdub)。 我又活过来啦，可以继续讨论这个话题。
>电脑上绝大多数播放器都是无交错的（progressive, u-interlated, 逐行扫描)，这样你要是看有交错的视频，那动的物体都会有个模糊边，定格时看有锯齿。
这个我昨晚验证了一下，如果压缩时采用上场优先、下场优先，则定格时有锯齿，而采用基于frame的方式，则没有锯齿，但有一个虚影。
另外，测试表明Ulead在压缩xvid时，开启HT和关闭HT的时间耗费一致，一段全幅DV 6'40"的文件，需要5分二十多秒，百试不爽。 提到上场下场就意味着是隔行的.逐行是没有场的概念,只有帧 >提到上场下场就意味着是隔行的.逐行是没有场的概念,只有帧
那么我是否可以理解为：选择基于帧的方式制作xvid，则程序内部自动进行了去交错，而选择基于场的方式则未做去交错？ 不确定。我怎么用过ulead。 呵呵，看了大家的讨论，挺有意思。。。俺以前在国内某非编硬件公司做过一段时间技术支持，聊一下自己的一点看法：
视频编辑渲染运算，主要运算量消耗在特效渲染和输出重新编码部分，一般都是以层为单位叠加、衡量，比如四层、六层（包括素材层、特效层、字幕层等若干层，比较直观得说也就是非编软件中“轨道”的概念），当然广播级的非编都是指实时渲染（一般需要NLE硬件支持），无需等待，要求1：1甚至更高速度输出特效渲染结果，可以实时预览、浏览、修改、渲染输出。
专业的广播级非编系统，都配有硬件非线性编辑卡。配套对应的非编软件也做过一些优化，非编卡的硬件部分有专门的GPU和CPU，就象PS2游戏机跟普通PC玩游戏的差别，能够有效解决渲染过程中的运算瓶颈问题。
也就是说，其实真正的广播级非编平台的硬件配置并不是特别高，主要要求系统平台的稳定性和板卡兼容性，因为主要特效都是靠非编卡来运算，而有的非编卡其实很挑板子。
国内很多非编套机工作站，说白了也都是攒出来的，PC部分配置一般P4或者Xeron即可，如果真的想玩非编，与其花重金在机器配置上，不如踏踏实实上一块硬件的广播级非编卡，虽然价格不菲，但也比前两年便宜了很多，比如以前的主流之一的DPS Velocity非编卡，原来一块曾经卖到8w多，基于它的非编套机卖到2、30w，现在dps卡也就2w出头，加上pc部分，也就不到3w就能搞定，但这是真正的广播级标清非编工作站，1：1实时渲染，用起来爽得多。
http://www.ju35.com/images/upload/2007-09/24/1190599055967410.jpg
当然，随着后来PC性价能不断提升，CPU＋GPU＋IO的纯PC非编方式也逐渐流行起来，但从运行效率和稳定性方面，目前还是不能完全取代专业非编卡工作站的主流地位，而随着高清HD摄像机信号源的普及，数据量和运算量都有了平方级的增长，纯PC工作站跑起来依然吃力，更不要说胶片级电影特效以及其它特殊效果需求，还是需要有硬件卡的支持，之前好莱坞比较流行的王道特效装备是SGI的工作站。
一般电视台内部的工作网络，用上行、下行的光纤连接各个工作站、素材库、服务器、NAS等，存储需求包括各个栏目的片头、片花、广告、节目正片。。。一般标清信号级别的，存储量都在TB级以上了，随着国内的发展，很多省台的设备方面投入都超过了CCTV的水平，比如HN卫视。。。
http://www.bluebox.com.cn/Img/dx.jpg
至于软件方面，更多推荐avid、Vegas之类，个人比较喜欢Canopus的Edius Pro，康能普的视频编码器是我感觉最好用的。
电骡上可以搜索关键字下载：http://lib.verycd.com/2005/11/04/0000072940.html 啊，为了我3千买的DV机配3万块的非编器材？我还是以时间换价钱吧。
不过我趁机会问问，为什么同一段dv拍的的视频，我生成的25fps和50fps的avi视频文件（用xvid编码）大小差不多呢？我觉得帧速高一倍，文件即使经过压缩也应该大几成吧？
50fps比25fps的动作流畅得多，可惜有些设备上放不出来。 懒得打字，转点东东参考一下吧：
动态关键帧距（I-frame interval）
动态关键帧距是另一个XviD所具有的，在空间和画面之间获得最大平衡的技术。我们知道在视频压缩中不是每一帧都记录着全部的画面信息，事实上只有关键帧记录着完整的画面信息，而后续的P帧（P-Frame）仅仅是纪录下与之前一帧的差值。如果关键帧之间的画面变化很大，则会浪费宝贵的空间在P-Frame上；而加入把变化很大的那一帧记录在关键帧里，那么由于后续的帧不再有更大的变化，就可以节省P帧所需的空间。因此，根据画面镜头切换和运动幅度来变换关键帧的位置，对于视频压缩下的画面质量提高，就有着事半功倍的效果。 WK！
nick是干什么的，感觉是全能呀:-)
我见过你吗？
另，对mp2压缩算法有研究吗？它也有类似于关键帧的这种处理方式吗？ 见过，嗯，年初攀冰时候，还有几次前两年在白河，前一阵跟风总碰过一次面，msn nick.bj@hotmail.com。
已经5年多没接触视频行业，有非编的相关问题也可以咨询Ricar，他现在在台里作栏目，自己也有台PC，使用Vegas方面的实战经验比较丰富。
btw：流媒体方面，对算法方面其实也就是个一知半解，因为自己不是Coder，主要兴趣点还是在应用吧。
以前有朋友在国内作这方面行业的，不过很久没联系了，也不太了解现在技术发展。
风总也是作这个行业的，哈哈，他应该才是这方面的专家。 我记得I frame（还有B,P什么的）好像是间隔不变的，所以体积也该加倍。但现在想想大概是弄错了。 自从一年多前对比研究后，有人用C写了原来用python脚本语言写的一个很好的avisynth去交错模块，现在很好的去交错计算只用原来的1/20时间不到了！现在在我的2.8GHz机器上，把DV视频文件转换为xvid格式只用不到2:1的时间，而且质量远比以前号很好。
页:
[1]