Q&A
「負荷」という言葉をネットワーク負荷、ユーザーの待ち時間、運営費、どの意味での負荷かをはっきりさせると有意義な回答が得られそうに思います。
例えば、動画ファイル等重めのファイルでも
クライアント側で動画生成⇒blob形式のデータをダウンロードということであれば、
サーバーからダウンロードしているということではないので
負荷はサーバーから直接ダウンロードする場合と比べてかからないでしょうか？
サーバー（レンタルを想定しています）には転送量制限があるので
なるべく負荷をかけないようにしたいと思い投稿させていただきました。
回答3件
0
ごきげんよう
クライアント側で動画生成⇒blob形式のデータをダウンロード
確かに一度HTML、JS、CSS、画像データはダウンロードしてしまえば、それ以上の通信は発生しないわね。
動画のバイナリデータはたった数秒でも凄まじいサイズになる。
midiのような仕組みを構築したいという要望よね？
まぁ扱うモノにもよるわね。
例えばゲームのプレイングムービーのようなものをコマ枚に画像データにして、パラパラ漫画のように差し込んでいく作り方をするなら完全に無駄よ。
動画のエンコーダーも賢いから時系列で色が変わってない箇所は色の情報を削ったりして軽量化してるから逆に重くなる。
でも逆に、写真や図形を切り貼りして音楽を付けたようなものなら確実に軽くなるでしょうね。
わざわざ質問する位だから後者の使い方なのよね？そちらの想定で話を進めましょう。
次、作ったBlob形式の動画データ。
FileAPIを使ってフォルダを指定してあげてそこに改めて書き込むか、BlobをURLに変換させてDLさせるという違いこそあるけれど、どちらもメモリ空間上のデータをそのまま保存するから転送量は一切かからない。
これも質問文の通りね。
だから転送量対策としては一考の余地があるわね。
でも、どうやって動画を生成するの？
フロントエンドエンジニアのほぼ全員が即答で無理と答えるくらい難易度が高いわよ。
（調査したら多分いけるという事は分かったけど、根本的な解決になってないからオススメはしない）
HTML5で実装されたのは主に「動画を再生」する機能、動画を生成する機能はとてもしょぼいのよ。
バイナリデータを触れるってだけで、JavaScriptはそもそもバイナリデータを触る為の言語じゃないし。
私も「HTML5 Web標準API バイブル」という書籍を眺めたけれど、MediaRecorderという機能くらいしか見つからなかったわ。
new MediaRecorder(stream)で作成する時にChromeの画面を60fpsでパシャパシャ記録するstreamを自作すればいけるんじゃないかしら？
まぁ、このstreamの作り方は私も皆目見当がつかないし、多分答えられる人は居ないんじゃないかしら。
もしくはAviUtlみたいなC言語で書かれている動画作成ソフトをゴリ押しで移植して使う方法ね。
こっちも質問しても答えは帰って来ないわよ。
参考までに私の話をすると、MP3の音楽ファイルをJavaScriptでVorbis OGGにエンコードしなおしてダウンロードさせるという似たような事を夏休みにやったのだけど、調査から実装までで夏休みが全て潰れたわよ。
Emscriptenというソフトを使えば移植は可能だけど、C言語がある程度触れないとスタートラインに立てないわ。
動画を扱うなら専用のパーサはC言語で付け足す必要があるし、私は二度とやりたくないわね……
【追記】
もしかしたらあるかも…と思って探したら案の定見つかったわ。
videoconverter.js
FFmpeg library into JavaScript, using Emscripten.
コマンドライン操作でAviファイルを生成するFFmpegというソフトがあって、それをEmscriptenでJSにコンパイルしなおしたもののようね。
でも、出来ると言ってもEmscriptenで生成したJSファイルは死ぬほど扱いが難しいし、
動画データをエンコードするのは凄まじい負荷が掛かるから、普通にDLするより絶対時間かかるし、スマホで見ようとすると燃えるように発熱するでしょうね。
GUI操作のパソコンの動画メーカーみたいなソフトをWeb上で自作するつもりでなければオススメしないわ。
よしんば動画データにできても、今度はその動画データを再生するところまでがゴールでしょ？
ブラウザの種別によってコンパイルする動画データを切り替えるような処理も必要になりそうね。
私だったら何百万積まれても絶対やらないわ。
サーバー（レンタルを想定しています）には転送量制限
どうせ貴方が作った無名のサイトなんて誰も利用しないわよ。
転送量の心配はもっと有名になってから心配することね。
案じるより産むが易し
逆に怒られる程に成長したサイトなら、お客さんも居るだろうし対策する価値があるってわけね。
だから転送量超過で怒られてから考えた方が良いと思うわ。
アドバイスするなら、そのサイトがヒットした時に備えて独自ドメインだけは取っておきなさい。
そうすれば、いざ転送量過多でレンタルサーバから追い出されても、もっと強力なサーバに移行出来るわよ。
おまけ: CSSアニメーションに関して
もしかしてBlob云々は興味本位であって、
ムービー的なものなら何でも良かったのかしら？
参考サイト: drop out
このサイト、実は全部CSSアニメーションよ。
だから手間暇は掛かってるしレンダリングがそこそこ重いけど、ファイルサイズ自体はとても軽い。
このサイトは大量のPNG画像を使ってるから8MBの超力作になってるけど、2MBはアニメーションとは関係ない画像だし、PNGを極力さけてSVG中心にしていけばもう2MB程は削れるかもしれないわね。
このクオリティでmpegにしたら多分20〜30MBくらいになるんじゃないかしら？
動画はあまり詳しくないからヤマカンだけど、線をきっちり出そうとすると1000Kbpsくらいにはなるわよね？
質問の根底がmpegの動画ファイルではなく、可愛いアニメーションで魅せたいという要望なら、実現出来ると思うからCSSアニメーションについて調べてみてね。
投稿2018/05/02 08:25
編集2018/05/02 14:40
総合スコア21400
> JavaScript上で扱うデータはAjax通信等で取得してこない限り全てクライアント側にあるの。
jsファイルはサーバからダウンロードされるのではないかしら。
動画の元となる素材データはどこにあるのかしら。
実体がデータでもファイルでも所在がサーバである限りは、ダウンロードされることに変わりはないのだわ。
ごきげんよう
確かに「扱うデータ」を指す意味合いが曖昧だった、お詫びするわ。
文章の見直しと、回避策を充実、本当に軽くなるのか？の3点に関しては本文の中に追記という形で書き表したわ。
> midiのような仕組みを構築したいという要望よね？
良い例えね。
表現力を落としても構わないのなら、素材データ(MIDI音源に変わるもの)を用意するのは賢い事だわ。
ただし、初回ダウンロード時(素材データのダウンロード時)に転送量は増えてしまうから、素材データの置き場所は分散させるべきではないかしら。
ダミ声で脳内再生されるのですがそれは
初心者目線に立った分かりやすいご回答感謝いたします。
0
ベストアンサー
こんばんは。
私もちょっと調べてみたの。といっても、こんなページを見つけたぐらいなんだけど。
Capture a MediaStream From a Canvas, Video or Audio Element | Web | Google Developers
これはcanvasを使ってvideoのストリームを作る方法ね。
Record Audio and Video with MediaRecorder | Web | Google Developers
そして、こちらがストリームを録画する方法よ。
どちらも説明とサンプルがあるから参考になると思うわ。JSを使ってcanvasでアニメーションを実演する方法なんてのはわかると思っているから省略するけど、それをcaptureStreamでストリームにできるってことが重要なの。あとはそのストリームをMediaRecorderで録画がすれば良いってだけ。とっても簡単だね。動画データはすべてブラウザ上で作成されるから、データ転送も抑えられると思うわ。実際に、二番目の録画のサンプルは、動画自体は一切転送していないしね。ただ、動画の素材になる画像データや音声データ、それを動かすためのJS類は転送する必要があるわ。目安としては、一昔前の紙芝居Flashぐらいのサイズになるかしら。といっても、私も当時のことはよく知らないんだけどね。
でも、ちょっと注意して欲しいんだけど、ChromeとFirefoxの最新版じゃなきゃダメなの。あとは、ビデオのフォーマットも限られてくるってことかな。
うーん、GWで大学も休みだし、ちょっとサンプル作りににでもチャレンジしてみようかしら。
投稿2018/05/02 14:40
総合スコア21751
ご回答ありがとうございます。
１つの方法としてcanvasでのストリームを録画する方向で考えていました。
確かに素材を使う場合はある程度は負荷が発生すると思いますが、
例えば、webcamをストリームへ変換し録画する程度であれば
js読込以外転送が発生しないと理解しました。
ありがとうございます。
0
動画形式に関して詳しいわけではありませんが、質問の前提で誤解があるように思えましたので、考え方だけ書いておきます。
Blob形式
一般的には、次のファイルがサーバからダウンロードされます。
- foo.js (JavaScriptファイル)
- index.html (HTMLファイル)
- index.css (CSSファイル)
- bar.mp4 (動画ファイル)
「ここで bar.mp4 を無くし、JavaScriptで動画生成する事でダウンロードが必要なくなるのでは」と考えたようですが、動画生成の為の入力データはサーバからダウンロードしなければなりません。
JavaScript
1createMovie(inputData); // 引数 inputData の元となるファイルをサーバからダウンロードしなければならない
bar.mp4 をblob形式に変換し、foo.js に記述したとするなら、foo.js に bar.mp4 の容量が加算されて、サーバからダウンロードされるという事です。
jsファイルではなく、htmlファイルに埋め込んでも同じで、htmlファイルの容量が肥大化するだけです。
従って、動画ファイルをblob形式に変換してどこかに埋め込むだけで解決する問題ではありません。
動画ファイルの容量削減
(A) 動画ファイルの品質を下げる
動画の解像度、フレームレート等を下げる事で容量を小さくします。
(B) 動画ファイルのエンコード形式を変更する
動画のエンコード形式を変更する事で最も容量が小さくなるエンコード形式を探します。
(C) 同じデータを何度もダウンロードさせない
miyabi-sun さんのMIDI形式と基本的な考え方は同じです。
動画ファイルを「複数の部品で構成されるもの」と前提し、部品データを予めダウンロードしておきます。
動画A、動画Bはそれぞれ部品を指定するだけのファイルなので、容量は節約できるわけです。
MIDI音源に変わるものが必要で、それは自分で定義して作り出す必要があります。
(D) ベクター形式でデータ化する
Canvasはビットマップ形式、SVGはベクター形式と呼ばれます。
それぞれ向き不向きはありますが、いわゆる図面データはベクター形式が向いており、ファイルサイズを削減できる可能性があります。
(E) 圧縮率を上げる
今まで提案してきた内容は大きな視点でみれば、圧縮アルゴリズムを考えているのに等しいと思います。
例えば、(C) は辞書式に近いといえるのではないでしょうか。
(通常と違うのは、(C) が複数のファイルを介して辞書式で圧縮しようとしている事です)
他にも「圧縮アリゴリズム」でWeb検索すればいろいろ出てくると思いますので、探ってみると面白いかもしれません。
Re: deep さん
投稿2018/05/03 02:27
総合スコア18194
あなたの回答
tips
プレビュー
