Re: [請問] 同片源1080p與720p同流量下的畫質

看板AVEncode作者 ( )時間12年前 (2011/11/08 13:05), 編輯推噓3(3推 0噓 63→)
留言66則, 6人參與, 最新討論串2/3 (看更多)
首先 影片的檔案或許長這個樣子 9fearare8y094yqa35qa280824Wderoeroq304e,lq43l2%$@^%#%$wtrtr54@%$^@$%^$%^$.... 把這串意義不明的資料流"正確地"轉化為一個個"有意義"的畫面 -- -- | | | o | | /O\ | | / \ | | | -- -- 這個工作我們稱為Decode(解碼) 做這件事情的東西叫做Decoder(解碼器) 所謂的影片流量指的是"最原始"的那串意義不明的資料流速度 我個人粗淺的理解 影片播放的時候應該是這樣子的 |-------| |-------| 影片資料流->|Decoder|=>"有意義的畫格"->|filters|=>"經過filters處理後的畫格" |-------| |-------| | |--------| | 輸出成你看到的影片<="放大或縮小處理後的畫格<="|Renderer|<-- |--------| 以H264處理上的複雜度來說 大部分Decoder>filter>Renderer 就是說把一串不明的資料流轉化為有意義的畫面比把現成的畫面放大縮小還來的複雜 而且Resize的時候資料並沒有被"丟失" 只是在輸出端前被"處理" 原本的資料流還是不停地被處理著 我覺得這是skyzer沒有搞懂的地方 所以我覺得上面madVR那篇推文中討論的事情基本上沒甚麼好講的 Deinterlace只是filter的一種 只要是可以取消或調整強度的功能 嚴格來說都不會是Decoder程式模塊的一部分 他只是一個外掛的filter 只是有些filter的優先權可能很高讓你以為他是Decoder的一部分 但程式內部的架構和你眼睛所見是不會一樣的 老實講我對filter和Renderer的關係理解不精 或許有誤煩請指教@@ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.34.214.97 ※ 編輯: y3k 來自: 114.34.214.97 (11/08 13:28)
推
11/08 13:29, , 1F
對 我的問題就是在"處理"這部分上 我以為處理的方法就是進
11/08 13:29, 1F
→
11/08 13:31, , 2F
行資料刪減以達成畫面縮小的目的 所以才會用"丟失"這個詞
11/08 13:31, 2F
→
11/08 13:32, , 3F
不過處理方式是不是真的如此 我並不清楚@@"
11/08 13:32, 3F
→
11/08 13:35, , 4F
所以我知道原本的流量是不變 而我的疑問是有用在"看到的影
11/08 13:35, 4F
→
11/08 13:38, , 5F
片"的資訊流上 感謝y大的回覆!
11/08 13:38, 5F
→
11/08 16:24, , 6F
實務上decoder多半會直接加入deinterlace的部分 不需要
11/08 16:24, 6F
→
11/08 16:24, , 7F
另外再接一個dshow deinterlace filter在decoder後面
11/08 16:24, 7F
→
11/08 16:26, , 8F
可以參考coreavc/MPC/CL video decoder各家的設定畫面
11/08 16:26, 8F
→
11/09 08:08, , 9F
呃..我覺得Deinterlace和撥放Interlaced影像不是一件事耶
11/09 08:08, 9F
→
11/09 13:39, , 10F
影片播放時是誰在去交錯? 如何確定? 這點可能要先弄清楚
11/09 13:39, 10F
→
11/09 14:03, , 11F
ffdshow raw video filter、DXVA、AviSynth
11/09 14:03, 11F
→
11/09 14:04, , 12F
未必是用decoder提供 也不是每個decoder都有附帶 也不是每個
11/09 14:04, 12F
→
11/09 14:05, , 13F
人都滿意附帶的去交錯演算法 或許付費軟體多有附帶去交錯
11/09 14:05, 13F
→
11/09 14:06, , 14F
但開源或免付費軟體不代表「多」或「都」有
11/09 14:06, 14F
→
11/09 14:07, , 15F
一個powerdvd產品不代表全世界
11/09 14:07, 15F
→
11/09 14:08, , 16F
即使是MPC internal MPEG2 filter或CoreAVC都有提供interlace
11/09 14:08, 16F
→
11/09 14:09, , 17F
輸出 這就是給使用者自行選擇去交錯方法
11/09 14:09, 17F
→
11/09 14:13, , 18F
如果你覺得手邊有很多自帶去交錯的decoder 那恭喜你
11/09 14:13, 18F
→
11/09 14:14, , 19F
很可惜我無法負擔付費產品 在開源或免費軟體的選擇似乎不多
11/09 14:14, 19F
→
11/09 14:19, , 20F
也之所以你說"多"、"都" 我才請你介紹 這樣是有很多嗎？
11/09 14:19, 20F
→
11/09 14:27, , 21F
ffdshow跟MPC video decoder都有去交錯功能 這樣還不夠?
11/09 14:27, 21F
→
11/09 14:28, , 22F
就算沒用過/沒在用 也不必斷言去交錯非decoder所為
11/09 14:28, 22F
→
11/09 14:28, , 23F
現實上跟你想像的並不一樣
11/09 14:28, 23F
→
11/09 14:29, , 24F
我不曉得你的需求是什麼 一定要硬體去交錯才OK?
11/09 14:29, 24F
→
11/09 14:29, , 25F
我從頭到尾都沒有否定過這類decoder的存在~
11/09 14:29, 25F
→
11/09 14:30, , 26F
我和y3k只想表達的是deinterlace本來就不是decoder的「責任」
11/09 14:30, 26F
→
11/09 14:39, , 27F
dkfum也沒說去交錯是decoder的責任啊 只是講現況而已...
11/09 14:39, 27F
→
11/09 14:49, , 28F
madvr提供DXVA2 deinterlacing對一些人是天大的好消息
11/09 14:49, 28F
→
11/09 14:51, , 29F
表示去交錯多項選擇或者像web大提到可以減少效能負擔
11/09 14:51, 29F
→
11/09 14:54, , 30F
"現況"是不是「大部分」、「多」不需要 你可要多問問madvr的
11/09 14:54, 30F
→
11/09 14:55, , 31F
使用者群 我沒辦法給你回答 對我自己來說 這支援我是受益者
11/09 14:55, 31F
→
11/09 14:57, , 32F
那是因為他不曉得hw去交錯需要renderer支援
11/09 14:57, 32F
→
11/09 14:58, , 33F
而你的問題是 以為大部分的去交錯都不是decoder所為...
11/09 14:58, 33F
→
11/09 15:03, , 34F
多寡的問題 上面推文已提 另外去交錯不同於解碼 不同方法的
11/09 15:03, 34F
→
11/09 15:04, , 35F
的結果效果也不同 甚至有很大差異 所以並不是"有去交錯"
11/09 15:04, 35F
→
11/09 15:06, , 36F
就是每個人能接受的結果 當然這是個人喜好 是另一個議題
11/09 15:06, 36F
→
11/09 15:08, , 37F
因為去交錯並不是誰誰誰的責任 自decoder以降 誰都可以作
11/09 15:08, 37F
→
11/09 15:09, , 38F
也誰都可以不作 反正只要有一個Component有作就好
11/09 15:09, 38F
→
11/09 15:10, , 39F
通常decoder會作 是因為它沒辦法揣測後面有沒有人去作
11/09 15:10, 39F
→
11/09 15:11, , 40F
所以自己作掉最保險 單純把2個field合成1個frame也算有作
11/09 15:11, 40F
→
11/09 19:29, , 41F
其實我會這麼認為是有原因的@@ 我曾經弄了一個有交錯的clip
11/09 19:29, 41F
→
11/09 19:29, , 42F
然後用掛了madvr的mpc-hc x86播放 然後用alt-enter切換視窗和
11/09 19:29, 42F
→
11/09 19:30, , 43F
獨佔模式 發現切換的那一瞬間會出現交錯 如果frame從decoder出
11/09 19:30, 43F
→
11/09 19:31, , 44F
來時已經去過交錯 怎麼會在做這種切換的時候產生interlace?@@
11/09 19:31, 44F
→
11/09 19:33, , 45F
這個檔案在撥放的時候是看不出交錯的 所以我覺得是因為切換的
11/09 19:33, 45F
→
11/09 19:34, , 46F
時候filter那些東西進行了reset之類的動作 而deinterlace也在
11/09 19:34, 46F
→
11/09 19:38, , 47F
其中 當時我是這麼解釋這件事的
11/09 19:38, 47F
→
11/09 19:43, , 48F
另外我當時有把原檔和交錯後的檔案做過比對 那些線條應該不是
11/09 19:43, 48F
→
11/09 19:44, , 49F
resize的原因@@ 我想知道我這樣的結果上有問題嗎?@@
11/09 19:44, 49F
→
11/09 19:49, , 50F
其實你可以check一下renderer收到的video sample是否是
11/09 19:49, 50F
→
11/09 19:50, , 51F
interlaced...如果是 那表示你播那個檔時是hw去交錯的
11/09 19:50, 51F
→
11/09 21:45, , 52F
恩有可能@@
11/09 21:45, 52F
→
11/09 21:47, , 53F
我覺得這個討論到這裡告個段落吧XD?
11/09 21:47, 53F
→
11/09 21:53, , 54F
madvr這玩意0.78才有HW解交錯 究竟你的影片是誰解交錯的呢?
11/09 21:53, 54F
→
11/09 23:15, , 55F
我去年寒假左右 madVR連字幕都不支援的時候玩的 後來去年差不
11/09 23:15, 55F
→
11/09 23:16, , 56F
多這個時候電腦硬碟爆掉重灌 現在想起來也不知道要怎麼解釋= =
11/09 23:16, 56F
推
11/13 23:44, , 57F
以前不知在哪看到的DirectShow文章說不管是…
11/13 23:44, 57F
→
11/13 23:45, , 58F
Split/Decode/Render,統稱為Filters,然後再依功能分成
11/13 23:45, 58F
→
11/13 23:46, , 59F
Split/Decode/Render三大類,而Deinterlacing只是介於Decode
11/13 23:46, 59F
→
11/13 23:47, , 60F
與Render之間的一種Filter, 不知道我這觀念對不對？
11/13 23:47, 60F
→
11/16 22:15, , 61F
dshow filter的三類是 source/transform/renderer filter
11/16 22:15, 61F
→
11/16 22:17, , 62F
除了source/renderer外的所有事情都由transform filter
11/16 22:17, 62F
→
11/16 22:19, , 63F
處理,最常見的就是decoder.如果要把deinterface的功能
11/16 22:19, 63F
→
11/16 22:19, , 64F
單獨作成一個filter也是可以 也是transform filter的一種
11/16 22:19, 64F
→
11/16 22:20, , 65F
但是沒看過這種filter,因為通常decoder也會順便作去交錯
11/16 22:20, 65F
推
11/22 01:20, , 66F
啊…對！就是 Source/Transform/Renderer 三種dshow filter
11/22 01:20, 66F
‣ 更多 y3k 的文章
文章代碼(AID): #1EkBYPuZ (AVEncode)
‣ 更多 y3k 的文章
文章代碼(AID): #1EkBYPuZ (AVEncode)