正常來說非實時編碼需求的話編碼速度遠低於cuvid解碼以及拷回內存速度，而cuvid會讓顯卡始終處於最高功耗狀態（即是只用1%的gpu），所以： 1. 功耗越低越好 2. 價格越低越好。如果是帶iGPU的CPU的話更是如此，可以讓DGNV解碼，其他應用全邊移到iGPU上保證穩定性（當然前提這是壓片機完全不考慮其他負載需求）。如果不帶iGPU的話，解碼剩餘的dGPU資源至少要保證系統桌面渲染不卡，一般來說中低端N卡應該都沒問題 3. DGNV更新時有可能會提高PureVideo版本需求（即是沒提高最低需求，使用新版本指令的效率甚至deint等pp的效果也可能不同），所以保持以後升級兼容性的話盡量...

fch1993 写了：你这个 輸出color space的方式也改的不对吧。

对于rgb48输入，居然是rounding输出RGB32，我都快瞎眼了。

不应该是madvr输出y416 evr渲染器dither输出rgb32吗。

lavf的pixel fmt converter輸入的rgb只能到argb32，沒有更高的，轉換是FFmpeg內部完成的

話說您在哪兒看到我說過有修改rgb輸入時的csp選擇邏輯了？
哦抱歉您都快瞎眼了當然只能睜眼說瞎話，當我沒說好了

其實現在最缺少的不是什麼視頻教程而是Google使用教程吧… How_to_Google.png avspmod 谢谢，我试了一下，但是发现定位帧经常需要很长的时间，甚至卡死，有办法解决么？ avs样本： FFIndex("00013.m2ts", demuxer="lavf") FFVideoSource("00013.m2ts", threads=1, seekmode=0) LanczosResize(1280,720) 首先要seekmode=-1 吧 然後這是線形解碼 不能現在在100fps 突然要預覽1000fps這樣 要...

fieldbased丟給taa肯定直接報錯… 上面這個還根本沒丟半場… 倍高沒shift… 很多官方渣deint/pullup再渣upconv再i剪輯/pulldown導致的問題分單場之後deint比aa更好 譬如[syntax lang="avisynth"]TFF = GetParity SeparateFields AssumeFrameBased TFF ? AssumeTFF : AssumeBFF di = QTGMC E = di.SelectEven O = di.SelectOdd ConditionalFilter(E, O, "E.CFiel...

你不是想問進度麼，那就直接問好了
OpenCL的東西是muggs搞的，如果他在的話直接問他
如果只是要patch的話，目前他放出過的最新的這裡有（僅稍微調整了一下API）。編譯好的成品頂樓裡都有，舊版在我的MF文件夾裡也都能找到。之後至少在IRC上還沒有更新的。

qtaac編碼用的是apple的quicktime組件
如果有64-bit的quicktime（其實iTunes也行）
當然就可以讓64-bit的x264也支持qtaac
所以這得去找蘋果…

HEVC最終spec明年才完全確定，現在只有draft，現在做出來的東西以後沒法保證還能用，一般也不會有編碼相關的東西隨便放出來（04年左右給x264寫了一些asm的人有一個和x264完全沒關係的項目叫 x265 ，目前算是除了官方HM之外完成度較高的一個實現吧…）。標準化的東西，肯定都是至少初版標準確定，才會出現成熟的實現，而不會反過來搞的。Libav的HEVC解碼器倒是一直有人在做（ https://github.com/smarter/libav/commits/hevc ），雖然好像並不是直接接下今年GSoC項目，而且同樣在最終標準出來之前不會merge。另外相比HEVC來說其實開源社...

不，除非極其RP地瓶頸卡在pipe buffer上之外應該是一樣的

好的下次libx264用all吧，现在是偷懒直接把x264 lite版给link进去…
其实现在也可以pipe给x264…

从头到尾不代表一定是线性seek。很多时候滤镜本身会要求一个前后帧序列，但是它不一定内部cache好。更不用提使用了Trim、Splice等NL操作的情况。 即使你是真的从头至尾的线性seek，Haali或者dshow滤镜的工作机制仍然会导致frame accuracy受影响： 像DSS2之类的源滤镜为了可以让非线性seek的滤镜正常工作，自己使用了一个在任何情况下对于请求帧都在当前GOP（如果可以获取的话）内像前后做一次framecount correction的机制，即使你是完全裸压根本不需要它这么做的情况。因为DSS2不知道你后面想怎么做，它始终使用统一的处理方式。问题是这个基于Haal...