YouTubeをデータストレージとして活用するハック 66
ストーリー by nagazou
こればっかりになったら困るわ 部門より
こればっかりになったら困るわ 部門より
多くのクラウドストレージサービスは、一定容量を超えて使うと有料になってしまうことが多いが、その対策としてYouTubeをデータストレージとして活用する方法が考案されたらしい。YouTubeには、1本の動画は｢256GBまたは12時間のいずれか小さい方｣という制約がある。しかし、本数に関しては無制限となっていることから、これに目を付けて容量無制限のストレージとして活用しているようだ（Hackaday、データを動画にしてアップロードしたもの[動画]、GIZMODO）。
元データの変換にはDvorakDwarf氏が開発した「ISG（Infinite-Storage-Glitch）」を用いているという。このツールは、バイナリファイルをビデオファイルにエンコードする役割を持つ。YouTubeの圧縮アルゴリズムの影響を回避するための対策もされているという。サンプル動画の見た目は昔ながらの砂嵐だが、きちんとデータが仕込まれているとのこと。動画は元のファイルの約4倍のサイズになるという。こうした行為がYouTube側の規約に反しているかは不明であるようだ。
元データの変換にはDvorakDwarf氏が開発した「ISG（Infinite-Storage-Glitch）」を用いているという。このツールは、バイナリファイルをビデオファイルにエンコードする役割を持つ。YouTubeの圧縮アルゴリズムの影響を回避するための対策もされているという。サンプル動画の見た目は昔ながらの砂嵐だが、きちんとデータが仕込まれているとのこと。動画は元のファイルの約4倍のサイズになるという。こうした行為がYouTube側の規約に反しているかは不明であるようだ。
仕組みは単純 (スコア:3)
やってることは超単純です．
- データを画像のピクセルに変換（白黒モードとRGBモードがあって，白黒モードは1byteを1画素（ピクセル）に，RGBモードは3bytesを1画素に変換します）
- youtubeの不可逆圧縮対策．画像サイズを縦横2倍．データサイズが4倍になりますが，縦横2倍にするだけで回避できるそうです．
この2つだけ．
この程度ならわざわざプログラム書かなくても，ffmpeg あたりを使えばワンライナーで実現できそうです．
つまりファイルを動画にするエンコードするときは
$ cat 元ファイル | ffmpeg -f rawvideo -pix_fmt rgb -video_size 640x480 -r 30 -i /dev/stdin -vf scale=1280:-1 hogehoge.mp4
動画を元ファイルに戻すデコードは
$ ffmpeg -i hogehoge.mp4 -s 320x240 -f image2 frame%08d.rgb && cat frame*.rgb > ファイル名
こんな感じです．動作確認してませんが，これをベースにオプションを微調整すれば，結構すぐに再現できるとおもいます．
Re: (スコア:0)
単純に元データのバイト列をそのまま動画にしたらブロックノイズとかによるデータ化けで実用にならないと思うのだけど
各ピクセル（サブピクセル）16階調ぐらいにする必要があるような
Re:仕組みは単純 (スコア:1)
ソースのGitHubを見に行くと白黒(バイナリ)モードは1ピクセルが0か1を表すと書いてあった。つまり1ピクセル1バイトではなく1ビットだ。そりゃそうだろうな。実際貼られているサンプル動画もどう見ても256階調じゃないし。元コメのannoymouse cowardがアホなだけ。RGBモードは不可逆圧縮対策を行わないモードなので1ピクセル3バイトで正しい。
Re: (スコア:0)
別コメもつっこんでるけど、動画エンコードは基本的に不可逆圧縮だということを忘れてませんか？
Re: (スコア:0)
ここで行われているのは、データの圧縮ではなく膨化。
動画エンコードを介しても可逆なまでに、膨化させているだけ。
Re: (スコア:0)
＞不可逆圧縮対策（略）縦横2倍にするだけで回避できるそうです
へぇー
意外と行けるもんなんですね
Re: (スコア:0)
普通やるとしたらYUV420モードじゃないのか
そしたら1pixelあたり1.5bit
RGBで縦横2倍にすればいいというのもクロマが縦横1/2に間引きされるからじゃないの
Re: (スコア:0)
QRコードのコマ送り動画?
Re: (スコア:0)
単純な1ピクセル1バイトエンコードで背景から切り出すためのマーカーもエラー訂正もないのでQRコードよりずっと単純
GMailFS (スコア:1)
fuseを使ったGMailFSや、Windowsで一世を風靡したGMail Drive shell extensionを思い出した。
https://github.com/hansendc/gmailfs [github.com]
https://www.viksoe.dk/code/gmail.htm [viksoe.dk]
時代は巡る。
PAPERBACK (Re:GMailFS) (スコア:2)
2012年にあった「PaperBack [ollydbg.de]」というソフトを思い出しました。GIGAZINEの紹介記事 [gigazine.net]も参照。
A4用紙1枚に1MBぐらいを記録でき、AES暗号化もできるという代物。
なお、作者は「Olly, the author of OllyDbg, presents his new open source joke:」と言っており、試しに使って大笑いはできても、実利用には（面倒くさくて）使いませんでした。
Re:GMailFS (スコア:1)
ish思い出した年寄り
#音声データに載せたら流石に今時の圧縮では復元難しいのかな
規約違反かどうか？ (スコア:1)
現状の規約に違反してるかどうかは大した問題ではない。
Googleの不利益につながるなら、規約変更して削除するだけでしょ。
Re: (スコア:0)
これだよね。
かつての容量無制限ストレージサービスがどんどん失われていったように。
Re: (スコア:0)
ダウンロードデータにも広告を挿入しておくというのはどうだろう
Re: (スコア:0)
こういう一般的なこと分からないひとが多い世の中だから。
＃映画や漫画の配信にこういうの使ったらチャンネル登録爆増、再生時間大幅アップなんてことになる
Re: (スコア:0)
無限に見えたGoogleのリソースも動画の爆発に耐えられず各サービスの有料化に走っているが、それがどんどん加速していく。結果不利益をこうむるのは我々だ。今どこのクラウド業者もそんな感じ。規約がどうこうの問題ではない。負担すべきものを負担しようとしない迷惑な輩だ。
Re: (スコア:0)
誰も見ないゲーム実況とかを毎日何時間も上げてるような連中が溢れているYouTubeからしたら誤差みたいなもんだろ
W@r3zでみた (スコア:1, 荒らし)
うめ～このみかんとかでんことかポートモレスビーとか。
んでいざ引っ張り出そうとしても地球病になって落とせないんですね。
Re: (スコア:0)
あの手のって真面目に画像データに埋め込むんじゃなくて、画像データは一切弄らず画像フォーマットのすき間に入れ込んでる奴のが多かったような
GitHub (スコア:1)
とかどうなんだろう？
gayazone
PCMプロセッサーを (スコア:1)
思い出したぞ。
https://ja.wikipedia.org/wiki/PCM%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%... [wikipedia.org]
Re:PCMプロセッサーを (スコア:3)
さすが高齢化スラド、レトロなネタ「PCMプロセッサー」が出るのがシブイ。
デジタルデータを動画信号にすると言ったらPCMですよね。
「1977年9月 - ソニー、世界初のPCMプロセッサー「PCM-1」発売（定価 480,000円）」
見たよ聴いたよこの「PCM-1」。デジタル録音再生をする未来が身近に来るぞと
ワクワクしていた1977年。当時エンコードとかデコードとか技術書を読みましたなあ。
Re:PCMプロセッサーを (スコア:1)
wikipediaに説明があるように元をたどればNHK技研、DENONの業務用機
当時のデジタル録音機はたかだか12bit程度で、デジタルは音が悪いという現在の迷信はここから生まれた
ダイナミックレンジの狭さはどうしようもないので、DENONからリリースされたデジタル録音のレコードはピアノ曲、室内楽が中心だった
CDになってからも再生側のD/Aコンバータに問題があって、これもデジタルは音が悪いという現在の迷信の起源になっている
（この問題を救ったのがΔΣ型のコンバータ）
Re:PCMプロセッサーを (スコア:1)
媒体がVHSテープなだけのカートリッジテープ装置 [ipsj.or.jp]ではなく、
NTSCを使ってデジタルデータを保存する機械が有ったんですね、知らなかった。
Re:PCMプロセッサーを (スコア:2)
僕はそちらの「富士通 FACOM 6475 カートリッジテープ装置 」の方を今まで知りませんでした。
ためになります。
Re:PCMプロセッサーを (スコア:1)
当時はADCやDACが高価だったので、左右チャンネルでマルチプレクスして使ってたそうです。
# なので左右のサンプル点がサンプリング周期の半分だけズレる(同じだけズラして再生する分には問題なし)。
# 今時の機材で再生させようとするとデジタル的にサンプル点を一致させる処理が必要にｗ
# サンプリング周波数の44.056kHz(=44.1/1.001kHz)と並んでデジタルオーディオの黒歴史ｗｗ
Re:PCMプロセッサーを (スコア:2)
44.056は論外にしても、CDが44.1kHzなんて半端なサンプリング周波数になったのも、こいつが元凶。
PCMプロセッサの対応した映像信号とサンプリング周波数は、
・44.1kHz
PAL: 垂直25Hz、帰線期間を除いて走査線625本中588本に記録、一本あたり3サンプル
(NTSCのベースになった白黒映像信号規格: 垂直30Hz、走査線525本中490本に記録)
・44.056kHz
NTSC: 垂直29.97Hz(正確には30×1000/1001)、走査線525本中490本に記録
と、日米欧で同じサンプリング周波数にするために、25×588×3=30×490×3という公倍数を取る感じで44.1kHzに規格化したけど、NTSCがカラー化で1000/1001倍という半端な周波数変更してる影響でサンプリング周波数が微妙に異なる二種類のモードができることになった。
で、CDの規格制定時に、ソニーは44.056kHzを推したけど、フィリップスが勝って PALベースの44.1kHzに。
PCMプロセッサなんてものがなければ、44.1なんて半端な数字じゃなく、もっとキリが良い数字になったと信じたい。
ホワイトノイズ (スコア:0)
映像を見ていたら、ホワイトノイズが聞こえた気がした。
Re:ホワイトノイズ (スコア:2)
音も併用したらちょっとは足しになりそう
PCMで可聴音域にデジタルデータを入れる技術は枯れまくってるぐらいにあるし
Re: (スコア:0)
Re: (スコア:0)
画面はダンプリストをゆっくり流せばいいかと。
そういう動画って既に投稿されてそう (スコア:0)
記事みたいな大容量データでなくとも、特定のチャンネルにメッセージが埋め込まれた動画Aが投稿されたら攻撃を開始し、動画Bが投稿されたら活動休止するマルウェアとかありそうな気がする。
それなら自前で指令サーバー用意しなくても良いですし、追跡しにくそう。
Re: (スコア:0)
C&Cサーバを立てる手間を省く手段としてIRCを使うボットネットなんかは昔からある。
YouTubeを使うと無数のHTTPS通信に紛れ込ませられるのが利点かな。
攻殻機動隊 (スコア:0)
YouTubeを見てウィルスに侵される事件が頻出するのか
Re: (スコア:0)
主電源を斧で切れば大丈夫。
Re: (スコア:0)
おじさんツール名思い出せないんだけど (スコア:0)
昔々、画像偽装ファイルとかなかったっけ？
Re: (スコア:0)
「ステガノグラファー」ですかね？
単なる迷惑行為 (スコア:0)
回転寿司で馬鹿なことをしてる連中と根本的に同じ人種
Re: (スコア:0)
スラドも変わりましたね
技術的な記事を見る視点がそもそも違う人達が増えました
Re: (スコア:0)
別目的のサービスのタダ乗りを「活用」とかよくもまあって言えたもんだって感じ
せめて「ISG」だけに着目する記事ならアレゲと言えたかもしれないが
Re: (スコア:0)
意識高い風にいうほど技術的に高度な事をやっているわけでも、アイデアが秀逸というわけでもないよね。
こういう事をして悦にいる人が一定数でると、規約にヘンな縛りが増えて他のユーザにとばっちりが回ってくる可能性があるから嫌がられているのだと思うよ。
まあ回転寿司のバカッターと同罪とまではいわないけど、そんなにレベルが違う話でもないと思うよ。
# 4418756の人ではないです。
Re: (スコア:0)
そりゃ出来るだろうけど迷惑なだけだから手間かけてまでやらない、って話ですよね
拡散した時点で対応されて終わりですし、炎上売名目的の質の悪い人種
ここからグーグルとの技術勝負になれば面白いかもしれませんが、こういう手合いは金にならない事はしないでしょうね
一番怒ってるのはひっそりと活用してた層…
Re: (スコア:0)
アレゲかどうかといえばアレゲなんじゃない？
むしろこれをストレージとして活用される事を危惧してるんなら
そっちの方がどうかしてるかと。
効率に全振りして最大25%なんでしょ。
ためしに使ってみようという気も起きない。
Re: (スコア:0)
Youtubeペロペロ。
醤油差しと違って、Youtubeはペロペロするのに少しだけ知識が必要というだけ。
常識人はやれてもやらないだけで、こんなのは技術というほどのものでもない。
4倍ならかなり効率的 (スコア:0)
Webのコピペをテロップにして流してるだけとか、合成音声で読ませてるだけとか、
ああいうの滅茶苦茶データ量浪費してるじゃん？
実用性としては… (スコア:0)
一ファイルあたり実質64GBまでなのはまあ十分としても、
エンコードする時間、アップロードにかかる時間、突然動画を削除されるリスク、
アカウントごと停止されるリスク、突然の規約変更による劣化による復号情報喪失のリスクなんかを考えると
いまいち割には合わない気がする
テープドライブ (スコア:0)
DATに記録せずにYoutubeに画像としてバックアップする機器を発売すると良い。
Re:本数無制限 (スコア:2)