推 randle:推 支持的是Open Web! 01/28 20:17
推 Kreen:支持免錢的，就算 H.264 不收消費者錢，他跟廠商收，最後還 01/28 21:45
→ Kreen:不是轉嫁消費者＝ ＝ 01/28 21:46
推 raiechun:VP8內部很多地方跟H.264太類似，想免專利費很難 01/29 01:15
推 JoeJohnson:樓上的說法我頭一次聽說 有來源嗎?? 01/29 22:43
推 raiechun:樓上去看原文末的連結 01/30 00:24
推 JoeJohnson:我看了…文長，我以整編回覆回答 01/30 00:39
raiechun 兄請我看的來源是：
http://blog.fulin.org/2010/05/vp8_first_in_depth_tech_analysis.html
這是對岸的翻譯文章。 有看到raiechun 說"太類似"的部份。
然後文章提到的英文原文是：
http://x264dev.multimedia.cx/archives/377
英文原文的日期是： 2010/5/19
如果我沒記錯，當天就是Google 宣佈開放VP8格式的WebM的相同時間。
但是，英文來源文章不是raiechun所說的VP8內部，它很明顯是H264內部吧？
所以H264會對VP8有諸多疑慮，包括你所說的"太類似"的地方，
兩者是競爭對手，我覺得他要多懷疑都很合理。
而事實上呢，自從Google 開放WebM 格式的這8個月以來，目前沒人有對WebM的
專利權發出任何法律行為，其實在這8個月之中，WebM project 正在努力翻修
VP8源碼，但翻修的主因是"效能不彰"，而不是什麼專利權的問題。一直到目前
WebM 最新的 libvpx 0.9.5，專案小組在每次的release changelog 都有提到
效能的改善進度。
然而對我們這些網站開發者來說，WebM 這東西還是有好有壞…
好處是，它容量相當小，畫質高(非常接近H264)。這也是為何它適合用在網路。
拿一個64M的.mp4，我以FFmpeg 以最高畫質轉成WebM，它容量只有28M，
如果以最高畫質轉成flv 呢？ 它容量變成162M ....
如果你要經營一個影音網站(像Youtube)，絕對會想要棄flv取WebM。
而缺點，就是轉檔效能太慢。這也是VP8源碼翻修的重點之一。
它仍然是目前最大的痛點。
剩下的是支援問題，尤其是Apple 與Adobe ，
Adobe 的Flash 後端目前只支援flv，等未來新版Flash 開始支援WebM播放的話，
WebM格式就會被更多的網站開發者所接受，那時候才會大爆發的普及吧。
抱歉認真了..
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.165.96.165
※ 編輯: JoeJohnson 來自: 118.165.96.165 (01/30 01:37)
推 weiyucsie:推認真考究 :) 01/30 01:46
推 bobchao:推個認真考究 01/30 02:51
推 eggimage:推 而且apple他老大不爽的話 市場要普及也會受到阻擾.. 01/30 07:09
推 Mr7:推 解釋很清楚 連門外漢都看得懂了 01/30 07:31
推 hgs1906:感謝您的分享 拜讀 OTZ 01/30 10:51
→ xvid:拿container來比較 厲害厲害 檔案大小取決於編碼時設定的流量 01/30 15:12
→ xvid:你的意思是VP8只需要H.264一半的流量就能達到相同的畫質 01/30 15:16
→ xvid:太神奇了捷克 01/30 15:17
→ JoeJohnson:回樓上，我FFmpeg轉檔測試結果是如此 01/30 16:07
推 lovemost:推 01/30 17:40
→ ksng1092:能否請教"相同畫質"的分析判定方法是？ 01/30 18:28
→ xvid:PSNR是一種方法 01/30 18:38
→ ksng1092:突然發現到一個問題...flv又不是編碼格式，是怎麼比的XD 01/30 18:45
→ ksng1092:所以判斷相同畫質要用軟體去跑嗎？ 01/30 18:47
→ xvid:所以我才覺得這篇荒謬... 大概是原po的肉眼心得 01/30 18:51
→ xvid:編碼的profile和參數也不少 也不曉得所謂最高畫質是怎回事 01/30 18:52
→ silky7:還沒有提出法律行為不代表將來不會提出 VP8還是有可能會被 01/30 21:17
→ silky7:要求專利的 VP8的畫質接近H.264 basic profile 01/30 21:17
→ silky7:大約和VC-1相當 遠不及H.264 main profile 不過解碼的複雜 01/30 21:19
→ silky7:度相對比較低 要容量小、畫質好 最好的選擇還是H.264 01/30 21:19
→ silky7:youtube現在提供VP8(webM)和H.264(flv/mp4)二種格式的影片 01/30 21:20
→ silky7:但是他的H.264版本壓縮品質非常差勁 相同流量下如果玩家以 01/30 21:21
→ silky7:x.264自行編碼 畫質會提升非常非常多 youtube應該同樣使用 01/30 21:22
→ silky7:x.264壓縮 但是壓出來的品質跟垃圾一樣 這也是為什麼YT上 01/30 21:22
→ silky7:webM的版本和H.264的版本看起來差不多的原因 因為H.264真正 01/30 21:23
→ silky7:的實力被弱化了 google在打什麼主意 我們可以拭目以待... 01/30 21:24
→ xvid:google要用youtube webM拓展 可能要先解決IE市佔率....XD 01/30 21:26
→ silky7:webM推廣起來的話 就算google不跟使用者收錢 也可以從其他 01/30 21:29
→ silky7:方面獲利 跟微軟擁有VC-1的技術一樣 google可不是慈善公司 01/30 21:29
→ xvid:即使往後adobe flash支援VP8 H.264/VP8同時支援的情況下 01/30 21:30
→ xvid:對使用者來說 VP8沒什麼吸引力 01/30 21:30
→ JoeJohnson:其實兩位大可回文，我很樂於討論這些問題 01/30 21:46
→ JoeJohnson:大家認知有差距，我想和大家使用的工具軟體不一樣有關 01/30 21:49
→ JoeJohnson:每個格式都有專門轉檔壓縮程式，轉出來必利於該格式， 01/30 21:51
→ JoeJohnson:這也是大家看到的盲點之一。我都以FFmpeg 為主，這是 01/30 21:53
→ JoeJohnson:最普遍的伺服器端轉檔方案之一，我不認為他獨利於WebM 01/30 21:54
→ JoeJohnson:當然這就可回答，我的相同畫質是用 ffmpeg -sameq 參數 01/30 21:55
→ JoeJohnson:至於Youtube 轉的H264壓縮像垃圾一樣…很簡單，據傳 01/30 22:02
→ JoeJohnson:Youtube 後端很可能就是FFmpeg (可以研究看看？) 01/30 22:03
→ JoeJohnson:至於廠商之間的普不普及的問題，說真的，與我何甘？ 01/30 22:06
→ JoeJohnson:我只是希望未來真的可以不用見到Flash 播影音，超愛當 01/30 22:08
→ xvid:H.264是個標準 我想認知差距不在工具... 剩下的s大解釋很清楚 01/30 23:03
→ ksng1092:要用sameq參數來比較，我記得前提是source要是一個無壓縮 01/31 12:15
→ ksng1092:（或至少是無失真）影片，不然常常會出現轉出來比原影片 01/31 12:16
→ ksng1092:還要大的結果... 01/31 12:16
→ ksng1092:而且.mp4轉檔成.flv這一步我實在搞不懂是想做什麼，.mp4 01/31 12:20
→ ksng1092:可以是h264編碼.flv也可以是h264編碼啊... 01/31 12:21
→ ksng1092:所以這例子是要告訴我們h264比h264大5倍多嗎XD 01/31 12:22
→ JoeJohnson:h264怎樣我不管，但flv才是廢… 它一定要專門工具才行 01/31 13:07
→ JoeJohnson:不然轉出來是又肥又大，只好牲犧畫質來換它的容量 01/31 13:08
→ theory:... 原 PO，重點是編碼方式跟 container 不能放在一起比 01/31 13:11
→ ksng1092:就說flv不是編碼格式了orz 這樣到底是要比什麼？ 而且那 01/31 13:22
→ ksng1092:sameq的比法裡面問題實在是很多耶...... 01/31 13:22
→ JoeJohnson:我說了，H264怎樣我不管，而且我從沒說H264不好吧？ 01/31 13:26
→ JoeJohnson:我只想表示WebM 比flv 好用多了。就這樣。 01/31 13:28
→ ksng1092:你的比法就跟"標楷體比docx好"一樣很奇妙啊 01/31 13:31
→ JoeJohnson:而HTML5 video 指的H264，主要指的是mp4，但瀏覽器對他 01/31 13:33
→ JoeJohnson:的支援並不統一，目前也只有WebM可能闖過瀏覽器這關.. 01/31 13:34
→ JoeJohnson:你可以把我的WebM 小寫，變成 .webm 的檔案來理解 01/31 13:36
→ ksng1092:副檔名是什麼完全沒有影響啊 換了要做什麼...... 01/31 13:41
→ ksng1092:還有至少用個無壓縮影片當原始檔來測試sameq吧... 01/31 13:41
→ ksng1092:事實上sameq能不能拿來比不同編碼格式相同畫質下的容量大 01/31 13:45
→ ksng1092:小我也不能確定XD 01/31 13:45
→ JoeJohnson:好啦，抓我語病，沒有比理解文章意思重要... 別堅持了 01/31 14:59
→ ksng1092:這不是語病，明明是這篇文的核心......這篇文不就是想說 01/31 15:08
→ ksng1092:WebM這個編碼格式在相同畫質下有容量優勢嗎？ 但是比較過 01/31 15:09
→ ksng1092:成和方法都不明不白不清不楚，這不算在語病的範圍內吧 01/31 15:09
→ ksng1092:在有爭議的測試方法之下做出的結論要怎麼讓人理解... 01/31 15:12
→ JoeJohnson:我又做個測試，用Panasonic DMC-FX48 相機錄影 01/31 15:22
→ JoeJohnson:原檔是存成mov，容量37M，分別FFmpeg -sameq 轉檔 01/31 15:23
→ JoeJohnson:flv: 6.6M, mp4: 6.1M, webm: 4.4M 01/31 15:24
※ 編輯: JoeJohnson 來自: 61.31.89.70 (01/31 15:25)
→ ksng1092:首先，mov的編碼格式是？ flv的編碼格式是？ mp4的編碼格 01/31 15:26
→ JoeJohnson:或者你們能告訴我要如何測試？ 01/31 15:26
→ ksng1092:是又是？ 再來，看下一篇文章有提到sameq參數的解釋，你 01/31 15:26
→ ksng1092:覺得這可以當成轉不同格式比較之用嗎？ 01/31 15:27
→ JoeJohnson:sameq 不能算的話，有更好的辦法嗎？ 01/31 15:28
→ ksng1092:老實說我不知道，你沒看到我前面有問嗎XD 是有人回答PSNR 01/31 15:30
→ ksng1092:但是sameq明顯要原始與輸出用相同編碼相同解析才會有畫質 01/31 15:31
→ ksng1092:近似的效果（有錯也請指正） 01/31 15:31
→ ksng1092:所以就這點來看，這個參數不適合比對不同編碼格式的壓縮 01/31 15:32
→ ksng1092:率才是 01/31 15:32
→ JoeJohnson:嗯… 所以看起來是難有公平的工具了 01/31 15:35
→ JoeJohnson:不過我是實作派，不是理論派。有冒犯請見諒 01/31 15:36
→ ksng1092:相關產業裡一定會有比較用工具，我想甚至可能有分析軟體 01/31 15:39
→ ksng1092:不過我覺得你還是得先分清楚容器與編碼格式orz 01/31 15:39
→ ybite:其實我猜YouTube壓很爛是為了避免使用者Decode時太吃資源... 02/01 00:18
→ ybite:愈好的畫質=吃愈多的CPU，加上Flash大部分情況得CPU解H264.. 02/01 00:19
→ ybite:因此對YouTube的Case而言，H264壓得很糟糕是可以理解orz 02/01 00:22
→ ybite:也因此對Google而言，換成WebM/VP8並不會帶來太大的畫質差異 02/01 00:26
推 david74:JoeJohnson大完全搞混 codec 和 container 了... 02/01 08:29