概要
１日目
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で簡単に実行できるのは便利でいいですね。