很奇怪,片源已看过,最后两帧是没有重复的,压制的是红花坂上的海,H264 TS的,用的是DGAVCINDEX作的分离,一开始以为是压制的问题,重压了一遍,最后还是有重复两帧(本故事纯属虚构的那个画面)
后面觉得可能是DGAVCINDEX的问题,但挂DGA在AVS上看最后两帧也是黑的(即正常画面),所以就觉得奇怪,应该不会是参数问题吧?因为压别的都没这样重复的啊?
不知道所以想请问是什么造成这样的奇怪事情?
请问大大,我是ATI显卡,没办法用DGINDEXNV,那要分析BD视频应该采取什么方式才行呢?DIRECTSHOWSOURCE实在不想使用这个方法,请问还有别的工具能分析TS然后丢给MEGUI处理吗,或者说其他的压制者是怎么处理BD的M2TS的?06_taro 写了:以前在TS上遇到过很多次,症状基本相同,使用的源滤镜是DGNV r2013,预览没问题压出来就RP了,avs内产生影响的操作都是线性的(为了去除trim的影响还出过几次无损半成品来测试),最后两帧出现的重复基本上都来自于之前1~2个GOP的起始帧,另外当时的显卡驱动本身不是很稳定,不知道能不能作为参考。
PS. DG系列比较早期的很多个版本对H.264流GOP的M/N判定都存在一些问题,尤其是影响IDR间距的N判定很少准确的,不知道是不是导致GOP定位问题的原因。还有如果一个GOP跨了两个TS文件(在TS里是允许的,只要解码时这两个TS都导入DG的话,理论上应该先正确合并为一个GOP并准确解码,而不需要像Open-GOP那样每一帧都处于缺少关键帧而进行修复状态的解码)的情况DG系列也一直有问题,直到最近某个版本的DGNV才刚刚修复,DGDI和DGAVC这些不再更新的东西应该一直有这个bug。
大大说的太复杂了,请问线性和非线性是什么东西呢,是代表视频的i和p吗?SEEK和SEEKMODE是什么东西?还有THREADS=1是代表什么呢?1线程吗?06_taro 写了:progressive的h.264的话,用ffms,demuxer限定lavf,seekmode限定0或者-1,这样出来的结果应该是精确的:
FFIndex("input.m2ts", demuxer="lavf")
FFVideoSource("input.m2ts", threads=1)
但是这样的话没法进行非线性seek,写脚本时需要注意。
如果一定要进行非线性seek的话,跨度不大时可以用FrameCache或者MP_Pipeline的prefetch,跨度大的话还是用libav/ffmpeg进行一次remux成mkv再用FFVideoSource("remux.mkv", threads=1)吧(这样也不需要lavf的demuxer)。ffms的官方文档里说用haali的mkv muxer也行,或者eac3to的(本质还是haali),不过我试出来haali的也容易RP,liti姐说libav/ffmpeg出来的没问题。
interlaced的h.264流貌似现阶段除了最新版DGNV+稳定的NV驱动之外几乎没有完全无RP的方法。我自己也是A卡,用的是DGDI,比较注意的话一般也问题不大…
请问大大libav和ffmpeg应该在哪个地方载入呢?06_taro 写了:这么说吧,拿到一个m2ts,先用
FFIndex("input.m2ts", demuxer="lavf")
FFVideoSource("input.m2ts", threads=1, seekmode=-1)
加载,如果需要上滤镜的话后面加上滤镜,然后拿去跑。如果没问题跑完了,就确实没问题了;如果跑到一半报错了,那通常就是非线性seek导致的(seekmode=-1时出现非线性seek会直接报错)
具体可以参见ffms的文档,MeGUI里的ffms文件夹下的doc里有。
libav和ffmpeg是工具,编码区有下载。