Mr-Z♂的个人资料

失算了，囤的油挥发了，一年半，6瓶355ml直接空了三瓶，还有两瓶挥发掉一些，一瓶挥发很少，没想到密封性这么良莠不齐

分享一下我主要用于BDrip的x265参数吧…… 大概就是这样，除非画面很有个性的那种，不用管压冻鳗还是真人，直接用 -D 10 --crf 14 --psy-rd 2 --aq-mode 1 --aq-strength 0.8 --qcomp 0.7 --pbratio 1.2 --preset 6 --no-sao --no-rect --no-strong-intra-smoothing --b-intra --weightb --ctu 32 --cbqpoffs -2 --crqpoffs -2 --deblock -1,-1 --rc-lookahead 80 --keyint 360 --min-keyint 1 --no-open-gop --bframes 8 --rd 5 压4k的话--ctu也许应该改到64，--keyint和--min-keyint按需求调呗，有调戏进度条的需求就调小点，不太离谱的话码率一般不会爆炸顺便说一下提高速度和高CRF的调整方向吧提高速度的调整，说的顺序可能是对画质的影响从低到高这样子 --me hex --subme 2 (前两个一起大概提速50%的样子) 减少--bframes 减少--rc-lookahead --no-b-intra (这三个提速不明显) --early-skip --rd 4 (early-skip的影响似乎在rd4比rd5明显) (rd4大概……提速100%？early-skip也提升挺明显的不过俩一起用对画质的影响就是高一点的级别了) --rskip 2 (rskip的提升大概与画面特性有关) 再往下就干脆用preset+no-sao了吧然后是高CRF大概需要调整的一些参数，没啥顺序，都看情况调降低--psy-rd，看着降吧，大概crf18降到1.5这样子，这参数降到0也没关系，感知不强 --aq-mode，改成2或者345，都是2的变种 --aq-strength，改高保护纹理，改低保护线条，大概（ --qcomp，调低点，比如默认0.6就挺合适的 --pbratio，默认是1.3，可以直接把这个参数删掉用默认值，这玩意说实话，调1.2的差别大概也得长个复眼才能看出来吧你看我为什么把它们写前面加到crf22以上的时候可以把sao开起来 ffmpeg写法别漏了4xx，照源写，虽然大部分都是420 -pix_fmt yuv4xxp10le -preset 6 -crf 14 -x265-params psy-rd=2:aq-mode=1:aq-strength=0.8:qcomp=0.7:pbratio=1.2:sao=0:rect=0:strong-intra-smoothing=0:b-intra=1:weightb=1:ctu=32:cbqpoffs=-2:crqpoffs=-2:deblock=-1,-1:rc-lookahead=80:keyint=360:min-keyint=1:open-gop=0:bframes=8:rd=5

dwing吧吧主竞选：NO.0001号候选人

五

四

三

二

一

Pot+LAV+madVR配置教程_v1.10 多图预警，一共30张图，2.93MB咕咕咕，等madVR更新了再更新教程版本号到2.0吧一些相关的文件下载：lanzous。com/b01tttu3c 还有啥要补充的会在二楼有些关键词会被屏蔽，所以文件名看起来有点奇怪

水，写了个玩具无图，懒得搞（ga♂yhub有图自动去重复帧、插帧、计算timestamp、混流、转为cfr最终输出 ga♂yhub地址：/Mr-Z-2697/ddfi 理论上插帧的部分可以替换成任何插帧方式，使用RIFE、DAIN之类的神经网络或许会有稍好的结果欢迎吐槽

缩小画面时 Linear Light 的作用（水贴）首先，这是一张128×128的黑白像素棋盘状交错的图现在要对其进行1/2的Scale，即缩小到64×64，那么按照比较简单的想法，通过四个像素的融合来达到这个目的，即两个黑色（0，0，0）和两个白色（255，255，255）融合为一个新的像素，那么得到的会是一张每个像素均为（128，128，128）的图片但是，如果把原本的图片和缩小的图片保存下来，然后确保1:1的查看的情况下，从屏幕前远离，会发现缩小的图片看起来比较暗而如果是在 Linear Light 下做的缩小的话，看起来会是这样，更为接近远离时所看见的样子只是展示一下这个现象，至于背后的原理比较复杂就不提了

staxrip吧吧主竞选：NO.0001号候选人

x265与YUV的4:2:0与4:4:4采样温馨提示：即使测试最终得出444优于420的结果，也不代表我在任何意味上支持对420源进行简单拉升后就压成444的行为，本测试从源为444的角度出发。半采样的影响和内容特性有关，这个测试分为几个部分，先发实拍部分。以前油管扒的8K，用VS内置Lanczos缩到1080p YUV444P10，然后用FFmpeg同样使用Lanczos进行该进行的444->420和x265纯preset slow压制，之后对结果使用VS内置Lanczos升到444后与源脚本进行比对。同crf得出的体积相同（±1%），x265自动对444加上了+6的cbcrqpoffs，虽然严格来说可能不算”同参数“，不过这个参数很简单直接，可以认为是为了达到控制体积这一变量的目的而做出的调整。而编码耗时方面的影响是：crf从16到28，420分别比444快了24%、27%、28%。（编码耗时已减去源脚本耗时）初步结论：没有（为什么x265用纯预设参数，因为我懒，反正变量有控制好就行了（为什么用FFmpeg来做444->420，因为我是假定源为444的情况，那么降采样的过程也应该算进耗时里面。视频ID wrjYr7-gKQg，vp9版。（暴躁提示：实际上，我想说的是，无脑444，【哔——】吧你。

提问的要点（不按要求没人回答莫怪）播放环境组件以及版本：硬件、系统、驱动、播放器、外置解码器、渲染器等。出现问题的文件：至少提供完整Mediainfo，或者提供原始下载链接，最好上传到不限速网盘。出现问题的操作：从打开文件开始，最好每一次点击（鼠标、键盘操作）都详细记录。

libaom-av1 简单参数测试温馨提示：因为画面复杂，所以码率高一些片源还是【とある科学の超楽曲集】中收录的电磁炮第二季第二个OP。还是编码之后用ffmpeg的libvmaf跑分然后用Excel作图。经过简单的比对，libaom-av1的质量比svt-av1和rav1e好，决定只选libaom-av1作为测试用的编码器。（用的是ffmpeg里的）同时会有x265的slow和veryslow预设作为基准。（开启no-slow-firstpass以及对14M、7M、3.5M关闭sao）首先是预设（cpu-used），本来计划是从8到0跑下来的，但是跑到2的时候半路炸了，索性不测更慢的了，于是只有8到3了。因为是第一次跑，所以计划是从上次的 2pass 14M（相当于x265 slow crf14）一路减半，然后选一档码率和预设作为接下来可能有也可能没有（太慢了，而且中高码感知不强，甚至涂抹更多）的测试的标准。结果：平均VMAF： 3 - 98.8234，4 - 98.7774，5 - 98.7106，6 - 98.7133，7 - 98.7137，8 - 98.7142，x265-6 - 98.7016，x265-8 - 98.7099 编码耗时： 3 - 4:23:25，4 - 2:37:29，5 - 1:57:34，6 - 1:18:59，7 - 1:19:23，8 - 1:19:40，x265-6 - 0:18:02，x265-8 - 1:54:39这么挤可能看不清楚，如果真的很在意的可以下载Excel文件查看： http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fpan.baidu.com%2Fs%2F1SER8HP6v2hvxnhlVlnJ25Q&urlrefer=4c9700425d8e348396c906ec7b7d4e1d，749x 根据这一次的结果，6~8编码耗时和vmaf得分都差不多（甚至折线都几乎重合），决定只对3~6进行接下来的测试。为什么不选得分最高的8？因为我感觉6作为名义上更好的预设应该还是有什么优点的。让我选择一个在crf14下的编码方式，我肯定选择在x265 slow基础上调参。

沙雕向）硬解H264 RGB 把RGB拆了，BR缩了，塞成YUV420，x264设Matrix为GBR

昨儿搞了点片来压，压完2.7G 既然压了，那就顺便对比一下某组压的7.2G 说起来啊，有个云压片的guy最近狂吹“国外大神组”，狂贬包括我在内（主要是我？）的几位吧友，倒也没见它出点什么片微=云=上传有点慢，等传完二楼整活。俩示例图估计要被压了，png在此： fil⚪es.cat⚪box.m⚪oe/y2l1⚪2p.p⚪ng fil⚪es.cat⚪box.m⚪oe/cw3⚪6gj.p⚪ng

x265一些参数调整的质量比较（VMAF折线图） VMAF跑得慢很多，我会慢慢把之前的SSIM转过来，同时随缘更新，SSIM的就不更啦。片源为【とある科学の超楽曲集】中收录的电磁炮第二季第二个OP，2pass 14Mbps编码后用FFmpeg的libvmaf进行比较，使用Excel绘制折线图。首先是sao，这就可以说明vmaf比ssim靠谱了，sao的ssim比no-sao高，显然是不合理的；结果当然是，sao需要关闭。

x265几个参数调整的SSIM折线图可能有随缘更新。片源为【とある科学の超楽曲集】中收录的电磁炮第二季第二个OP，比较方法为2pass 14Mbps SSIM比较及肉眼比较。 merange，可以看出几条折线没有什么太大的差别，57更是已经几乎和92重合，肉眼比较也是如此，所以完全可以开低节省时间。qg-size，32明显的SSIM整体比8高了一截，肉眼比较也是32比8好，建议开32。pbratio，没什么明显差异，两条折线几乎重合；肉眼比较互有优劣；如果不知道自己在干什么，保持默认的1.3即可。aq-mode，虽然从SSIM看貌似有较大差异且难以得出结论，但在肉眼比较中互有优劣；这也是意料之中，毕竟只是调整码率分配，与压缩率关系不大；个人认为在高画质编码中保守地开1就行。aq-strength，基本同上；个人认为应该开0.8。

x265 CUTree 开启与关闭 SSIM折线图最近吧里有个云压片的××说关闭CUTree画质更好，所以做一个图来打脸使用FFmpeg libx265编码，在preset slow的基础上稍微修改了参数，开启与关闭CUTree分别编码，微调CRF到体积接近到100KB 使用FFmpeg的SSIM功能，取"All"列，用Excel绘图可以看出关闭的在有些部分接近甚至略微高于开启，其余部分关闭明显低于开启至于为了某些略微的提升而明显牺牲部分质量是否值得……

FFmpeg 视频转PNG的一些坑，及避坑本文仅适用于当前版本，如果以后FFmpeg修复了某些Bug请勿喷我是之前在搞Flip Flappers的OP的Waifu2x的时候，用FFmpeg把视频转成PNG序列的时候、以及平时偶尔瞎捣鼓的时候发现的（不要吐槽为什么不用VS滤镜……我用waifu2x-ncnn-vulkan，那时候还没有VS移植）大概是以下几点： 1、YUV420-->RGB的时候，使用的Chroma Upscaling算法是Neighbor，导致颜色质量降低（见图一中间红色部分） 2、对于没有标注Matrix的视频，默认使用BT.601的Matrix进行YUV-->RGB，但如果视频实际为BT.709，会导致色差（见图一和图二三的色差） 3、10Bit的YUV，FFmpeg默认将其转换为RGB48BE，如果直接指定转为RGB24会出现色带（见图一和真领子）避坑方法： 1、先进行一次YUV420-->YUV444的转换：format=yuv444p10le（之前我是先extractplanes再分别scale色度，后来发现这个偷懒办法） 2、使用Zscale滤镜进行Matrix的指定：zscale=min=709:m=709 3、先转换为RGB48BE，再转换为RGB24：format=rgb48be,format=rgb24 总的滤镜链的写法是：-vf zscale=min=709:m=709,format=yuv444p10le,format=rgb48be,format=rgb24 图一(默认)↓图二(调教)↓图三(madVR)↓如果发现上面的图片不是PNG，请看以下地址：图一：files.catbox.moe/zb5w3y.png 图二：files.catbox.moe/334g02.png 图三：files.catbox.moe/59fq4h.png

potplayer吧吧主竞选：NO.0001号候选人

【水帖？】解压即用包（真+伪）之前做了个解压即用包（为什么不叫绿色版？因为LAV和madVR都会写注册表，似乎不大“绿色”）放在和教程所需文件同一个网盘分享链里但是没有单独开一帖啊我现在想想，要是有人看完教程才发现原来有解压即用包可能会觉得不爽啊所以水一帖喽链接接一号>>t.cn/AiC955TG，无提取码短链接二号>>url.cn/5n1LvuH，提取码ufiv 压缩包密码是SBBD 对的，我就是懒得单独开一个分享链

Pot+LAV+madVR配置教程(又来丢人了)_v1.9 多图预警一共25张图 2.56MB 百度现在连图里的链接都能揪出来封帖网盘地址请去v1.7和v1.8看或者我尽量在二楼试着发

(疑问+水帖) 为什么WEB源的动画在某些场景会比BD亮度降低呢？

玩累了就直接睡觉，没问题的

关于软解和硬解 (D3D11) 的画质一样的论证方法首先要排除会引入随机数的选项，否则结果将不准确。 LAV的Dithering不能关，只好以Ordered Dithering代替。madVR方面主要是Debanding和Dithering，Dithering可以关就关了。然后就是分别切换D3D11和软解，播放器全屏，用键盘上的截屏键截屏，用微软送的画图工具保存为PNG。两次截图的各种散列值均一致。至于散列一样代表什么意思，自行百度。以上过程可以轻易重现，不信我的人自己试去。

我房里有一些好康的_v1.8

SVP白嫖指南怎么才能发链接不被删帖呢试试看二楼发

madVR 隐藏选项在madVR目录下的一个 (或多个) 具有特定名称的空文件夹或文件可以启用隐藏选项，然而你可能不应该用这些选项。 BilinearSuperRes: 使用低质量但速度更快的 SuperRes 模式。 DisableHdrBrightnessTweak: 关闭对阴影亮度的提升，这个情况通常发生在HDR里面的显示器峰值亮度设置在120或180 nits的时候。 DontRenderAfterStop: 在播放结束或暂停的时候使madVR停止渲染7秒。可能可以防止跳转时间时的黑屏闪烁和播放速率变化。 force full range input: 强制madVR把所有输入当作full range对待。 KeepLastFrameOnStop: 播放结束的时候不会显示黑屏 (会停在视频的最后一帧) 。 ShowBlackBars: 在zoom control检测出的活动视频区域 (非黑边区域) 外围用绿框标记。 ShowRenderSteps: 在OSD里面显示每个着色器步骤及其渲染消耗的时间。由于需要刷新GPU并且等待每个步骤的渲染完成，将会使拖慢渲染时间。根据步骤的数量和GPU的不同这个影响可能很大或相对很小。只有OSD开启的时候才会启用。 YCbCr: 用YCbCr代替RGB输出，但还是把它当作RGB。 ShowHdrMode: 显示HDR模式。部分演示图

教程_v1.7 帖子标题越来越简洁了有木有多图预警一共26张图会消耗你2.8MB的流量改了好多东西感觉可以直接叫2.0了其实可能是因为觉得没改多少内容就更新很丢人于是改了很多无卵用的地方（逃

教程更新_v1.6 原本用来更新的度盘链接被度娘吃掉了新分享的链接也是秒删只好这样了

IMCO4200老机翻新，油管搬来的

关于软解和硬解的画质区别问题总有些人说软解画质好，那行，我做个实验，实验步骤也都放上，如果怀疑我的结果可以自行实验。首先写一个Avisynth脚本，用DSS调用Lav解码。解码输出RGB24格式，因为后面要保存成PNG。Lav这里选Ordered Dithering，这是关键。因为Lav解码精度高，到最后要输出8位的RGB要做Dither，如果用Random（随机） Dithering那肯定结果会不一样。然后就是用随便什么支持AVS的工具输出一帧。在Lav设置里面切换软解之后再重复一次操作。我使用的命令行为： ffmpeg -i test.avs -ss 23.886 d3d11.png ffmpeg -i test.avs -ss 23.886 sw.png 23.886随便打的数字，ffmpeg会找到离这个时间点最近的前一帧。 SHA1结果：可以得出结论：软解与硬解，无画质区别。

有没有可以检测压制崩坏画面的工具？整个文件解码下来看看有没有花屏/丢帧什么的不知道用FFmpeg行不行 ffmpeg -i src -f null NUL 有解码错误应该会有错误输出实际上我已经在进行这样的操作了，这样是否可靠呢？

如何将 Lav 解码的数据喂给编码器？

不管怎么设置，PotPlayer就是不用Lav来解码OPUS 不管是在音频解码器里面选择OPUS的解码器为Lav，还是在全局滤镜优先权里面强制使用Lav，还是两个同时使用，PotPlayer就是死活要用内置FFmpeg解码OPUS

用madVR，截图有点小问题这是使用Ctrl+E直接截图保存这是使用Ctrl+C复制画面后粘贴到系统自带“画图”里面保存局部放大颜色交接的地方，出现了锯齿，推测是由于chroma upscaling的低质量导致的。是某种原因，导致直接存储为文件时没有使用madVR选定的chroma upscaling算法，而是直接用了最近邻。请问，这种原因是什么？或者如何解决这个问题？

4K压制这么强了吗？4K x265比1080p x264还小 x265，crf=17，no-sao，no-strong-intra-smoothin，psy-rdoq=1，次时代音轨，一部4K电影居然不到10G，比一些“高码”1080p x264还小啊，是x265真这么强还是片源本身省码率？

x264设定ref=3，用mediainfo查看，显示参考帧4帧，什么情况？

大佬们有什么性能消耗低的播放器推荐吗？ potplayer+Lav+madVR的搭配还是不适合笔记本啊

VLC等软件的安卓版，ARMv7、ARMv8、x86、x86_64该怎么选择？

解码True-HD、DTS-HD之类的音频用什么工具比较好？用途是将这些音轨解码，输出wav或者flac文件，不是播放时挂的解码滤镜。 eac3to用的libdcadec和ffmpeg，哪个比较好？或者有优于这两者的选择？

Potplayer加载外部音轨的问题加载了外部音轨，但是外部音轨与内封音轨在同时播放……

内置硬解设置，该不该开使用FFmpeg DXVA 解码器？就这个

FFmpeg用-ss -to截取视频居然是要把视频从头解码到-ss指定的位置截开头的部分还好，截末尾的部分直接吃满CPU，还疯狂读取硬盘，编码进度丝毫不动，要等到解码到指定位置的时候才开始编码，然后编码一会儿就好，解码等待时间漫长同样是用FFmpeg作为核心的ShanaEncoder，截取视频的时候就不会这样是因为ShanaEncoder用的命令不同，还是说ShanaEncoder的作者修改了FFmpeg的源码做到的？

疑惑为什么动漫组还有一些日剧、日影组喜欢用FLAC音频？换句话说，为什么压日本货的组喜欢用FLAC？原盘的音频是什么格式呢？直接保留原盘的音频不好吗？

请问，x265编码视频输出的info里面的cpuid=1173503是什么意思？见过的几乎所有x265编码的视频都有这个一开始没注意到都是一样的，以为是记录编码视频的CPU的某些信息，后来发现都是一样的，又想是不是记录编译x265的CPU的信息，然后又发现不同编译版本也一样…… 虽然不是什么大问题，还是请教一下各位大佬了（本来想去h265吧发的，然而去那边一看，好多小白）

我在设置Win10的局域网文件共享时遇到了点问题我用笔记本（Win10家庭版），设置一个共享文件夹，台式机（Win10专业版）可以直接访问，然后用台式机共享的文件夹，用笔记本访问却提示需要“网络凭据”，似乎是需要提供台式机的用户账户的用户名和密码，然而问题来了，我是用Microsoft账号登陆的，没有本地的用户账户……试了一下把Microsoft账号密码填进去也不对……去控制面板里面把“密码保护共享”给关掉了还是一样…… （微软在这一点上有点ZZ了，Win10安装过程中必须要Microsoft账号登陆，然而系统内有些地方却仍然需要本地用户账户）

有没有能把视频流的码率绘制成曲线的工具？以时间为x轴，码率为y轴能支持264视频流就够了，有支持265的就更好了

7z吃不满CPU？我CPU八线程，全都选了，CPU利用率才这么点而WinRAR利用率高很多，压缩速度也更快是不是只要找到方法能使7z的CPU利用率提升，压缩速度也会提升？

Vapoursynth有没有办法硬解码？ Vapoursynth有没有办法硬解码？我在编码一个UHD电影，用VS加个字幕而已，CPU占用超高，我的CPU是E3-1231 v3