查看完整版本: [-- [原创]岁末争霸战----2003年最强的视频编码 --]

『漫游』酷论坛 -> 影音精华区 -> [原创]岁末争霸战----2003年最强的视频编码 [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

<<   1   2  >>  Pages: ( 2 total )

skywalker 2003-12-28 02:14

[原创]岁末争霸战----2003年最强的视频编码

终于到年底了..........
今年以来视频编码的发展进入了百家争鸣的时代........
免费的视频编码越来越多..........
而且在压缩质量和效率上比原来也有所提高.........
这里就把最新的六种视频编码作出比较.........
它们分别是:
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
这东西不是为我这种人准备的，太深奥........

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版本就坏了才好

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. 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. 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

Silky 2003-12-29 10:27
引用
最初由 skywalker 发布

红色的球实在不好找.......
看来得自己画一个了..........

不一定要紅色的球，只是紅色比較明顯。

我剛剛用 Sister Princess RePure -ARIA- 中的一個畫面做示範
原本的畫面

開啟 Wavelet3DNR2 之後的畫面

開啟 4:1:1->4:2:2 補間的畫面


應該非常明顯 ;)

skywalker 2003-12-29 10:36
其实已经画了一个红色的球了........
用了4:1:1->4:2:2 補間 后果然和恐怖............
多谢Silky兄了........

关于SP, 我没用packet bitstream主要是因为很多人使用的是ffdshow......
而ffdshow解packet bitstream有bug........
所以无论怎么弄都会有一部分人看的时候出问题...........
相对来说, b-frame decoder lag 算是比较轻的问题, ffdshow解packet bitstream的bug好像是变成黑白的了???

bestword 2003-12-29 11:05
请问Silky,量化矩阵应该如何自订？我知道在哪里自定，问题是那些数值设多少合适？
请问skywalker，为什么说XVID压的时候选H.263效果比较好？我看到的文章多是说设成MPEG效果较好

skywalker 2003-12-29 11:26
引用
最初由 bestword 发布
请问skywalker，为什么说XVID压的时候选H.263效果比较好？我看到的文章多是说设成MPEG效果较好


其实Silky已经回答过了
http://popgo.net/bbs/showthread.php?s=&threadid=193792&pagenumber=3


至于量化矩阵, 在xvid里面可以设置, api4的话就在选quant type的下面................
一般是下一些别人已经设置好的矩阵, 当然自己调也可以,
左上是dc, 频率为0的系数.........
其他是ac, 越望右横向频率越高,越往下纵向频率越高...........
频率越高代表画面的变化越厉害,也就是细节越多........

alexheart 2003-12-30 01:08
偶然的机会发现 Silky 兄也上漫游, Hi Silky 兄 ^_^. (好久没来这里, 这次故地重游我的 id 都被删了:p )

引用
至于量化矩阵, 在xvid里面可以设置, api4的话就在选quant type的下面................
一般是下一些别人已经设置好的矩阵, 当然自己调也可以,

beta3里附有几个 custom matrix. 有人提到那几个矩阵以前 koepi 也附送过, 我不曾注意到 :p
顺便附两个在别处和 Silky 兄讨论到的矩阵 ^_^

引用
by Silky:
压低码率，用 CCE 的 very low matrix 效果不错
intra
08 16 19 22 26 27 99 99
16 16 22 24 27 29 99 99
19 22 26 27 29 34 99 99
22 22 26 27 29 34 99 99
22 26 27 29 32 35 99 99
26 27 29 32 35 40 99 99
26 27 29 34 38 46 99 99
27 29 35 38 46 56 99 99
inter
16 17 18 19 20 21 99 99
17 18 19 20 21 22 99 99
18 19 20 21 22 23 99 99
19 20 21 22 23 24 99 99
20 21 22 23 25 26 99 99
21 22 23 24 26 27 99 99
22 23 24 26 27 28 99 99
23 24 25 27 28 30 99 99


cce = cinemacraft encoder, 非常厉害的 mpeg-2 encoder.

引用
RC2 矩阵是
intra
08 08 09 11 13 13 14 17
08 08 11 12 13 14 17 18
09 11 13 13 14 17 17 16
11 11 13 13 13 17 18 20
11 13 13 13 16 17 20 24
13 13 13 16 17 20 24 29
13 12 13 17 19 23 28 34
12 13 17 19 23 28 34 41
inter
08 08 08 09 09 09 09 10
08 08 09 09 09 09 10 10
08 09 09 09 09 10 10 10
09 09 09 09 10 10 10 10
09 09 09 10 10 10 10 11
09 09 10 10 10 10 11 11
09 10 10 10 10 11 11 11
10 10 10 10 11 11 11 11

质量很高，1st-pass 压出来文件很大，要用 2-pass 缩小把文件压成和 H.263 一样大再比较。
如果同码率，RC2 矩阵会优于 H.263，那么我们可以说这个矩阵是很优良的。
不过根据我的测试，计算 PSNR，RC2 矩阵会比 H.263 低。
这个矩阵适合用在高码率，它有非常好的视觉品质，画面很锐利，同时暗部没有 H.263 量化的色块，画面很漂亮，大家可以试试看


既然谈到 ffdshow, 再谈谈关于量化矩阵和 ffdshow, XviD 默认矩阵的 intra 和 inter 最左上角的值分别为 8, 16. 这个值代表着此 macroblock 的 "平均值" 吧. 我发现若使用这两个值有所改动的自制矩阵, ffdshow 不能正常解码.

引用
关于SP, 我没用packet bitstream主要是因为很多人使用的是ffdshow......
而ffdshow解packet bitstream有bug........

ffdshow 解码其他 codec 编码的视频时有时会有这样那样的不兼容问题. 尤其是每天都有更新的 XviD.

所以 FFX/FFX-2 我一直没有公布任何转录后的版本 (还有一个原因是看了 Silky 转录的后给我压力很大 :D) :) (我只在 ccf 上传了从原 ps2 光盘里提出的动画, 自己在玩, 测试) 因为我觉得若用默认的矩阵谁都可以去编码, 而效果并非 "那么" 赏心悦目; 而用自制矩阵的话多半大多数的人的 ffdshow 都会解码错误 到时候或许会有很多人不分青红皂白还以为是 XviD 的错误. 或许我可以写个说明, 但我知道那多半没用. 等候 milan 发布更新的 ffdshow :p

其他的, dev-api-4 的 qpel + bf ffdshow不能正常解码.:p
而且必须选择 "disable XviD" (则 ffdshow 不关联 XviD, xvid.ax 自己解码) , 若是 "use XviD" 也不能正常解码.

ps. 现在网上才出的一个 ffx-2.ztdd 的版本(比如 ccf/tlf 都发行了)是来自于 ccf 上认识的一个好友制作的, 因为我马上要说的是鞭他尸, 所以不提他名字了 :D (我跟他在 ccf 的 irc 上讨论过了, 他个人希望我也能在各处指出一下他制作时的少许不妥之处).
如果您曾下载观赏过, 各位高手可能都发现了----
错误是没有做resize...画面的比例错误了(这是唯一的错误), m2v 的长宽比是 640 x 416, resize时,
若是缩小宽度, 应该 640 x 416 resize---> 576 x 416 才是正确的比例
若要稍作放大, 则 640 x 416 resize ---> 640 x 458---> 满足 mod32 补黑边至 640 x 480

由于本贴着重讨论 Codecs , 所以我还是谈 XviD 方面的吧.
他使用了 bframe, 以前跟 Silky 兄讨论过关于 FFX 的转录, 像这种高动态的动画并不太适用于开启 B-frame, 不过既然 XviD 可以动态加入 bf, 所以只说这个选择没错，但不太妥切. :)

另外, 这个版本使用了默认的 bf packed bitstream, 所以若您下载了此动画需要关闭 ffdshow 才能避免出错. (真不知有几个人能看到在此的说明 :rolleyes: , 那小子居然不加点说明文档 :p)

pps. 虽然如此 ffdshow 我还是要装的, 因为我的显卡有点老, 解码 YV12 时总会出个小错, 所以有时必须用 ffdshow 关闭 yv12 输出...

alexheart 2003-12-30 02:10
引用
XviD 因为是 open source，自由度高，版本众多，给人不稳定的「错觉」，事实上，XviD 并没有不稳定，相反的，它的 bug 比 DivX 还少

nod
而且感觉 DivX 的 staff 不以为然似乎从来就不打算修正这些 bugs, 作为商业软件的开发者一点都不敬业...

XviD 作为开放源代码的软件, 大家发现 bugs 都可以参与其讨论, 开发者也会注意, 若真是bug那会立马开始修正的. 所以 XviD 的 bugs 少于 DivX 也在情理之中 :D

lady 2003-12-30 11:57
刚刚试了RC1的矩形阵,特意我用要求BIT很低的动画([2003.12.2x] 虎の穴1号店プレゼントDVD タイガードラマ (iso+mds).rar,还准备拿去WINNY上发布的^^)
我没加FITER,用第3方软件自订矩行阵(没有用XVID附的),IBBBBPBBBBPBBBB
用WMV9输出(还是不能接受XVID)
为了节省时间,我用1PASS,发现哪怕是用QB86,出来的SIZE也很大呢,不知是否QB值太低,静态祯的画质也烂了一点(难道一定要加FITER?)
看情况,哪怕是2PASS,效果也不会好,坚决不推荐....
RC2完点试,看看效果如何

对比的标准,我是以以下矩行的质量的为标准对比

08 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16

lady 2003-12-30 12:06
引用
最初由 alexheart 发布

nod
而且感觉 DivX 的 staff 不以为然似乎从来就不打算修正这些 bugs, 作为商业软件的开发者一点都不敬业...

XviD 作为开放源代码的软件, 大家发现 bugs 都可以参与其讨论, 开发者也会注意, 若真是bug那会立马开始修正的. 所以 XviD 的 bugs 少于 DivX 也在情理之中 :D


很多BUG,我看了,也不算什么BUG,只是没有XVID那么自由而已,毕竟,是要从兼容性为第一考虑的,例如B-FRAME的限制,不是每个人都懂设置,总要考虑一般的应用
要大大提升压缩比,我觉得不该交由MEPG4来胜任了,现在的MPEG4发展已经差不多极限了,不要再压榨它了....呵呵
对DIVX SHAFF的很多苦衷我个人表示理解

RogueCS 2003-12-30 12:43
用Beta3试验了RC2矩阵，效果和size都直线上升

暗色部分的色块有明显好转，可还是没法完全消除，相对RV9的测试样品，仍有少量的量化色块。请问能做到完全杜绝暗色场景的量化色块吗？

还有，请问在Beta3自带的Custom量化矩阵中，对压动画合适的有哪些？

skywalker 2003-12-30 12:56
引用
最初由 lady 发布


对比的标准,我是以以下矩行的质量的为标准对比

08 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16
32 32 32 32 32 32 32 32 16 16 16 16 16 16 16 16



这个matrix..........
好像是那个3D/Animation的matrix啊...........
这个是wmv默认的???

lady 2003-12-30 13:04
引用
最初由 skywalker 发布



这个matrix..........
好像是那个3D/Animation的matrix啊...........
这个是wmv默认的???


既然要对比,就要拿好的矩行来对比,这个是就如你所说的是那个默人的矩行,有个中间标准才好比较
WMV9是封闭的,没有公开任何矩形
但XVID可以实现的,同样也可以在DIVX/WMV9上实现,而且少了兼容性问题
个人觉得正是XVID兼容性不好的补救

alexheart 2003-12-30 13:05
引用
要大大提升压缩比,我觉得不该交由MEPG4来胜任了,现在的MPEG4发展已经差不多极限了,不要再压榨它了....呵呵

没到极限:D, 并入 H.264 的 MPEG-4 v10 将空前强大. :D

Silky 2003-12-30 13:05
引用
最初由 skywalker 发布
关于SP, 我没用packet bitstream主要是因为很多人使用的是ffdshow......
而ffdshow解packet bitstream有bug........
所以无论怎么弄都会有一部分人看的时候出问题...........
相对来说, b-frame decoder lag 算是比较轻的问题, ffdshow解packet bitstream的bug好像是变成黑白的了???

新版的 ffdshow 我沒有試過，不過聽 sysKin 說過 ffdshow 解 packed bitstream 有 bug，他已經向 ffdshow 的作者 milan 回報這個 bug，不過 milan 現在似乎很忙，還沒有回應。
用 ffdshow 解碼 XviD 的 AVI，要將 iDCT 的設定，由 "simple idct" 改成 "XviD"，這樣才不會產生一些奇怪的瑕疵，所以還是要調整。
因此我建議播放 XviD 的 AVI，最好還是用 XviD 自己的 decoder 來解碼，才能得到最穩定的畫質，反正現在 XviD 的 decoder 可以單獨下載，安裝也很方便，這樣也可以避免一些不能播放的麻煩，一勞永逸 :D

lady 2003-12-30 13:09
引用
最初由 Silky 发布

新版的 ffdshow 我沒有試過，不過聽 sysKin 說過 ffdshow 解 packed bitstream 有 bug，他已經向 ffdshow 的作者 milan 回報這個 bug，不過 milan 現在似乎很忙，還沒有回應。
用 ffdshow 解碼 XviD 的 AVI，要將 iDCT 的設定，由 "simple idct" 改成 "XviD"，這樣才不會產生一些奇怪的瑕疵，所以還是要調整。
因此我建議播放 XviD 的 AVI，最好還是用 XviD 自己的 decoder 來解碼，才能得到最穩定的畫質，反正現在 XviD 的 decoder 可以單獨下載，安裝也很方便，這樣也可以避免一些不能播放的麻煩，一勞永逸 :D


不LAG的解决方法
反而是用DIVX5带的PLAYER来放,不管是DIVX/XVID
呵呵
保证不LAG,我试过,您也可以一试

lady 2003-12-30 13:09
引用
最初由 alexheart 发布

没到极限:D, 并入 H.264 的 MPEG-4 v10 将空前强大. :D


如果真到那个时候,也许就不叫MPEG4了....:P

Silky 2003-12-30 13:26
引用
最初由 alexheart 发布
偶然的机会发现 Silky 兄也上漫游, Hi Silky 兄 ^_^. (好久没来这里, 这次故地重游我的 id 都被删了:p )

Hi alexheart 兄!
沒想到會在這裡遇見你 :D
漫游我也是好久沒來，最近因為連不上 ccf，到處亂晃，所以又迴游... :p
引用

既然谈到 ffdshow, 再谈谈关于量化矩阵和 ffdshow, XviD 默认矩阵的 intra 和 inter 最左上角的值分别为 8, 16. 这个值代表着此 macroblock 的 "平均值" 吧. 我发现若使用这两个值有所改动的自制矩阵, ffdshow 不能正常解码.

這是 ffdshow 長久以來的 bug，我和 sysKin 都很驚訝它竟然經過這麼久都沒有修掉。我曾為了這件事做了一連串的實驗，幫助 sysKin debug，不過沒有結果。
總之，這是 ffdshow 的錯 :p
引用

所以 FFX/FFX-2 我一直没有公布任何转录后的版本 (还有一个原因是看了 Silky 转录的后给我压力很大 :D) :)

啊？我做的那個很爛 ^^;
我自己看了都很慚愧，當初怎麼會做出這種東西.... -__-;;
期待您做的終極版本 :D
引用

若是缩小宽度, 应该 640 x 416 resize---> 576 x 416 才是正确的比例
若要稍作放大, 则 640 x 416 resize ---> 640 x 458---> 满足 mod32 补黑边至 640 x 480

說到這個，順便提起，NTSC 的 PAR 是 72/79，切邊要切到 702.2222... 才是完全準確，但是這是不可能的任務，沒有辦法切到小數點啊。
但是有一個方法 ;)
還記得 MPEG 規格書上提過，NTSC D1 720x480 的有效範圍是 711x486 嗎？
711 這個數字有個玄機，711 可以被 79 整除。
所以
720x480 左右切邊-> 711x480 -> 711*72/79=648 -> 648x480 左右再切邊-> 640x480

剛剛好，多完美 :p

Silky 2003-12-30 13:32
引用
最初由 lady 发布


不LAG的解决方法
反而是用DIVX5带的PLAYER来放,不管是DIVX/XVID
呵呵
保证不LAG,我试过,您也可以一试

疑？可以嗎？我試過還是會 delay 一個 frame 啊，這個應該是 AVI 的限制，除非換一個載體，或者使用 packed bitstream。
還有 DivX 5.1.1 的 decoder 解碼 XviD 的 packed bitstream 沒有問題，但是遇到 XviD 兩個或兩個以上的 B-frame，而且又是 120fps 的時候，會發生嚴重的 lag，因為
==
DivX 5.1 的 decoder 默認會取代系統上所有的 MPEG-4 解碼器，自動播放所有的 MPEG-4 AVI，連 XviD 的 AVI 也被它搶去播放。
DivX 5.1 的 decoder 播放 XviD 的多個 B-frame 是沒有問題，但是我發現一個 bug，那就是當 XviD 的 AVI 是 120fps 的時候，120fps 的 AVI 本身就插入許多 null frame，而 packed bitstream 也會插入新的 null frame，假設下面的 sequence 是 30p，每一張 frame 後面要插入 3 張 null frame
I [n] [n] [n] [P|B] [n] [n] [n] [n] [n] [n] [N] [n] [n] [n]

[N] 代表 packed bitstream 插入的，用來取代 P 的 Null frame。

DivX 解碼只有一個 B-frame 的 120fps 沒有問題，但是解碼有兩個或兩個以上的 B-frame 的 120fps，sequence 向上面那樣，就會 skip 跳中間的第二張 B-frame，造成畫面會頓。

我之前也是播放 120fps 的 XviD B-frame AVI 都會頓，後來才發現是 DivX 搞的鬼，換回 XviD 自己解碼就沒有問題了。
DivX 5.1 decoder 把設定畫面中的 "Support Generic Mpeg-4" 選項取消，就不會用 DivX 來解碼 XviD 的 MPEG-4。

Silky 2003-12-30 13:36
引用
最初由 lady 发布


如果真到那个时候,也许就不叫MPEG4了....:P

H.264 是 MPEG-4 的一部份，屬於 MPEG-4 part.10，又稱為 MPEG-4 AVC(Advanced Video Coding)，所以它還是叫 MPEG-4 :p

csr2000 2003-12-30 13:39
引用
最初由 lady 发布


不LAG的解决方法
反而是用DIVX5带的PLAYER来放,不管是DIVX/XVID
呵呵
保证不LAG,我试过,您也可以一试


你有试过最近的Beta3吗？ 加了packed bitstream的用DivX播放lag非常明显，找个小动态水平移动的场景看看吧 :D

Silky 2003-12-30 13:55
引用
最初由 alexheart 发布

没到极限:D, 并入 H.264 的 MPEG-4 v10 将空前强大. :D

其實就算是不把 H.264 列入，目前的 XviD 都還沒有到 MPEG-4 的極限，還有一堆工具沒有實作，MPEG-4 最強的 Studio Profile，SONY 在今年 NAB 發表的業界新規格 HDCAM SR 就是使用 Studio Profile 的硬件壓縮蕊片
http://www.sony.jp/CorporateCruise/Press/200303/03-0305B/

形狀編碼等高壓縮率的工具都還沒有做出來。

就算不提壓縮工具，目前的 XviD 也還有一堆壓縮核心沒有優化
1. B-frame 沒有 VHQ，這個差距很大
2. 要做像 MPEG-2 一樣的 Adaptive quantization，根據 HVS(Human Visual System)，計算 Activity，每個 block 給不同的 quant，不要整個畫面都用同一個 quantizer
3. 2-pass 優化，1st-pass 計算最佳 lambda，2nd-pass 再根據這個 lambda 壓縮
4. B-frame Direct mode 改進，現在的 Direct mode 會造成 銳利線條的邊線出現「斷線」、「殘點」的現象，以後除了要判斷一整個 block 的 SAD(Sum of Absolute Differences) 誤差，還要判斷這個誤差是都集中在一個、或者少數幾個 pixel 身上，如果是集中在少數幾個 pixel 上，代表這個是「端點」，就不要使用 Direct mode
5. 解決 B-frame 閃爍的方塊，靜態畫面一整片均勻物體會產生「浮動」的現象
6. 解決暗部色塊的缺陷
7. ...... 等等等等，還有好多有趣的點子，可以增進畫質的點子，還有許多缺點都還沒有修改，這些都要等到 1.0 正式推出以後才會繼續改進，所以 XviD 遠遠還沒有到 MPEG-4 的極限，還有一段距離。

不過，現在已經運作的很好了 :D

Silky 2003-12-30 14:11
引用
最初由 lady 发布
刚刚试了RC1的矩形阵,特意我用要求BIT很低的动画([2003.12.2x] 虎の穴1号店プレゼントDVD タイガードラマ (iso+mds).rar,还准备拿去WINNY上发布的^^)
我没加FITER,用第3方软件自订矩行阵(没有用XVID附的),IBBBBPBBBBPBBBB
用WMV9输出(还是不能接受XVID)
为了节省时间,我用1PASS,发现哪怕是用QB86,出来的SIZE也很大呢,不知是否QB值太低,静态祯的画质也烂了一点(难道一定要加FITER?)
看情况,哪怕是2PASS,效果也不会好,坚决不推荐....

不知道哪一個是 RC1 矩陣，上面 alexheart 兄列的兩個矩陣，第一個叫 very low bitrate 矩陣，第二個叫 RC2 矩陣，會稱為 RC2 矩陣，因為它是大部分日本 RC2 動畫 DVD 所使用的矩陣。

還有，您是用 TMPGEnc 做 WMV9 的壓縮嗎？
不知道是不是我漏掉了什麼訊息，不過據我所知，WMV9 是不能使用 MPEG 量化矩陣的，WMV9 的量化方式類似 H.263，而且只能用這一種量化方式。
同時 WMV9 也沒有 B-frame 的架構。
所以我很好奇您是用什麼軟件做這些設定的？照理說應該是不能這樣設定才對。
如果您是用 TMPGEnc 做這些設定，TMPGEnc 的這些量化矩陣設定，GOP 設定，只有在用它自己壓縮的 MPEG-1/MPEG-2 上面才有效，對於 AVI 輸出，使用 WMV9 Codec 壓縮，是無效的。也就是說這些設定在壓 WMV9 的時候都是沒有作用的，WMV9 不會去用你設置的矩陣，因為它根本不採用這種量化方式。您可以做一個實驗，看看變更矩陣，然後 WMV9 用一樣的設置壓縮，出來的文件應該會是一模一樣的，變更 TMPGEnc 的矩陣設置對 WMV9 沒有影響。

TMPGEnc 能影響 AVI 輸出的，有
1. Picture type 指定為 I Picture 的畫面會透過 VCM，指定壓縮的 Codec 一定要把這個畫面壓為 keyframe
2. 設定為 copy frame 的畫面，會透過 VCM，指定 Codec 一定要 drop 這個 frame 不壓縮

就我所知，只有這兩個功能。

Silky 2003-12-30 14:23
引用
最初由 lady 发布


既然要对比,就要拿好的矩行来对比,这个是就如你所说的是那个默人的矩行,有个中间标准才好比较
WMV9是封闭的,没有公开任何矩形
但XVID可以实现的,同样也可以在DIVX/WMV9上实现,而且少了兼容性问题
个人觉得正是XVID兼容性不好的补救

如上所述，WMV9 應該沒有設置量化矩陣的功能。
同時 DivX 也一樣，DivX 也還沒有完全實作，MPEG-4 ASP(Advanced Simple Profile) 應該要具有的，H.263/MPEG quantization 兩種量化方式的功能。DivX 只能用 H.263 一種量化方式。
能使用 MPEG 量化，設置量化矩陣的，目前實用上大家比較容易接觸到的，有 XviD, Nero Digital, 和 FFMPEG。

Silky 2003-12-30 14:51
引用
最初由 RogueCS 发布
用Beta3试验了RC2矩阵，效果和size都直线上升

暗色部分的色块有明显好转，可还是没法完全消除，相对RV9的测试样品，仍有少量的量化色块。请问能做到完全杜绝暗色场景的量化色块吗？

用 RC2 矩陣還是會有色塊，這種情況我沒有遇過，也許碼率真的有點不足？
MPEG 量化可以避免 H.263 量化在暗部場景的色塊現象，但是不能避免因為碼率不足造成的 block 瑕疵。
RV9 在壓縮中有用 deblock-filter，所以方塊感會比較輕微，我想您要做到和 RV9 一樣的效果，可能要另外加 filter。
要去除暗部色塊，可以用 iago 的方法，加上
LumaFilter()
Unfilter(-5,-5)

不過我是保真派的 :D ，不喜歡對訊源做加工，上面的方法會稍微改變一些原始畫面，所以我從來沒用過。
我想可能有幾個方法
1. 用 Zone 的功能，手動指定那幾段暗部場景的部分，把它們的 quantizer 設低一點
2. 提高整體碼率
引用

还有，请问在Beta3自带的Custom量化矩阵中，对压动画合适的有哪些？

可能沒有半個 :p

RC2 矩陣適合用在高碼率，低碼率千萬不要用，還有它的 inter 砍的很少，遇到原本訊源上有一種「粉塵狀」的噪訊時，經過 RC2 量化，這些粉塵狀噪訊會擴散得更多，整個畫面會籠罩「一層」厚厚的噪訊，這種訊源也不能用 RC2 量化，甚至根本不能用 MPEG 量化方式，這種訊源用 H.263 量化是最佳的。

MPEG 量化的優點
1. 線條銳利，畫面清晰
2. 細節保留非常多
3. 不容易有色塊
缺點
1. 畫面會有點「髒」，不乾淨，畫質不穩定，會有一種騷動感
2. 很怕銳利的線條，銳利線條周圍會出現閃爍的雜點

H.263 量化的優點
1. 畫面乾淨，會把訊源的雜訊濾掉一部份，等於具有 filter 的效果，不像 MPEG 量化，反而會把噪訊保留、擴大
2. 畫面穩定，騷動感輕微
缺點
1. 細節損失，對我來說，損失太多了，實在看不下去 :p
2. 畫面會有一點模糊，不像 MPEG 銳利
3. 容易產生色塊

以動畫來說，很多動畫訊源都是以 H.263 質量比較好。
MPEG 請用在高碼率、不顧文件大小，只追求最高質量的時候使用。

不過，極低碼率時，用低碼率使用的 MPEG 矩陣，有時候可以得到比 H.263 好一點的效果，block 會比較少（高頻削多一點，低頻削少一點的矩陣，例如 very low bitrate 矩陣）。

66666 2003-12-30 15:21
请问楼上，H263的量化效果跟RV9的量化效果比较的话，谁更好？

还有就想问一下，H264的量化有没有可能加入到XVID中？

jmz 2003-12-30 19:43
不是一般的专业啊。。

lai012 2003-12-30 21:37
雖然還是門外漢.但有空得好好研究.
佩服.謝謝.

sssdsdsds 2003-12-30 22:33
了解了不少东西 收获不小阿

angeltalent2002 2003-12-30 23:13
[QUOTE]最初由 skywalker 发布



多谢Silky兄的指点.......
把chorma当luma处理的那个方法真的是太强了..........
没想到可以这么用的^^...........
好在这个地方并不会影响到测试结果............
下次压的时候一定会试试这个方法.........
红色的球实在不好找.......
看来得自己画一个了..........

灌篮高手里好多好球球
汗，路过，说什么偶都看不懂

cnchg 2003-12-31 10:07
楼主
我下了一个avi视频
我也装了xvid和divx编码器
可还是不能出图象
能告诉我是怎么回事及解决方法吗？？？？:)

skywalker 2003-12-31 12:30
引用
最初由 cnchg 发布
楼主
我下了一个avi视频
我也装了xvid和divx编码器
可还是不能出图象
能告诉我是怎么回事及解决方法吗？？？？:)


看关于播放的置顶贴.......


另外再看到有人跟非讨论的贴就直接删了...........

littleyizhi 2003-12-31 13:10
Silky兄 alexheart兄稀客呀~

sky好像缪精品的id吧（偶是借了个id用的 :D)

赶快把教程搞定

mingdi6 2004-01-11 13:37
我还是偏爱rm9，个人感觉个人使用足以

looking03 2004-01-14 08:19
求教：

我用11M无线网（在笔记本机）看台式机上的已下载好的电影，一部戏内有时有一两个场境会有继续的现象，总的来说，都很顺。我想是解码与连网的呑吐量问题，如我copy到本台上就没问题，实线网也没问题。（两台机子都应没问题，一台是PIII　1G　512M，另一台pc是p4 1.8g）

我只想知道，在这种情况下换另一种解码器会不会有改善，因照道理，11M的无线网是完全可以滿足的。

bestword 2004-01-18 18:10
在另一个帖子讨论的时候突发奇想，于是就对数据做了对比，发现：

三个场景的测试，第一个场景RV9以2.79%的文件扩大只换来了0.18%的效果优越（平均信噪比，全局信噪比的话比这个还低）；第二个场景不用说了，XVID文件小效果还好；第三个场景，RV9以5.65%的文件扩大只换来了0.63%的效果优越（平均信噪比，全局信噪比RV9被XVID胜过了）。也就是说，实际上XVID是在以相对的低码率对抗高码率的RV9，而且就是这样它的表观效价比仍然胜过了RV9。如果考虑到XVID是以效果较差的H.263方式压的，那么在前两个场景如果用MPEG方式，XVID应该还可以更加胜出。第三个场景因为Silky说MPEG不适合压画面上有很多灰尘的场景，所以就不考虑MPEG了。
从统计学的角度来说，除第三个场景下RV9文件大小超过了XVID大小的5%而拥有统计学意义外，其他各项数值都因为差异小于5%而应判定“统计学上无差异”的。所以真正的测试结果应该是RV9和XVID基本平手，XVID微弱优越，但这种优越没有统计学意义。这时XVID的码率控制和压缩速度上的优势就成为我们选择它的原因。

csr2000 2004-01-18 23:16
用了MPEG，文件大小起码大20%，然后要压到同样的大小，PSNR下降就不是一点了吧，这个你有考虑吗？
动画用MPEG和H.263的视觉效果你进行过比较吗？ PSNR只能做个参考，XviD里有很多选项都是降低PSNR来提升视觉效果的

skywalker 2004-01-18 23:46
引用
最初由 bestword 发布
在另一个帖子讨论的时候突发奇想，于是就对数据做了对比，发现：

三个场景的测试，第一个场景RV9以2.79%的文件扩大只换来了0.18%的效果优越（平均信噪比，全局信噪比的话比这个还低）；第二个场景不用说了，XVID文件小效果还好；第三个场景，RV9以5.65%的文件扩大只换来了0.63%的效果优越（平均信噪比，全局信噪比RV9被XVID胜过了）。也就是说，实际上XVID是在以相对的低码率对抗高码率的RV9，而且就是这样它的表观效价比仍然胜过了RV9。如果考虑到XVID是以效果较差的H.263方式压的，那么在前两个场景如果用MPEG方式，XVID应该还可以更加胜出。第三个场景因为Silky说MPEG不适合压画面上有很多灰尘的场景，所以就不考虑MPEG了。
从统计学的角度来说，除第三个场景下RV9文件大小超过了XVID大小的5%而拥有统计学意义外，其他各项数值都因为差异小于5%而应判定“统计学上无差异”的。所以真正的测试结果应该是RV9和XVID基本平手，XVID微弱优越，但这种优越没有统计学意义。这时XVID的码率控制和压缩速度上的优势就成为我们选择它的原因。



其实XVID的优势是在比较高的码率上, 已经快到h.263的极限了, 再要提高码率就要减少p frame的使用, 到时候效率就会降低了..............
rv9虽然提高码率后PSNR的增加不大, 但是反过来说, 降低码率对psnr的影响也不大...........
所以rv9(RV10?)的的适应性更强............
RV9在低码率下的画质明显胜于其他的codec...........
所以说在压的时候就要计算好compressbility, 看是用rv9好还是用xvid好...........
我自己是用XVID的, 因为我喜欢下雨 :p .........


查看完整版本: [-- [原创]岁末争霸战----2003年最强的视频编码 --] [-- top --]


Powered by phpwind v8.5 Code ©2003-2011 phpwind
Time 0.024392 second(s),query:2 Gzip disabled