德国开元华人社区 开元周游

标题: 关于 DVDrip BDrip 制作的一点心得 [打印本页]

---

作者: xenor    时间: 5.1.2010 04:59
标题: 关于 DVDrip BDrip 制作的一点心得


最近看到不少讨论高质量 dvdrip bdrip的帖子。感到异常激动 于是 准备把自己的经验分享分享 欢迎拍砖 但要有理有据
此文比较长希望大家有耐心看完 本人对rip的精度有较高要求 所以rmvb之类的随便压压就行了 没有讨论价值
此文设及avs x264等常识 请自行查阅相关信息
=======================================================

对于rip 我的理解是在最大限度保持原有dvdiso bdiso画质的前提下 尽量删除无用数据 压缩视频体积
那种从现成的db 或dvdrip 专制的rmvb或 低分辨率的视频我认为 只能算是2次压缩 而不叫rip 而那些从bd 或dvd直接转制的低分辨率低音质的视频也不是最终要追求的目标

要rip首先要有片源
目前主要片源主要来自 BDISO（BDMV，和BDiso本质相同只不过只提取了里面的所有文件及目录结构 而没有保留原iso的轨道信息）DVDISO 电视台录制等等 因为我没有做过TVrip 所以这里只讨论 BD DVDrip

就片源的复杂程度和处理难度上来说 BDISO<dvdiso<TV录制

对于BDiso来说 目前广泛应用的视频编码是x264（avc）还有微软的VC-1 （wmv9 advanced profile 或wvc1) 但是因为vc-1有版权 所以只有部分美国纪录片等采用了此种视频编码。而目前应用最广的是 x264（avc）。
这里要说的是 h264是一种编码标准 而x264 avc才是真正的应用 所以说编码是h264是不确切的。x264和vc-1的优缺点 将在后面讨论。音频采用lpcm truehd-audio dts-hd等等。支持视频分辨率1080p 16：9 1080i 720p 等高清分辨率。至于HD-DVD也是一种次时代的高清媒体 目录结构和DVD近似 视频音频编码和BD近似 因为其本身的局限性 目前其地位几乎被BD取代了


dvd的话 则采用mpeg2的编码来存储视频 这个大家应该很熟悉了音频则有 pcm dts ac3 而ac3中也有很大的码率差别 支持视频分辨率 ntsc720x480（16：9或4：3） pal720x576（16：9或4：3）
================================================================
下面将会介绍dvd bdrip相关知识
1。交错

说道这里就要提一下交错（interlace）和渐进（progressive）了 这个我想也是大家了解最少的

对于交错的片源则要分 ntsc 和pal来说明 (关于电视制式请自行参考http://baike.baidu.com/view/6053.htm?fr=ala0_1_1 http://hi.baidu.com/waining2006/blog/item/62c9f7c42b013daa8326ac7d.html 这里不做详解)

ntsc
电影的原始胶片播放速率为24fps 而ntsc则要求必须每秒播放30fps（其实最后标准被定为29.97fps 因为 30fps时模拟信号中的不同频率之间会产生干扰）
这种情况下必须把24fps的胶片转为30fps的ntsc信号 最常用的方法就是3：2pulldown 就是 把原来的4帧拆成8个场 奇数扫描行为奇场a 偶数行为偶场b 将4帧编号为1，2，3，4
则8场为 1a1b 2a2b 3a3b 4a4b pulldown时 将8场重新组合成5帧 即 1a1b 1a2b 2a3b 3a3b 4a4b 因为2，3两帧用了不同帧的场 所以画面不是完整的 但是因为电视是隔行扫描的
无论是交错还是不交错我们都能看到完整画面 但电脑不同 因为是逐行的 这2个不同帧的场会同时显示出来 导致我们看到的画面包含2个不同的信息 这样就是交错
还有一种就是全interlace的俗称30i 这种就是每秒播放的30帧都是交错的。 常见于dv录制视频 演唱会等 。这是因为 dv等摄像机每秒拍摄60个画面 每个画面只拍其中一个场 最后专制时
将2场合成一帧 得到 30帧 因为所有场都属于不同画面 所以这重组的30帧都拥有不同画面的信息 所以就都交错了 还是应为电视时隔行扫描 每次只能显示一个场所以我们看电视看不出来
常用的滤镜有 tfm()+decimate() aad() 等等

对于前者因为保持了原始胶片的所有场 可以通过场匹配反交错将画面还原回原始胶片的24fps 这个过程就是koifly前面的贴子里说的ivtc
具体原理就是 判断帧是否交错〉不交错直接输出 交错〉把帧拆成场 然后和相邻两帧的互补的场进行组合 得到新帧 然后判断交错 不交错输出 继续下帧的处理 交错〉换另外一帧进行重新匹配然后重复之前的工作直到
得到交错值最低的画面为止。因为有些电影由于剪接或后期处理的问题造成某些帧无论怎样都无法得到正确的匹配 产生ivtc错误 这样只能对这帧全帧反交错 得到近似画面了
常用的滤镜有 tfm()+decimate() aad() 等等


后者因为在拍摄过程中就已经丢弃掉了一部分画面信息 因此不能完全还原只能全部进行全帧反交错 得到30fps无交错的近似画面
avs基本找不到又快效果又好的反交错滤镜 这里如果是dvd的话 推荐用 tempgaussmc_beta1mod()和 tdeint()里的mode2

对于pal 要诟病的地方就多了 首先 25fps看似无交错画面完美 但是 因为原始电影胶片是24的加快播放速度 肯定声音音调会变高 导致音频失真
或者全交错的根本不可能还原为原始画面 或者本身就是30i全交错胡乱转成25fps了事。这也是为什么收藏电影的发烧级fans们只追求美国1区 日本2区和台湾3区ntscDVD
而不希望收藏欧洲2区 中国6区 pal的dvd的原因。或许我们根本听不出来那因为加快播放速度而提高的那点音调。但是后者导致的画面信息丢失应该更为严重

具体做法就是 如果progressive 就直接不用处理 交错的只能全桢反交错 顺便再说一次 tempgaussmc_beta1mod() 很强大 但是速度。。。。

对于bd 1080p 720p 的话 我说 片源很好不用处理了。。。。。如果是bd 1080i那么反交错会给机器造成很大的负担 建议直接interlace编码然后在
播放时硬件反交错 我这里 8600gt硬反效果不错
或者降低分辨率做720p等

=====================================================

2。分辨率 变形 裁边 ar ae
前面大家仔细看的话会发现我说 ntsc720x480（16：9或4：3） pal720x576（16：9或4：3）
那么有人就要问 为什么ntsc720x480或pal720x576 分辨率不是固定的吗 怎么还能即 16：9又4：3？

因为 这里存储的像素不是正方型的 不同制式的像素有不同的长宽比
即ar ntsc实际画面16：9时宽度为79/72 高度为4/3 4：3时 宽79/72 高为1
pal时 16：9 宽为117/128 高为4/3 4：3时 宽 117/128 高为1

在播放时 会根据情况遵循就高不就宽的原则变为正确的比例
这里要说下 什么是就高不就宽 因为 清晰度是由垂直分辨率决定的 比如我们所说的1080p 720p 480i/p 240i 576i/p等 都是以高度为准
比如320x240的分辨率 是240i/p的 而不是 320i/p等等 当然如果有人非要搞非主流 320p也是完全有可能的

dvd在实际播放中 保持高不变 宽度x sar(sample 又叫storage aspect ratio) 得到正确的分辨率
这里 ntsc的sar 16：9时为 40：33   4：3时为10：11 那么根据 ntsc720x480的分辨率计算 得到的4：3 的实际播放分辨率为 654.55x480 根本不是
4：3。。呵呵。。因为 模拟信号在转制dvd或传播过程中由于信号损失容易造成左右两边画面坏掉 因此都会在采样时左右多留8像素的画面喂给信号损失
如果你是在电视上看dvd的话那么这左右8像素会被自动裁掉的 电脑上的话 就会发现画面左右有黑边而且左右边缘很模糊
按照正确的宽高比 实际的横向分辨率应该为 近似的704 又因为 编解码器都根据一个指定的mod进行编解码的 曾经在很长一段时间内都以16为标准
即视频长宽必须是16的倍数才能被编解码 因为 704即能保持正常变形而比例不出错 且又是16的倍数 就被广泛采用了 这也是为什么目前很多视频分辨率
为704x480或704x396的原因

这样 704x40/33=853.3  或704x10/11=640 才是正确的
我们rip的时候 传统上无论有无黑便左右都要裁掉8像素 但是 因为现在的编解码器已经很好的支持了非16mod 而且 目前的dvd实际黑边根本没有这么多
为了最大限度保留画面 可以按照4的倍数 只切掉黑边保留更多的画面 因为走ar都是宽xsar算出来的 所以几乎不存在变形错误的问题
ar还有个好处就是 在编码过程中所有像素没有发生任何变化只是插入了sar的变形信息 这个播放时会被播放器自动识别 即使最后播放时也是点对点变形的 因此画面失真较小

另外一种就是resize
所谓resize 就是在原有像素的基础上添加或减少像素得到想要的正确的比例 因为插入或减少了像素 最后成品和原始视频不是点对点的 画面细节损失
较重。reszie的好处就是兼容性比较强 不会因为播放设备无法读取ar信息导致最终播放不能正确变形 导致实际比例错误
如果要走resize的话 一般建议计算ae (aspect error) 举个例子 比如你视频画面经过正确的ar后 是一个正圆 但是你经过rersize后得到的画面和原来的画面相比
有偏差 这个偏差就是ae 一般以百分比表示
下面引用某高人的公式
------------------------------------------------------------------------
一.
NTSC的DVD(4:3)
因為寬正確的AR(Aspect Ratio)是79:72的
所以令
A=(切邊後的寬*72/79)/切邊後的高
B=變形後的寬/變形後的高
AE(Aspect Error)=(A/B-1)*100%
例如:
切邊後的寬684,切邊後的高468
變形後的寬640,變形後的高480
A=(684*72/79)/468
B=640/480
AE=(A/B-1)*100%
-------------------------------------------------------------------
NTSC的DVD(16:9)
因為寬正確的AR(Aspect Ratio)是79:72的,而高的AR是4:3的
所以令
A=(切邊後的寬*72/79)/(切邊後的高*3/4)
B=變形後的寬/變形後的高
AE(Aspect Error)=(A/B-1)*100%
---------------------------------------------------------------
二.
PAL的DVD(4:3)
因為寬正確的AR(Aspect Ratio)是117:128
A=(切邊後的寬*128/117)/切邊後的高
B=變形後的寬/變形後的高
AE(Aspect Error)=(A/B-1)*100%

------------------------------------------------------------------------
PAL的DVD(16:9)
因為寬正確的AR(Aspect Ratio)是117:128的,而高的AR是4:3的
所以令
A=(切邊後的寬*128/117)/(切邊後的高*3/4)
B=變形後的寬/變形後的高
AE(Aspect Error)=(A/B-1)*100%
------------------------------------------------------------------------

根据公式就可以确定你resize后的误差了 一般1%以下就基本没人能看出差别了

常用的resize滤镜有
LanczosResize()
BicubicResize()
Spline64Resize()
Spline36Resize()
用法都差不多

对于bd来说 因为他的par是1 所以原始分辨率就已经输出了正确的比例 无需resize 或ar
对于黑边如果不是很重建议不裁了
目前有一些bd老片 是直接用以前的4：3画面左右加上几百像素的黑边做到1920的 这类没必要留两边的黑边 直接裁到1440就行了
============================================================================
3。关于色彩

因为我们使用的电视和电脑有着不同的色空间 如果我们要电脑上看rip的话 那么会转换到相应的电脑rgb的色空间上 具体涉及到yc伸张 等内容网上相关内容不少感兴趣自行搜索
这里要说的是 不同类型的颜色转换的方程不一样 错用会导致颜色错误
dvd存储的标清 一般为bt601 或bt709 目前bd高清则全是bt709 只有bt709才用转换
因为现在播放器都默认可以自动切换转换方式 所以建议如果拿不准的话 不要使用所有和颜色有关的操作。。这样转来转去只能更糟
另外有些BDrip教程上说要 把色空间转成yv12 其实这个就是为了更好兼容各种avs滤镜 这个如果是x264 avc的BD原盘已经是yv12 4:2:0了 没必要再转换

============================================================================
4。压制
网上教程不少 不多说只说重点
关于码率模式 x264 不存在cbr 所以不要相信谁说他压出了cbr的x264
megui中建议使用 2pass 或crf模式
如果你比较偏重最后得到rip的体积 那么可以用2pass 只要输入码率最后得到rip的体积几乎差不了多少
2pass模式下 每一帧画面的质量是不一样的 复杂程度高的码率高 低的码率相应会低 使用高参数会在有限的码率下尽可能高的提高质量
这里dvd建议1200以上 1800以下 bd至少3000

如果你不考虑体积 重质量的话就用crf 这种情况下所有帧的质量是一样的 根据质量负载度高的提高码率 低的降低码率 最后体积出来会有很大波动使用高参数有助于提高压缩比
但这里要注意 如果连续b帧过多的话有可能会降低画质
建议动画片 14到18   真人电影 18到24 bd开mbtree动画16到18 真人20 到22 不开 动画18到22 真人24到26

其他参数 随便找个high profile就行了 压好片 80%在前期avs脚本处理 19%在后期编码压制 还有1%得靠rp
如果前期处理不好 特别是dvd ivtc错误满屏飞或是根本比例就做错了 参数再好白搭 前期处理得当 用不了多高的参数就能压出好片
如果有虐机倾向可以尝试这套参数压bd 这个不是最bt的
x264_r1247 --profile high --rc-lookahead 96 --crf 16 --keyint 300 --min-keyint 1 --ref 4 --bframes 8 --b-adapt 2 --qpmin 1 --vbv-maxrate 38000 --vbv-bufsize 30000 --direct auto --subme 10 --trellis 2 --partitions all --qcomp 0.6 --me tesa --merange 32 --no-fast-pskip --no-dct-decimate --psy-rd 0.5:0.1 --aq-mode 1 --aq-strength 0.8 --transfer bt709 --colorprim bt709 --colormatrix bt709 --ssim --threads auto --thread-input --output "output" "input"

其实dvd的话这样足够了
x264_r1247 --profile high --crf 15.0 --thread-input --deblock 1:1 --bframes 3 --b-adapt 2 --b-pyramid --b-bias 0 --scenecut 40 --ref 4 --rc-lookahead 60 --aq-mode 1 --aq-strength 1.0 --merange 32 --me umh --subme 7 --partitions all --trellis 2 --psy-rd 1.0:0 --no-fast-pskip --sar 40:33 --output "output" "input"
把crf改到合适值就行了 e8400 不到2小时一集电视剧 50分钟一集动画片

下面说下x264 和vc-1
如果vc-1不是微软的东西 第3方支持多的话 完胜x264
首先vc-1自身的复杂度比较低 也就是说编解码时消耗系统资源少速度快 而且解码时要进行的运算也少不少 对画面的还原度高 但是相应的压缩比会降低
而x264等基于mpeg4技术的东西虽然压缩比高 但对色阶处理上存在严重的先天缺陷 我们可以看到很多bdrip 甚至bdiso色彩过渡上band满屏飞虽然这种band可以通过增加噪点加大码率来解决
但是这样就增加了前期处理的负担和最终成品的体积 到最后也不会比vc-1小多少。好在ffdshow可以接其他解码器而且自带的即时deband滤镜效果很好，不过那速度 估计能淘汰70%的电脑了
曾经试过同时开 反交错+deband e8400直接卡到不行。。。。。。
不过就目前来说 x264还是主流 谁让微软太nb了。。。。。没第3方支持白搭


=================================================================
5。关于真人电影和动画的压制


2者说区别的话 就是 真人电影或3d动画一般表现内容多为自然环境 细节丰富 这时重在保留细节 具体可以尽量少降噪 保持原有色彩 加大码率而对于ivtc等反交错的处理上可以适当简化
因为 自然环境细节较多 而且一般电影大多都是直接胶片专制 制作比较规范即使dvd交错也很容易用tfm等高速滤镜处理 bd的话只要不把颜色做错就行了 跑个全自动完全可以
至于体积大小 我想只要能压到原体积的一半以下就行了 不用过分的去限制 至于体积控制到几 cd 几dvd  那都是什么时代的事了 现在硬盘也不贵吧 尽量保持全篇连贯性才是正道

动画的话侧重点就不一样了 有人说动画比电影好压 其实我只能说那人根本没压过动画 动画最重要的就是反交错 因为画面单一 色彩集中 如果出现交错 或ivtc错误 很明显 而且特别是一些厂商剪辑得乱七八糟 同一集动画里混杂多种交错类型的例子很多 如果再遇到滚动字幕的话vfr是必不可少的了。这样rp不好的话一集20分钟的片基本上前期反交错就能搞掉你半个多小时 在你avs比较熟练的情况下
动画重线条 细节部分留得太多会给人画面很脏的感觉 适当降噪+收线+锐话有时候会得到很好的效果



这里补充说下vfr
就是可变帧率 和cfr相对的 有些东西里面混杂30i和film型的只有做vfr才能播放流畅 全做成24p 30fps的地方会明显丢帧 做30p则24p部分因为该删的重复帧没删掉导致播放起来很钝
目前支持vfr的媒体格式有mkv mp4 wmv 等 avi不支持vfr 只能插入占位帧 做120fps  120是 24 30 和60的最小公倍数 而且用avi封装x264缺陷很多
具体做法可参考下面的脚本

DGDecode_mpeg2source("V:\咲-Saki-\咲-Saki- DVD 01.d2v", info=3)     #源
trim(0,40241).aad(1,ovr="D:\x264\p.txt").assumefps(23.976)               # 截取op正片到ed中滚动字幕出现前的一部分 用aad进行场匹配得到24000/1001帧率的视频 为了和其他部分拼接 改变帧率到23.976(23.976不完全等于24000/1001所以23.976fps的视频不能和24000/1001的拼接)
\++trim(40242,42403).TempGaussMC_beta1mod().assumefps(23.976)  #截取ed中滚动字幕出现到字幕结束的部分 用TempGaussMC_beta1mod()进行bob+反交错 最后得到实际帧率为60000/1001(近似59.94)fps的视频 为了和其他部分拼接 改变帧率到23.976
\++trim(42404,0).aad(1,ovr="D:\x264\p.txt").assumefps(23.976)         #截取滚动字幕结束后到全片结束的部分 进行和第一部分同样的处理

#######################################3
按照以上脚本 压制出恒定帧率为23.976的视频
但是因为ed部分做了60fps处理 这个视频的时间是完全不对的
最后要通过 timecode来指定ed部分的帧率
timecode格式
################################
新建1空白文档 比如 timecode.txt 打开写上下面的

# timecode format v1              此行必写
assume 23.976                       如没有特别指定 以23.976fps的帧率播放此片
32193,36516,59.94                    指定从32193帧到36516帧这部分 以59.94fps的速率播放 这个帧数是 经过avs处理后的帧数 而不是原始视频的

最后封装时 连同该timecode.txt一起封装就行了


如果要封装成mp4  timecode必须写全
# timecode format v1              
assume 23.976                       
0,32192,23.976                                正片到字幕出现部分
32193,36516,59.94                             ed部分的
36516,结束桢,23.976                           最后部分的

mkv可以只写与 assume不同的部分


这样最后就得到vfr的视频了

---

作者: yellowbee    时间: 5.1.2010 20:36
不好意思我来晚了

加分加分。
前两天还在想过一段时间把摄像机里面拍的dvd导出来呢，这文章正好用得上。

---

作者: apex    时间: 5.1.2010 22:22
谁有空闲压缩蓝光呢，呵呵，现在下高清只是个权宜之计，喜欢的话，偶以后肯定会买高清碟收藏。


不过对网上的高清组致以崇高的敬意，没有他们，我们暂时没有高清看。哈～～

---

作者: yellowbee    时间: 5.1.2010 22:25
回复 3# kurz
我只压压dvd，话说现在高清都没地方下了，全部调整中

---

作者: apex    时间: 6.1.2010 19:59
论坛也少有楼上这种h迷，hide就免了吧，哈～

---

欢迎光临 德国开元华人社区 开元周游 (https://forum.kaiyuan.de/)

Powered by Discuz! X3.2