『漫游』酷论坛>『影音数码技术学习交流』>影音精华区>[原创]岁末争霸战----20 ..
[原创]岁末争霸战----2003年最强的视频编码
skywalker@2003-12-28 02:14
终于到年底了..........
今年以来视频编码的发展进入了百家争鸣的时代........
免费的视频编码越来越多..........
而且在压缩质量和效率上比原来也有所提高.........
这里就把最新的六种视频编码作出比较.........
它们分别是:
3ivx D4 4.5(MPEG4)
DIVX 5.11
RV9 新VBR 2pass
WMV9
VP6 6.0.9.2
XVID 圣诞版(patch -156)
要说的几点是, 没想到XVID再我测试刚好做完的时候就出了beta3, 不过只差了5各patch, 而有可能会影响结果的只有I-frame那, 不过应该区别不大.
VP6 终于改进了原来的2-pass和休整了bug, 现在终于可以和其他编码一搏了.............
其实本来还计划了一个片段的.........
不过因为花的时间远远超出了预计(一共花了5天时间)..........
所以最后一个就没做了...........
下面是测试用的设置:
全部的max key-frame interval 都是 10 sec
3ivx:
基本没什么可设置的
2-pass best quality
half-pel + 4mv
Divx使用的设置是:
performance/quality --> slowest
Bidirectional encoding on
其它的都是 off
n-pass, n>=3
Rv9使用的设置是:
EHQ=80
customPacketSize=16000
patternAdaptivity=1
MSL=60
使用了新的VBR 2-pass
Max bitrate 一般是 average的两倍
zoom and pan的MSL 改成了 5, low motion的改成了10.
WMV:
Maximum quality
decoder = Complex
2pass
10sec max I-frame interval
XVID:
motionsearch= Ultra high
VHQ=4
quant type = h.263
BF: 3/100/100
trellis = on
chromamotion = on
chroma optimizer=off
2 pass:
high bitrate scene=10
low bitrate scene=10
degration=5
improvement=5
over flow control=5
i-f boost=0
i-f reduction = 20
min i-f=4
这里在低动态的那个片段里的25%中因为无法接近设置的码率, degration改成了20.
VP6:
这里到后来才发现犯了个错误, 本来该使用 advance profile, 但使用了simple profile.
使用advance profile的话,PSNR应该会有0.1到0.3的提高.这个以后如果有时间再重新测试.
good quality<<用best quality的话速度就会由 帧/秒 变成 秒/帧 了....
VBR
progressive
quant= 2-31
2pass= 70/40/400
其他都是off
下面是测试的样板script:
3ivx:
fil=avisource("M:\avis\3ivx\3ivx25.avi")
org=avisource("ffv1.avi")
compare(fil,org,channels="YUV",logfile="M:\avis\3ivx\3ivx25.log")
divx:
fil=avisource("M:\avis\divx\divx90.avi")
org=avisource("ffv1.avi")
compare(fil,org,channels="YUV",logfile="M:\avis\divx\divx90.log")
RV9:
fil=directshowsource("M:\avis\rv9\rv990.rmvb",fps=29.97)
org=avisource("ffv1.avi")
compare(fil,org,channels="YUV",logfile="M:\avis\rv9\rv990.log")
VP6:
fil=avisource("M:\avis\vp6\vp690.avi")
org=avisource("ffv1.avi")
compare(fil,org,channels="YUV",logfile="M:\avis\vp6\vp690.log")
WMV:
fil=avisource("M:\avis\wmv\wmv25.avi")
org=avisource("ffv1.avi")
compare(fil,org,channels="YUV",logfile="M:\avis\wmv\wmv25.log")
XVID:
fil=avisource("M:\avis\xvid25.avi").trim(1,0)
org=avisource("ffv1.avi")
compare(fil,org,channels="YUV",logfile="M:\avis\xvid25.log")
这里是测试结果的表格:
http://www-personal.umich.edu/~liusu/test/results.xls
如果没有M$ office的话, 只有看图了
http://www-personal.umich.edu/~liusu/test/spreadsheet.png
先讲解一下各个测试的作用.......
Average PSNR= 平均峰值信噪比
作用是测量一个视频编码在一定文件大小下和源文件的差别的平均值
这个越高画质就越高
Overall PSNR = 全局峰值信噪比
作用是测量一个视频编码在一定文件大小下和源文件的差别, 还考虑PSNR的连续性.........
和平均峰值信噪比相比, 如果有一个10dB和90dB的帧, 那平均峰值信噪比就是50, 而两个50dB的帧的平均峰值信噪比也是50.......
很明显两个50dB的看起来要好得多, 因为10dB的帧看起来可以说和原来的是完全不一样了, 即使有一个90dB的, 但那个烂的帧会让人觉得总体的画质低下. 而全局峰值信噪比则考虑到了这一点..........
峰值信噪比的数值的变化越小, 数值就越高..............
一个视频编码本身的压缩能力决定了平均峰值信噪比.........
但它的流量控制(rate control)却是它全局峰值信噪比 高低的关键..........
下面的rate control就是用全局峰值信噪比/平均峰值信噪比 x 100% 得出来的, 从这里可以看出一个视频编码的2-pass(或n-pass)的性能.
因为测试的东西太多........
我不可能用人眼来看谁好谁差了............
所以暂时只有依靠PSNR来判定了............
这里文件大小的100%是用xvid quant 2 来决定的........
之所以最高用90%, 就是为了测试xvid的流量控制能力........
第一个片段是使用的gundam seed的第一个op
使用的avs sript是:
import("D:\aviutil\aviutilfilters.avs")
mpeg2source("seed.d2v",idct=7)
converttoyuy2()
ConvertYUY2ToAviUtlYC()
AU_wavelet3DNR2(2,0,20,0,20,20,20,20,20,20,5,0,0,0,0,10,false,true,true,false,false,false,false,false,false,false,false,false,true,true,false,false)
ConvertAviUtlYCToYUY2()
converttoyv12()
warpsharp(bump=100,depth=96,blur=3,cubic=-0.6)
undot()
因为这个script很慢....
所以转成了ffv1的avi来做测试.........
在高动态的情况下, 光看平均psnr的话, RV9是最强的......
不过RV9的2-pass性能似乎不太理想..........
在overall psnr里面的领先在80%的时候被XVId超越了........
不过在这个测试里面, RV9是明显的胜利者............
只有在高码率的情况下XVID 才会胜出........
VP6在中低码率的情况下表现相当不俗.........
再进入高码率后就不行了............
Divx5.11似乎比XVID差了一点,几乎平行, 毕竟都是mpeg4的codec.....
不过,同样是mpeg4的3ivx的表现就相当差了.........
average psnr和overall psnr都殿底了........
MS的WMV9似乎还老当益壮......
实力和xvid 不相上下, 但相对与RV9就差了不少............
第二个片段是使用的12国记的op:
用的script:
mpeg2source("123.d2v",idct=7)
trim(0,2280)
这里完全是镜头的动作,横移,拉近,拉远.........
这里面XVID基本上是所向披靡.........
除了在低码率下被RV9和WMV击败外.............
overall psnr 在大部分情况下都远远超过其他codec.........
这个片段的前半对码率的需求相当低, 而后半对码率的需求比较高.....
这对2-pass是一个很好的考验.............
从这里来看..........
xvid的2-pass的rate control(流量控制是相当优秀的)..........
而divx的n-pass也不错, 虽然在average psnr 中差点殿底, 不过在overall psnr中总算搬回一成, 缩短了和其他codec的差距..............
这里要注意的是wmv在低码率下超过了设定码率 20%以上.........
所以实际PSNR应该更低...........
第三个片段是用的12国记第8话一段比较暗,动态低,但背景有不少缓慢移动的灰尘的场景(DVD的chapter 2)
mpeg2source("123.d2v",idct=7)
trim(301,4080)
这里首先要说的是WMV好像并不喜欢这一段场景...........
在2nd pass里老是出错退出..............
我花了半天时间, 始终无法弄明白是什么原因...........
始终无法压出25%大小的wmv..........
在低动态下, RV9继续保持无敌性..............
无论是overall psnr还是average psnr.........
RV9都是绝对的胜利者............
DIVX和XVID的表现相当相似..........
不过XVID在高码率下胜出.........
VP6在最低的码率下仅次于RV9(虽然差了很远)............
在高码率下表现不佳............
WMV在90%的时候的文件大小超出了设置大小很多..........
不明白为什么会如此............
而3ivx在25%的时候居然超出了设定50%以上..............
所以实际应该会低与xvid和divx的...........
关于压制的速度......
3ivx是最快的.................
然后是vp6 simple.......
vp6 advance和xvid的速度大概差不多........
不过xvid有fast first pass(beta 3 还有了turbo mode), 所以速度应该快与VP6..........
剩下几个应该就是慢了一个等级的了.........
Rv9因为也有fast first pass, 所以速度在vp6之后..........
而WMV9和DIVX5.11的速度就是有XVID或VP6的1/7-1/10了......
当然两个可以使用更低的精度来提高速度, 不过在画质上就会差更远了............
似乎到这里就是完了............
因为测试的数量太大........
所以多半有一些错误........
希望大家看到后能指出来................
哦......
还没说哪个最强啊............
如果要质量的话.......
应该是选RV9吧...........
如果觉得RV9太慢............
就使用XVID吧.............
bestword@2003-12-28 03:06
偶想问一下为什么XVID的quant type是h.263而不是MPEG
skywalker@2003-12-28 03:35
引用
最初由 bestword 发布
偶想问一下为什么XVID的quant type是h.263而不是MPEG
因为h.263的dct 噪讯比较小..........
对于动画来说比较好...........
cscscscscs@2003-12-28 10:44
可以介绍一下3ivx是什么东西吗？？之前一直没听过这个codec……
lhhluo@2003-12-28 10:52
在doom9那里看到vp6的测试结果
和你的测试结果不大一样啊
66666@2003-12-28 13:55
引用
最初由 cscscscscs 发布
可以介绍一下3ivx是什么东西吗？？之前一直没听过这个codec……
应该是最早的MPEG4吧，网上很多电影都是这个格式
cscscscscs@2003-12-28 14:40
引用
最初由 66666 发布
应该是最早的MPEG4吧，网上很多电影都是这个格式
最早不是divx3吗？:confused:
小鬼@2003-12-28 19:57
谢谢楼主怎么多的介绍！！
其实我也不知道什么最好~~
我是全都装的！！
不知道算不算真确！！！
给点建议吧·！
skywalker@2003-12-29 00:30
引用
最初由 lhhluo 发布
在doom9那里看到vp6的测试结果
和你的测试结果不大一样啊
doom9上的不一样........
原因1: 他用的不是动画.........
原因2: 他的vp6用了PP, 而其他的没有用.............
我全部都没用pp, 因为xvid和divx都可以用ffdshow来读, 而ffdshow可以用avisynth, 所以用PP的话, XVID和divx会比较强. 我的测试中xvid只是随便用了一个滤镜PSNR就上升不少
abcbuzhiming@2003-12-29 01:22
这东西不是为我这种人准备的，太深奥........
Re: [原创]岁末争霸战----2003年最强的视频编码
Silky@2003-12-29 06:45
引用
最初由 skywalker 发布
第一个片段是使用的gundam seed的第一个op
使用的avs sript是:
import("D:\aviutil\aviutilfilters.avs")
mpeg2source("seed.d2v",idct=7)
converttoyuy2()
ConvertYUY2ToAviUtlYC()
AU_wavelet3DNR2(2,0,20,0,20,20,20,20,20,20,5,0,0,0,0,10,false,true,true,false,false,false,false,false,false,false,false,false,true,true,false,false)
ConvertAviUtlYCToYUY2()
converttoyv12()
warpsharp(bump=100,depth=96,blur=3,cubic=-0.6)
undot()
抱歉和 skywalker 兄討論一個題外話，這個 script 裡面用到 Wavelet3DNR2，skywalker 兄有開啟橫 512 以上時 4:1:1->4:2:2 補間的選項，這個選項開啟之後，如果橫軸分辨率達到 512 以上，會做 4:1:1->4:2:2 補間，這樣會造成色彩的部分有很大的瑕疵。
您找一個紅色的球形物體來看，會發現原本平滑的紅色邊線會出現垂直一條一條，不平整的紅色細線，同時色塊的現象會更明顯。
如果不勾選這個選項，Wavelet3DNR2 會用 4:4:4->4:2:2，平均兩個 chroma sample，情況會好很多，不過對色彩部分的改變還是很大，尤其是紅色的部分，非常容易看出來。
您可以找有紅色圓形物體的影片做一個實驗，相信只要看過一次，注意到這個現象，您就會不想用 Wavelet3DNR2 了 :p
但是 Wavelet3DNR2 降噪的功能很強，不用好可惜，我想可以用下面的方法解決，就是只用 Wavelet 處理 Luma 的部分，Chroma 不要處理，或者交給其他 filter 處理。
wavelet=source.Greyscale() # <- 把 source 用 Greyscale() 處理，只留下 Y-channel
wavelet=wavelet.ConvertYUY2ToAviUtlYC()
wavelet=wavelet.AU_WAVELET3DNR2(2,0,10,10,0,0,0,0,0,0,5,0,0,0,0,10,false,false,true,false,false,false,false,false,false,false,false,false,false,false,false,false)
wavelet=wavelet.ConvertAviUtlYCToYUY2()
source=MergeLuma(source, wavelet, 1.0) # <- 將 Wavelet3DNR2 處理之後的 Y-channel 覆蓋回原本 source 的 Y-channel，保留原本 source 的 Chroma 不變
這樣就可以避免 Wavelet3DNR2 造成的色彩瑕疵。
由於人眼對 Luma 亮度的噪訊比較敏感，所以保留 Chroma 不處理通常也可以接受，或者用其他 filter 對 Chroma 做處理，最後用 MergeChroma 合併回 source。
source=MergeLuma(source, wavelet, 1.0)
source=MergeChroma(source, other_filter, 1.0)
或者，用另一個方法，把 UV copy 到 Y-channel，然後用 Wavelet3DNR2 對 Y-channel 做處理，處理完畢以後，再把 UV copy 回 U, V-channel。
u_chroma=UToY(source) # <- 把 U copy 到 Y-channel
u_chroma=u_chroma.ConvertAviUtlYCToYUY2()
u_chroma=u_chroma.AU_WAVELET3DNR2(2,0,10,10,0,0,0,0,0,0,5,0,0,0,0,10,false,false,true,false,false,false,false,false,false,false,false,false,false,false,false,false)
u_chroma=u_chroma.ConvertAviUtlYCToYUY2()
v_chroma=VToY(source) # <- 把 V copy 到 Y-channel
v_chroma=v_chroma.ConvertAviUtlYCToYUY2()
v_chroma=v_chroma.AU_WAVELET3DNR2(2,0,10,10,0,0,0,0,0,0,5,0,0,0,0,10,false,false,true,false,false,false,false,false,false,false,false,false,false,false,false,false)
v_chroma=v_chroma.ConvertAviUtlYCToYUY2()
filtered=YtoUV(u_chroma, v_chroma) # <- 把 U, V 從 Y-channel copy 回 U, V 各自的 channel
source=MergeLuma(filtered, source, 1.0) # <- 將原本的 Y 和 filter 之後的 UV 合併
結合以上的方法，就可以用 Wavelet3DNR2 對 Y, U ,V 三個 channel 分開做處理，不過這個方法很慢，非常慢，不建議使用 ^^;
lady@2003-12-29 07:52
个人觉得,这种类似的比较很是没意义的
基本上,主要一点,压不同的VIDEO,相信大家都不会用一样的FILTER,不一样的SETTING....
CODE自身带的简单的SETTING,很多都可以由第3方软件实现的,包括B,P,I-FRAME的设置,而对于整个VIDEO完成后的效果影响最大的,基本就是前期的处理,至于CODE用哪个,基本都是差不多效果的,1-10%的压缩比差距,对于一个24分钟的200M动画来说,也仅是2-20M而已(而我看到的CODE的压缩比差距,似乎没有到10%呢^^)
至于选用哪个CODE,个人觉得既然压缩比差别不大的话,应该选用稳定,兼容性好,质量高的CODE
个人偏爱WMV9,原因也很简单,WMV9有中水到渠成的感觉,虽然压缩时间比较长(虽然很多人说只长一点,而我发现的确是比DIVX/XVID用多了50%的时间),但基本不用重压,CODE里面的简单设置已经比较合理,用1PASS出来的效果也很好,想呀更高压缩比的,就做2PASS,更甚者,用第3放软件直接调B,P,I-FRAME的比例,更加深入的,连FRAME的矩行图也可以手动编辑....相对地说,如果其它SETTING多的CODE,第一次出来效果不满意,要压第二,三...次的话,时间也就耗了
特别要说说的是,XVID的API4真的很不稳定,举例,POPGO废弃的DVDRIP,用1.0 BETA2会提示B-FRAME破损,用1.0BETA3会屏幕180度翻转了...
看来,如果不改善的话,我以后看XVID的动画片,要换装3个以上的XVID版本才行了....
上帝报佑我的WINXP的注册表不要那么脆弱,一天看几个动画,换几次CODE版本就坏了才好
Re: Re: [原创]岁末争霸战----2003年最强的视频编码
skywalker@2003-12-29 08:55
引用
最初由 Silky 发布
抱歉和 skywalker 兄討論一個題外話，這個 script 裡面用到 Wavelet3DNR2，skywalker 兄有開啟橫 512 以上時 4:1:....................
多谢Silky兄的指点.......
把chorma当luma处理的那个方法真的是太强了..........
没想到可以这么用的^^...........
好在这个地方并不会影响到测试结果............
下次压的时候一定会试试这个方法.........
红色的球实在不好找.......
看来得自己画一个了..........
引用
最初由 lady 发布
个人觉得,这种类似的比较很是没意义的
基本上,主要一点,压不同的VIDEO,相信大家都不会用一样的FILTER,不一样的SETTING....
CODE自身带的简单的SETTING,很多都可以由第3方软件实现的,包括B,P,I-FRAME的设置,而对于整个VIDEO完成后的效果影响最大的,基本就是前期的处理,至于CODE用哪个,基本都是差不多效果的,1-10%的压缩比差距,对于一个24分钟的200M动画来说,也仅是2-20M而已(而我看到的CODE的压缩比差距,似乎没有到10%呢^^)
至于选用哪个CODE,个人觉得既然压缩比差别不大的话,应该选用稳定,兼容性好,质量高的CODE............................
RV9的vbr使用比较复杂(其实也不复杂,花半个小时就可以学会写job file), 也许你不爱用,用wmv我也可以理解...............
自己喜欢用的codec无法在测试中表现不佳, 觉得很没有意义也是正常的............
不过关于你xvid解码的问题, 用ffdshow就可以了, Xvid自带的还不是很稳定, 你如果看change log, 就会看到里面加了很多东西, 然后也有不少bugfix, 都是新加进去的东西产生的..........
如果用ffdshow还有问题, 那么只能是你电脑的RPWT了.........
如果要说到兼容性, 怎么看也是mpeg4的兼容性比较好........
软件硬件的decoder都有一大堆...........
wmv9的软件decoder我只看到一个...........
硬件的我还没有看到........
就稳定性而言, 压低动态的时候老是出错退出.......
我重装了VCM的codec,也重新启动了电脑........
如果不是我RPTW的话就只能是MS软件的bug了........
Silky@2003-12-29 09:48
引用
最初由 lady 发布
至于选用哪个CODE,个人觉得既然压缩比差别不大的话,应该选用稳定,兼容性好,质量高的CODE
不管压缩比，光比质量的话，XviD 使用 MPEG quantization，自订量化矩阵，无疑是目前质量最高的。
只要你用高质量的量化矩阵压缩过一次，亲眼看到 MPEG-4 能够压出来的超高质量，保证以后低码率的东西你根本看不下去 :D
因为现在大家都习惯看 NR 很重，把所有细节都 "洗掉"，糊成一团，看起来像「油画」，同时线条很细，很锐利，也很刺眼的画面 ^^;
大家都认为这种画面很漂亮，我看起来却觉得很痛苦 ^^;;
例如，NR 太重，把所有的细节都洗掉，茂密的草地变成「一块」绿色的黏液，透明的白云变成「一团」厚重的白泥，木头的材质纹理、墙壁岁月斑驳的痕迹，通通不见了。
锐利化太过，出现白边，或者 "出血"，画面只剩下高频，非常怪异，完全不协调，看了眼睛很「刺痛」。
这种过度 filter 之后的画面，用什么 Codec 压缩，损失掉信息都补不回来，所以大家会认为用哪一种 Codec 压缩都一样。
事实上各个 Codec 的特性都不一样，差异非常大。
引用
特别要说说的是,XVID的API4真的很不稳定,举例,POPGO废弃的DVDRIP,用1.0 BETA2会提示B-FRAME破损,用1.0BETA3会屏幕180度翻转了...
看来,如果不改善的话,我以后看XVID的动画片,要换装3个以上的XVID版本才行了....
上帝报佑我的WINXP的注册表不要那么脆弱,一天看几个动画,换几次CODE版本就坏了才好
api-4 是开发中的 tree，不稳定是应该的，不过 1.0 beta 应该没什么大问题，至少压出来的文件兼容性不会有问题。
你提到的第一个问题，beta 2 的 decoder 会显示 B-frame 破损，那不是 B-frame 破损，而是 B-frame decoding lag。
这个问题是 1.0 beta 2 的 dshow decoder 没有做处理，隐藏这个画面不显示，因为 beta 2 不在意这种问题，这个问题自然会在将来的 1.0 正式推出前修改。
基本上用之前的 decoder 播放就可以了，beta 版着重的不是这个，不过因为有人反应，所以提早在 beta 3 就修改了。
这个问题的发生原因是因为制作者使用 B-frame 压缩的时候，没有勾选 packed bitstream 的选项，我转贴一篇说明
==
packed bitstream 是 DivX 设计的，因为他们发现在 AVI 里面放 B-frame，会造成严重的影音不同步的问题，为了要解决这个问题，所以他们设计了 packed bitstream。
AVI 这个文件格式当初设计的时候并没有考虑会有 B-frame 放在里面，它的 sequence order 是循序的，也就是
1 2 3 4 5 6 7 8
I B P B P B P B ....
然而播放的时候，读入 2B 并不能立刻解码播放，要等下一个 3P 被读进来解码完毕以后，才能解码 2B，因为 2B 会参考它后面的 3P，在 3P 还没有解码完毕之前，我们不知道 2B 要参考的 3P 是什么样子，也就无法解码 2B。
这样子就会造成一个解码的 lag，解码的延迟，所以解码会变成这样
- 1 2 3 4 5 6 7 8
- I B P B P B P B .... <-- 输入
- I B P B P B P B .... <-- 输出
往后 delay 一个 frame，在 3 的时间点，读入 3P，于是便可以输出 2B。
所以用 VFW Codec(xvid.dll) 去解码这种 AVI，第一个画面会显示英文「警告，无法输出画面，因为 B-frame decoding lag」。
用 DirectShow Filter(xvid.ax) 播放时，XviD 的 DShow 有设计过，不会输出这个画面，所以我们看不到。（1.0 beta 1 的 DShow 好像还没有改过，所以会输出这个画面，pre-beta 3 的 decoder 就不会了，而 VFW Codec 因为 VFW 限制的关系，一定会输出这个画面）
不管有没有这个画面，都会延迟一个 frame，所以会造成影音不同步，由于只有差距一个 B-frame，所以不注意听的话可能不会察觉，但是仔细听的话就会发现。
而 .mpg 文件没有这个问题，因为它的 bitstream 是
1 3 2 5 4 7 6 9 8
I P B P B P B P B ....
这样排列的。
MPEG-4 有自己的标准 "载体"，装载 bitstream 的容器，container，叫做 .mp4，这个是从 apple 的 .mov 格式改过来的，里面可以放声音、影像、图片、文字、动画... 等等各种各样的物件。
用 .mp4 来装 MPEG-4 的 bitstream 的话，就跟 .mpg 装 MPEG-2 一样，不会有 B-frame decoding lag 的问题。
不过大家还是习惯用 AVI 装 MPEG-4 视讯。
DivX 为了解决这个问题，提出了 packed bitstream，把 B-frame 和它要参考的 P-frame 包在一起，变成下面这个样子
- 1 3 2 5 4 7 6
- I [P|B] [n] [P|B] [n] [P|B] ....
[n] 是 null，空的 frame。
解码器遇到 packed bitstream，就知道 P 跟 B 是包在一起的，中间有一个特殊设计的 | 会区分开来，B-frame 可以实时解出来，而后面的 [n] 则显示先前解出来的 P-frame。
这样就破解了 AVI 之中无法处理 B-frame 的限制。
也许有人会想，就算不用 packed bitstream，我把声音也跟着往后 delay，不就可以解决了吗。确实，这样就不会有影音不同步的问题，但是还是有许多兼容性的问题，在不同 player 上，会发生各种奇怪的现象，例如画面显示的顺序错乱等等。
而且 XviD 的 B-frame 不只一个，它可以
I B B P B B ....
甚至还可以
I B P B B P B P P B B B ....
lag 更乱。
把压好的 XviD B-frame AVI 用 VD 加载，按左右方向键移动试试看，比较有 packed bitstream 和没有 packed bitstream 的文件的差异，相信你就会明白有开 packed bitstream 的重要性。
例如 XviD 的三巨头之一 Isibaar，他自己压影片一定会开 packed bitstream :)
所以用 AVI 格式的时候，packed bitstream 非常重要，一定要开启。
==
由上可知，B-frame decoding lag 并不是一个 bug，也不是「不稳定」，而是用 AVI 格式装载 B-frame 必然会有的现象。
第二个问题，beta 3 播放画面会 180 度翻转，这是因为你有用 DirectVobSub 显示字幕的关系，VobSub 对于现在的 XviD decoder 输出的格式会翻转 180 度，解决的办法只要强制 XviD decoder 输出 YV12 就可以避免了。这个是 DirectVobSub 的问题，不是 XviD 的 bug，也不是不稳定。
这些问题都不是压制出来的文件有毁损，或者不兼容，只是 beta 版的 decoder 不着重在这些输出优化的小细节上。
事实上，使用者使用 AVI 格式 + B-frame，本来就应该勾选 packed bitstream，而 VobSub 翻转，VobSub 为了解决不同格式输入翻转的问题，本身就有设计翻转画面的选项。
这些问题本来就存在，只是以前 decoder 都帮我们预先想好了，处理掉这些问题，所以我们没发觉。
而这些问题，自然都会在 1.0 正式推出的时候修掉，目前 XviD 开发小组关注的是真正的 bug。
XviD 因为是 open source，自由度高，版本众多，给人不稳定的「错觉」，事实上，XviD 并没有不稳定，相反的，它的 bug 比 DivX 还少 :D
Re: Re: Re: [原创]岁末争霸战----2003年最强的视频编码
Silky@2003-12-29 10:27
引用
最初由 skywalker 发布
红色的球实在不好找.......
看来得自己画一个了..........
不一定要紅色的球，只是紅色比較明顯。
我剛剛用 Sister Princess RePure -ARIA- 中的一個畫面做示範
原本的畫面
開啟 Wavelet3DNR2 之後的畫面
開啟 4:1:1->4:2:2 補間的畫面
應該非常明顯 ;)
«12345»共6页
| TOP