头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

x264 - 06_taro编译版(r2431)

2011-03-30 21:24

最新版下载:
x264_rev2431_tMod.7z
x264_rev2315+704_tMod-Lite-MacOSX.zip

项目地址:GitHub

解压不能的请去7-zip下载页下载最新版7-zip解压。
上次由 06_taro 在 2014-04-24 15:02,总共编辑 214 次。
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

编译日志

2011-04-13 23:57

2013.04.29 r2315+704
1. 官方r2309有x64的configure時無法自動檢測opencl sdk的bug,反正我這裡直接繞過,2309的8bit全部可以opencl,沒必要出2309-1
2. r2310有個官方bug fix,一般遇不到的小問題
3. r2310->r2315一堆大家都用不了的AVX2和一個看起來沒問題的SSSE3優化,所以直接升上來了

2013.04.24 r2309+704 請買Haswell

2013.04.11 r2274+704v8 修掉一個音頻編碼直接crash的bug,果然與其用不知道哪兒來的patch不如自己寫 {:cat_11} 不過現在儘管不crash了,也基本上沒幾個能用的codec了,得找機會把整個音頻部分按照FFmpeg/Libav的新API重寫一遍= =

2013.04.11 r2274+704v7
1. Subtitles filter重要更新:
  1. 支持和--fps或--timebase/--tcfile-in同時使用,不會再出現無法渲染或者渲染時間錯誤的衝突
  2. 使用subtitles vf的input demuxer不再限制為y4m/lavf/ffms,現在可以使用包括raw/avs在内的任意demuxer
  3. 在發現有使用--sub添加字幕的情況下,自動將輸入轉換為yuv420p8,從而在輸入colorspace不符合subtitles渲染條件的情況下(譬如10bit)時,不再需要手動設定--vf resize:csp=i420:8/subtitles --sub "sub.ass"了,可以直接--vf subtitles --sub "sub.ass"
2. fps的ntsc correction部分修改,使用更安全的方式,不再動timebase,從而防止各種demuxer對timebase定義不統一而導致RP,譬如ffms在2274+704v2裏的問題
3. 特別指出一點,之前說過很多次的mkv内部timecode-scale精度太低導致mkv->mp4時fps jitter的問題,在x264裏直接lavf/ffms讀取時也是可以不通過tcfile-in而直接指定timebase來修正的,譬如24000/1001的cfr可以使用--timebase 1001/24000或者--fps 24000/1001強制cfr,而如果是24p+30p+60p混合的vfr則可以用--timebase 1001/120000,如果tivtc自動2pass出來部分有18p的情況可以用--timebase 1001/360000。因爲現在subtitles與--timebase不衝突了,所以可以在壓制過程中一次性修正,故特此説明一下。

2013.04.07 r2274+704v5
1. TriAQ
2. 重新增加--no-opts,和--opts 0一样,以兼容其他各种custom build的参数,顺便修正多次使用--opts时没有像其他参数一样使用最后一个的bug
3. fgo和yadif的几个小修正
4. opencl lookahead的patch更新,不过这个lite版里偷懒没编译进去…

2013.03.18 r2274+704v3
因为blog里貌似想要10bit的MixAQ/OreAQ的回复不少于是花了几分钟把MixAQ/OreAQ在high bit depth下的crash问题修掉了,正好最近Libav的API有很大调整,故偷懒暂时只有lite版的MixAQ,非lite版或者OreAQ请等下次大版本更新时一起出吧,反正估计需求不大 {:cat_15}
至于坑了很久一直没开的TriAQ计划,估计还是不会开吧(死…

2013.03.09 r2274+704v2
1. 修正部分情况下ffms/lavf读取BT.709的high bit depth源时输出文件错误地自动标记BT.601的问题,感谢akw28888的报错
2. (/!\)--opts参数范围从0~2修改为0~3,其中0和1与原来相同,3与原来的2相同,现在的2是只写x264的参数而不写版本号
3. 对输入的ntsc fps correction从原来的仅在demuxer=avs时有效修改为全输入有效。注意由于部分demuxer内部处理fps非常不规范(包括lavf/ffms在内,lavf目前在修改fps处理流程,不过它目前这种线性读取机制不修改的话结果不保持乐观,至于ffms大概早就没救了,希望liblsmashworks早点出来= =),有可能导致使用这些demuxer时有些无法想象的诡异问题 {:cat_15} ,请养成自行验证输出文件的timecodes的好习惯。

2013.03.08 r2274+704
增加avxsynth的audio支持(非Windows部分)

2013.02.27 r2273+704
avs demuxer中增加自动调用LSMASHVideo/AudioSource及LWLibavVideo/AudioSource来作为源滤镜,现在除了wmv优先dss2、avi优先AVISource以及mp4/qt/mov/m4a/3gp/3g2优先调用LSMASHVideoSource之外,其他的通用型滤镜(及以上格式主要源滤镜失败时的fallback)调用顺序是LWLibavVideoSource->FFmpegSource2->DSS2->DirectShowSource

2013.01.10 r2245+704
因为VapourSynth可以跨平台用(虽然需要自己编译核心/滤镜),于是增加一个MacOSX x64版,其他各种*nix平台有需要可以自己搞,简易流程:http://astrataro.wordpress.com/2013/01/ ... 5704-tmod/

2012.12.27 r2230+702

2012.11.11 r2230+696 (my chinese ime was broken, so no cn changelog {:cat_18} )
1. updated x264 core to 0.129.2230+696
2. (important!!) (should have) fixed a regression in fgo patch, usually occurs on still or slowly moving objects with clean background ( and it is quite possibly that this regression not only existed in my builds but also in many others’ builds with fgo patch ). If anyone used this patch grabbed from rev2085 to rev2216, please replace your patch from here. Thanks \Noir/ for reporting and testing
3. high bit depth y4m support, with skipping depth filter enabled
4. all 8-bit builds except no-opencl ver were built with opencl support ( Catalyst™ 12.9 should have fixed the crashing ), so they need OpenCL runtime installed in your system, otherwise use no-opencl ver instead.
5. added support for .vpy file input via vfw interface (using AVISouce/HBVFWSource):
图片

2012.09.14 r2216+688
2012.09.12 r2216+686

2012.07.20 r2208+677
D_S熬膠了吧r2204給revert了…如果喜歡r2204那種新的進度條樣式的話,tMod裡可以自己用--stylish開啟。注意這種進度條與很多GUI不兼容,詳見doom9各種GUI用戶投訴貼= = 另外--stylish時console標題仍然使用舊的樣式,以免像r2204那樣標題裡顯示的數字前沒有標籤不明所以

2012.05.25 r2200+666
1. x264更新到rev2200,其中threaded-lookahead可以大幅減少lookahead部分出現速度瓶頸的可能性,默認在不開slice-threads的情況下lookahead-threads等於threads/6,而在開slice-threads的情況下等於threads
2. 原來avs為high bit depth時只支持16bit或者等於x264編譯版本的bit depth的輸入,譬如10bit版只支持16/10/8bit的avs,8bit版只支持16/8bit的avs,其他情況下不報錯不警告但是結果是錯誤的,原因是輸入輸出bit depth不等的情況下不會跳過內置depth filter,而16bit hack始終將輸入當作16bit,就算--input-depth=9~15也當成16bit處理;現在增加一個"Use f3kdb for bit depth conversion when needed"的patch,在輸入bit depth不等於16/8或者x264編譯的bit depth時,自動調用f3kdb來轉換bit depth,當然這樣就需要avs自動加載目錄裡有f3kdb插件,反正正常來說這樣用的人應該很少(所以這個問題早就發現了一直懶得去修),真有需求的自己把f3kdb扔avs自動加載目錄內
3. avs根據分辨率自動切換matrix的patch更新,另外增加sws根據分辨率自動切換matrix的patch,雖然我也沒測試現在的對不對,反正sws這種東西能不用就請盡量別用吧= =
4. 輸入源文件後綴名為dgi的時候自動調用DGSource。原來x264只支持輸入d2v時自動調用mpeg2source以及輸入dga時自動調用AVCSource,想想現在DGSource用得挺廣的就隨手加了進去…

2012.04.26 r2197+666
增加ffmpeg版。與libav版區別:
1. ffmpeg的utvideo解碼使用的是libutvideo,經過了SIMD優化,比使用libavcodec內置utvideo解碼器的libav版解碼utvideo的速度更快。而且我這裡測試的有些情況libavcodec解碼utvideo的結果有時候不准確,libutvideo就沒這個問題。如果確定了的話還是把這個問題報給libav/ffmpeg比較好……
2. ffmpeg版支持celt音頻的解碼。libcelt不保證舊版本兼容性,不過最新版本已經穩定(其實是全部移到opus內,celt自己停止開發了)。tMod內的ffmpeg對應的libcelt版本是v0.11.3-19-git-r1588(e18de77)(內附編譯好的單獨的編碼/解碼器)。
3. ffmpeg支持raw輸入時的input-csp比libav多一些:rgba64be, rgba64le, bgra64be, bgra64le, 0rgb, rgb0, 0bgr, bgr0, yuva444p
libav版對應的就是原來不註明版本的tMod。
lite版對應原來的special_offer。
► 显示内容 輸入utvideo時ffmpeg/libav版速度對比
2012.04.22 r2197+664
升級至官方r2197。
音頻編碼部分添加(ff)libaacplus,這樣沒有qtaac的x64版在低碼率也有靠譜的aac編碼器了。libaacplus的bitrate最高只有72kbps,即使設定了更高也會被降到72kbps,而且編碼出來的都是he(碼率非常低的情況下會自動使用hev2)。由於libaacplus與vo-aacenc會衝突,而vo-aacenc中高碼率下質量比faac還差,低碼率更是比不過aacplus,所以直接去掉了。

2012.04.18 r2194+664
1. libav更新,修復了之前libav/ffms解碼時一個會導致crash的惡性bug
2. 更新編碼時顯示內容,增加了已編碼文件的大小
3. 更新VSFilter.dll,增加了icl 12.1編譯的VSFilter

2012.04.08 r2192+664
1. 之前困擾很多人的2nd pass裡開zones有可能導致mbtree被自動關閉的問題官方devel的repo裡修復了,所以雖然不是穩定版也編譯了一個出來
2. 按最新的ITU標準更新了level,支持到5.2
3. Auto VBV Settings的patch更新,增加了"auto_high422"和"auto_high444"

2012.03.24 r2184+663
x264-audio更新,libvorbis的patch被merge,另外支持直接e-ac3->lsmash importer
x264的即時進度顯示刷新時空格增加以保證把之前的進度覆蓋掉。刷屏的請增加console的buffer(width)(感謝ZilcH菊苣提供截圖):
1. 鼠標右鍵點擊命令行的標題欄,在右鍵菜單裡選擇“默認值/Defaults”;
图片 图片
2. 點擊“佈局/Layer”選項卡,將“屏幕緩衝區大小/Screen buffer size”裡的“寬度/Width”調大。一般120左右應該已經足夠了。同時將下面的“窗口大小/Window size”的“寬度/Width”也酌情調大;
3. 保存,退出命令行。之後所有命令行都會按照這個調整過的來運行,就不會再出現刷屏現象了。

2012.03.22 r2184+660
lsmash更新,可以從libav的ademuxer裡讀取audio priming,習慣於蛋疼地檢查delay的可以更方便了……
去除沒人看的spf,增加ets(estimated total size),現在應該沒理由繼續用MeGUI了吧……
图片

2012.03.17 r2184+659v2
之前的版本裡libvorbis都不可用,實際上vorbis用的都是ffvorbis,x264-audio默認把libvorbis屏蔽掉了(貌似是因為要加自己的libvorbis encoder,就像lame/faac那樣,不過已經一年多過去了還沒完成,而且也沒把屏蔽給去掉)。v2裡重新啟用了libvorbis,內核是AoTuV,公認的質量最高的vorbis編碼器。

2012.03.16 r2184+659
libvorbis更新到1.3.3(其實用的是質量最高的aotuv,不過aotuv官方還停留在基於libvorbis 1.3.2的b6.03,這個是自己將libvorbis相關部分更新的,等aotuv官方更新了再說)。libav/ffms/l-smash相應更新。rev2184修正了win32thread的問題,所以繼續用win32thread。

2012.03.11 r2183+656
x264-rev2183的更新會導致win32thread編譯版crash,所以暫時使用pthread,等這個問題官方修復了再說…

2012.03.08 r2183+654
1. x264更新至r2183,libav/ffms更新
2. libav編譯時去除掉無用的lib,減小exe體積

2012.03.05 r2164+652
1. lsmash、libav、vo-aacenc、vo-amrwbenc繼續更新,不編碼音頻不用mp4容器不用lavf/ffms的基本上沒必要更新……
2. gcc直接跳過4.6.3,用的是4.7.0-rc1的,反正看了下基本上在4.6.x基礎上沒有什麼新的regression,速度和4.6.3沒啥區別……

2012.02.22 r2164+651
1. lsmash更新,支持從lavf的ademuxer直接將dts copy至mp4內(原來只能從lsmash的demuxer copy,所以只支持raw dts,現在audio的源可以是mkv等非raw格式)
2. libpack更新,主要是opencore-amr更新至0.1.3,vo-aacenc和vo-amrwbenc更新至0.1.2,然後libav/ffms也姨媽到最新版
3. 理論上修正--opts 0時的問題(和該帖內的修正方法不同,現在應該是正確的了)。不過本來這個bug我就重現不出來,所以實際怎樣自己按需測試……
4. 增加一個patch,防止在--no-progress時顯示mp4 remux過程的信息。

2012.02.07 r2164+649 v2
1. 更新BugMaster的新aq-mode patch。原来的aq-mode=3没有改动,增加了aq-mode=4,现在有两个AutoVAQ的mod了。我个人感觉现在的三个AutoVAQ之间还是aq-mode=3稍微好些(AutoVAQ和VAQ本身区别较大,所以就不和aq-mode=1比较了),仅极少数sample的小测试,不具有指导意义。具体情况还请自己试验。
2. 编译时不再使用--enable-lto。lto对大部分项目来说速度会略有提升,不过x264的情况似乎有所不同,详见这里的测试

2012.02.05 r2164+649
1. 暫時移除avi output的支持,因為其用到的avformat很多API都更新了,懶得去調整,反正估計沒人用……
2. x264官方將內部8->10的轉換算法改成原來patch內的limited range了,所以patch移除。注意現在和原來還是有些不同。原來patch的是limited range用shift,full range用bit dup;而現在無論limited range還是full range都直接shift。考慮到full range根本沒有明確的標準說明應該怎麼轉,所以不再修改,保持現在x264的。
3. lame更新到3.99-4,vo-aacenc和vo-amrwenc也小有更新。其他libav/ffms的日常姨媽就不提了。
4. 增加一個special offer版,該版本沒有interlaced/lavf/swscale/ffms/audio-encode的支持,速度上略快一點,文件也小很多,一般日常使用的avs/raw input還是支持的,raw audio muxer也是沒問題的(--acodec copy --ademuxer lsmash,非raw的輸入不支持mux)。

2012.01.22 r2148+643
1. l-smash继续更新,支持libav的新audio encoding API,所以libav也终于可以更新了。
2. 增加了BugMaster的一个patch,修正最新版x264对packed YUV 4:2:2处理不能的问题。

2012.01.20 r2148+641
l-smash終於更新了,解決了lavf的input/output接口更改導致的加載音頻時有時出現的error問題。順便現在支持了將DTS給mux進mp4的功能,不過目前只能用--audiofile "raw DTS file.dts" --acodec copy --ademuxer lsmash來操作,audiofile為DTS in mkv/mp4或者lavf的ademuxer還不支持。將DTS給mux進mkv則是很久以前就支持了,沒有上面這些限制,這裡順便提一下好了……

2012.01.19 r2148+631
1. 官方更新,修復r2143引入的在trellis=2 + subme>=8時的花屏問題
2. 更新--device,可以通過--device psp+iphone+dxva,--device ps3,iphone,xbox這樣的參數將壓制參數限制在多個device的限制範圍以內。

2012.01.12 r2144+631 好像r2144的10bit/x64版速度快得讓VX大神蕩漾了……確定2144(以及官方的r2145)在CABAC trellis代碼裡有問題,導致使用trellis時有可能出現花屏,勿用!這個修復之前暫時也不會繼續更新plain的官方代碼部分。

2012.01.11 r2140+631
1. devel的git各种high bit depth下的asm优化,10bit版速度也许会快些
2. 增加非官方的--device,其实以后会有官方--device,只不过谁知道D_S到底会不会在世界末日之前放出来,所以我自己随便写了一个,省得各种压PSP、PSV、iPhone版的说不兼容没法放,用法见fullhelp……
3. 将编码过程的fps精度增加到小数点后4位,顺便增加了spf(seconds per frame),一群EP大神们可以看出0.001fps和0.009fps的区别了……
4. fullhelp内增加--zones的帮助文档,防止再有--me tesa --merange 48 --zones 0,2000,merange=64这种其实根本无效的zones设置的出现……

2011.12.29 r2135+631 v2
删除Unicode支持的patch,虽然可以支持Unicode文件名但是会导致ASCII的avs脚本挂掉(当然如果avs脚本内全是英文就无所谓了),而且我自己一直不喜欢这个对Unicode做wrapping的支持方式,所以果断砍掉了,不如等gcc 4.8.0(?)的真·utf-8支持……

2011.12.27 r2135+631
1. x264_L-SMASH在等x264-audio更新,而x264-audio维护人员失踪了,于是还是自己把项目扔到GitHub了。
2. 因为项目git化了用原来的版本号检测脚本会导致和lsmash版本号不一致(vfr_maniac的dangerous git就有这个问题,当然实际上也不影响使用……),所以为了和lsmash的版本号保持一致用了新的版本命名方式(version/fullhelp里),例如“x264 core 120 r2135+631+26 71dfa3f tMod+OreAQ [8-bit@4:2:0 X86]”就是core 120,x264本身版本为r2135,“+631”是指lsmash的branch改动版本,“+26”是指tMod的branch改动版本,也就是我自己在lsmash的基础上修改的版本数,“tMod+OreAQ”是branch名,后面的是bit depth、chroma formats和build arch,对使用者估计有些用处所以放在fullhelp里。
3. 采用的是d_s的devel版x264,主要是因为目前的r2135比official的r2120还稳定些……
4. 增加了Unicode支持,顺便把ffms/lavf输入时matrix的自动检测加回来了。
5. 4:2:2/4:4:4没编译,用的人应该很少,需要的用-all版就可以编422/444了,反正慢不了多少。OreAQ的10bit版去掉了,反正10bit下OreAQ没啥用处,也有人报不管用。

2011.12.12 r2120+630
1. L-SMASH迟迟不merge于是自己建git来merge了……因为相比videolan上的official git,2121多出来的更新是x264内置最新libav时--fullhelp的問題,影响不大(其實我自己都重現出來過了,確實影響不大……),所以还是采用官方的r2120(其实最近又修了不少版本下来了……)。
2. 增加内置字幕渲染,和direct264一样通过--sub "1.ass" --sub "2.ass" --vf subtiltes来支持,譬如PSP用视频可以直接

代码: 全选

x264-8bit.exe --sub "xx.ass" --vf subtitles/resize:704,480,sar=40:33/pad:8,0,8,0 --profile main --ref 3 --weightp 1 --b-pyramid none --acodec aac [Other options] --output "output.mp4" "input.mp4"
,至于colormatrix问题请去找libswscale,我各种不管了……
3. 顺便这个版本开始input为raw时和为avs时一样,当输入输出的bit depth相同时会直接跳过x264内部的depth filter。

2011.12.08 r2121+629
1. gcc更新到4.6.2,lame更新到3.99-3,vo-aacenc更新到v0.1.1-7-g07931e3,vo-amrwbenc更新到v0.1.1-5-g05114fa,增加xavs從而可以直接解碼avs編碼(國產的那個,不是avisynth),其他libav內含的庫文件更新就不列了。另外x264自r2119開始有很多問題,不知是不是這個原因x264_L-SMASH也一直沒有把plain的升級給merge,因此這個算是應求用的非正式更新。
2. demuxer為libav/ffms時的自動range detect暫時去掉了,因為x264內部--fullrange改成--range/--input-range之後需要改的挺多,而反正是非正式更新就懶得去搞了。
3. 編譯時增加了之前patches-rev2106-v5的包內就加入了不過一直懶得編譯的--profile-force。原版x264當檢測到你設定的profile在當前參數下用不到的時候會自動降低profile以增加兼容性,例如--profile high --no-8x8dct時,因為沒有用到high需要的8x8dct,profile會自動被降到main,同樣編碼8bit視頻用--profile high10的話會自動降到high,不知是不是這個原因很多人把10bit的avc與high10 profile的avc給等價了,其實high10、high422、high444都可以放8bit 420的avc流。現在如果指定--profile-force的情況下會阻止x264自動降profile,也就是說可以允許high444來裝8bit 420而不會被自動降低profile到high了。其實這東西沒啥作用,純粹是想糾正一下錯誤的概念而已。

2011.11.14 r2106+629 v3,fgo更新一下,增加了一些指令集优化,不过XOP的优化没测试过(没对应的CPU……)。另外下一个stable版本的x264里--fullrange会取消,改成--range/--input-range,没准这次的这个是最后一个继续用--fullrange参数的版本了。

2011.11.03 r2106+629 v2
1. 昨天偷懶,沒先更新libav,結果正好之前的libav版本解碼Lossless的H.264 4:2:2/4:4:4有bug,於是來更新一下libav/ffms重新編譯了;
2. 去掉了--no-opts,改成了--opts <integer>。默認是--opts 2,也就是和官方版一樣寫x264的版本信息及參數;--opts 1時和原來的--no-opts一樣只寫x264信息,不加參數;--opts 0則x264的信息及參數都不加(貌似direct264默認的no-versioninfo就是這樣?沒用過不太確定)。

2011.11.02 r2106+629,lsmash有幾個比較令人在意的更新,主要是代碼上的,功能基本不變。另外OreAQ有個和chroma-format有關的結構,根據現在的x264分420/422/444/all不同的編譯版在編譯階段做不同處理。

2011.10.24 r2106+624,因为chroma-format在编译时确定的话可以加快一点编码速度,所以除了chroma-format=all的之外也增加了=420/422/444的,反正要改shell直接改EP些,结果跑了一整天,现在解压有40个binaries,总共近600MB,压缩包都达到了25MB,需要的自己选里面的用吧……

2011.10.24 r2106+623,libav支持H.264 4:2:2解碼,所以x264也可以直接吃H.264 4:2:2了。lsmash的更新可以讓x264輸出mp4的時候加metadata和copyright了(至少代碼有了,正式支持估計快了吧,standalone muxer是沒問題了)。fgo和fade-compensate的用法在fullhelp裡加了點說明。最後就是把--tune touhou在fullhelp裡恢復顯示了,你們懂的……

2011.10.16 r2085+619,例行姨媽。由於用到的libav加入了libaacplus,aac編碼可選擇性又多了(不過因為是屬於libavcodec而且是非官方的libavpatch,fullhelp裡不顯示)。

2011.10.01 r2085+616,例行姨妈。修正fullhelp里的profile信息(增加"high422"和"high444"两个可以用但是原来没有在fullhelp里写出来的profile,10bit版隐藏无法使用的"baseline""main""high"三个profile),然后lsmash的给力升级可以让(E-)AC3、TrueHD等格式的音频直接混流进mkv了~

2011.09.23 r2085+607,包括libav及ffms在內的例行姨媽。OreAQ有10bit版了,x264內用lavf/ffms做demuxer時會自動識別color range(libav在更新中,這個功能是否完善還不得而知……)

2011.08.25 r2074+602,libav及ffms更新,另外libav裡的ffmpeg正式改名叫avconv了,要不要放個新的libpack出來呢 {:cat_8} 其實肯定沒人用的吧……順便MixAQ和OreAQ的patch某幾處修正了一下。

2011.08.11 r2059+600,libav和ffms更新,x264轉換bit depth的算法徹底修掉了,雖然因為好久不碰C用的是噁心的外部變量暴力hack法,不過至少對limited range/full range能自適應地做出不同處理了……另外反正2057->2059只有幫助文檔和編譯選項修改了,不影響x264本身性能和穩定性,所以直接跳過2057了……

2011.08.09 r2044+598,ffms因為一些原因沒去更新,Automatically Level的patch去掉了,反正基本上用--level-force就可以做到幾乎相同的事情,而且用參數控制而非強制,對大家來說更加靈活。然後加上了皮神的skip bit depth filter的patch,在輸入輸出的bitdepth相同時不會再在x264的內部進行bitdepth轉換,省得現在鬧得沸沸揚揚的顏色問題,大家可以自行在輸入前級做好8->10的正確處理然後送入x264直接壓制。

2011.08.04 r2044+596,libav和ffms繼續更新,然後把加了aq-mode 3的patch pack放出來,其中MixAQ和OreAQ包含了加在打了aq-mode 3和加在沒打aq-mode 3的patch兩個版本上的兩種diff(其實是方便以後aq不斷改東西時自己方便的|拖……)。

2011.08.02 r2044+594,主要是增加了BugMaster新搞出來的aq-mode 3,據說ssim會上升,反正我沒試過;還有就是SAPikachu菊苣的avs 16bit hack。

2011.07.31 r2044+594,10bit解码各位还是用mplayer2或者madvr吧,嗯我个人渣渣电脑不想被mplayer2鄙视也不想被madvr卡死还是继续等0.32已经正式merge了lav video的lav filters……话说x264的422编码也即将出炉了,想尝鲜的可以去x264_422@github抓一个自己编译玩玩~

2011.07.25 r2037+592,使用的libav更新到0.7.1 stable,不過懶得傳libpack了囧……10bit需求挺大的所以也編譯了一份,不過MixAQ和OreAQ不支持10bit所以只有8bit版。(其實23日添加了10bit的r2019+587,只不過剛編譯好r2037的正式版就放出了囧,所以沒發布……)

2011.07.22 r2019+587,libav更新,全部用gcc 4.6.1正式版重编译(包括libpack),gcc4.6.0去用这个libpack的话可能会有一些不支持(譬如libgsm),patch更新很大,考虑要不要编译个10bit出来……

2011.06.22 r2008+574,libav更新至0.7正式版

2011.06.16 r2008+573

2011.06.06 libav更新,并增加了Dark Shikari的fork版的4:4:4解码支持(对应ffh264解码)

2011.06.05 r2004+555,lsmash的更新包含了一个平时有可能遇到的bug修正,所以重编译了一下。顺便用到的libav更新。

2011.06.04 r2004+553,看x264-devel的commit现在x264内置的resize滤镜使用的libswscale更新了,所以包含libav、polarssl、xvid、libvpx和x264的libpack全面更新。

2011.05.28 r2002+550,用到的libpack全面更新。另外x64的libav也通過polarssl增加了librtmp的支持。順便問了下vfr_maniac,他目前沒有把OreAQ改成aq3整合到MixAQ中的計劃,所以到暑假我再看看有沒有時間自己改出個TriAQ吧……

2011.05.18 r1996+537,用到的libpack更新

2011.05.14 r1995+536,用到的libpack更新。L-Smash更新,并重新增加OreAQ版,fgo等少数patch进一步优化,主要是增加avx的优化范围以及结构性调整。libav和ffms加入-Ofast优化,顺便让x64的libav也加入了xvid的支持。

2011.05.12 r1995+533,libpack更新,AoTuV版替換官方版libvorbis(公認比官方版質量好的),vo-aacenc和vo-amrwbenc還是自己編譯了下新版的,libav也隨git更新,理論上是完全支持10bit解碼的(雖然手頭沒法測試),然後增加了orc和libshroedinger來支持dirac的無損視頻編碼,雖然libav的config過程還是沒有成功所以libav編譯版裡沒用到……順便libav不再限制硬件加速,反正作為類庫也沒影響……

2011.05.11 r1994+531,顺便自己编译libpack来用,於是初次編譯libav。gpac比较变态,opencore-amr和vo-aacenc/vo-amrwbenc版本号没变,所以这几个沿用sada-maru/xhmikosr的,其他自己抓了新版本编译。包括libav、ffms、faac、gpac、lame、libogg、libvorbis、opencore-amr、openjpeg、speex、theora、vo-aacenc、vo-amrwbenc、vpx、xvid,基本上libav、ffms和x264编译过程中用到的东西都包含了……

2011.05.09 r1947+530
加了两个patch,自动level,以及当输入demuxer为ffms/lavf时显示ffms/lavf分析得到的文件信息。

2011.05.06 r1947+529 v3
用gcc 4.6.x新增的-Ofast编译,速度按某人语是
gcc4.5系と比較し、同一のエンコード結果が得られるかチェック済み。私の環境ではgcc4.5.2と比較し約1.5%~1.9%の高速化
,如果哪天萌蛇想再跑一次138天的loop,而且不是靠EP avs而是靠EP x264的话,应该可以节省两三天的时间 {:cat_11}

2011.05.05 r1947+529 v2 修正--no-opts不能使用的问题,改diff的时候出的错,因为自己不用这东西下所以一直没发现= =

2011.05.03 r1947+529
gcc更新到4.6.0,顺便libpack内所有libs都更新为sada maru的gcc 4.6.0的编译版(sada不用的libfaac也自己
上次由 06_taro 在 2013-04-30 23:56,总共编辑 130 次。
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

头像
dgwxx
管理猿
帖子: 770
注册时间: 2010-09-19 20:42
联系: 网站

Re: [置顶] x264 06_taro编译版 (4月13日更新)

2011-04-14 0:45

管理员:
把taro的帖子分离出来了。
日常推 @dgwxx: 基本没什么技术的话题,欢迎没事看看消遣。
&#9658; 显示内容 平庸的rip
&#9658; 显示内容 “不知道”的五大理由

头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: [置顶] x264 06_taro编译版(4月16日更新rev1937+505)

2011-04-16 11:12

呃,弱问下
x264 0.115.1937+505_tMod 6629997
这版的nonfree是yes是什么情况……只是要确保unredistributable...?

头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: [置顶] x264 06_taro编译版(4月16日更新rev1937+505)

2011-04-16 14:24

其實這個binary是不能發布的……

因為faac是non-gpl的,在編譯x264的時候必須nonfree,當然也可以自己改configure來去掉nonfree,但是區別在版權上而不在功能上,所以沒必要去自欺欺人

如果不把faac編譯進去的話就可以不用nonfree了……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

头像
upyzl
帖子: 446
注册时间: 2010-12-25 18:44
来自: 湘/京
联系: 网站

Re: [置顶] x264 06_taro编译版(4月16日更新rev1937+505)

2011-04-16 14:48

了解~~~(才知道自己已经蠢到连faac和ffaac都分不清了- - 我这么多年都犯了多少错误orz...

头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: [置顶] x264 06_taro编译版(4月21日更新rev1937+517,增加OreAQ版)

2011-04-21 8:31

現在l-smash裡qtaac也必須要nonfree了,而libvo_aacenc沒用過不知道質量咋樣,所以更要堅定不移的xxxx了……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

头像
4h4h270
帖子: 163
注册时间: 2011-04-10 17:59

Re: [置顶] x264 06_taro编译版(4月26日更新rev1947+523)

2011-04-27 13:32

qtaac编码的--aextraopt怎么用啊 {:cat_5}
帮助是这样
--aextraopt Profile and bitrate mode
sbr : enable HE-AAC encoding [0]
mode : bitrate control mode [abr]
"abr", "cbr", "cvbr"
我用 --aextraopt 1一直报错...--aextraopt sbr:1也不行....

头像
06_taro
核心会员
核心会员
帖子: 998
注册时间: 2010-09-22 18:32
来自: United Kingdom
联系: 网站

Re: [置顶] x264 06_taro编译版(4月26日更新rev1947+523)

2011-04-27 16:04

4h4h270 写了:qtaac编码的--aextraopt怎么用啊 {:cat_5}
帮助是这样
--aextraopt Profile and bitrate mode
sbr : enable HE-AAC encoding [0]
mode : bitrate control mode [abr]
"abr", "cbr", "cvbr"
我用 --aextraopt 1一直报错...--aextraopt sbr:1也不行....
--aextraopt <string> Pass extra option to codec [codec specific]
Should be comma separated "name=value" style
其实在qtaac之前audio部分还有这个说明
aextraopt就是audio extra options,所以用paraName=paraValue的方式使用,类似--zones的用法

如果要sbr的话

代码: 全选

--aextraopt sbr=1
其他模式例子

代码: 全选

--aextraopt mode=cbr
注意cbr、abr和cvbr需要配合--abitrate使用,譬如

代码: 全选

--abitrate 128 --aextraopt mode=cbr
fullhelp里方括号里面的就是参数例子

话说qtaac最大的优势就是tvbr,l-smash里默认用的也是tvbr,但是tvbr和sbr不兼容,要是非要用sbr的话我觉得还不如上Nero……
つまんねー事聞くなよ!

I, personally, for me, believe (obviously sometimes) that my OS choice is right. That's me. I'm not telling you that you should believe it. Learn the facts, and the origins behind the facts, and make up your own damn mind. That's why you have one. (source)

Follow me: @06_taro

304——
为纪念伟大的宇宙史上最强压制304先生,联合国教科文组织决定,将每年的第304天,即平年的10月31日或者闰年的10月30日,定为世界304日。

头像
4h4h270
帖子: 163
注册时间: 2011-04-10 17:59

Re: [置顶] x264 06_taro编译版(4月26日更新rev1947+523)

2011-04-27 19:05

谢谢
我傻了 --aextraopt <string> Pass extra option to codec [codec specific]
Should be comma separated "name=value" style

这段就写在上面一点,都没有看到 {:cat_5}

回到 “视频编码器 / Video encoder discussion”