概要

１日目
http://qiita.com/taktod/items/0d87e511388fde7ffe2d
２日目
http://qiita.com/taktod/items/278255153b6bba68e95f

これらの続き
今日は３日目

今日はttLibGoをつかってちょっとしたサーバープログラム書いてみました。

https://github.com/taktod/websocketPublishTest
できたのがこれです。

流れ

html5のgetUserMediaとMediaRecorderを利用してwebmファイルを作成
そのデータをwebsocketでgoに渡す

で、go側で取得データをデコード & エンコードしてfragmented mp4の形で保存してみる

というコードを書いてみました。

今の所とりあえずファイルに保存してるだけですが、h264 & aacにエンコードしたものをrtmpサーバーにpublishしてもいいし
websocketで他の視聴クライアントになげてMediaSourceExtつかって再生して配信してもいいし
mpegtsに書き出してHLSを組んでもいいと思います。

やってて思ったこと

最近のMediaRecorder(chrome)ってh264吐くんですね

MediaRecorderで特に指定せずに書き出しやってみたところ、h264 & opusのwebmになりました。
そういえば、webRTCもh264対応してましたっけ
なんか地味に時代を感じました。

opusの音声の開始が0からはじまってなかった

はじめつくって録画したデータを聞いてみたところ、なんか音声と映像の同期がずれてました。
調査してみたところpts が0.08あたりから開始してました。
そんなことあるんですね。

h264データのkeyFrame間隔

writerの動作はkeyFrameがきたらデータを書き込むという処理にしてあるのですが
chromeが出力するwebmのh264データをみていたところ、keyFrameの間隔が非常に長そうでした。
なので、初めはencodeかけずに取得フレームをそのまま利用していたのですが、急遽x264でencodeし直す形に・・・

まぁ、x264Encoderの動作テストできてよかったかな。
ただ、手元のテストでは、生成データのサイズが２倍ほどに大きくなってしまったので、もうちょっと変換パラメーター
調整しないとだめだなぁと思いました。

FrameのID

chromeが出力するwebmですがopusがtrack1、h264がtrack2になってました。

writerの処理の初期化の関係でh264をtrack1、aacをtrack2にしているので、そこが妙な気分に・・・
かといって、フレームをいくつか取得してからwriterを初期化するのもなんだかな・・・と思ったので
IDを直書きすることにしました。
もちろんこのコードだと、映像のみや音声のみのデータは扱えません。

つくった感想

まぁ、楽しくかけたかな。
特に大きなトラブルもなくつくれましたし・・・

こういう感じに息抜きにサクッとプログラム書いて
go runで簡単に実行できるのは便利でいいですね。