作者查詢 / falcon
作者 falcon 在 PTT [ AVEncode ] 看板的留言(推文), 共430則
限定看板:AVEncode
看板排序:
全部PC_Shopping2287PlayStation1950MH1113MobileComm946Steam482AVEncode430Gossiping324Android249Windows214EZsoft64ck49th32252Headphone33Storage_Zone32Kaohsiung24Google15TY_Research14Key_Mou_Pad12C_Chat9OverWatch6AfterPhD5Patent4AC_In3Baseball3Brand2FORMULA12HardwareSale2HatePolitics2LCD2Military2movie2Depstore1joke1RealMadrid1Wine1<< 收起看板(34)
6F→: 原文還真的會用 file size / weight03/30 03:25
19F推: mp3以目前的眼光來看確實低效率,且相容性也不是特別突出06/10 05:29
20F→: 隨著時代演進,不是舊格式相容性變差,而是新格式追上了06/10 05:36
21F→: 以音質來說位元率越低越要注重壓縮效率,所以實際上是影片06/10 05:47
22F→: 長度不夠長,或聲道不夠多,所以新編碼格式較高的壓縮優勢06/10 05:47
23F→: 帶來的體積大小差異不能突顯出來06/10 05:47
24F→: 相容性越高越好那大家影片繼續用mpeg2video+mp3就好了06/10 06:03
25F→: 更何況YT就直接提供高效率的格式,直接remux 就好,除非是06/10 06:16
26F→: 為了製作標準影音光碟,否則沒任何理由重新編碼06/10 06:16
27F→: 重新編碼只建議,為了節省空間或保證相容,例如製作有嚴格06/10 06:20
28F→: 參數規範的標準影音光碟如AVCHD/BDVideo06/10 06:20
1F推: 看起來像是程式bug,建議你嘗試其它版本或是handbrake03/07 17:08
2F→: vidcoder只是handbrake核心套上不同介面而已,而且現在已03/07 17:14
3F→: 經有正體中文化了,免安裝版還能可攜化03/07 17:14
4F→: 將portable.ini.template重新命名portable.ini.template03/07 17:14
5F→: 更正 portable.ini03/07 17:15
6F→: 若都不行可能就要改用ffmpeg之類的進階工具了03/07 17:16
10F推: 注意 -framerate 和 -r 是同一個選項,重點是順序09/25 14:54
11F→: 你要指定輸入或輸出fps 是根據選項的位置09/25 14:54
12F→: ffmpeg -r in_fps -i INPUT -r out_fps OUTPUT09/25 14:54
13F→: in_fps 就是 1/每張圖片秒數 out_fps 則是輸出fps09/25 15:00
7F推: 位元率控制不要使用平均位元率方法,因為依照每個畫面的複06/19 00:47
8F→: 雜程度不同,所需的資料量也不同,平均位元率方法採先決制06/19 00:47
9F→: 這可能導致影片前段位元率分配過高,而後段位元率為了讓輸06/19 00:47
10F→: 出平均位元率達落在使用者設定值而下修,造成前後品質落差06/19 00:47
11F→: 推薦使用CRF指定一個目標品質,它會根據目標畫質決定位元06/19 00:52
12F→: 率分配,缺點是輸出檔案的平均位元率是不可控制的,但不是06/19 00:52
13F→: 製作標準光碟影片的花也不需要強迫控制位元率在某個值06/19 00:52
14F→: 另外x264的veryslow preset其refs值高達16,這沒必要的06/19 00:59
15F→: 你可以強制指定refs在合理值4或5,或是用level來限制refs06/19 00:59
16F→: 大致上用 crf 18 + veryslow + ref 5 其他參數看情況調整06/19 01:01
17F→: 至於工具,相同過濾器、編碼器、參數設定,轉出來是一樣的06/19 01:04
18F→: 主要是差在介面有給你哪些選項,跟用起來是否順手06/19 01:05
19F→: 另外2pass方法只是讓位元率分配接近CRF方法,不是做標準光06/19 01:11
20F→: 碟影片,沒必要2pass浪費2倍時間控制特定檔案大小06/19 01:11
21F→: 上面的crf跟ref是值根據x264編碼器,x265的甜蜜點不同06/19 01:16
27F推: refs是reference frames,handbreak有提供cli參數輸入框,06/22 09:45
28F→: 規則同ffmpeg的-x264opts或-x264-params選項06/22 09:45
29F→: key[=value][:key[=value]][:key[=value]]...06/22 09:45
30F→: crf就是依據觀感品質分配位元率的方法,比你憑感覺可靠06/22 09:51
31F→: 真的不想要太大檔案可以把設定值拉高些,犧牲一些品質06/22 09:53
32F→: 或是說跑1st pass crf + 2nd pass bitrate06/22 09:57
33F→: 1st pass crf禁用快速編碼 輸出檔案 大小ok就不跑2nd pass06/22 10:00
34F→: 太大再用2nd pass bitrate指定大小06/22 10:02
35F→: 就是一個以目標品質為主 太大再依前次的結果下修06/22 10:04
36F→: 的花式方手法 沒太大意義 因為通常都是品質更重要06/22 10:05
37F→: 因為也只有標準光碟影片真的有必要特別控制位元率06/22 10:07
38F→: 至於去噪點我推薦nlmeans或waifu2x,前者ffmpeg有支援06/22 10:26
39F→: 後者ffnpeg不支援你可以把影片轉圖片再餵它06/22 10:28
40F→: 但是你要有心裡準備 處理速度會非常感人06/22 10:29
54F推: 如果需要fdkaac編碼器的ffmpeg可以用自動編譯腳本07/01 23:29
55F→: https://github.com/m-ab-s/media-autobuild_suite07/01 23:29
56F→: 不過要追求品質我會寧願用ffmpeg解碼通過管道餵qaac07/01 23:32
57F→: 浪費大量時間就為了效率好一點編碼器07/01 23:45
58F→: 還不如去下載itunes挖他的編碼器來用ffmpeg+qaac07/01 23:45
59F→: 你指定了level編碼器會根據設定值與解析度限制合適的refs07/02 00:18
60F→: 但如果你強制指定refs就不需要指level,但如果你兩個都指07/02 00:18
61F→: 定,那實際只會應用refs設定值,level會變成單純的標籤07/02 00:18
62F→: 就像泡麵包裝外寫的內容物,跟裡面實際的內容物是兩回事07/02 00:18
65F→: refs有甜蜜點,所以才會推薦你直接指定4或5,除非輸出的07/02 02:05
66F→: level會過高才需要,考慮指定level讓編碼器決定refs07/02 02:05
67F→: ffmpeg不支援unsharp,如果你要寫腳本,handbrake有cli版07/02 03:00
68F→: 更正,ffmpeg目前不支援lapsharp07/02 03:01
71F→: 試過ffmpeg的nlmeans_opencl嗎?gpu比cpu快上許多...07/02 20:30
72F→: -init_hw_device opencl=gpu -filter_hw_device gpu07/02 20:35
73F→: -hwaccel opencl -i input.avi -vf "hwupload,07/02 20:35
74F→: nlmeans_opencl,hwdownload,format=yuv420p"07/02 20:35
81F→: 我是突然想到要回應原PO嫌nlmeans太慢這點07/03 00:09
82F→: 我對銳化沒什麼需求,上面就我所知的而已07/03 00:09
83F→: 上面的範例,hwupload前方也要加上format=yuv420p07/03 01:33
5F推: frame絕大多數不是完整的,解碼時需要依賴其他frame的資料06/20 02:04
6F→: 才能得到完整的畫面,就算能播放也是一堆破圖06/20 02:04
1F推: 一個圖場相當於只有一半畫素的影格,1圖場對1影格之間轉換11/10 20:48
2F→: 只是插補或去掉像素,流暢度應該不變的11/10 20:48
3F→: 將兩個圖場合成一個影格會使流暢度減半,但能得到更好品質11/10 20:51
4F→: 你原本的影片嚴格來說不是30影格/秒而是60圖場/秒才對11/10 20:59
5F→: 所以實際上相當於60fps但每個影格只有一半畫素11/10 21:01
6F→: 30fps是將兩個圖場當一個影格合計之後的結果11/10 21:03
7F→: 但它實際上並不是每秒30影格11/10 21:08
8F→: 交錯式掃描的影片不是由連續影格組成而是連續圖場組成11/10 21:11
30F→: http://tinyurl.com/yxkuu96p11/11 12:21
31F→: frame = 影格 或 畫格 也就是對岸所說的 幀11/11 12:26
32F→: field = 圖場 只有一半像素(單/基數行)的畫面11/11 12:30
33F→: 兩個圖場可以換算成一個影格 例如60i換算成30fps11/11 12:31
34F→: 數位相機是60fps拍攝→60i儲存 每個圖場都是不同時間點11/11 12:34
35F→: 所以這種類型的60i影片反交錯→30fps流場度會減半11/11 12:35
36F→: 所以實際上怎麼處裡是要看片源類型11/11 12:38
37F→: 而如果只有某幾畫格交錯可能就是TeleCine11/11 12:49
38F→: 此時你就必須用Field Match(圖場匹配)的方式來消除交錯11/11 12:50
39F→: 對於NTSC60i用 -vf "fps=30000/1001,fieldmatch,decimate"11/11 13:18
40F→: 如果是混合類型(例:TC+原生交錯)或其他各種情況...11/11 13:21
41F→: -vf "fps=30000/1001,fieldmatch,bwdif=deint=1,decimat"11/11 13:22
42F→: 應該都可以用上述方式處裡11/11 13:22
43F→: 如果你不確定你的影片是什麼類型就試看看這個11/11 13:27
44F→: 60i到30fps會使流暢度減半是對於數位相機拍的片源11/11 13:47
45F→: 至於TC的60i還原成原生fps是30沒錯11/11 13:49
47F推: 就我小時候的記憶玩遊戲只聽過掉格沒聽過掉幀的11/11 14:10
48F→: 幀應該是很早傳入外來用語11/11 14:12
50F→: http://terms.naer.edu.tw/detail/2453802/?index=311/11 14:37
53F→: 看來意義上是相通的,不過我記得以前台灣的習慣不是用這字11/11 14:44
57F→: 更正ntsc 60i 3:2 pulldown 還原原生是24p才對11/11 15:49
58F→: 扣掉圖場匹配後產生的重複影格11/11 15:54
59F→: 如果你確定是此類型可直接用 -vf "pullup,fps=24000/1001"11/11 16:11
60F→: 另外 fieldmatch不支援vfr輸入所以前面要用fps=30000/100111/11 16:18
61F→: 將輸入固定為cfr11/11 16:18
62F→: 如果確定輸入是cfr則可省略11/11 16:20
78F→: 提醒一下 靜態片段就算是交錯式掃描也不會出現梳狀線11/12 15:37
79F→: 你必須找一個連續動態的片段來檢查梳子狀線出現頻率11/12 15:37
80F→: 頻率2/5就是TC 3:2 pulldown11/12 15:41
22F推: 所謂的重新編碼就是還原始無壓縮格式後再進行壓縮編碼10/16 21:22
23F→: 也就是說檔案能變多小是由壓縮格式與參數決定10/16 21:22
24F→: 並不是比原本大就是無損或這比原本才是有損10/16 21:22
25F→: 經過有損編碼一定是會損失訊息,無論檔案是比原本大或小10/16 21:24
26F→: 也就是說若要達到縮小檔案且目視無感損失,你的目標格式與10/16 21:32
27F→: 參數的壓縮效率就要比片源的還要強才行10/16 21:32
28F→: 更高的壓縮參數可以讓畫質/位元率的效率更代價是轉碼時間10/16 21:35
29F→: 至於真無損對於一般人是沒有意義的,假設無損壓縮是無壓縮10/16 21:45
30F→: 格式的1/10大小,那有損壓縮可能做到1/100大小無感損失10/16 21:45
31F→: 兩者的差距是極大的 真無損通常是當暫存檔使用 不適合保存10/16 21:46
32F→: 常見的h.264編碼器QP 0就是真無損壓縮 你好奇可以試試看10/16 21:50
33F→: 我所說常見的 h.264編碼器 是指 x26410/16 21:51
34F推: 你要是把有損轉無損轉無損只會得到超巨大檔案 因為過程10/16 22:23
35F→: 實際上就是 有損壓縮格式→無壓縮格式→無損壓縮格式10/16 22:23
36F→: 只要是有損轉有損一定會損失訊息 不是同格式同參數就無損10/17 03:06
37F→: 要無損只有兩種 直接複製視音訊資料流 或是轉無損編碼10/17 03:06
38F→: 另外再說 分割檔案 若是要以複製形式而不重新編碼 你只能10/17 03:19
39F→: 挑某些時間點 因為壓縮格式的關系 並不是每張影格都是完整10/17 03:19
40F→: 的大部分影格都必須 依賴其他影格的資料 自由挑選剪接時間10/17 03:19
41F→: 點 你必須以重新編碼來產生新的結構10/17 03:19
4F推: 看起來VidCoder是先將字幕會到影像上才縮放到畫面10/09 16:43
5F→: 所以當畫面縮放到正確比例後 字幕反而連帶被壓扁了10/09 16:44
6F→: 你可以嘗試用Aegisub將ASS字幕樣式水平縮放設定為54%10/09 16:44
7F→: 這樣字幕被壓扁後應該會變成正常比例10/09 16:46
8F→: 因為播放軟體是先縮放畫面再繪製字幕所以字不會受縮放影響10/09 16:48
9F→: VidCoder無法改變視訊篩選器順序所以就只能從字幕著手10/09 16:57
10F→: ASS水平縮放應該是75%才對 前面算錯了...10/09 17:01
11F→: 也可以直接用記事本開啟ASS改ScaleX為7510/09 17:05
12F推: 不好意思 (720/552)/1.850.7才對10/09 17:25
13F→: (720/552)/1.85約0.7才對10/09 17:26
14F→: 所以 ScaleX,ScaleY 設定為 70,10010/09 17:28
15F推: 如果你是要將字幕燒錄在影像上是什麼格式都沒差10/15 01:54
16F→: 因為最後變都是變成影像的一部分10/15 01:54
17F→: 如果你只是要將字幕與影音封裝在同一檔案才需要考慮格式10/15 01:55
18F→: 因為封裝的字幕格式要考慮檔案格式或播放器能不能支援10/15 01:57
19F→: 如果字幕最是燒死在影像上 那又何必轉成sub?10/15 02:10
20F→: VidCoder目前就支援直接將外部ASS繪製到影像上輸出10/15 02:10
21F→: 沒有必要先傳sub,若你只是學習處裡sub來源,我建議換工具10/15 02:10
22F→: 例如ffmpeg會比vidcoder適合10/15 02:10
23F推: https://m.mobile01.com/topicdetail.php?f=510&t=446283610/15 02:28
1F推: mp3只支援雙聲道,flac是多聲道嗎?09/30 17:08
2F→: 是否排除因為聲道縮混導致音量改變?09/30 17:08