アカウント名:
パスワード:
GPGPUでJPEGなエンコーダを作る時等で、誰でも行っていた手なので、何を今更感。
エンコーダではなくデコーダを高速化できるという技術ですね
圧縮はそもそも今までも並列処理できる展開は符号長が可変なので頭から順に展開していかないとどこからどこまで符号かわからない＝並列処理に向かないそれなら事前にそれぞれの符号の目印を埋め込めば良いのでは？
という理屈自体は割と単純なように思います動画圧縮でいえばずっとBフレームしか存在しなかったものにGOPという概念を追加するような
圧縮の方はおまけみたいなもので、展開を高速化できたというのが核心じゃないのしかもGPUを使用する既知の最速デコーダと比較して
誰でもやってるなら、おれおれライブラリなりRedditなりで公開してる人もいるよね？例えばどれ？
おまえは本当に「Hello, world!」がほしいのか？
うん欲しい。誰でもやってるハロワレベルの話なら腐るほど記事もあるよね、きっと。それならちょっと検索すりゃ一瞬で出せるっしょ？何で勿体ぶってるの？
動画エンコーダの老舗、FFmpegのソースをgitから持ってくればよかろ？っ https://github.com/FFmpeg/FFmpeg [github.com]
これデコーダの話なんですけど？(爆笑)
「誰でも行っていた手」なのはエンコーダの話ですよ。文字は読めても意味は読めないんですね。
> 「誰でも行っていた手」なのはエンコーダの話ですよ。はい、その通りだと思います。つまり、この論文はデコーダの話だと理解できずエンコーダの話ししちゃうくらい理解が及んでないと言うことです。(爆笑)一行コメントくらいはなんとか読めても前後を含めるとなると読めないんですね。
> 「誰でも行っていた手」なのはエンコーダの話ですよ。それなら、エンコードする時にエンコードにはクソの役にも立たないギャップ配列みたいなのを一緒に作るのを、誰でも行っていた手だと思うくらい君は技術音痴と言うことになりますね。
aviファイルにはインデックス領域が普通に存在しててだな。この手法のはインデックス領域の下n桁だけを保存しますみたいな物。
このツリーの親コメントの意図がどうであったかは知らないが、「頭から読んでいく場合にはクソの役にも立たないインデックス領域」なんてのを圧縮時についでに作るのを、多くのエンコーダがやっていた筈。
# MPEGのは知らんけど、フレームヘッダがあるから適当にシークしてからヘッダ見つける方法？
aviファイルにはインデックス領域が普通に存在しててだな。
そのインデックスはフレームとか上位のものを指してると思うんだけどそれはギャップ配列の目的とはまったく別なので
技術音痴と言うことになりますね。
っていわれても仕方がないんじゃないかなー。そもそもコンテナの avi を持ち出しても意味がないのでは。
親コメントのJPEGのは知らんけど、この話のは要するにはシーク用のインデックス(ヒント)ですよ。それを「あとから長さ不定の断片群を結合するので展開後の位置は不明で良い」とすることで「処理分割の境界から符号境界までのオフセット情報さえあれば良い」ということにして「分割数が膨大ながらもコンパクトに表現することができました」というもの。
多分一番大事なのは最後のヒント情報のコンパクトさだと思うんだけど、発表のインパクト重視で「分割可能なようにオーバーヘッド無視でヒント乗せれば爆速」みたいな発表してあまつさえ「普通のzipとかにも応用したい」なんて言っちゃうもんだから「分割可能なようにヒント盛れば早くなるのは当たり前だ何言ってんの」と突っ込まれる。
新規なのはデータ構造なわけだけど、このデータ構造を採用したものが既にあると言う話？
色々技術的な指摘をされようとしていますが、素直に元論文を読まれた方がよいかと実行可能なコードまでは記載されていませんが、数式を使って理論的な説明がなされていますファイル種類毎のサイズ、圧縮率、処理時間、CPU 版との比など、突っ込もうとされていることに対しては概ね答えがありますよ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
ふつーに (スコア:2)
GPGPUでJPEGなエンコーダを作る時等で、誰でも行っていた手なので、何を今更感。
Re:ふつーに (スコア:4, 参考になる)
エンコーダではなくデコーダを高速化できるという技術ですね
圧縮はそもそも今までも並列処理できる
展開は符号長が可変なので頭から順に展開していかないとどこからどこまで符号かわからない＝並列処理に向かない
それなら事前にそれぞれの符号の目印を埋め込めば良いのでは？
という理屈自体は割と単純なように思います
動画圧縮でいえばずっとBフレームしか存在しなかったものにGOPという概念を追加するような
Re: (スコア:0)
圧縮の方はおまけみたいなもので、展開を高速化できたというのが核心じゃないの
しかもGPUを使用する既知の最速デコーダと比較して
Re: (スコア:0)
誰でもやってるなら、おれおれライブラリなりRedditなりで公開してる人もいるよね？
例えばどれ？
Re: (スコア:0)
おまえは本当に「Hello, world!」がほしいのか？
Re: (スコア:0)
うん欲しい。
誰でもやってるハロワレベルの話なら腐るほど記事もあるよね、きっと。
それならちょっと検索すりゃ一瞬で出せるっしょ？
何で勿体ぶってるの？
Re: (スコア:0)
動画エンコーダの老舗、FFmpegのソースをgitから持ってくればよかろ？
っ https://github.com/FFmpeg/FFmpeg [github.com]
Re: (スコア:0)
これデコーダの話なんですけど？(爆笑)
Re: (スコア:0)
「誰でも行っていた手」なのはエンコーダの話ですよ。
文字は読めても意味は読めないんですね。
Re: (スコア:0)
> 「誰でも行っていた手」なのはエンコーダの話ですよ。
はい、その通りだと思います。
つまり、この論文はデコーダの話だと理解できずエンコーダの話ししちゃうくらい理解が及んでないと言うことです。(爆笑)
一行コメントくらいはなんとか読めても前後を含めるとなると読めないんですね。
Re: (スコア:0)
> 「誰でも行っていた手」なのはエンコーダの話ですよ。
それなら、エンコードする時にエンコードにはクソの役にも立たないギャップ配列みたいなのを一緒に作るのを、誰でも行っていた手だと思うくらい君は技術音痴と言うことになりますね。
Re: (スコア:0)
aviファイルにはインデックス領域が普通に存在しててだな。
この手法のはインデックス領域の下n桁だけを保存しますみたいな物。
このツリーの親コメントの意図がどうであったかは知らないが、
「頭から読んでいく場合にはクソの役にも立たないインデックス領域」
なんてのを圧縮時についでに作るのを、多くのエンコーダがやっていた筈。
# MPEGのは知らんけど、フレームヘッダがあるから適当にシークしてからヘッダ見つける方法？
Re: (スコア:0)
aviファイルにはインデックス領域が普通に存在しててだな。
そのインデックスはフレームとか上位のものを指してると思うんだけど
それはギャップ配列の目的とはまったく別なので
技術音痴と言うことになりますね。
っていわれても仕方がないんじゃないかなー。
そもそもコンテナの avi を持ち出しても意味がないのでは。
Re: (スコア:0)
親コメントのJPEGのは知らんけど、この話のは要するにはシーク用のインデックス(ヒント)ですよ。
それを「あとから長さ不定の断片群を結合するので展開後の位置は不明で良い」
とすることで「処理分割の境界から符号境界までのオフセット情報さえあれば良い」
ということにして「分割数が膨大ながらもコンパクトに表現することができました」というもの。
多分一番大事なのは最後のヒント情報のコンパクトさだと思うんだけど、
発表のインパクト重視で「分割可能なようにオーバーヘッド無視でヒント乗せれば爆速」
みたいな発表してあまつさえ「普通のzipとかにも応用したい」なんて言っちゃうもんだから
「分割可能なようにヒント盛れば早くなるのは当たり前だ何言ってんの」と突っ込まれる。
Re: (スコア:0)
新規なのはデータ構造なわけだけど、このデータ構造を採用したものが既にあると言う話？
Re: (スコア:0)
色々技術的な指摘をされようとしていますが、素直に元論文を読まれた方がよいかと
実行可能なコードまでは記載されていませんが、数式を使って理論的な説明がなされています
ファイル種類毎のサイズ、圧縮率、処理時間、CPU 版との比など、突っ込もうとされていることに対しては概ね答えがありますよ