なんか動画のリエンコードで一日が終わった件

文化の日を忘れていた

今日が旗日だというのに気付いてなかった。気付いていれば月曜日も休みをとって 4 日の旅行に出来たのに、とかちょっと思った。あと日曜日草津温泉田沢温泉の宿が妙に埋まっていたことも合点がいく。月曜に休みを取っていた人がいたのだろう。
なんか悔しい。

さて、今日は一日中ドラレコの画像をリエンコードしてた。
今まで Microsoft 製の Moive Maker っていうのを使ってたんだけど、コイツの画質があまりよろしくない。さらに音質もよろしくない。ということでせっかく Adobe CC に入ってるんだし Premiere 使おうと言うととで Premiere でやってみてるんだけど……なんかそれでもドラレコの紅葉の方がキレイ……。
とくに黄色が色あせるんだよなー。
H264 の 2 Pass の 5Mbps。
あと暗い部分でのブロックノイズがひどい。
それでいてエンコード時間は 3 倍くらい伸びた気がする(汗)。まぁ倍速以上の動画は 60fps で書き出しているので、30fps よりは時間がかかるのは解るが……。それにしてもうーむ……。

で、とりあえず今回は Youtube に上げてみた。いつもは自分のサーバに上げるんだけど、Youtube だとどうなのかなーと。Youtube はアップされるとそれをさらにまたリエンコードするんだよね?
なんかファイル サイズは 128GB まで OK みたいなので、25Mbps で作ったヤツをアップした。
アップが終わった後 360p しか有効にならなくて、なんだーと思っていたら、解像度の低い順番に見られるようになるらしい。ということはソースが一つあってそれを元に各解像度のデータにしているのではなくて、各解像度のデータを使っているってことか。容量食いそうだがその方がサーバには優しいのかな?

紅葉ドライブは Youtube の再生リストにしました。

あと、圏央道の動画も。

もう一つの問題は、Youtube の動画を自分のサイトに貼る場合、インライン フレーム(iFrame)を使って貼るんだけど、これだとうまく % で貼れない。高さの % も必要となる。
うちのサイトみたいに一つのデザインでスマフォも PC も OK ですみたいなサイト(こういうデザインをレスポンシブ デザインという)だと、高さってちゃんとやろうとしたら JavaScript で要素の高さを出してやらないといけない(と思う)。この辺、レスポンシブ デザインをやってるひとはどうやって解決してるんだろう?
気になる。
自分のサイトにデータを置く場合は、Video タグで横幅とあと縦横比は固定ってのを指定しておけば縦は特に指定しなくても良い。こうすることによってウィンドウ サイズが異なる場合でもちゃんと動画の全体が表示される。Youtube の場合、横幅が 560 ドットとドット数で指定してしまっているため、iPhone とかスマフォで見ると動画が欠けてしまうのだ。

レスポンシブ デザインのめんどくささ

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり PC でアクセスしてもスマフォでアクセスしても、同じデザインで出力される……というわけではなくて、一つのデザインしか定義してないんだけどそれで PC でもスマフォでもちゃんと表示されることである。

今やっているスマフォのゲームも最初、レスポンシブ デザインで作っていた。
このレスポンシブ デザインの肝は簡単に言ってしまえば%で作ると言うことである(ぁ
どういうことかというと、例えば 2 段組をするとき、全体幅が 1024 ドット、左側がメイン コンテンツで 640 ドット、右側がメニューとかで 384 ドットにしよう……ってのが今までの作り方。
レスポンシブ ウェブの場合は、全体幅は 100% で作り、本文左側は 62.5%、メニューとかの右側は 37.5% にしようってこと。そうすればどんな機器だろうが割合で区切られるので、それらの機器に従った大きさになる。
これはレイアウトだけでなく、画像の大きさに至るまで何もかも%で指定する。

ところが、この作り方には二つの欠点がある。

  • 文字の大きさは変わらない
  • ドット単位の微調整は不可能

ブロック要素や画像などは画面の大きさに従って勝手に変わってくれるのだが、文字の大きさはそれに追随してくれない。なので細かいディスプレイに出しても、荒いディスプレイに出しても同じ大きさ(ドット)で表示されてしまうため、要素の中に表示される文字数が変わってしまい、結局レイアウトが乱れる。
これはディスプレイの画素数と CSS ピクセル比ごとに文字の大きさを定義しておく必要がある。
さらにゲームではインターフェースに凝るため、ドット単位でのボタンやゲージ(メーターやプログレス バー)などの表示が必要となる。ブラウザは小数点第三位くらいまでの%値しか見てくれず、ドット単位での微調整はできない。これの回避方法は、ドット単位で組んだあと、Javascript や CSS の ZOOM を使って最適な大きさに表示するのだが、iOS の Safari などでバグが発生し使えないことが多い。これに関しては、まだボクの中では特に解決策は見いだせていない。
今回はドット単位で調整が必要なところは、合成した画像を変化する種類分作って対応するというわりと原始的な方法で回避した(^^; どういうことかというと、下地があってその上にボタンをドット単位で並べなければいけないような場合、下地とドット単位で並べたボタンを合成してしまい、どのボタンが光っているかというパターン分の画像を用意することによって、ドット単位での調整をしなくて良いようにした。ただこの方法は、パターンが膨大にある場合は使えない……。

まぁ、一番いいのは Javascript の ZOOM である。コイツさえ正常に動いてくれれば、レスポンシブ デザインは一気に楽になる。何故かというと、ドット単位で自由に作れるからだ。従来の作り方のように、例えば全体幅を 1024 ドットとか 640 ドットとかと固定して自由にレイアウトした後に、Javascript で機器のディスプレイの大きさに合わせて拡縮するようにすれば楽ちんなのである(爆。

他にも Table を使うのが難しかったり、横幅を必要とするモノがどうしてもスマフォなどだレイアウトが崩れてしまったりなど、一つのデザインで様々な機器に対応するのは一筋縄では行かない。TAMA Networks も燃費なんかの表の部分や、説明付きの画像の場合はスマフォで見ると崩れてしまう。
この辺、何とかしたいなぁと思いつつ……。
写真はこの日食べたもの。バーガーキングのブルーベリーのハンバーガーと、秋葉原の万豚記。

1412080730 1412080731 1412080737 1412080740 1412080741 1412080747