Elastic TranscoderとMedia Convertで作った動画エンコードサーバを、ffmpegのサーバにどうして置き換えたのか
Elastic TranscoderとMedia Convertで作った動画エンコードサーバを、ffmpegのサーバにどうして置き換えたのか:
この記事はAWS Advent Calendar 2018の18日目の記事です。
Weddy Weddyというアプリを弊社で開発していまして、Elastic TranscoderとMedia Convertを使用して、動画と音源を合成してエンコードするサーバを作りました。
ただ今現在ではこの仕組みをやめてffmpegを使って大人しく動画変換サーバを作ったのですが、その理由など色々とを放出してみようと思って書かせていただきます。
ダンサー向け動画プラットフォームです。
簡単に言うとTikTokのガチのダンス動画バージョン。
おふざけとかなしで、こちらが選曲編曲したバトルとかでよく使われてる曲(30秒前後くらい)を撮影時に流し、それを投稿してサーバ側で動画と曲を合成していくようなアプリです。
頑張ってダンサーにアプローチしたり広めたりなどでぼちぼちユーザも増えてきています。
ちなみにWeddy Weddyっていうのはジャマイカの有名なクラブパーティの名前だったりします。
ffmpegをLambda上で走らせるとなると…という気分になってしまった。
とりあえずLambda通すとエラー検知とか面倒だったなぁと。
あとLambdaコードの管理が正直面倒。
とりあえずffmpegを使わずにMedia Convertを使えばできるというと判明。
ただしH265変換はMeida Convertは現状対応しておらず、Elastic Transdocerを通さないといけず。
けどポーリングで検知するのはちょっと辛いなぁと思いつつ。
それにまだまだスピードは足らず、30秒程度の動画で1分半ぐらいかかってしまう。
それにMedia Convertでは縦動画をそのまま変換しようとすると、内部のrotateタグが削除されてしまうので、再生するときに縦動画が横動画扱いになってしまう。
いっそのこと動画エンコードサーバを作ることに。
そうすればH265変換も曲合成もなんでもできるなぁと。
それにサーバスペックという名前の札束でぶん殴ることでスピードアップすることができるなぁと。
月額のサーバ代と考慮して30秒程度の動画で30秒ぐらいまで抑え込むことに。
もう少しスピードアップしたいならばffmpegのGPU対応で、サーバもGPUにしないといけないんだけど。
実はHLS形式で最初は配信していたんだけど、変換回数でコストがかかるし、そもそも全部読み切らないで途中で止まってしまうとかもあったり、そもそも短い動画だから向いていないかもなぁとか色々と考えていたり。
それにHLS形式で出そうとするとMedia ConvertだとどうしてもH264になってしまうし。
だからH265でMP4で行こうかと思ったり。
Elastic TranscoderとMedia Convertを使うのは流れ的には問題ないんだけど、動画の長さとかそこらへんによってはそもそもエンコードに時間がかかってしまう。
というかSNSみたいな動画のプラットフォームとして運用するならばアップロードに時間がかかりすぎるので辛いところがある。
ffmpegでもスピードを出したいならば札束でぶん殴るか、GPUでぶん回すかしないと厳しい。
この記事はAWS Advent Calendar 2018の18日目の記事です。
Weddy Weddyというアプリを弊社で開発していまして、Elastic TranscoderとMedia Convertを使用して、動画と音源を合成してエンコードするサーバを作りました。
ただ今現在ではこの仕組みをやめてffmpegを使って大人しく動画変換サーバを作ったのですが、その理由など色々とを放出してみようと思って書かせていただきます。
Weddy Weddyとは
ダンサー向け動画プラットフォームです。
簡単に言うとTikTokのガチのダンス動画バージョン。
おふざけとかなしで、こちらが選曲編曲したバトルとかでよく使われてる曲(30秒前後くらい)を撮影時に流し、それを投稿してサーバ側で動画と曲を合成していくようなアプリです。
頑張ってダンサーにアプローチしたり広めたりなどでぼちぼちユーザも増えてきています。
ちなみにWeddy Weddyっていうのはジャマイカの有名なクラブパーティの名前だったりします。
Weddy Weddyの動画の仕様
- 縦型
- 720p
- h265
- mp4
試作1
流れ
- 動画をS3にアップロード
- DBに投稿データを挿入
- S3アップロードをフックにElastic Transcoderを走らせて動画をエンコードおよびサムネイル作成してS3に再びアップロード
- S3アップロードをフックにffmpegをLambda上で走らせて動画と曲を合成
- 合成した動画のアップロードをポーリングで検知してDBを書き換え
- 動画投稿完了しましたを通知
難点
ffmpegをLambda上で走らせるとなると…という気分になってしまった。とりあえずLambda通すとエラー検知とか面倒だったなぁと。
あとLambdaコードの管理が正直面倒。
試作2
流れ
- 動画をS3にアップロード
- DBに投稿データを挿入
- S3アップロードをフックにElastic Transcoderを走らせて動画をエンコードおよびサムネイル作成してS3に再びアップロード
- S3アップロードをフックにMedia Convertを使用して動画に曲を合成
- 合成した動画のアップロードをポーリングで検知してDBを書き換え
- 動画投稿完了しましたを通知
難点
とりあえずffmpegを使わずにMedia Convertを使えばできるというと判明。ただしH265変換はMeida Convertは現状対応しておらず、Elastic Transdocerを通さないといけず。
けどポーリングで検知するのはちょっと辛いなぁと思いつつ。
それにまだまだスピードは足らず、30秒程度の動画で1分半ぐらいかかってしまう。
それにMedia Convertでは縦動画をそのまま変換しようとすると、内部のrotateタグが削除されてしまうので、再生するときに縦動画が横動画扱いになってしまう。
現在の仕様
流れ
- 動画と曲をffmpeg使って合成してS3にアップロード
- 合成した動画のURLを取得してDBに挿入して動画投稿完了しましたを通知
どうして今の仕様なのか？
いっそのこと動画エンコードサーバを作ることに。そうすればH265変換も曲合成もなんでもできるなぁと。
それにサーバスペックという名前の札束でぶん殴ることでスピードアップすることができるなぁと。
月額のサーバ代と考慮して30秒程度の動画で30秒ぐらいまで抑え込むことに。
もう少しスピードアップしたいならばffmpegのGPU対応で、サーバもGPUにしないといけないんだけど。
ちなみに
実はHLS形式で最初は配信していたんだけど、変換回数でコストがかかるし、そもそも全部読み切らないで途中で止まってしまうとかもあったり、そもそも短い動画だから向いていないかもなぁとか色々と考えていたり。それにHLS形式で出そうとするとMedia ConvertだとどうしてもH264になってしまうし。
だからH265でMP4で行こうかと思ったり。
まとめ
Elastic TranscoderとMedia Convertを使うのは流れ的には問題ないんだけど、動画の長さとかそこらへんによってはそもそもエンコードに時間がかかってしまう。というかSNSみたいな動画のプラットフォームとして運用するならばアップロードに時間がかかりすぎるので辛いところがある。
ffmpegでもスピードを出したいならば札束でぶん殴るか、GPUでぶん回すかしないと厳しい。
コメント
コメントを投稿