X
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
レス数が1000を超えています。これ以上書き込みはできません。
0389名無しさん＠編集中 (ﾜｯﾁｮｲ 37c7-fIkj)
垢版 |
2018/10/21(日) 17:59:37.22ID:j7ka/yrK0
ttps://mkvtoolnix.download/doc/NEWS.md
MKVToolNix、AV1正式対応来た
0395名無しさん＠編集中 (ﾜｯﾁｮｲ bf81-o90R)
垢版 |
2018/10/25(木) 13:09:00.79ID:WTE0P24Q0
479分　14GBあるAVを容量節約のためにNVENCでH.265の低ビットレートでエンコードしたが速くていいわ（低ビットレートでもH.265なので汚い穴が綺麗に見えてしまう）
0396名無しさん＠編集中 (ｱｳｱｳｲｰ Saa9-aZGo)
垢版 |
2018/10/25(木) 17:58:44.37ID:uYpAsWDZa
Firefox63でYouTubeのAV1を見れたけど、途中で再生が止まるな
Firefoxがフリーズする訳じゃないけど
64だとマシにはなる
デフォ有効になるにはもう少し掛かりそうだ
0399名無しさん＠編集中 (ﾜｯﾁｮｲ 2b80-2SzA)
垢版 |
2018/10/31(水) 12:48:39.07ID:qHnqaqyu0
>>398
正確にコピペしないと許さないマンかよw

以下は一世代前のモデルとの比較です。

8ビットHEVCの書き出しが30倍速く
------------------------------
6コアMac mini
-
デュアルコアMac mini(基準値)

公式サイトの表現そのまま持って来たけどこれでいい?
これを従来比って表現したらアホ呼ばわりされるのか(´･ω･`)
0401名無しさん＠編集中 (ﾜｯﾁｮｲ f7ec-7TBo)
垢版 |
2018/10/31(水) 19:09:08.17ID:QdtmEmZr0
>>399
https://www.apple.com/jp/mac-mini/#footnote-10
・64GBのRAMと2TBのSSDを装備した3.2GHz 6コアIntel Core i7搭載Mac mini試作モデルと、
　16GBのRAMと1TBのSSDを装備した3.0GHzデュアルコアIntel Core i7搭載Mac mini量産モデルを使用し、
　2018年10月にAppleが実施したテスト結果によります。4,096x2,160解像度、毎秒23.98フレームの
　Apple ProRes 4444ビデオを含む60秒のプロジェクトを使用し、リリース前のCompressorでテストを実施。
　パフォーマンステストは特定のコンピュータシステムを使って実施したもので、
　Mac miniのおおよその性能を示しています。

4Kでのテスト結果らしいけど、実際の速度は誰かがテストしないとわからんね。
0407名無しさん＠編集中 (ﾜｯﾁｮｲ a380-pCVE)
垢版 |
2018/11/01(木) 04:15:40.15ID:dwS4kd3w0
そのイメージで概ね合ってると思うよ
Intel QSVみたいなハードウェアエンコーダ回路をSOCに統合したものだけど
もともとT1は内臓カメラデータの処理とかTouchBarの表示制御のためGPUから
グラフィック情報をやり取りするパイプがあったからうまく実現できたんだと思う

モバイルデバイスにおけるHEVC撮影/再生時のバッテリー消費を抑える必要性から
自社開発進めてるんだろうけど、HEVCエンコーダに限った意味じゃなくても
このエンジニアリングは賞賛に値するわ
0410名無しさん＠編集中 (ﾜｯﾁｮｲWW ca6e-+DU9)
垢版 |
2018/11/01(木) 05:44:31.64ID:QxNcxnB+0
>>407
なるほど、ありがとう
そうなるとこれは、Macの省電力ノート系の構成と、MacOSに特化したものなんだろうな
WindowsPCに載るのは望み薄いというか、そもそも電力気にしなければ、PCIEに載せたそこそこなnVidia GPUで、性能的には楽に上回りそうな気がする

まあMac miniの10万円セグメントでも、ここまで性能的にも使えますよ！という、安いクライアントマシンの売りなんだろうな
やはりちゃんとした拡張性の高い、MacProの後継機を作ってくれんかなぁと、毎度思わずにはいられない
0411名無しさん＠編集中 (ﾜｯﾁｮｲ 63ec-MyS3)
垢版 |
2018/11/01(木) 13:45:50.12ID:oRPV86XJ0
MAC mini 2018 のGPUは Coffee Lake の Intel UHD Graphics 630 とあるけど、QSVは使えないんだろうか？
使えたとして、QSVでのHEVC 4Kエンコードより、T2チップの方が速いってことなんだろうか？
0412名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MM8a-Nfgq)
垢版 |
2018/11/01(木) 14:22:03.72ID:Sln92vVMM
CPUパワーのあるデスクトップならx264/265があるしHEVCは配信には使えないし回路面積それなりに取りそうだし
どういう層がメインターゲットなんだ?
0419名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MM8a-Nfgq)
垢版 |
2018/11/02(金) 09:11:33.10ID:T8KOWQrDM
>4K Main10 の veryslow 設定以外のいくつかのエンコーダー・コマンドラインでは、インテル® AVX2 と比較してパフォーマンスが低下しました。
平均して+6%程度の効率UPみたいだしAVX512が登場してから結構経つのに1個人の利用者としては対応直後にrigayaさんが検証してた頃よりあまり進歩が無いとだけ理解したわ。
0420名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-MyS3)
垢版 |
2018/11/02(金) 15:30:53.04ID:bTV4YUEn0
>>419
そりゃおめー、>>418の記事は5/11の英語記事を日本語にしただけだからよ。
内容も4月に発表があった時（rigayaさんの検証もその時）のPDFをベースに
あらためて書いただけのようだから、進歩なんてあるわけねーがや。
0426名無しさん＠編集中 (ﾜｯﾁｮｲ 1ad2-2KtO)
垢版 |
2018/11/07(水) 06:20:07.49ID:A8H7jtiX0
dav1dはもうlibaomより2倍くらい早いっぽいね

Ryzen 2400G

dav1d v0.0.1-44ad79e
dav1d.exe -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --framethreads 12 --tilethreads 4 --muxer yuv4mpeg2 -o nul
8929/68.149=131fps

libaom v1.0.0-883-g3ab5b877d
aomdec.exe --threads=12 -o nul Chimera-AV1-8bit-1920x1080-6736kbps.ivf
8929/133.645=66fps
0430名無しさん＠編集中 (ﾜｯﾁｮｲ d7ec-MyS3)
垢版 |
2018/11/07(水) 21:41:23.10ID:KDwv143T0
・元x265プロジェクト、現Beamr所属のTom Vaughan氏が語るHEVCとAV1など (10/16公開)
　　The state of advanced codecs; separating hype from reality - Tom Vaughan | September 2018
　　https://www.youtube.com/watch?v=vgE8-4rcXl0

・Mozillaの人によるAV1の技術解説 (7/31のイベント、10/17公開)
　　Into the Depths: The Technical Details behind AV1 by Nathan Egge
　　https://www.youtube.com/watch?v=On9VOnIBSEs

・AV1関連の動画を集めた再生リスト
　　https://www.youtube.com/playlist?list=PLDa6QBb3vqVzcVBCWS3WKrcvf4ZqJeiW-
0431名無しさん＠編集中 (ｱｳｱｳｸｰ MM4d-EOzO)
垢版 |
2018/11/09(金) 22:41:28.76ID:8NC5ogPvM
Microsoft、Windows 10用のAV1 Video Extensionをベータテスト開始
https://news.softpedia.com/news/microsoft-launches-free-av1-video-codec-for-windows-10-523704.shtml
Windows 10 October 2018 Updateユーザーは今すぐMicrosoft Storeからダウンロードできます
初期のリリースであるため、AV1ビデオを再生する際にパフォーマンスの問題が発生する可能性があります。
この拡張機能を引き続き改善していきますと述べている
0434名無しさん＠編集中 (ﾜｯﾁｮｲWW d1c3-2miv)
垢版 |
2018/11/10(土) 07:26:33.56ID:ZbEwVURh0
SwitchのTegra X1が、エンジン部が元のままだとしたら、Maxwell世代最後のGM206と同同等のNVDecでVP9 8bitまで感じなのかな？
この世代のNVDecはGTX1060以上まで採用されてる

カスタム設計時に刷新されていれば、Pascal 14nm（GP107〜、GTX1050/ti/GT1030/MX150）と同世代で12bitまで対応してるかも

NVEncはGPU世代毎なんだけどNVDecは世代末に先行で更新入るんだよな
0441名無しさん＠編集中 (ｱｳｱｳｸｰ MM4d-C3ss)
垢版 |
2018/11/11(日) 09:25:21.63ID:UE6ueG1YM
お、AV1の本格攻勢が始まったのか？
一般ユーザにも扱いやすい環境が整えばいいなあ
規格乱立とかエンコード・デコード手順が複雑とか対応環境が少ないとかだとすぐ廃れるからな
0445名無しさん＠編集中 (ﾎﾟｷｯｰ 8981-Nrm4)
垢版 |
2018/11/11(日) 19:20:05.05ID:Fqt/apnt01111
Microsoft、Windows 10用のAV1 Video Extensionをベータテスト開始
https://news.softpedia.com/news/microsoft-launches-free-av1-video-codec-for-windows-10-523704.shtml
Windows 10 October 2018 Updateユーザーは今すぐMicrosoft Storeからダウンロードできます
初期のリリースであるため、AV1ビデオを再生する際にパフォーマンスの問題が発生する可能性があります。
この拡張機能を引き続き改善していきますと述べている
0453名無しさん＠編集中 (ﾜｯﾁｮｲWW d1c3-PUUa)
垢版 |
2018/11/12(月) 18:59:42.85ID:MJdo0dF20
>>451
円盤収録したコンテンツで百数十円
ストリーム配信コンテンツなら年間で事業者支払いしていればコンテンツ提供毎に掛からない
頭割りしても全体で何千万〜何億PVも有れば何円にもならん
ライセンスフリーへの対応も実質利用者のためじゃなく提供者の出費減らすためで
スムーズな再生にアクセラレート対応とかの為にとか、CPU負荷増加とか手間みたいなもんでユーザーがライセンスフリーのために負担する方がデカい
0454名無しさん＠編集中 (ﾜｯﾁｮｲWW 491e-pmes)
垢版 |
2018/11/12(月) 22:02:34.73ID:/+MvnmQa0
>>452
なんだその無料のやつ。特定のパソコン向け?
俺の自作パソコン出てこねえ。パソコンというか今は亡きスマホか?
>>453
まぁね。でも金払うの気が引けるな。まずクレジットカード登録からだし。しかもVLC使えば無料だし
0456名無しさん＠編集中 (ﾜｯﾁｮｲ 492d-A2K7)
垢版 |
2018/11/12(月) 22:56:47.31ID:xulboH4M0
つべのav1ダウンロードしたら264より倍くらい大きさある
vp9もmp4より大きいときあってよくわからない
0461名無しさん＠編集中 (ﾜｯﾁｮｲWW 491e-pmes)
垢版 |
2018/11/13(火) 01:53:40.94ID:Ia8HYJK/0
7から8とか。実質別ソフトだからもう一回払うことになるんだろうけど、でも、新規じゃなくてアップグレードユーザーは一度払えばOKにしてほしい。たぶん、厳密に追跡できないからだろうけど。
0465名無しさん＠編集中 (ﾜｯﾁｮｲWW d1c3-XdqY)
垢版 |
2018/11/14(水) 12:24:29.97ID:vRkHyfxj0
ビットレート上げればコーデックの違いやエンコーダ性能の差が無くなっていくから現状のつべAV1で画質評価するだけ無駄
あくまで動作確認用でわざと重いデータにしてるのもあるけど、ここまでビットレートの差が有れば多少現状でのエンコーダの出来が悪くても画質面で悪い印象与える心配も無い

そうでも無ければ、運用コストに占める割合が大きい回線帯域を犠牲にする様な事もしないだろ
0470名無しさん＠編集中 (ﾜｯﾁｮｲWW 1d1e-Opbz)
垢版 |
2018/11/16(金) 00:32:33.07ID:Wid/3dv60
本気で移行したきゃ、jpegで保存するカメラアプリは今後ストアから排除するとかそういうレベルでやらんと無理だろう。
そのためには最低エンコード、デコード速度をjpeg並みにもっていかないと。googleが前に押してたwebpすら速度jpegに比べて遅すぎだし
0476名無しさん＠編集中 (ﾜｯﾁｮｲWW 1d1e-Opbz)
垢版 |
2018/11/16(金) 05:36:18.02ID:Wid/3dv60
あくまで適当なイメージで言ったんでちょっと普段見てる適当なサイトのメディア条件をふ調べて見たけど、
gigazine,窓の杜,techcrunch,cnet.jp
amazon,楽天,メルカリ,価格.com
全部pngかjpgかgifだった。
0478名無しさん＠編集中 (ﾜｯﾁｮｲWW 1d1e-Opbz)
垢版 |
2018/11/16(金) 05:50:19.18ID:Wid/3dv60
つか、前に画像のエンコード、デコード時間を計測するandroidのテストアプリ作ったんだけどそれでweb,png,jpegで3000*2000ぐらいの画像を1 枚エンコードしたら
jpeg:700ms
webp:6000ms
cortexA72のへぼ端末だけどこんな時間かかるんだもんな。
heifだかheicだかの次世代フォーマットが写真保存用に使われるにはこのスピードをどうにかしないと。
0480名無しさん＠編集中 (ﾜｯﾁｮｲWW eaab-Z4zx)
垢版 |
2018/11/16(金) 06:36:31.05ID:yGVbU7cx0
webpはデコードはけっこう早い。エンコード遅くても僕は良いです。それより非可逆圧縮で透過が使えるのが大きい。
Jpegはアルゴリズム上256bit以上のSIMDがあまり効かないとjpeg-turboか何かで読んだことある。そんなの要らないくらい神速だけど
0481名無しさん＠編集中 (ﾜｯﾁｮｲWW 1d1e-Opbz)
垢版 |
2018/11/16(金) 07:08:46.62ID:Wid/3dv60
デコードの時間も計測してたんだけど書かなかった
jpeg:エンコード 730ms デコード 353ms
webp :エンコード 6290ms デコード 1190ms
png :エンコード 7070ms デコード 415ms
androidの標準APIで品質100でエンコード。
内部で使ってるであろうlibwebpとかSIMDで最適化されてないだろうから誰かが頑張ればもっと速くなるんだろうが
0482名無しさん＠編集中 (ｱｳｱｳｲｰ Sa2d-/8ns)
垢版 |
2018/11/16(金) 07:18:14.32ID:0iDaa9nYa
JPEGのエンコードはハードウェアで実装されてるからスマホでも爆速なんだろう
ブロックサイズが固定なのもハード実装に向いてそうだ
なまじブロックサイズを可変とかにするから時間掛かるようになる
ハードウェアの実装に特化した画像コーデックを考えれば普及するんじゃないか？
0489名無しさん＠編集中 (ｱｳｱｳｸｰ MM2d-mhdf)
垢版 |
2018/11/16(金) 12:39:09.82ID:373SiSkFM
Chrome・Firefox・Edge「WebP普及させよう」
Safari「おぉん？次世代はHEIFだろJK」
Web開発者「結局ブラウザ依存になるからJPEGでいいや……」

こうなるのは目に見えてるのに未だに連携することを覚えない学習能力皆無のブラウザ開発者たち
0500名無しさん＠編集中 (ｽﾌﾟﾌﾟ Sdea-bZqS)
垢版 |
2018/11/16(金) 16:56:07.39ID:N0WFRQxkd
圧縮の必要性に疑問あるんだろ。
画像なんかデカくても数MBで、何年も前と比べて高容量化がHDDでもSSDでもeMMC(スマホ)でも進んでる今は圧縮の必要性に疑問符が付くユーザーが多いんでねえの。
動画なら高画素化が急激に進んだから圧縮は必要だろうが…
0505名無しさん＠編集中 (ﾜｯﾁｮｲ 7ec2-AcPE)
垢版 |
2018/11/16(金) 20:53:49.01ID:+R6VBQPa0
音楽はタグで管理してるくせに画像は写真だけEXIF/XMPだけど後は全部ファイル名で管理っていう
みんな画像ファイルに特に興味ないんだよ、見れりゃ良いしわざわざ集めるもんでもないんだろうなぁ
動画も録画してる人以外はコレクションしようがないから管理方法の普及が一向に進まないね
0507名無しさん＠編集中 (ｱｳｱｳｲｰ Sa2d-/8ns)
垢版 |
2018/11/16(金) 21:54:26.05ID:dKkNu3via
>>499
そのサイト色々なフォーマットで比較できるけど、MozJPEGは確かにWebPより劣ってるけどかなり善戦してる
劣化が気になる場合はクオリティを上げれば良いだけだし、JPEGは今後も使われるだろうな
逆に今回の比較で明らかにWebPの方がMozJPEGより良い事は分かった
0508名無しさん＠編集中 (ﾜｯﾁｮｲW 6ae0-mmxC)
垢版 |
2018/11/16(金) 22:00:53.41ID:tthnmREP0
>>499
色再現性がwebpと比べて非常に素晴らしいね。
輪郭は俺にはあまり変わってるように見えない。どっちもかなりぼけてる
0509名無しさん＠編集中 (ﾜｯﾁｮｲW 6ae0-mmxC)
垢版 |
2018/11/16(金) 22:06:31.17ID:tthnmREP0
>>499
これAV1だけロスレス945Kbyteとか凄く小さくなるんだけどエンコード/デコード速度どんなもんなんやろ
0515名無しさん＠編集中 (ﾜｯﾁｮｲ cdb3-ABD/)
垢版 |
2018/11/17(土) 21:09:01.23ID:M9Du4/fO0
JPEGはもう更新するの無理だろうね
mp4も10bit対応したらそれで終わりだと思う
0516名無しさん＠編集中 (ﾜｯﾁｮｲ 4a11-maOp)
垢版 |
2018/11/17(土) 21:17:09.36ID:yLuQP9Ai0
意味が分からないけど解像度やフレームレートが増したりしたら
より高圧縮なmp4動画というのは求められ続ける（解像度そのままでも元が大きいから無駄にはならない
0517名無しさん＠編集中 (ﾜｯﾁｮｲ cdec-maOp)
垢版 |
2018/11/17(土) 21:20:32.28ID:wKv7rNvi0
>>515
> mp4も10bit対応したらそれで終わりだと思う

突然出てきたけど、これなんのことを言いたいんだ？
ビット深度のことなら対応するのはコーデック(HEVCやVP9等)であって
コンテナ(MP4等)じゃないし、HEVCやVP9には12bitもあるけど。
0527名無しさん＠編集中 (ｱｳｱｳｲｰ Sa2d-/8ns)
垢版 |
2018/11/19(月) 09:23:46.07ID:JNvou+3Na
>>522
DCTも別にブロックが必要と言うわけでは無いけどね
画像全体に適用すると左端の高周波成分のカットが右端に影響しちゃうからだろうね
ウェーブレットはそうならないはず
詳しくは知らん
0528名無しさん＠編集中 (ｱｳｱｳｲｰ Sa2d-/8ns)
垢版 |
2018/11/19(月) 09:56:55.81ID:JNvou+3Na
ちなみにウェーブレットはある画像は、それを半分にしたものと更に半分にしたものと、以下繰り返し...
を組み合わせれば表現出来る、という小学生でも思い付きそうな理屈がつい40年位前まで誰も思い付かなかったという事らしい
しかも発見したのは数学の専門家でもない
50年前に行って俺が発見したかったw
0530名無しさん＠編集中 (HappyBirthday!T Sa2d-JwVn)
垢版 |
2018/11/20(火) 12:33:07.72ID:U5LXFZDQaHAPPY
>>529
確かに似てはいるけど、フラクタルはどんな複雑な図形も単純な図形の繰り返しで表現出来るっていうのを画像圧縮に応用したもので、決まったやり方がある訳じゃないはず
実際には矩形に分けて縮小したり回転したりしてるようだけど
ウェーブレットは>>528の通りだ
ちなみに半分というよりはモザイク化すると言った方が正確かもしれん
で、それぞれの画像の差分がウェーブレットそのものだ
1枚目と2枚目の差分をゼロにしてしまって元に戻しても多分それっぽく見えるはずだが多分少しのっぺりした画像になるはず
これが高周波成分をカットしたという事になって、この後の圧縮が効きやすくなる
ざっくりしてるが大きく間違ってはいないはず…
0540名無しさん＠編集中 (ﾜﾝﾄﾝｷﾝ MM9f-qDc6)
垢版 |
2018/11/22(木) 18:26:53.04ID:9CUXdSRdM
倍半分変わるような処理もまあないし不便を感じたらでいいでしょ
2600K発売からもう2カ月弱で8年になるのに大してIPCもクロックも上がってないしな
新しいEPYC見てから動向決めるとかでええやろ
0544名無しさん＠編集中 (ﾜｯﾁｮｲW 7fe0-qDc6)
垢版 |
2018/11/22(木) 21:18:47.85ID:9Im+UerH0
>>541
まじかー俺は5960Xなんだけど今の6コアのほうが速そうだな…
って思ったけどこれよく見たらx264/265じゃないのな。
自作板のx264/265のベンチスレではhaswell世代とzenは同一コア数クロックではほぼ均衡、kaby世代とも10%程度の差だった筈だから殆どの人にはその結果は当て嵌まらないと思うぞ。
0546名無しさん＠編集中 (ﾜｯﾁｮｲ 63ec-zhOP)
垢版 |
2018/11/22(木) 21:27:38.34ID:JXJuizuM0
>>544
> これよく見たらx264/265じゃないのな。

PremiereProの方はx264/265じゃないと思うが、TVMW6はx264/265を使ってるよ。
　　http://tmpgenc.pegasys-inc.com/ja/product/tvmw6.html

ちなみに>>541の元記事はこれ。

　Sandy Bridgeから最新第9世代まで新旧CPU・徹底ベンチレポート - PC Watch
　https://pc.watch.impress.co.jp/docs/news/1151575.html

解像度とかは記事に書いてないが、画像を拡大してよく見ると 3840x2160/29.97fps/3分23秒01の動画かな。
0548名無しさん＠編集中 (ﾜｯﾁｮｲW 7fe0-qDc6)
垢版 |
2018/11/22(木) 22:17:06.41ID:9Im+UerH0
4770kってTB3.9GHzで9900kはTB5.0GHz(何コアで幾らかは知らね)だろ？
>>544の何がおかしいんだよ。
9900Kは定格がOCみたいな仕様だし通常運用域でのOC考えればかなり近い値になるぞ。
0551名無しさん＠編集中 (ｻｻｸｯﾃﾛﾗ Sp47-86ze)
垢版 |
2018/11/22(木) 22:59:28.24ID:cyN/nsFvp
>>548
何言ってるか全く意味不明なんだが
H.265のTMPGエンコ時間は9900Kが781秒で4770Kが2019秒
4770Kが3.9GHzだとして1.5倍にOC（5.8GHzでまず無理）して比例して1346秒になっても近い値にはならんが
0556名無しさん＠編集中 (ﾜｯﾁｮｲ b3ec-zhOP)
垢版 |
2018/11/24(土) 09:41:57.43ID:1o4hzJcU0
自動ビルドスクリプトのmedia-autobuild_suiteが9月頃にrav1eやdav1dに対応してた。
それぞれのバイナリや、dav1dを有効にしたffmpeg等もビルドできる。

jb-alvarado/media-autobuild_suite
　: This Windows Batchscript is for setup a compiler environment
　　for building ffmpeg and other media tools under Windows.
https://github.com/jb-alvarado/media-autobuild_suite
0560名無しさん＠編集中 (ﾜｯﾁｮｲW f39f-YSKh)
垢版 |
2018/11/25(日) 01:17:20.65ID:zhkxxxZl0
動画関連は専用ユニット積むし
旧製品はともかく下のグレードでも問題ないようになるんじゃないの
乗っけてもらうのには政治力もいるだろうけどそのあたりAV1はバックが最強軍団だからそこは心配いらんし
0562名無しさん＠編集中 (ﾜｯﾁｮｲWW 43c3-cWZC)
垢版 |
2018/11/25(日) 02:00:32.87ID:GQN5W3DX0
CeleronでAVXまで駆使してソフトエンコードってのもね
後々の世代でメディアエンジンでデコード出来れば良いグレードで
間違ってもデータ造る側で使うもんでは無い罠
少々不効率でも当倍速再生ならDXVA2とかでも実装されるだろうし
0565名無しさん＠編集中 (ﾜｯﾁｮｲ e3ec-zhOP)
垢版 |
2018/11/25(日) 02:43:21.36ID:PfCvLe3g0
>>557
>>531のdav1dの記事に書いてあるけど、SSEとARMの最適化も今週メドにリリース予定らしいよ。
　

dav1d、なかなか良い感じ。
i7-4702MQ＋ffplayでデコードがlibaomだと720p60や1080p24が少しカクついてしまうし、
1080p60はカックカクで話にならないけど、libdav1d（-tilethreadsを2以上に指定するとよさげ）だと
1080p60もスムーズに再生できてるっぽい。

　Halo Infinite - E3 2018 - Announcement Trailer
　https://www.youtube.com/watch?v=Fmdb-KmlzD8
　※1080p60のAV1あり。なぜか最後の方でデコードがひっかかる部分があるけど。
0569名無しさん＠編集中 (ﾜｯﾁｮｲ bfeb-ylOc)
垢版 |
2018/11/25(日) 12:57:57.82ID:5esxLJN30
AV1はエンコ遅すぎ　結局なかなか進化しないな
ハードエンコのグラボ出るのいつになるのよこれ
0572名無しさん＠編集中 (ﾜｯﾁｮｲ ffd2-ta/Z)
垢版 |
2018/11/25(日) 15:52:32.43ID:9SyyyIpg0
x265のveryslowより圧縮率が高いということは演算量もそれ以上ということだからカリカリに最適化してもそこまで早くはならないだろうしねえ
nvidiaあたりがいい感じのハードエンコーダー作ってくれないと一般人には縁が無いだろうね
0573名無しさん＠編集中 (ﾜｯﾁｮｲ 33b5-zhOP)
垢版 |
2018/11/25(日) 15:56:51.49ID:i4bTkEii0
でもハードウェアエンコは設定を詰めたりできないのが多くて配信とか以外じゃ結局ソフトエンコがメインになりそうな
ハードウェアエンコのAV1がx264でじっくりエンコしたものに匹敵あるいは凌駕するレベルならともかく
0578名無しさん＠編集中 (ﾜｯﾁｮｲWW d381-Mf4I)
垢版 |
2018/11/26(月) 02:18:23.76ID:qLjHOxCE0
何この悔しそうなコメント

Mozilla、2019年1月リリースの「Firefox v65」でGoogleが開発した画像フォーマット「WebP」をサポート予定。グローバルユーザーの72%が利用可能に。
https://applech2.com/archives/20181125-firefox-v65-support-webp-image.html

＞Mozilla はこの新形式に対するいくつかの懸念から初期の実装作業を中止していました。
＞しかし、Microsoft Edge が最近になって対応したことや、
＞WebP 画像しか配信せず正しく表示されないサイトの数が増え続けていることから、
＞Firefox の開発者は態度を変えざるを得ませんでした。
0579名無しさん＠編集中 (ｱｳｱｳｲｰ Sa47-BrqF)
垢版 |
2018/11/26(月) 09:19:03.63ID:7rLAkN/0a
MozJPEGの出来が良くてWebPにする意味がほとんど無かったからな
それにWebPはJPEGと違って4:2:0のみで、逆に劣化する可能性もある
Googleの言い分としてはどうせお前ら違いなんかわかんねーだろﾌﾟｯて事なんだろ
0598名無しさん＠編集中 (ﾜｯﾁｮｲWW 6fc5-F7GE)
垢版 |
2018/11/26(月) 19:44:53.45ID:2gql7SC10
>>596
戦犯はMicrosoft
IEとEdgeが対応してない

こうやって大手企業がいちいち足引っ張り合ってるから新しいコーデックや圧縮方式が流行らないんだ
足並み揃える気がないなら永遠にレガシーフォーマットだけサポートしてろ
0601名無しさん＠編集中 (ﾜｯﾁｮｲW 7fe0-qDc6)
垢版 |
2018/11/26(月) 20:12:58.42ID:Uh//oc6S0
apngは余りにもデコードが重過ぎる
0603名無しさん＠編集中 (ﾜｯﾁｮｲW f39f-YSKh)
垢版 |
2018/11/26(月) 21:25:37.36ID:5jY/nS9X0
言うてもAPNGはPNG本家では蹴られてるしW3CやISOでの標準化がされてるわけでもないしでそんな責めるほどでもないやろ
足並み言うならmozillaの勇み足ともいえるわけで
次のよりベターな選択肢が見えてる今となっては無理して対応せんでもと思わなくもない
0609名無しさん＠編集中 (ﾜﾝﾄﾝｷﾝ MM9f-qDc6)
垢版 |
2018/11/27(火) 09:08:45.48ID:BllgX5Q9M
AVIFがデコード軽いならそれでいいかなぁ
GIF代替はwebmでいいや
0612名無しさん＠編集中 (ﾜｯﾁｮｲ ffd2-ta/Z)
垢版 |
2018/11/28(水) 06:13:55.48ID:PMyeRoXc0
ディープラーニングを利用した映像圧縮技術
http://www.wave.one/video-compression
https://static1.squarespace.com/static/57c8be4459cc68c3e3d7b040/5bec7ccc03ce6411e9c358a2/5bec7cf2032be4f1c237ca86/1542394827614/hd_quality.png

To the best of our knowledge, we are the first machine learning method to outperform all commercial video codecs in this setting.
For instance, on typical SD videos, our codec achieves on average 30%-40% reduction in file size for the same quality over HEVC/H.265.
0615名無しさん＠編集中 (ﾜﾝﾄﾝｷﾝ MM8a-hTpF)
垢版 |
2018/11/29(木) 09:06:46.33ID:TK3Z1YN2M
ここまで上がるとなるとh267あたりでAIが採用されるのは間違いなさそうやね
0618名無しさん＠編集中 (ﾜｯﾁｮｲ 5a76-my/U)
垢版 |
2018/11/29(木) 11:13:25.97ID:bjPO2wB+0
開発競争が無意味と言えんが。
コーデックなんか普及しなきゃ意味ないのにな、
Blu-rayにねじ込んだVC1（笑）
0622名無しさん＠編集中 (ﾆｸｸｴ 1a11-C0zt)
垢版 |
2018/11/29(木) 21:43:14.66ID:XDriPRzI0NIKU
今の水準からしたら眉唾だね>昔の超解像度技術

今も昔も将来もデータを失わずにエンコードすることなんてできないんだから
その後工程での補正を前提にもっと強く圧縮するというのは今の延長線ではあると思う
だけど、「とても自然に補正できる補正エンジン」があることが前提だけど
0627名無しさん＠編集中 (ﾜｯﾁｮｲ 831d-lzSb)
垢版 |
2018/11/30(金) 10:21:11.33ID:EVEKoJ810
最近の超解像は人工知能つかってディティール水増しする方向なのかな
https://vitalab.github.io/deep-learning/images/srgan-super-resolution/figure2.png
これとか、ぼやけ感は無くなってるけどディティール自体はデタラメでSSIMも悪化するっていう

そんで正確性は高いけどボヤけるのと、ぼやけてないけどデタラメってのは
どうやらトレードオフらしいとか
0632名無しさん＠編集中 (ﾜﾝﾄﾝｷﾝ MM8a-hTpF)
垢版 |
2018/11/30(金) 18:49:59.38ID:MZSOHUZhM
あれは酷かったね…耳が痛くてしょうがなかった
自分は画像に関してはwaifu2xなんかの超解像見るに速度さえ出せればディティール保持も見た目の最適化も両立出来そうだと感じる
単に量子化ノイズの除去やディティールの復元だけじゃなくてベクター解析なんかにも応用されまくるんかなやっぱ
0637名無しさん＠編集中 (ﾜｯﾁｮｲWW 838a-+fLy)
垢版 |
2018/12/02(日) 18:56:46.15ID:l3ffSDJQ0
超解像によって生まれる冤罪。。
というのは冗談だけど、動画圧縮は、もとの動画からいかに違和感なく情報を間引くかという方向から、いかに少ない情報の動画から情報が詰まっていそうな動画を（デコードで）作り出すかという方向へ重点がシフトするのかな。
0638名無しさん＠編集中 (ﾜｯﾁｮｲ b7b5-C0zt)
垢版 |
2018/12/02(日) 19:10:05.15ID:uYlYhsww0
そういうのオーディオではよくある手法というか機能だけどそれが気に入らないって人も一定数存在するから
映像方面で実装されたとしても容易にオン・オフできるような形にはなるだろうね
0641名無しさん＠編集中 (ﾜｯﾁｮｲWW db1a-dMo3)
垢版 |
2018/12/02(日) 22:31:31.44ID:fL8ekCcT0
テレビにもアプコン機能あって、地上波とか4Kにしてくれるけど、元がウンコならアプコン後もウンコだし、無いピクセルから元の画素を予想する技術ってAI使ってもまだあと二回くらいイノベーション必要だよね、特にCPUで…
テレビに量子コンピュータが搭載されるような時代の話…
0646名無しさん＠編集中 (ﾜｯﾁｮｲ 1ad2-3wM6)
垢版 |
2018/12/04(火) 10:16:10.49ID:I5Nux3Qt0
元々スケジュール遅れまくってたし6月に仕様決まったときもバタバタしてて見切り発車みたいなとこあったもんね
まだ問題が残ってたんだろうなあ
0647名無しさん＠編集中 (ﾜｯﾁｮｲ e3ec-C0zt)
垢版 |
2018/12/04(火) 10:32:34.51ID:drsA15ra0
>>643
Chromeさんの翻訳で読んだけど、誤訳でなければ以下のような感じかな。

　・ハードウェアデコーダ開発側が、一部の仕様を制限したいと考え、
　　それに沿った新しい仕様のリビジョン（1.1.0なり1.0.1なりとにかく1.0の次の版）を求めているらしい。

　・1.1.0に従って作ったストリームは1.0のデコーダでもデコードできるが、
　　1.0に従って作ったストリームの一部（1.1.0に違反するもの）は1.1.0に特化したデコーダではデコードできない。

　・まあまだ普及の初期段階だし、1.0準拠のストリームが世にあふれかえってるわけでもないから
　　エンコーダ/デコーダの開発がスムーズに1.1.0にシフトしていくならあまり問題ないかもね。
　　ただいくらか遅れはでるかもしれないし、実際どうなっていくかは要注目。
0656名無しさん＠編集中 (ﾜｯﾁｮｲ 1a11-C0zt)
垢版 |
2018/12/04(火) 17:17:43.22ID:GX5PFI8B0
最初期のh.264のHWデコーダーにあった
Bフレとref数は3までがベターみたいな感じで
HWでコードに適した制限を付けるのかな

>>655
今だからこそ切り捨てというも手かも（プロファイルでややこしくするよりは
それに、どうもフルスペックAV1 1.0ストリームを
1.1以降専用HWデコーダーでデコードできないって話みたいだし
0658名無しさん＠編集中 (ﾜｯﾁｮｲ 2380-wM+0)
垢版 |
2018/12/04(火) 21:26:28.63ID:uNmsPgx/0
AV1の仕様をフルカバーするハードウェア作ろうと思ったら高額になって
安価な製品の販売が実現できないからじゃないの

QZSSもセンチメータ級の測位出来る機器は巨大で価格の桁が違うじゃん
0660名無しさん＠編集中 (ﾜｯﾁｮｲ 4e81-r3MB)
垢版 |
2018/12/05(水) 05:12:37.71ID:cyY8DigN0
もうVP9でええやないか！！！！！！！！！！11111111
0665名無しさん＠編集中 (ﾜｯﾁｮｲ 9aec-C0zt)
垢版 |
2018/12/05(水) 13:56:05.44ID:HYXqj8dC0
テクノマセが後場急伸、ソフトウェアによるＨＥＶＣ　８Ｋ／６０ｐエンコーダの開発に成功
https://kabutan.jp/news/marketnews/?b=n201811300409

> 数学的手法を駆使した独自のコンピュータアルゴリズム「ＤＭＮＡ」を使用した、
> ソフトウェアによるＨＥＶＣ　８Ｋ／６０ｐエンコーダの開発に成功し、
> 先に開発済みのデコーダとあわせてリアルタイムエンコーダ／デコーダシステムとして
> ライセンス提供を開始すると発表

> ＨＥＶＣのリアルタイムエンコードは、ハードウェアで実現するのが一般的だが、
> 同社製品は市販のパソコン上で動作するようソフトウェアを最適化してあるとしており、
> 開発済みのリアルタイムデコーダと組み合わせ、比較的安価・簡便にシステムを構築できるとしている。
0669名無しさん＠編集中 (ﾜｯﾁｮｲW b116-OEli)
垢版 |
2018/12/07(金) 01:04:15.73ID:7TOMa/480
数学者集団な会社なんだからべつにウソでもないんじゃ
h264初期もこの会社当時は結構画期的なことやってたような
ウソならこんなに長く(2000年創業)会社はもつまい
0675名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MMd3-58q8)
垢版 |
2018/12/07(金) 06:54:25.72ID:e6N9cwTgM
ZEN2TRが現在は妄想レベルの廃スペックで出てくれればガチで余裕で回るな。
エンスー向け最上位も一般じゃないといえばそうだが…
0679名無しさん＠編集中 (ﾜｯﾁｮｲWW 5bc5-URvo)
垢版 |
2018/12/08(土) 07:13:47.72ID:vnLYXNBK0
ようつべは新コーデック出る度にコロコロ変換してるみたいだけど画質劣化していかないの？
ってかこんなゴリ押し出来るのGoogleだけよなぁ……
他サイトじゃその都度変換なんてやってらんないんじゃないか
0680名無しさん＠編集中 (ﾜｯﾁｮｲWW 911a-ZVco)
垢版 |
2018/12/08(土) 08:44:28.81ID:RltGl8+t0
>>679
念のため言っておくが、YouTubeにはサーバーにマスター動画が保存されていて、視聴用にそれを変換しているぞ。
VP9とかAV1とか、それらはその都度、オリジナルの動画から変換している
0681名無しさん＠編集中 (ﾜｯﾁｮｲ 81ec-n9Ol)
垢版 |
2018/12/08(土) 14:09:03.96ID:DMlfxTZY0
>>679
> ようつべは新コーデック出る度にコロコロ変換してるみたいだけど

ついでに言うと「新コーデック出る度に」どころか、視聴数の多い動画なんかはちょくちょく変換しなおしてたりするよ。
再エンコード日はyoutube_dlでmp4を落として確認。

　2016/11/07投稿。現在は2018/10/24に再エンコードされたもの。1月下旬と10月中旬はまた別のファイルだった。
　The World in HDR in 4K (ULTRA HD)
　https://www.youtube.com/watch?v=tO01J-M3g0U

　2012/03/12投稿。現在は2018/10/23に再エンコードされたもの。2018/06/16にも再エンコードされていた。
　livetune feat. 初音ミク 『Tell Your World』Music Video
　https://www.youtube.com/watch?v=PqJNc9KVIZE

あとは投稿直後はエンコ速度優先の低圧縮率の動画にしておいて、数時間後には高圧縮率の動画に差し替えたりとかもしてるらしい。
https://egg.5ch.net/test/read.cgi/streaming/1534122281/465-500
0683名無しさん＠編集中 (ﾜｯﾁｮｲ e1e4-xqdQ)
垢版 |
2018/12/08(土) 18:24:16.78ID:W/3q6tz20
エロ動画保存するのにHEVCにしようかと思ってたけどAV1とか出てきて悩むなぁ
本人申請あれば5年で消えるから定期的にキャプチャした生データのみが溜まる…
もうdrm解除できないし
0686名無しさん＠編集中 (ﾜｯﾁｮｲWW d1c3-RvGO)
垢版 |
2018/12/08(土) 19:05:02.71ID:FPGviYix0
実写の処理だとソフトウェアエンコーダならコーデックなりで良いけど
ハードウェアエンコーダだとマクロブロック捜査（配置）ロジックが弱くて、下手にHEVCとか使う方がH264より画質容量比悪かったりするからな
使えるマクロブロックパターン増えているのに配置の最適化ロジックが追いついていない
0688名無しさん＠編集中 (ﾜｯﾁｮｲW d3e0-58q8)
垢版 |
2018/12/08(土) 21:51:54.83ID:viLrk8j40
h265 veryfastでいいじゃんx264のmidiumぐらいの速さ?で実写なら倍縮むぞ
0690名無しさん＠編集中 (ﾜｯﾁｮｲ 81ec-n9Ol)
垢版 |
2018/12/09(日) 20:50:54.96ID:mhf9FFUb0
>>688
どういう条件での比較かわからんけど、倍縮むというのがファイルサイズ半分になるということなら
x265はそこまで優秀じゃないから、それ相応に画質が落ちてると思う。

圧縮率の向上を期待して使うなら、x265は最低でもmedium、できればslowで使った方がいいんじゃないかな。
速度的にはx264のslow〜veryslow相当になるけど、それが許容できないならx265は使わずx264 mediumでいいんじゃないかと。
0695名無しさん＠編集中 (ﾜｯﾁｮｲ 93d2-WxAZ)
垢版 |
2018/12/10(月) 16:43:54.58ID:n0Skvy6a0
保存用の動画をいくつかAV1でエンコードしてたのにエンコードし直さないといけないのはめんどいな
しかも新しい仕様いつ決まるかわからないし
0700名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MMd3-58q8)
垢版 |
2018/12/10(月) 17:47:26.94ID:Amm8KNrHM
最近は重要なのはソース保持でavisynthなり通して見てどうでもいいのをエンコだなぁ
0701名無しさん＠編集中 (ﾜｯﾁｮｲWW f9c3-0t9+)
垢版 |
2018/12/10(月) 19:22:20.75ID:ezq7cQK10
個人はHDDなどの記憶容量媒体が増加していることもあってさほどエンコードが重要ではなくなったからなぁ
問題は動画配信サイトの帯域でこれはコストも削減できるし消費者も恩恵を受ける
0702名無しさん＠編集中 (ﾜｯﾁｮｲWW 5bc5-URvo)
垢版 |
2018/12/10(月) 20:09:20.82ID:b7Lg7s4k0
もっとリソースが逼迫しないとどいつもこいつも本気で動かなそう
いつも通り足引っ張り合って、いつまでもH.264のまま前に進まない

少しでも容量を削減できる新フォーマットは普及して欲しいけど
0703名無しさん＠編集中 (ﾜｯﾁｮｲ 99ec-n9Ol)
垢版 |
2018/12/11(火) 01:04:05.10ID:uQEkQ78/0
i7-4702MQ、Zeranoe ffmpeg 4.1 x64 (libaom 1.0.0-900-g7715ae1c7)

ffmpeg.exe -i input -strict -2 -an -c:v libaom-av1 -pass 1 -cpu-used 4 -tile-columns 3 -tile-rows 3 -threads 8 -b:v 0 -crf 30 -f mp4 NUL
ffmpeg.exe" -i input -strict -2 -an -c:v libaom-av1 -pass 2 -cpu-used 4 -tile-columns 3 -tile-rows 3 -threads 8 -auto-alt-ref 1 -lag-in-frames 25 -b:v 0 -crf 30 -f mp4 output.mp4

●アニメOP 1920x1080, 23.976fps, 2232frames
　　エンコード時間 05:43:35.34(20615.34秒)
　　エンコード速度 0.108fps (x265 veryslowだと0.71fps)

●crowd_run 1920x1080, 50fps, 500frames
　　エンコード時間 03:25:56.45(12356.45秒)
　　エンコード速度 0.04fps (x265 veryslowだと0.4fps)

さすがにAV1エンコはまだまだ遅いね。-cpu-used 0や1は試す気になれぬ。
一応これでSSIMではx265 veryslow --tune ssimと同レベルの数値が出てる模様。
0705名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MMd3-58q8)
垢版 |
2018/12/11(火) 10:12:13.85ID:oRfnvptFM
もう265veryslowの1/10程度になったのか
VP9代替までそれほどかからなさそうやね
0707名無しさん＠編集中 (ﾜｯﾁｮｲ 1381-Po2/)
垢版 |
2018/12/12(水) 07:19:20.09ID:KgM0kImh0
ITU H.266
https://de.wikipedia.org/wiki/Versatile_Video_Coding

H.265 / HEVC（ターゲット：常に50％）より少なくとも30％優れた圧縮率
解決策：4Kから16Kまで
360°ビデオのサポート
現在のスケジュール
2017年10月：提案を求める
2018年2月：受け取った提案の評価
2018年10月：評価のための最初のテストモジュール
2019年10月：最初の規格案
2020年の終わり：最初の公式基準
2021年6月：最初のハードウェア実装
0716名無しさん＠編集中 (ﾃﾞｰﾝﾁｯW d3e0-58q8)
垢版 |
2018/12/12(水) 20:35:59.91ID:YVoHYalp01212
>>713
> ファイルサイズがあまり小さくならないことから、フォーマット変換のみ行っているようです。
うーん…有象無象のニコ厨の方がまだマシな記事書きそう
0718名無しさん＠編集中 (ﾃﾞｰﾝﾁｯWW 918a-YO2S)
垢版 |
2018/12/12(水) 21:33:42.17ID:tTRXYDvO01212
コンテナだけ変えたって言ってるのかと思ったけど
> 時間はかかるが、丁寧にエンコードしてビットレートを下げてるようだ。
って書いてるとこ見ると「丁寧にエンコード」してないことを端折って書いた感じか
誤解を招く書き方というかなんというか
0721名無しさん＠編集中 (ﾜｯﾁｮｲ 9fe3-IKOO)
垢版 |
2018/12/18(火) 14:42:57.99ID:hNCNccbz0
ソニーのHEVC。
Sony’s next codec is “XEVC” – could blow the doors off the industry with 8K RAW at 240Mbit
https://www.eoshd.com/2018/12/sonys-next-codec-is-xevc-could-blow-the-doors-off-the-industry-with-8k-raw-at-240mbit/
https://www.eoshd.com/wp-content/uploads/2018/12/sony-xevc-codec-8k-702x722@2x.jpg

キヤノンのXF-HEVC。
https://www.newsshooter.com/wp-content/uploads/2018/09/xf705_4a-600x433.jpg
0722名無しさん＠編集中 (ﾜｯﾁｮｲ 9fec-UKyl)
垢版 |
2018/12/18(火) 17:48:50.99ID:0Ydc/crf0
AVIFのGitHubに、実装例を集めたWikiページが追加されてる。

　Home ・ AOMediaCodec/av1-avif Wiki
　https://github.com/AOMediaCodec/av1-avif/wiki

実装例の１つ

　AVIF Wasm decoder demo
　https://cconcolato.github.io/wasm-av1/
　（https://twitter.com/cconcolato/status/1073681832414048256）

AVIFサンプルファイル

　Netflix：　　 http://download.opencontent.netflix.com/?prefix=AV1/Chimera/AVIF/
　Microsoft： https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Microsoft
https://twitter.com/5chan_nel (5ch newer account)
0732名無しさん＠編集中 (ﾜｯﾁｮｲW e3e0-odIk)
垢版 |
2018/12/22(土) 17:26:18.26ID:3LX/WNsr0
aviはあーゔぃー
0735名無しさん＠編集中 (ｱｳｱｳｳｰ Sac9-zSrn)
垢版 |
2018/12/22(土) 17:53:59.13ID:wWcj1yXha
H.264 | AVCは全部足してのばすとこう？
International Telecommunication Union Telecommunication Standardization Sector Rec. H.264 | International Organization for Standardization/International Electrotechnical Commission 14496-10 Moving Picture Experts Group 4 Part 10 Advanced Video Coding
0742名無しさん＠編集中 (ﾜｯﾁｮｲWW 1bc5-ELYF)
垢版 |
2018/12/22(土) 21:04:20.25ID:acspqH9p0
AVC　アダルト ビデオ コンテンツ
HEVC　エッチ エロ ビデオ コンテンツ
VP9　ビデオ ポルノ 9
MPEG　マゾヒスト ペンペン エロ ギンギン
HEIF　エッチ エロ インサート フィニッシュ
AVIF　アンアン
（ここで何くだらねー事まとめてんだと我に返る
0746名無しさん＠編集中 (ｱｳｱｳｴｰ Sa13-9rjZ)
垢版 |
2018/12/23(日) 04:08:29.59ID:0ENhhAK1a
libvpxのvp9デコーダがマルチスレッドに最適化されて速くなるらしい
ffmpegのvp9デコーダであるffvp9が以前からlibvpxより数倍速かったからほとんどのソフトには関係ない事だけど
chromiumがバイナリサイズが増えるからとかいうクソみたいな理由で頑なにffvp9を拒み続けてるからchromium系のブラウザ使ってる人には将来的に恩恵あるだろうね
ちなみにffvp9とdav1dの作者は同じ人
chromiumはAV1になっても同じような対応をする可能性が高いのでおそらくchromiumでdav1dは使われないだろう
https://www.phoronix.com/scan.php?page=news_item&;px=Libvpx-Tile-SB-Row-MT-Decode
0750名無しさん＠編集中 (ﾜｯﾁｮｲWW 1bc5-ELYF)
垢版 |
2018/12/23(日) 12:39:02.22ID:LCza3bO+0
>>748
Apple、64-bit環境への移行に伴い
macOS Mojave後のmacOSでネイティブサポートされなくなる
レガシィメディアのファイルフォーマットをFCPXやiMovieユーザー向けに公開。

2018年12月にメディアエディタ向けに案内されたメーリングリストによると、
AppleはmacOS Mojave後のmacOSにて64-bitテクノロジへの完全な移行を行う目的で、
QuickTime 7フレームワークとの互換性のあった以下のメディアフォーマットやコーデックをレガシィフォーマットとし、
macOSでネイティブサポートしなくなると発表しています。

3ivx MPEG-4
AV1 / VP9
AVC0 Media AVA0 Media
BitJazz SheerVideo
（以下略）

＿人人人人人人人＿
＞　AV1 / VP9　 ＜
￣Y^Y^Y^Y^Y^Y^Y￣

レガシーとは一体……
0753名無しさん＠編集中 (ﾜｯﾁｮｲWW 1bc5-ELYF)
垢版 |
2018/12/23(日) 12:55:49.71ID:LCza3bO+0
こうやって足を引っ張り合う訳ですよ
人類って本っ当にバ〜〜〜〜〜〜〜〜〜化だな〜〜〜〜〜〜〜〜〜〜〜〜〜ｗｗｗｗｗｗ

いや本当にこれH.264が動画界のJPEGポジションで居続ける将来しか見えないんだけど
0756名無しさん＠編集中 (ﾜｯﾁｮｲ 4580-MCmy)
垢版 |
2018/12/23(日) 13:55:18.84ID:yZSGGkBX0
https://support.apple.com/ja-jp/HT209000
記事読む暇がないヒト向けに書いておくと、自社製ソフトウェア上における
「ネイティブ編集対応をやめる」のであって、直接扱おうとしたらまず
ProResにトランスコードが始まるようになる。それから編集ってこと

※変換されんの嫌なら他社製ソフトウェアで編集してねってことで
わざわざWindowsマシン使って変換とかが必須になるわけではない
0763名無しさん＠編集中 (ﾜｯﾁｮｲ 23ec-q1e7)
垢版 |
2018/12/23(日) 19:17:53.91ID:dxQmKrOA0
>>748 >>750 >>756
Final Cut Pro X のレガシーメディアについて - Apple サポート
https://support.apple.com/ja-jp/HT209000

macOS 用 iMovie のレガシーメディアについて - Apple サポート
https://support.apple.com/ja-jp/HT209029

Macのことはよく知らないけど、そもそもこれまで Final Cut Pro X や iMovie で
VP9やAV1を読み込むことはできたのかな？そういう話題を見かけたことが無いような・・・。

レガシーと言ってるのは、コーデック自体のことというより、QuickTime 7 フレームワークを利用しているものを
レガシーだと称しているだけみたいだね。

> 2019 年前半にリリース予定の Final Cut Pro のアップデートに、QuickTime 7 フレームワークを使う
> レガシーメディアを探し、変換する機能が盛り込まれる予定です。

読み方によっては、この時にAV1やVP9の変換読み込みをサポートすると解釈できないこともないけど・・・さて。
0764名無しさん＠編集中 (ﾜｯﾁｮｲWW 6d1b-sXR5)
垢版 |
2018/12/23(日) 21:39:44.17ID:w2tNj4U/0
レガシーフォーマットだから、フレームワーク提供しないよー
他社アプリは勝手に拡張して対応してくれるかもねー

ってAOMに参加したばかりの大企業とは思えない決定だな
0766名無しさん＠編集中 (中止 edec-q1e7)
垢版 |
2018/12/24(月) 01:05:09.32ID:agtwOkQX0EVE
「影響を受けるメディアフォーマットの例」の中に「AV1／VP9」が入ってるから
そこだけ見て誤解してる人が多いようだけど、主題は

　　「QuickTime 7 フレームワークの利用停止」

なので、やってることはごく真っ当な進化だと思うよ。
そもそもこれまでもAV1/VP9の読み込みなんてサポートしてなかったみたいだし。
サードパーティの読み込みプラグインがあるのかと思って探してみたけど見つからなかった。

だいたい現状で動画編集ソフトでAV1/VP9素材を扱う需要なんてほぼ無いだろうし、
動画編集ソフトでAV1をネイティブにサポートする時期なんて、HWデコーダ/エンコーダが
それなりに出だすであろう時期（1年後くらい？）になってもまったく問題ない。

そんなことよりSafariとかでのAV1/VP9再生をさっさと実装しろよと思うけど、
AV1はともかく、VP9はサポートしないまま終わりそうではある。
0767名無しさん＠編集中 (中止WW 6d1b-sXR5)
垢版 |
2018/12/24(月) 02:37:54.93ID:5OVvOqT40EVE
>>766
AV1がネイティブサポートされない、つまりAVFoundationで対応する予定が無いんだと思うよ
そうすると動画編集ソフト云々では無く、Safariでの再生対応も無いんじゃないかな
0772名無しさん＠編集中 (中止 Sp61-rGfj)
垢版 |
2018/12/24(月) 23:48:51.96ID:ezLTY33bpEVE
VP9を個人でエンコする需要がない
個人ならライセンス関係ないからHEVCの方が全面的に優れてるし
AV1も今のところ遅すぎるから微妙だし
再生だけ対応してくれればいい
0774名無しさん＠編集中 (中止 ad60-q1e7)
垢版 |
2018/12/25(火) 01:52:41.38ID:W8TD/jAC0XMAS
スマホこそエンコードできたほうがいいでしょ
外出してビデオ撮影したファイルサイズを小さくできたり
ビデオ通話で画質が良くなったり
ひきこもりぼっちだからどれも関係ないしやっぱいらねーわ
0777名無しさん＠編集中 (中止WW 8dc3-9Nh/)
垢版 |
2018/12/25(火) 03:01:01.73ID:Iw27XV7n0XMAS
av1をモバイルでエンコードできるのは10年くらい掛かりそう
デコードを頑張ってほしいが、林檎とかいう天の邪鬼がいるからどうなるやら
0779名無しさん＠編集中 (中止 MMa3-odIk)
垢版 |
2018/12/25(火) 06:56:14.37ID:5vg9f2bCMXMAS
HEVCは企業側が採用したがらないからもし動きがあるとすれば次のVVCじゃないかな…
0781名無しさん＠編集中 (中止WW f5c3-sbOp)
垢版 |
2018/12/25(火) 08:47:09.86ID:jtOS7ekg0XMAS
撮影用コーデックは撮影者が扱えてナンボだから、扱いづらいコンテンツ提供向けのライセンスフリーの高圧縮コーデックの方を優先するなんて普通に考えればありえないと思うけどな、スマホ用なら尚更だし
0783名無しさん＠編集中 (中止 c3dc-gbB5)
垢版 |
2018/12/25(火) 10:29:52.21ID:LjZb6PqY0XMAS
静止画にしろ動画にしろ、オフィス系ソフトと年賀状作成ソフトで手間なく開けるようにならない限り日本では普及しないだろうなあって思う
0784名無しさん＠編集中 (中止 MMe1-ELYF)
垢版 |
2018/12/25(火) 12:24:36.72ID:1dLwpqi0MXMAS
>>783
法人市場ではそうかもしれんが
個人向けでオフィスや年賀状ソフトに依存しきってる奴が何%いると思ってるんだ

具体的な割合は知らんがそう多くは無いだろう
0789名無しさん＠編集中 (中止 Sa13-9rjZ)
垢版 |
2018/12/25(火) 19:34:55.82ID:9dBfh34KaXMAS
フォーマットとは少し違うかもしれないけどhttp2.0とhttp3.0はGoogleが作ったプロトコルがベースだな
あとはbrotliとか
0791名無しさん＠編集中 (ﾜｯﾁｮｲ 5ad2-NEfe)
垢版 |
2019/01/01(火) 13:34:33.06ID:6lyMxGai0
https://drive.google.com/open?id=1vs9oqpXJt91FhkfNtYHFB3fO2OiN98C3
画像をAVIFに変換するbat書いた
Windows 10 Insider Preview Build 18305.1003で表示出来るファイルになるのを一応確認済み
まだ仕様が決まってないから画質確認して遊ぶ用だけど、AVIFと同サイズくらいのjpgを出力する機能もあるから興味ある人は試して
0792名無しさん＠編集中 (ﾜｯﾁｮｲ 76a7-AIgs)
垢版 |
2019/01/02(水) 14:31:20.61ID:cJ3tV5fJ0
jpgとそこまで画質変わらないな
0794名無しさん＠編集中 (ﾜｯﾁｮｲWW 13f7-+Rby)
垢版 |
2019/01/03(木) 10:55:38.27ID:I5Axic6f0
jpg品質85の時
Y-SSIM 0.971384916666667
bpp 1.82670423719618

avif
Y-SSIM 0.972543208333333
bpp 1.07366349962023

jpg品質95の時
Y-SSIM 0.988786333333333
bpp 3.28187476264106

avif
Y-SSIM 0.988429625
bpp 1.92569732666016

bppは24枚の画像で(ファイルサイズ*8)/(横幅*縦幅)を計算した平均値
0799名無しさん＠編集中 (ﾜｯﾁｮｲW 9301-iY/o)
垢版 |
2019/01/03(木) 15:36:56.04ID:uW4rZPkL0
JPG85と95っておおよその人が一見して分かる差だと思うけど
0800名無しさん＠編集中 (ﾜｯﾁｮｲ 5123-xhm2)
垢版 |
2019/01/03(木) 16:07:40.43ID:PlOBTmFY0
実写というか写真だとオリジナルと見比べないならあまり気にならないけどCG、イラスト、アニメ絵とかだと
結構わかる差だよな
なんというかもともとソースが不自然にきれいすぎるもの相手だとどうしても目につく感じ
0803名無しさん＠編集中 (ﾜｯﾁｮｲ 69b0-ZWW8)
垢版 |
2019/01/06(日) 23:58:49.38ID:Bfy9mN6O0
95未満だとキラーサンプルがあるとだれでも劣化が分かる
現実的には85で4:4:4なら結構いい感じ。
※クオリティ値はバニラcjpegと標準量子化テーブルでの話

JPEGって4:2:0がウェブの実質的標準なので性質悪いんだよな
カメラのJPEG保存ならセンサーが元々ベイヤー配列だし4:2:0も悪くないけど、
公開時にサーバー側処理で1/4未満の解像度にリサイズされた時点で各ピクセルは4:4:4相当の情報持つからね
0805名無しさん＠編集中 (ﾜｯﾁｮｲW 69b0-sxLP)
垢版 |
2019/01/07(月) 00:57:14.91ID:LDILApyf0
高DPIになればそうだね。

ちなみに有名どころのサービスで再エンコでしっかり4:4:4 JPEGを吐くのはPixivしか知らない。
もしかしたらGoogle Photosもサムネイル表示だけ444だったかも※大きい解像度は420
0806名無しさん＠編集中 (ﾜｯﾁｮｲW 69b0-sxLP)
垢版 |
2019/01/07(月) 01:15:48.07ID:LDILApyf0
ただしGoogle系はWebP対応ブラウザだと、フォーマットの制限で全部420
Webpは再エンコに極度に弱い
https://www.youtube.com/watch?v=ujBp5B35el4

大きいマクロブロックを使える最新のフォーマットの方が8x8のJPEGより色滲みの範囲が広くなるため再エンコ時の世代劣化が酷くなりがちなんだけど、WebPのエンコーダーは根本的に設計ミスしてるとしか思えない
ローパス効きすぎてるんじゃねえのかな
0807名無しさん＠編集中 (ﾜｯﾁｮｲW 69b0-sxLP)
垢版 |
2019/01/07(月) 01:28:33.66ID:LDILApyf0
一応擁護するとGoogleは真にJPEGを置き換える目的のPIKというフォーマットを開発中。進展聞こえて来ないけど。

今度はブロックも敢えて8x8にしてJPEG並の再圧縮耐性がある模様
0810名無しさん＠編集中 (ﾜｯﾁｮｲW 534b-hWLU)
垢版 |
2019/01/07(月) 05:15:39.69ID:IwP6LG2y0
VP9を見るとGoogleは最初から自分の利益の為にコーデックを作ったから公開する。
普及率上げられるよう努力はするけどそれ以上あまり深入りはしない。といったスタンスだと思う
プラットフォーマーでそれなりに責任感感じて後々のサポートまで考えてるのってMSぐらいじゃないの?色々乱立してカオスになる事は多いけど面倒見はいいよ
0811名無しさん＠編集中 (ﾜｯﾁｮｲW 69b0-sxLP)
垢版 |
2019/01/07(月) 11:05:54.81ID:LDILApyf0
Google PIKも恐らく頓挫する。複数の量子化テーブルを持てる点で優れてるんだけど、Guetzli開発で培った画質評価アルゴリズムで量子化テーブルを最適化するので劇重。

しかもカラースペースを考慮に入れて画質評価をするメカニズムなのでカオスになってる。現状はsRGBがハードコードされてる厄介な仕様。

JPEGの連中とてカラースペースを考慮に入れた圧縮をするのが理想なのは百も承知なんだけど、仕様が無駄に複雑化する上に改善効果が薄いから敢えてやってないんだよね
0816名無しさん＠編集中 (ﾜｯﾁｮｲWW 699b-9+ha)
垢版 |
2019/01/07(月) 16:00:56.23ID:ninKal400
ビデオコーデックに関してはNHKと日本企業が開発すれば、NHKが放送用規格売り込んで大手電機メーカーが民生機器売って一気に普及するんじゃないの。
互換性保つ事前提になりそうだけど。
0819名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MMd3-hWLU)
垢版 |
2019/01/07(月) 18:17:51.22ID:5mR8utRvM
>>816
NHKは265/266の開発にもモロ携わっているから…(作る訳ねーだろ)
0821名無しさん＠編集中 (ﾜｯﾁｮｲWW 699b-9+ha)
垢版 |
2019/01/07(月) 21:49:39.66ID:ninKal400
NHKがスーパーハイビジョン研究で先行してるし、NHK主導の日本の放送方式は色んな国で使われていたはず。
あとテレビに限らずエンコーダーやテレビカメラ、放送機器とは別に、民間のビデオカメラやデジタルカメラは日本企業が世界でもトップシェア。記録フォーマットのAVCHDはそこそこ普及した。
XAVCとかATRACとか、一社だけでやればそりゃあ普及しないけど…
0822名無しさん＠編集中 (ﾜｯﾁｮｲ 1316-xhm2)
垢版 |
2019/01/07(月) 22:00:34.93ID:65/kj72t0
地上デジタルのことならブラジルとか中南米の一部だけ
コーデックは世界標準のものを使ってるだけだし
次の4k/8kは実情と乖離した22.2ch音声も規格化されてたり悪い意味でガラパゴスの極致
0827名無しさん＠編集中 (ｽｯｯﾌﾟ Sd33-cJ4o)
垢版 |
2019/01/08(火) 00:42:52.47ID:xQaccg9zd
8K放送とかリアルタイムエンコーダ/組み込み用デコーダの技術不足で
時期尚早残念ハイビジョンの地デジの二の舞になると思ってたんだけど

実際どんな感じなの？
0829名無しさん＠編集中 (ﾜｯﾁｮｲWW 3319-0RrR)
垢版 |
2019/01/08(火) 02:07:35.97ID:SiWIHh5P0
コンテナはTCや字幕やら載せられるMXFしかありえないし
XAVCはオープンだしほぼ全てのNLEがXAVCサポートしてて、ポスプロ中間CODECとしてはほどほどの圧縮率で使いやすい

4K見てると5.1chもあるが、0.1の重低音chは無音なことがほとんど
下が100Hz以下まで再生出来るなら、0.1は無しの方が個人的にはいいけれど
0830名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM95-Py2J)
垢版 |
2019/01/08(火) 08:36:09.99ID:qA0WsWAzM
4Kでもオーバースペック気味なのにNHKは8Kなんて無駄な事にカネ使うなっての
こんな無駄の為に国民の負担増やすから国際競争力が低下するって解ってないだろ
0833名無しさん＠編集中 (ｽﾌﾟﾌﾟ Sd33-jxS1)
垢版 |
2019/01/08(火) 10:07:39.85ID:xQ5uk0fMd
>>831
絶対にそうなると俺も思うわ、映像技術開発に金をかけずに衰退した後で「昔は日本がこの分野では世界一だったんだけどなぁ」とか懐古に浸りながら言うに決まってる
0834名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM95-Py2J)
垢版 |
2019/01/08(火) 10:43:00.34ID:qA0WsWAzM
DVDで十分じゃなくて映像の配信媒体として光学ディスク自体がニッチ化するのが明らかだった
blu-rayディスクレコーダーなんて放送と家電屋の既得権益に飲まれた日本の象徴的な産物
結果としてnetflix等のストリーミング映像配信サービスが黒船として正に脅威になってる
0837名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM95-Py2J)
垢版 |
2019/01/08(火) 11:00:46.69ID:qA0WsWAzM
8K採用するのに十分に低コストな編集、制作環境、配信コストの見込みが立っていればまだしもスケジュール最優先で決まったのが明らか

劇的に圧縮率が向上するようなコーデックも現状見込みがない事もここの住民なら解ってるはず

データ容量的に配信コストが高過ぎて光学ディスクと放送ぐらいしかまともに活用出来ない
つまり恩恵が得られる受け手は旧態依然とした映像マニアぐらいと言う絶望ぶり
0840名無しさん＠編集中 (ﾜｯﾁｮｲ 1316-xhm2)
垢版 |
2019/01/08(火) 11:44:38.51ID:9OnWazE60
>>831
日本の地デジ規格の何がダメかってコピーコントロールがあることで
そういうろくでもない縛りが黒船のおかげで崩壊するなら万歳三唱で迎え入れるって人は多いと思うぞ

それに2k放送に限っても「家電王国 日本」の威信をかけて開発したわりにmpeg2採用だったり
もうちょっと技術的なものと長期的スパンとのバランスをとる気はないのかって思う
0846名無しさん＠編集中 (ﾜｯﾁｮｲWW 699b-9+ha)
垢版 |
2019/01/08(火) 23:26:47.35ID:5MOzIVoc0
>>840
同感。H264今からでも採用しろよって思う。mpeg2の帯域を半分にしてH.264ぶち込んでもいいと思うくらい。
コピーコントロールはNHKが口出しまくってるんだよね、嫌なら無料でフルHDビデオオンデマンドを解放しろよ公共放送なんだからって思う。
0847名無しさん＠編集中 (ｻｻｸｯﾃﾛ Spc5-q3US)
垢版 |
2019/01/08(火) 23:41:15.50ID:e+kmjB2Ap
TVはGOP0.5秒（15フレーム）だからH.264にしても大して改善されないぞ
アニメエンコはGOP10秒（240フレーム）とかにして稼いでるのが大きいからな
低レートだとデブロッキングあるからマシだけど家電ならMPEG2でも同じようなの映像処理でやってるからな
0848名無しさん＠編集中 (ﾜｯﾁｮｲWW 3319-0RrR)
垢版 |
2019/01/08(火) 23:42:31.84ID:SiWIHh5P0
後からは、誰でも何とでも言える
スケジュールありきでないと、技術開発ってものは進まない
今でもHD放送のマスターはMPEG2 50MbpsのXDCAMだし、放送はMPEG2 13Mbps

地デジで全てのテレビがHDになった時でも、俺には必要ない、DVD最高！ってのがわんさかいたな
0853名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM95-Py2J)
垢版 |
2019/01/09(水) 11:14:07.26ID:RoTB2nIrM
地デジ自体をさっさと終了しろと思うわ
地デジ開始時も全部BSに追いやって地上波の帯域は携帯電話か無線LAN、wimaxの通信事業者にやれと思ってた

ところがどっこい明白に通信の時代になってるのに4K8K放送とか言い出すから目眩したわ
未来を潰す時代錯誤も甚だしい老害の発想
0855名無しさん＠編集中 (ﾜｯﾁｮｲ 512f-xhm2)
垢版 |
2019/01/09(水) 11:32:57.59ID:3uwF8g/N0
4K放送でH265使うために特許料金払うことになるだろうけど
パテントプール内の団体を思い出すたびにちょっとへこむ
NHKとか特許料何に使うねん
0857名無しさん＠編集中 (ｱｳｱｳｶｰ Sa55-5TW8)
垢版 |
2019/01/09(水) 12:56:16.98ID:v/qLEDL9a
アナログテレビの頃は互換性を維持したままカラー化や画質の向上をしてこれたけど、デジタルは一旦ご破算にしないと画質向上させられないのが痛いな
地デジをどうやって4kにするのか謎だな
というか無理なんだろうね
0860名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MMd3-hWLU)
垢版 |
2019/01/09(水) 14:23:11.92ID:K7pXGAJQM
mpeg2からh265になれば同一ビットレートで余裕じゃないの
0863名無しさん＠編集中 (ﾜｯﾁｮｲWW 71a5-cJ4o)
垢版 |
2019/01/09(水) 16:56:05.77ID:n/rKNJAQ0
地デジは放送側のエンコーダを更新して画質向上できないのかね？
ガチガチの規格に縛られてて変更できないとか有るのかな

同じ形式で出力するにしても、処理能力の暴力で叩くとか
新しいアルゴリズム採用するとかすれば品質上がりそうだけど
0864名無しさん＠編集中 (ｽｯｯﾌﾟ Sd33-HRNa)
垢版 |
2019/01/09(水) 17:06:28.21ID:/7usGwoYd
送出側のエンコーダの更新はしてたはず
地デジ初期に比べれば向上してる

デコーダの更新はほぼ不可能だろうし、当面は現行方式でいくだろうね
0868名無しさん＠編集中 (ﾜｯﾁｮｲ d9e7-xhm2)
垢版 |
2019/01/09(水) 20:51:14.48ID:fy0v0hR/0
というか帯域どうこうというなら縦解像度だけで話すのではなく、
全体の解像度（画素数）の差とかi/pの差とかフレームレートの差も考えるべきだろうと。
0869名無しさん＠編集中 (ﾜｯﾁｮｲW 534b-hWLU)
垢版 |
2019/01/09(水) 21:12:44.86ID:MYU0a4A60
sar4:3
インターレース
4:2:0
0870名無しさん＠編集中 (ｱｳｱｳｲｰ Sa45-DsDM)
垢版 |
2019/01/09(水) 21:36:16.20ID:1G0gBTj4a
地デジはセグメントを12(HD)、8(HD)+4(SD)みたいな事をやってるから、
8だけでHD放送して4に追加の高画質化情報を送るとかすれば、
古いテレビは今まで通りで新しいテレビでは高画質とか出来なくはなさそう
0873名無しさん＠編集中 (ﾜｯﾁｮｲ 5123-xhm2)
垢版 |
2019/01/09(水) 23:40:18.71ID:LxwMqcZE0
放送は基本的にリアルタイムエンコしてるから遥かにビットレートが低いはずのネット放送に
画質で負けたりすることがあるんだよな
エンコーダの進化で画質の向上の余地は充分あるはず
0876名無しさん＠編集中 (ﾜｯﾁｮｲ dd01-Fjw0)
垢版 |
2019/01/10(木) 00:02:22.66ID:0owCCzLj0
>>871-872
H.264のデブロッキングフィルタみたいにQP情報参照して、
マクロブロック単位でデブロックやリンギング除去掛ける画像処理があるんだよ
デコーダと直結してないと無理なのでPCだと難しいけど、
AvisynthのDGDecodeで出来るのでやってみるといい
荒れてるところだけ強く掛けるから全体に影響しないしかなり効果ある
0877名無しさん＠編集中 (ﾜｯﾁｮｲ dd01-Fjw0)
垢版 |
2019/01/10(木) 00:07:22.81ID:0owCCzLj0
逆にH.264のデブロッキングフィルタをOFFにしてみるのも面白い
低レートだとかなりガビガビになって元はこんなのなのかってのが分かる
これ出てウェーブレットとかすっかり下火になっちゃった気もするしかなりの発明だったと思う
0879名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/10(木) 00:40:50.98ID:6cauLr9D0
MPEG2の今の地デジ方式って、1998年に規格策定完了してなきゃいけなかったから、MPEG2しか選択肢がなかったんだがな
MPEG2に文句つけて大きな事を言ってる奴は、その20年前何してたんだよ？
やっとHDCAMが出始めた頃

まともにHDのCODECについて語れる奴は、少なくとも俺はお目にかかってないぞ
すぐに東京タワーから試験放送始めたが、まだまだデジタルチューナーもなくて、イベント会場でチラホラ程度
当初はIRDと呼んで、チューナーとか受信機とさえ呼ばなかったが
0882名無しさん＠編集中 (ﾜｯﾁｮｲ 1624-ae4N)
垢版 |
2019/01/10(木) 01:36:53.46ID:bWsaA+hm0
AV1のロイヤリティー・フリー保証の基本的なアプローチになっている
防御的解除というものがどういうものなのかさっぱり分からん。
アルゴリズム特許に関しても有効に機能するものなの？
0884名無しさん＠編集中 (ﾜｯﾁｮｲ 16f3-ae4N)
垢版 |
2019/01/10(木) 11:42:13.00ID:7Tqw7cEC0
地デジの話はここ見ると面白いぞ
http://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry
0885名無しさん＠編集中 (ﾜｯﾁｮｲ fa16-VK1S)
垢版 |
2019/01/10(木) 12:30:32.90ID:1857LXbZ0
>>876
デブロッキング・フィルタはディテール復元するものじゃないから
放送局から送出された時点でディテールが保持されてる（保持しやすい仕組みの）ほうが望ましいでしょ

>>883
受信してデコードする段階で一工夫するという話で
放送局がどうこうという話じゃないよ
もっとも、そういうのをやってるのは一部高級機だけだろうけど

>>879
欧州でやってるように適度なスパンで内容を見直したらいい
欧州の新版では音声にAC-4 が追加されたらしいし
そういう柔軟性と比べたら22.2chなんて愚直すぎると思う
0886名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MM8a-1+fo)
垢版 |
2019/01/10(木) 14:14:07.52ID:ppRNmCVnM
>>885
22.2chなんてのは作るだけ作ってlvで分けちゃえばいいじゃん
0889名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/12(土) 03:53:49.67ID:pqAaLsv/0
>>885
定期的に見直す＝既存のチューナーテレビが無用の長物と化す
今の日本で「新しい方式の地デジチューナーかテレビに買い換えないと、来年から映らなくなります」が許されるか？
0890名無しさん＠編集中 (ﾜｯﾁｮｲ a52c-hOH0)
垢版 |
2019/01/12(土) 04:44:53.85ID:nZ9gxucS0
アナログ完全停波は6年半前なのに「今の日本」ってどう言う意味
「今の日本」だとどうなのか詳しく
それに1年で映らなくなるなんて言い出すわけないのに極端な条件出すのは卑劣
0893名無しさん＠編集中 (ﾜｯﾁｮｲW 4db0-JK55)
垢版 |
2019/01/12(土) 06:18:11.65ID:CrUhXddg0
4Kじゃ中途半端なので地デジに関しては8Kで移行が妥当って思うけど、ビットレート的には不可能だな
NHKの8K HEVCエンコーダーも下が64Mbpsからだし

かといって全員がBSなぞ入れる訳ないので4K・8Kの標準的な楽しみ方が放送ではなくIPベースになるのは間違いない
0894名無しさん＠編集中 (ﾜｯﾁｮｲW 4db0-JK55)
垢版 |
2019/01/12(土) 06:32:30.39ID:CrUhXddg0
しかしオリンピックのタイムラインで無理矢理テスト放送で8Kねじ込んで当初の目標を達成するのはいいけど、どうせ将来そのままの仕様で本放送になるんだろうな

8Kの本放送はVVC普及まで気長に待っても良いように思うけど、何が何でもNHK案でHEVCのままになりそうな悪寒
0895名無しさん＠編集中 (ｱｳｱｳｲｰ Sa45-AQdJ)
垢版 |
2019/01/12(土) 10:45:44.03ID:V25mx18Aa
地上波は安定して送信できるビットレートが16Mbps程度らしいから、4k8k用の高ビットレートは衛星放送が必須なんだろう
ケーブルテレビ経由でも受信できると思うけど
0897名無しさん＠編集中 (ｵｲｺﾗﾐﾈｵ MM3d-Pxeg)
垢版 |
2019/01/12(土) 10:57:20.63ID:/UBRpgq3M
4Kが中途半端、8Kで移行が妥当って…
リビングで視聴距離2mの環境なら4K50インチ、8K100インチあたりがマニアが見て優位性があるラインだと思う(マニアでなければ1.5倍サイズまでカバー出来る)
0900名無しさん＠編集中 (ﾜｯﾁｮｲ 26ca-mNGr)
垢版 |
2019/01/12(土) 13:14:45.67ID:XxYV/SJc0
AV1っていつ頃からintelのCPUのqsvに統合されるようになるんでしょうか？
ice lakeには間に合いませんかね？
ちょうど2012年に作ったivy bridgeマシンが更新時なのでice lake（と言わずその次あたりでも）で対応してくれると
うれしいのですが。
0903名無しさん＠編集中 (ﾜｯﾁｮｲW 6d5f-Phfy)
垢版 |
2019/01/12(土) 15:07:22.92ID:0pmMrQMQ0
>>891
実際、FullHDなBSを、帯域・解像度とも落とされて、4K開始！きれい！今までと全然違う！
とやられた実績があるから、無いとも言い切れないな。
（アニメの720P放送、映画の24FPS放送は歓迎だが）
0908名無しさん＠編集中 (ﾜｯﾁｮｲ 4db0-bFM5)
垢版 |
2019/01/13(日) 00:19:10.60ID:r3v8oxdG0
>>906
ほいよ
https://www.phoronix.com/scan.php?page=news_item&;px=Intel-Gen11-Graphics-Details

＞There is not any AV1 acceleration yet but it's "coming soon" past Gen11 and Intel is "fully committed" to AV1.
念の為書くけど、この中の「past」は「〜以後に」という「after」みたいな使い方なので、Gen 11「以前に」来ると勘違いして読まないように。
「Gen 11では対応しないが、それ以降はすぐに対応予定である」という建前を言ってるだけ。
0909名無しさん＠編集中 (ﾜｯﾁｮｲ c52d-RNo8)
垢版 |
2019/01/13(日) 00:26:05.19ID:cHYCdQoL0
Haswellあたりは後からGPGPU使ってHEVCに対応とかさせてたのになあ
NVIDIAやAMDはもっとGPUのパワーあるのに後から対応とか全くやらないし
PCも家電と同じように10年使う時代が到来しそうになってきてるんだから頼むよ
0914名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/13(日) 01:14:55.78ID:hC0jZP9x0
>>909
日本中の地上波の送信機を交換するのに、大金と8年くらいかかる
つまりリアルタイムエンコード可能な個体化したエンコーダーと、それを正確に増幅するPA
8年前にできあがっていた規格で、どんなものがある？
H.264までかな
0916名無しさん＠編集中 (ﾜｯﾁｮｲ 1963-Fjw0)
垢版 |
2019/01/13(日) 02:59:46.16ID:vDg3J9sw0
H.264で地デジを見たけりゃ南米(ブラジル)に移住するんやなｗ
デジタル地上波がH.264で流れているんやなｗ
0918名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/13(日) 18:00:55.61ID:hC0jZP9x0
>>917
インターレースは評判悪いが、最近のインタレ解除アルゴリズムが優秀で、59iを59p化するとなかなかきれいだしな
あと、最近のテレビのモーションフローなんかで、30pが120pで表示されるし
XAVC300の60pは600Mbpsだが、30iでいいとなれば150Mbpsで済むことになる(そんな規格はないけど)

HD放送はまさにこれやってるけど、4K8Kはフルの60pだから、処理もストレージもかなり厳しい
0919名無しさん＠編集中 (ﾜｯﾁｮｲWW 4d9b-8J0Y)
垢版 |
2019/01/13(日) 19:10:48.18ID:hzF+ANxl0
>>918
そうは言っても細かい描写とかインターレースで消えてしまう部分の補完は無理があるから、高精細化が進んだHD以降はインターレースは害悪だと思う。
あと59iとか30iって…何？

GOPを1秒にするのはどうだろう
0920名無しさん＠編集中 (ﾜｯﾁｮｲ a52c-hOH0)
垢版 |
2019/01/13(日) 21:21:20.21ID:pKYDwAOg0
インターレースが汚いって言う知り合いの使ってるモニタ確認させてもらうと
ほとんどがI/P変換機能の無い安物PCモニタとか使って判断してたわ
0923名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/13(日) 21:54:21.08ID:hC0jZP9x0
>>919
インターレースで消えてるのは、ある瞬間の1/59.94秒に出てきて、次の1/59.94秒には消えてるディテールな
海の遠景の小さな波しぶきなんかは、このディテールを含んでる可能性はあるが
そもそも圧縮で消えるな

ごめん、フィールド周波数59.94Hzのインターレース59.94iを59iと略称してる
30iは同じだけど、NLEアプリによっては59.94iを
「29.94fpsフィールドを有効」
と書いてるのもあって、これの省略形が29.97iか30i
0924名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/13(日) 22:00:07.46ID:hC0jZP9x0
>>920
I/P変換は今のテレビにはほぼ入ってるからな
昔の一部ドンキ格安テレビとかPCディスプレイとか除いて

逆に、3840 x 2160 UHD 29.97pを4Kテレビで見ると、60pや120p化されててになめらかで驚く
ハリソンフォードが、「映画を24pから勝手にコマ数増やしてなめらかにして見るな！」と、視聴者に文句言ってたなw
0925名無しさん＠編集中 (ﾜｯﾁｮｲW 4db0-JK55)
垢版 |
2019/01/13(日) 22:11:33.00ID:r3v8oxdG0
コーデックが進歩した現在だと、インタレみたいな原始的なデータの間引き方をせずに、ビットレートを半分にした方が綺麗だし。こんな物が受け入れられたのはMPEG-2時代まで
0926名無しさん＠編集中 (ﾜｯﾁｮｲW 4db0-JK55)
垢版 |
2019/01/13(日) 22:27:27.23ID:r3v8oxdG0
最近傍ライン同士が同じブロックに詰め込まれた方が低周波成分の分布が増えて圧縮効率が良くなる。しかも解像度が上がるほどこの恩恵が増えるので、インターレースは消えるべくして消えた
0927名無しさん＠編集中 (ﾜｯﾁｮｲ fa16-VK1S)
垢版 |
2019/01/13(日) 23:33:14.05ID:c/wqKywx0
>>912
フランスかドイツで第二世代地デジへの移行（第一世代の終了と解釈した）が行われたってtwitterで観た記憶があったからの主張なんだけど、
自分の主張の一番のコア部分は、その時々の主流を柔軟に取り入れたらいいのにってことね
AVアンプスレだとAtomosが最新トレンドなのに日本の地デジはほぼ独自でニッチな仕様の22.2chなんて・・っていう感想が元
0928名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/14(月) 00:46:38.98ID:7UaQMeb/0
>>927
UHDブルーレイがすんなり出たように、既存のものに手をつけずに追加するなら何の問題もない
周波数は有限で、既存のHD放送が受信できなくなって次世代に定期的に乗り変われるなら、そんな簡単なことはない

22.2とatomosの関係は知らんけど
4K放送も新規の追加BSch
0930名無しさん＠編集中 (ﾜｯﾁｮｲWW 4d9b-8J0Y)
垢版 |
2019/01/14(月) 01:19:05.83ID:+/nGJIS00
>>923
59.94iは60iでいい気が…
そんな細かい事はまぁいいとして、
圧縮で消えた上でインターレースはキツい。あと文字やテロップも厳しい。
29.94fpsフィールド？
29.97フレームの59.94フィールドって意味だと思うけど…
0931名無しさん＠編集中 (ﾜｯﾁｮｲWW 0a19-cnaZ)
垢版 |
2019/01/14(月) 01:37:08.09ID:7UaQMeb/0
>>930
29.97fps(フレームパーセカンド)フィールドあり、の意味だろうけど
すごく紛らわしい

先日、Premiereで59.94pのGoPro素材を59.94インターレースで書き出したら、実際には119.88フィールドパーセカンドのものが出来てて、笑うしかなかった
0932名無しさん＠編集中 (ﾜｯﾁｮｲ 715f-VK1S)
垢版 |
2019/01/14(月) 02:02:16.67ID:zPROB4EF0
>>930
文字は止まってればインターレース関係ないし、テロップは動き補償型インターレース解除なら問題ない
CMの注意書きみたいな小さい文字が動いてると問題だけど、そんな映像普通作らないから
0933名無しさん＠編集中 (ﾜｯﾁｮｲ a52c-hOH0)
垢版 |
2019/01/14(月) 03:25:09.32ID:R4/8yja+0
NHKには高級取りのくせに無能な技術者がいるようでニュース7や9を見ていると
テロッパーとかはちゃんとした機材を適切に使ってて問題ないのが多いんだけど
ロゴとかがインタレ状態のギザギザシマシマになってるのが載ってて失笑してる
0940名無しさん＠編集中 (ﾜｯﾁｮｲW 5577-GBk7)
垢版 |
2019/01/14(月) 18:36:22.32ID:rbqjp7hC0
ところで現状、AV1の一番速いエンコーダーどれよ
0941名無しさん＠編集中 (ﾜｯﾁｮｲWW 7af7-NtvF)
垢版 |
2019/01/14(月) 20:24:41.10ID:MF228XEv0
>>940
libaom(cpu-used8)とrav1e(speed10)で比較してみたけど速度だけならrav1eのほうが1.5倍くらい速かったな
rav1eはまだマルチスレッドにすら対応してないけど
ちなみに画質はx264より悪くなるから実用性は無い
0942名無しさん＠編集中 (ﾜｯﾁｮｲW 5577-GBk7)
垢版 |
2019/01/14(月) 20:38:43.83ID:rbqjp7hC0
>>941
唯一の利点は一般ユーザーには関係ないライセンス料てか?
結局のところハードウェアエンコーダが出ないとキツいのか・・・。
0945名無しさん＠編集中 (ﾜｯﾁｮｲW 4db0-JK55)
垢版 |
2019/01/15(火) 03:42:20.59ID:Ex4KBApU0
JEM (VVCエンコーダー) でもAV1より2-3倍高速にエンコできるらしいし、技術的にHEVCの延長線上なので、2020年に制定されれば数年で普及すると思うけどね。h264 > 265のが革新的な機能追加が多くて対応が大変だったはずだよ
0948名無しさん＠編集中 (ﾜﾝﾐﾝｸﾞｸ MM8a-1+fo)
垢版 |
2019/01/15(火) 09:01:57.59ID:fl6QRCiFM
h265が普及してるとはとても言えない状況でav1/h266なんて回路面積喰いそうなデコーダを2つもミドルやエントリーSOCに載せてくるかな
あとav1の2〜3倍ってx265のveryslowより10倍はエンコード重いだろうし最新コーデックはもう個人のCPUでは扱えない感が強くて悲しい
0951名無しさん＠編集中 (ﾜｯﾁｮｲ a52c-hOH0)
垢版 |
2019/01/15(火) 16:03:02.41ID:0bta4PKJ0
IBMが量子コンピューターの販売始めたし、コンテンツインフラ提供してる巨大企業が
エンコードはがっつりやってくれるようになって、エンコード負荷軽減自体があまり
研究されなくなっていき、デコード効率重視になっていく近未来が見える気もする

5Gやそれを超えるような広帯域通信が普及すると、いま3DCGでレンダリングプールを
インターネット越しに企業が提供してるように、動画エンコードも素材データ送って
でかいサーバーに任せてしまうということが可能になってくるし
(超広帯域通信が普及しても4K8Kなどの高解像度化や高画質化の余地がたくさんあるから
圧縮技術のニーズがなくなる未来はまだ遠いと思う)

そうすると著作権破ってる奴らははねられてしまうから、自分でコンテンツ生み出してない奴らは
絶望することになってこのスレも過疎るんだろうな
0952名無しさん＠編集中 (ｱｳｱｳｸｰ MM45-vWGo)
垢版 |
2019/01/15(火) 17:52:49.80ID:EwLADQYQM
ハードウェア再生支援が対応してもソフトウェア側が充分に活用できていなかったり、ソフトウェアによっては初期設定のままだとハードウェア再生支援自体が無効だったりとか、対応がまちまちすぎて困る

例えば、Windows10標準の「映画と
テレビ」は、ハードウェア再生支援自体は使えるのだが、動きが微妙にではあるがなめらかでなくなる瞬間を見かける

高画質な再生をするのに使われるPotPlayerなんかだと、ハードウェア再生支援を使えばなめらかに再生はされるのだが、デフォルト設定は無効になっていて、しかも設定項目がどこにあるかがわかりにくい
（PotPlayerの場合、音声の設定がデフォルトで正規化処理を有効にしているのも問題ではあるが。
正規化処理を有効にしていると、再生するファイルによっては音声にプツプツというようなノイズが混じることがある。）
0957名無しさん＠編集中 (ﾜｯﾁｮｲW f177-JriC)
垢版 |
2019/01/23(水) 22:39:56.93ID:a3b964BD0
地デジの話が終わったら静まり返るの草
0958名無しさん＠編集中 (ﾜｯﾁｮｲ e1e7-uJAn)
垢版 |
2019/01/24(木) 00:49:00.64ID:jrUkBa/90
x265 3.0 がリリースされ、それに対応した x265guiEx 3.92 もリリースされた。

x265のリリースノートは現時点ではまだ2.9のままなので、3.0の内容については当面は2つ目のリンクから。
　https://x265.readthedocs.io/en/default/releasenotes.html
　https://bitbucket.org/multicoreware/x265/src/a6a12bc3ccf4b3138f1d62b2a81c9c40c3c88d62/doc/reST/releasenotes.rst

詳細は直接見てもらうとして、意識しとくべきなのは以下の３つあたりかな？

　・--preset slowerのパラメータ変更があり、従来のveryslowと同じになった。
　　その上でveryslowにいくつかパラメータ変更が入った。

　・--aq-modeのデフォルト値変更。 「1 : uniform AQ」 → 「2 : auto variance」

　・--tune animationの追加

あとはDolbyVision対応とか、--hevc-aq （これが以前話に出てた新しいAQ？）の試験実装とかかな。
リリースノートに書かれてない新オプションとして、--[no-]-hrd-concat というのもある。
0959名無しさん＠編集中 (ﾜｯﾁｮｲ e1e7-uJAn)
垢版 |
2019/01/24(木) 00:52:45.18ID:jrUkBa/90
メモ：

・slower/veryslowの変更
https://bitbucket.org/multicoreware/x265/commits/537bba0b7fdcbfc56ab4eb5315909c7a5cdb5a23?at=3.0

・aq-modeのデフォルト値変更
https://bitbucket.org/multicoreware/x265/commits/b14834a9d1c1864ea7e94d9cfed4e33f37e767c6?at=3.0

・--tune animation
https://bitbucket.org/multicoreware/x265/commits/1951152ff12db320a4b626e57ee1c870d84d7f14?at=3.0
0965名無しさん＠編集中 (ﾜｯﾁｮｲ 81e7-uJAn)
垢版 |
2019/01/24(木) 23:59:46.96ID:gqyytZo80
HDR対応と言ってもエンコーダーであるx265のやることは、
　・グレーディング済みのHDR映像データを受け取って
　・適切にメタデータを付与してエンコードする
ということだけだと思う。

ざっくりとしか理解してないけど、

　・単純なPQ方式やHLG方式なら --colormatrix や --transfer の指定だけでも済む。
　・HDR10なら、--master-display とか --max-cll とかも使う。
　・HDR10+なら、--dhdr10-info でダイナミックメタデータを渡す。
　・Dolby Visionなら今回追加された --dolby-vision-profile や --dolby-vision-rpu を使う。

といった感じじゃないだろうか。間違ってたらすまん。

ちなみに、rigaya氏のx265バイナリだと、HDR10+用の --dhdr10-info や --dhdr10-opt が使えない模様。
ビルドする際にCmakeで ENABLE_HDR10_PLUS を有効にしていないものと思われる。
（個人でHDR10+やDolbyVisionのエンコをする人がいるのかどうかはわからんけど・・・）
0969名無しさん＠編集中 (ﾜｯﾁｮｲ e1e7-uJAn)
垢版 |
2019/01/26(土) 00:55:16.71ID:YEK3jCy/0
>>967
HDRは多分対応してないとして、
　・10bitのファイル（HEVC/H.264/VP9あたり）が再生できるのか
　・HEVCなら4K対応とあり、それとは別にHEVCなら60fps対応とあるけど4K60fpsも再生できるのか
　　（ちなみにVP9だと30fpsとなっている）
といった点がいまいち曖昧だね。
こういう機器ってそういうことが多いからいまいち手を出す気になれない。
0972家に (ﾜｯﾁｮｲWW 492c-nzMT)
垢版 |
2019/01/26(土) 05:20:46.15ID:pZ8bVepO0
androidSTBの10bit対応ってH.264の10bitのみ対応とか、H.265の10bitのみ対応とかいろいろあるよね。

FireTV4K(旧箱) + KODIでH.265の10bit再生環境用意したけど、FireTVのアップデートのせいでスムーズに再生しなくなったよ。TV3台あるからFireTV4K 3台用意したのに・・・

結局、未だにRPi3 + LibreELEC でH.264・・・
0976名無しさん＠編集中 (ﾜｯﾁｮｲ 412c-ldh1)
垢版 |
2019/01/28(月) 12:55:11.19ID:Au8WsqKn0
無料で使えて当たり前ってスタンスの消費者の方が上から目線過ぎるだろ
仮に対価払っていたとしても消費者と技術提供者は対等な立場であるべき
いまの消費者側が技術提供者に対するリスペクトが無さ過ぎる現状は酷い
0982名無しさん＠編集中 (ﾆｸｸｴW 49b0-vY4p)
垢版 |
2019/01/29(火) 23:05:26.44ID:vXH0HeiX0NIKU
VVCはイントラ内予測も強化されるが、仮にこれを静止画フォーマットに使っても低ビットレートで綺麗になるだけでSSIM 0.95以上を目指す場合はJPEGと大してファイルサイズが変わらないというこれまで通りの流れになりそうな予感がする
0984名無しさん＠編集中 (ﾜｯﾁｮｲW 49b0-vY4p)
垢版 |
2019/01/30(水) 02:04:25.21ID:jhQlqKup0
コーデック自体とは関係ないけど、いつかYCoCgが標準になれば良いのにな
互換のためにYCbCrを続ける事で更なるYCbCrコンテンツを日々生み出し続けて完全に負の連鎖になってる
コーデックの仕様的にサポートはされてるんだから放送業界かあるいはNetflix, YouTube, Hulu級の規模のどこかが使い始めないと永遠に普及しない
0996名無しさん＠編集中 (ﾜｯﾁｮｲ dfe7-S1Ul)
垢版 |
2019/01/31(木) 02:04:22.46ID:EAyJdJqn0
>>984-988
> ビット数増やすのも計算途中だけで良い
> 入力と出力は共に8ビットのままYCoCgとRGBは無損失で相互変換できる

色々調べてみたけど、「nビット深度のRGB」をYCoCgで【無損失】で表現するなら、

　・「YCoCg」の場合
　　　Y/Co/Cgともに(n+2)ビットの深度が必要。
　　　Coだけは(n+1)ビットの深度でもいいけどCoだけ減らすようなことはしない。

　・「YCoCg-R」の場合
　　　Yはnビット、Co/Cgは(n+1)ビットの深度が必要。

という感じで、YCoCgの方が必要なビット数が多くなるのでは？
計算途中だけじゃないと思う。
1000名無しさん＠編集中 (ﾜｯﾁｮｲ dfe7-S1Ul)
垢版 |
2019/01/31(木) 02:34:09.28ID:EAyJdJqn0
今だ！！！1000get
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 195日 5時間 43分 20秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニューススポーツなんでも実況