夜の工房 » 软件&技术 http://www.vempx.net 逃避现实怎么了！沉迷二次元有啥不可以！ Fri, 23 Dec 2011 22:39:57 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 基于MPC-HC的10bit播放全攻略 v1.1 http://www.vempx.net/article/552.htm http://www.vempx.net/article/552.htm#comments Sat, 15 Oct 2011 16:03:30 +0000 VempX http://www.vempx.net/article/552.htm 目前10bit风头正劲，包括我在内的我周围的好多朋友已经全面转向了10bit压制制程，而且这个季度的新番，也有一些字幕组开始尝试10bit压制。技术总是要向前发展的，正如我们开始大刀阔斧地淘汰rmvb一样，10bit这种新技术也到了开始普及的阶段。普及10bit的理由？码率更低，画质更好，足够具有说服力了。不过很多人可能对10bit的解码播放感到很棘手，问我如何搞定10bit的朋友就已经不下4个了，每次都要把同样的话重复说一遍实在是浪费的一种体现。于是写个文，一可以直接发给搞不定10bit播放的人，二可以当个备忘，一举两得。
（向对本文撰写提供测试帮助的304童鞋表达感谢）
本文谢绝转载，如果有疏漏之处，欢迎留言。

最近来留言提问的朋友越来越多，非常感谢大家捧场。不过现在已经多到我有点处理不过来的地步了，而且WP的留言嵌套回复功能好是好，但是套的一多就容易乱，弄的我经常漏看评论。为了能给大家更好的解决问题，关于播放的提问请到NMM论坛回帖提问，这里的评论关闭，谢谢～

Changelog：

v1.1：
修改NORMAL END部分设置，减小资源消耗，支持外挂字幕（ssnake）

v1.0：
本文诞生

 

为了照顾不同的需求，本文分为几个不同的攻略路线，请按照自己的需要选择。
1、我很懒，而且我也不是很懂这些东西，更重要的是我不想折腾！
2、我想按照这个文章稍微折腾折腾
a、我对我的电脑性能很有自信，我要最好的播放效果！
b、我的电脑性能还凑合，能播就行，对画质要求不是太高
c、我的电脑性能勉勉强强，放普通的1080p占用率都很高
d、我的是老爷机，放普通的480p都不像样……

 

 

 

共通路线

1、如果你的机器安装了什么乱七八糟的解码包套装，那么最好把它卸了
2、你需要入手一个MPC-HC，途径有以下两个：
a、到官网下载一个最新的stable版，地址：http://mpc-hc.sourceforge.net/
b、到个人编译网站下一个最新的build版，地址：http://www.xvidvideo.ru
记住不管你选哪个，最好要用x86而不是x64，后者意义不大而且很可能会给你带来一些意外的问题
下安装版也好压缩版也好，这个无所谓，不过你最好心里清楚你把它放到哪了
３、为了播放rmvb，还需要一个单独的解码器Real Alternative Lite，下好后安装，一路下一步即可，地址：http://www.free-codecs.com/download/real_alternative_lite.htm
４、入手一个Haali分离器，用来处理mkv和mp4，安装的时候一路下一步，其中一个步骤参照下图，地址：http://www.free-codecs.com/download/haali_matroska_splitter.htm

haali

５、运行mpc-hc，打开选项，找到左边的【内部滤镜】项目，如图设置，去掉mkv和mp4的源滤镜，去掉h264的解码器

filter

６、找到【格式】项目，点击一下右面【关联】中的的【视频】按钮，进行视频文件关联

format

７、找到【字幕】项目，设置参照下图

subtitle

 

 

 

 

HAPPY END

首先请看共通路线
1、你需要一个高品质渲染器madVR，地址：http://madshi.net/madVR.zip
2、下载回来之后，把它解压到一个地方，放好，比如你MPC文件夹下
3、运行madVR里面的install.bat安装
4、运行mpc-hc，打开选项窗口，找到【输出】项目，选择madVR，如图：

madvr

5、搞定之后，随便播个什么视频，让mpc进入播放状态。然后在画面上点鼠标右键，选择【滤镜】->【madVR Renderer】，打开madVR的设置窗口，点【Edit Settings】按钮打开详细设置窗口
6、展开devices项目，会看到你的显示器型号，图标或许会是一个大问号，此时手动在右边选择一下类型即可，如图：

devices

7、展开【processing】下的【decoding】，如图设置，只解码h264

decoding

8、OK，到此结束，现在你已经能够播放10bit的H264视频了，并且使用的是高品质的madVR渲染器，其他大部分的视频播放起来也都没有问题了，恭喜恭喜

 

 

 

 

GOOD END

首先请看共通路线
1、你需要下载一个10bit解码器 LAV Filters 地址：http://files.1f0.de/lavf/LAVFilters-0.37.exe
2、安装在一路下一步的同时请参考下图，去掉Matroska、MP4和RealMedia；把滑块往下拉，去掉Real Video 1/2和Real Video3/4，然后就可以继续安装了

LAV1

3、打开mpc-hc，进入【选项】里的【扩展滤镜】，点右边的【添加滤镜】按钮，打开【选择滤镜】窗口，从里面找到【LAV Video Decoder】，点选之后点确定

LAV2

4、接下来，将【LAV Video Decoder】的优先级设置为首选

LAV3

5、选择左边的【输出】项，在右面选择【EVR 自定义预设】(Vista/Win7) 或【VMR-9未渲染】(XP)，缩放选择【Bicubic A=-0.60（PS 2.0）】，其他保持默认即可

output

6、OK，到此结束，现在你已经能够播放10bit的H264视频了，其他大部分的视频播放起来也都没有问题了，恭喜恭喜

 

 

 

 

NORMAL END

首先请看共通路线
参考GOOD END路线的设置，并实际播放10bit的视频看看是否流畅，如果不流畅继续往下看
1、下载DirectVobSub安装，地址：http://www.free-codecs.com/download/directvobsub.htm
2、找到【选项】里的【输出】，在右面选择【覆盖合成器】

overlay

3、找到【扩展滤镜】，双击右面的【LAV Video Coder】，打开LAV的设置页，如图设置，仅留下4:2:0的YV12和NV12

LAV4

4、回到【扩展滤镜】中，点右上方的【添加滤镜】，在弹出窗口中找到【DirectVobSub（auto-loading version）】，点选之后按确定添加

vobsub

5、把【DirectVobSub（auto-loading version）】设置为首选

vobsub2

6、找到【回放】项，将右下方的【自动加载字幕】去掉，如图

playing

7、OK，到此结束，现在播放10bit视频试试是否流畅，如果流畅那么恭喜。如果还是不行，那么直接往下看就可以了ww

 

 

 

 

 

 

TRUE END

我劝你还是直接换台新电脑算了，现在买SandyBridge构架的酷睿i3也不是很贵，放片子绝对没问题！

 

 

 

DEAD END

请直接下载最新的PotPlayer进行播放，地址：http://www.potplayer.org/xiazai/

]]> http://www.vempx.net/article/552.htm/feed 96 QQ/TM传送文件保证完整性的方法 http://www.vempx.net/article/428.htm http://www.vempx.net/article/428.htm#comments Sat, 25 Dec 2010 04:23:01 +0000 VempX http://www.vempx.net/article/428.htm 对于经常用QQ/TM传文件的同学来说，应该没少碰到文件传输出错的情况。大部分的时候，传输出错会发生在因网络不稳定而频繁断线、续传的情况下。所以为了保证尽量不出错，所以还是来稍微了解一下QQ/TM的续传机制。

相信不少同学碰到过再次接收相同文件的时候无法续传的现象，想要续传是有一定条件的。那就是，传输是发送方主动断开的，如果是因为掉线、接收方重启或者其他种种情况发生的断开，那么很大几率无法进行续传。

此时想要恢复续传可以参照如下的方法：

1、将已经传送一部分的.tmp文件改一个其他名字
2、让发送方传送该文件，发送个几K之后，让发送方主动断开
3、删除刚刚接收到的tmp文件，并把之前的tmp文件改名为和刚刚删掉的tmp一样
4、再次让发送方传送，此时就可以续传了

现在来说说如何保证传送文件的完整性。

1、将文件用rar打包
这个是最最简单的方法，rar在解压的时候会进行crc校验，一旦出错会立刻提示用户。

2、rar打包并添加恢复记录
这个就更保险一些，一旦出错之后还可以使用rr进行修复。

3、利用BT的hash功能进行校验
如果传送的是大文件并且没有用rar打包，或者rr不足以修复，就可以使用这个方法。发送方用BT客户端（如uTorrent）给文件生成一个种子，再把种子或者磁力链接发给接收方并且开始做种。接收方用BT客户端打开种子文件或磁力链接，并把文件保存到与已接收文件相同的位置。此时BT客户端会发现文件已存在，并且开始进行hash校验。因为没有tracker服务器的参与，所以接收方需要手动添加发送方的IP和端口到用户列表里。校验完毕之后，客户端会开始从发送方那里下载损坏的部分。不过此方法对于内网同学来说会比较麻烦，需要做端口映射或者打开路由器的uPnP功能。

暂时想到的方法就是这些……

=================================我是分割线=================================

下面随便聊聊，说说为啥我会写这个……

昨天大虾给我传HOTD的BDMV，总共4个分卷，每个分卷3,906,250KB。这个就是断断续续传完的，最终导致了悲剧的后果……囧。我收到全部4个分卷之后，就开始解压。没想到的是，仅仅是双击打开第一个分卷rar就报错说“不可预料的文件末端”，出错文件是分卷2。结果我一看，分卷2的文件大小是3,906,251KB……我擦咧！？头一次遇到传着传着还传大了的情况！！我感到无比惊奇啊！！

还好这rar有5%的rr，尝试修复，结果修复不能……囧

于是问大虾要了分卷2制作的种子，进行hash，结果让我无语……UT显示下载量是80%！没错是80%！！整整少了20%的内容，5%的rr根本无能为力啊！到现在我都搞不清为啥会这样，不过幸好这80%都是从头开始连续的。于是我用FreeCommander的文件拆分功能，把这个不完整的文件按照78%和22%的体积比例给拆开。之后按照上面的恢复续传的方法，让78%的文件作为tmp文件进行续传，最后解决了问题，避免了彻底重传的悲剧……囧

所以说QQ/TM对传大文件要多加小心啊

另外还有一个比较奇怪的事情，就是QQ/TM传文件的速度非常快。怎么解释呢，就是说，用它传文件的时候，速度非常明显快于其他传输方法。我和大虾的测试结果是这样：
对传：800K左右
我从大虾FTP下载：15K左右
我从大虾HTTP下载：15K左右
大虾做种我用BT下载：10K左右……

FTP和HTTP，无论我用10线还是20线，都是一样的悲剧速度……BT更悲剧，连这俩都不如。完全无法和对传的速度相比。这该怎么解释？我能做出的猜测就是TX自己有一个路由表，使用他的IM客户端进行文件传送的时候，会通过这个路由表进行优化的路由选择，达到高速。其他的原因我是想不出来了，总不会是TX做了代理服务器进行中转吧……囧。希望有知道的同学告诉我一下m(_ _)m

]]> http://www.vempx.net/article/428.htm/feed 7 [更新] Chapters file time calculator v0.2.1 http://www.vempx.net/article/311.htm http://www.vempx.net/article/311.htm#comments Sun, 02 May 2010 14:40:06 +0000 VempX http://www.vempx.net/article/311.htm 以前的废话：

嗯，今天花了一天的时间用C写的……
没办法我编程太废……
写这东西的初衷是为了使Chapter文件处理变得简便
BD经常是把所有的chapter连在一起，分话压的话，就要把后面几话的时间全部整体前移才行
用这个小东西就能很简单的搞定 =v=

点击下载：
Chapters file time calculator v0.2.1

注意: 输入文件必须是OGG Chapters文件.

用法:
timec <输入文件> [参数]

参数:
-?    显示本帮助
-t     时间整体前移计算 (默认)
-d    时间 x 1.001 (用于DVD Decrypter)

举例:
timec    chapters.txt
timec    chapters.txt -t -d

合法文件如下：

CHAPTER01=00:23:45.424
CHAPTER01NAME= Chapter 1
CHAPTER02=00:25:16.515
CHAPTER02NAME= Chapter 2
CHAPTER03=00:26:47.606
CHAPTER03NAME= Chapter 3
CHAPTER04=00:36:32.190
CHAPTER04NAME= Chapter 4

Changelog：

0.2.1:
调整输出编号从00开始(其实无所谓……)
修正计算后第一个章节时间可能为负数的问题 =_=

0.2：
支持章节标题保留
添加可选参数
针对DVD Decrypter抓取的章节时间不准确添加-d参数用以修正

0.1.1:
增加处理章节数量到30，应该够用了
调整输出章节文件编号从01开始

欢迎反馈问题

]]> http://www.vempx.net/article/311.htm/feed 6 可能是目前为止吸奶娃BD最好的处理方式 http://www.vempx.net/article/314.htm http://www.vempx.net/article/314.htm#comments Sun, 02 May 2010 13:36:03 +0000 VempX http://www.vempx.net/article/314.htm 先看蓝光原图

source

 

 

再来看处理后的720，因为这片子实在是没有1080的价值

processed 

 

处理的思路是大虾（dgwxx）想出来的
大虾我信你啊啊啊啊啊啊啊啊啊啊啊！！！！！！！！！
不过本处理方式需要大量的人肉操作，所以效率不好，眼泪很多，距离量产可能还有火星撞地球的几率，嗯～

]]> http://www.vempx.net/article/314.htm/feed 6 太悲剧了，今天才刚刚发现MPC-HC支持WASAPI音频输出 http://www.vempx.net/article/302.htm http://www.vempx.net/article/302.htm#comments Mon, 04 Jan 2010 10:43:04 +0000 VempX http://www.vempx.net/article/302.htm 啊啊啊，我太悲剧了！用了这么久居然没发现有这个功能！

MPC-HC设置中输出项里，右下的DirectShow音频里选择MPC Audio Renderer，这样MPC就会使用WASAPI独占输出了。这样就避免了Win7那个共享模式采样率带来的重采样问题了呀！

而且我更加悲剧的发现，从r1297开始就添加了这个功能了。我靠我究竟是在干什么啊，这么久都没注意到。

T T

]]> http://www.vempx.net/article/302.htm/feed 19 Haali Matroska Splitter 19.12.2009 http://www.vempx.net/article/301.htm http://www.vempx.net/article/301.htm#comments Mon, 21 Dec 2009 01:30:17 +0000 VempX http://www.vempx.net/article/301.htm Changes in Haali Matroska Splitter 19.12.2009:
• New Features:
- Added a 64-bit version
- A shell extension was removed from the splitter. This will be available seprately at a later date.
- Added truehd and mlp support for Matroska files and transpor streams
• Fixed items:
- Fixed lpcm in transport streams support

您终于更新了，真是不容易，距上一版本隔了将近一年啊……

http://haali.su/mkv/MatroskaSplitter.exe

]]> http://www.vempx.net/article/301.htm/feed 2 QQ mail plugin for firefox 1.0.0.2发布 http://www.vempx.net/article/296.htm http://www.vempx.net/article/296.htm#comments Fri, 20 Nov 2009 14:25:52 +0000 VempX http://www.vempx.net/article/296.htm Firefox用QQmail插件1.0.0.2发布了。
貌似解决了之前文章里提到的Win7下无效的问题。
终于，我不用再用XP兼容模式运行Firefox了。

]]> http://www.vempx.net/article/296.htm/feed 0 [补充]渲染器品质测试 http://www.vempx.net/article/293.htm http://www.vempx.net/article/293.htm#comments Sun, 15 Nov 2009 05:22:20 +0000 VempX http://www.vempx.net/article/293.htm 之前的测试，被aki指出并不是很精确(aki联动帖)，所以重新制作了一个测试用的图片。虽然不能100%还原实际观看视频时的情况，但是还是希望这个测试得到的结果能更加精确一些。

Source测试用原图

重新制作的图片包含了4个部分。最上方是黑色、红色、绿色、蓝色分别到白色的渐变。为了测试的精确，每个渐变的宽度为256px，正好是0-255阶。
第二部分为AVS生成的color_bar。
第三部分为我制作的随机颜色彩色条纹。每个条纹的宽度越往右越窄，最右边的条纹宽度为1px。
最后一部分则是普通的文字。

ImageSource(“Color_Test.bmp”,end=59)
Assumefps(“ntsc_video”)
ConverttoYV12(matrix=”rec601″)

EVR Haali
EVR                                                                 Haali

madVR VMR9
madVR                                                              VMR9

ffdshow
补充一张ffdshow的高品质RGB32输出

图片可点击放大进行肉眼判断。
输出图已经交给aki，等待他的数学计算结果。

]]> http://www.vempx.net/article/293.htm/feed 12 常用渲染器品质测试 http://www.vempx.net/article/292.htm http://www.vempx.net/article/292.htm#comments Sat, 14 Nov 2009 20:09:27 +0000 VempX http://www.vempx.net/article/292.htm 今天闲来无事，决定对常见的渲染器进行一下品质的测试。

测试前先稍微讲一下影响渲染器品质的几个主要因素。
1、Resize算法
2、Upchroma算法
我的测试并没有涉及到Resize之后的品质，所以第一条就略过不谈了，我们重点来说第二条。

众所周知，视频文件并非使用RGB，而是YUV。在YUV当中，使用的最多的则是YV12，也就是YUV4:2:0。对于YV12来说，它的亮度分辨率为1，色度分辨率为1/2。举例来说，对于一个720P的视频，它的亮度分辨率是1280×720，但是色度分辨率仅为640×360。这也就是为什么把一个RGB转到YV12之后，体积会变小的原因。再往深里说，为什么YV12要抛弃一半的色度数据而保留全部的亮度数据呢？这是由于人眼的特性是对亮度敏感，对色度不敏感而决定的。那么再顺便说个题外话，从RGB转到YUV，是要经过一系列计算的，那么这个计算的方式，也就是算法的不同，会导致结果的不同。我们常说的BT.601、BT.709等等指的就是RGB <-> YUV转换时不同的算法。在国际标准中，对于SD以及SD以下的视频，是使用601，而HD以及更高分辨率则使用709。换句话说，DVD应该用601，720和1080应该用709。

扯的有点远了，回到主题上来。由于YV12的色度分辨率仅有1/2，所以在播放的时候，需要把这1/2变成1才行。那么这个从1/2变到1的过程就是“无中生有”了。这个“无中生有”指的就是第二条Upchroma算法，这个算法在很大程度上影响了视频的播放质量。

那么测试开始
系统：Win7 Pro x64
显卡：GeForce 9800GT
播放器：MPC-HC 1.3.1337.0
解码器：ffdshow
色彩输入：YV12
色彩输出：YV12

我们首先需要一个用来测试的原始视频。我拜托风儿做了一个分辨率是1280×720的测试用图片，然后将这个图片作为原始素材导入AVS生成了一段测试用视频。

COLOR 原始图片 点击放大

ImageSource(“COLOR.bmp”,end=59)
Assumefps(“ntsc_video”)
ConverttoYV12(matrix=”rec709″)

以上内容为AVS脚本。
大概内容是，将Color.bmp文件作为图像，生成60帧。然后将帧率指定为NTSC制式的标准video帧率，也就是29.97，最后将RGB转换到YV12，使用709并将色彩范围压缩到16-235。
之后我使用VDM打开这个AVS脚本，把原始的YV12视频流直接保存出来，没有经过任何压缩。这样我们就得到了一个内容是YV12的测试用视频，接下来就要用这个视频来看各个渲染器的效果了。

VMR9 VMR9

EVREVR

Haali Haali

madVRmadVR

通过观察可以发现，在灰阶显示效果上，madVR以绝对的优势胜过其他的渲染器，Haali的表现也强于VMR和EVR。madVR的SoftCubic100带来的效果真不是盖的，难怪madshi一直在讲，madVR使用了效果最牛X的Upchroma算法。不过在彩色过度上，我的眼睛还真没看出什么太大的差别来……囧
排名的话，madVR > Haali > EVR ≈ VMR

madVR的确给了我们无与伦比的回放品质，但是正如我前面文章中讲过的一样，madVR的缺点也同样明显。在提供了高品质的同时，它无法给我们带来便利的功能。而且它对显卡性能要求也很高。是否要坚持使用madVR，还要各位自己决定了。

]]> http://www.vempx.net/article/292.htm/feed 5 Haali分离器在打开MKV文件时停滞的解决办法 http://www.vempx.net/article/291.htm http://www.vempx.net/article/291.htm#comments Fri, 13 Nov 2009 16:21:30 +0000 VempX http://www.vempx.net/article/291.htm 最近在放MKV文件的时候发现了这么一个事情。
由于我左右的个人Rip都是MKV格式，并且为了放流全部都放在一个文件夹中。在这个文件夹中大概有500多个MKV文件。每次当我播放这其中的某个文件时，播放器都会卡好几秒之后才正常播放。但是如果文件夹下只有很少的几个MKV文件，播放的时候则完全不会出现停滞现象。

针对这个让人极为不爽的问题，我进行了一番思考。
在MKVToolnix中Mux的时候，有一个Link UID选项。这个东西的作用，是把两个MKV文件通过UID链接起来，播放的效果是，只要这两个MKV文件在同目录下，播放完第一个之后会自动去播放下一个。
于是我在想，会不会是因为Link UID功能导致停滞。因为我那500多个MKV都在一个文件夹下，如果要有Link效果，那么需要对本目录下存在的所有MKV文件进行UID扫描，这可能就是导致停滞的原因。

既然找到了可能是原因的疑点，那么就设置一下进行确认。
打开Haali Media Splitter的属性窗口，在Input项中发现有设置项Try to open linked files，把这项设置为NO之后，再次打开我那500多个MKV中的一个，停滞现象消失了。

看来导致停滞的原因果然就是linked功能。这个功能我基本上也不常用，估计大部分的Riper也不会用到这个功能，个人建议还是把他关掉比较好。

]]> http://www.vempx.net/article/291.htm/feed 3