この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、大前です。
2022/11/17 に開催された Media-JAWS「【第9回】InterBEEだしリブートしちゃうよ！」に参加しましたので、参加レポートを書いていきたいと思います。
約1年半ぶりの開催となった今回は幕張メッセで開催中の Inter BEE 2022 に合わせて開催ということで、動画配信ネタもりもりの回となっておりました。
概要
コロナ禍でしばらく開催できていませんでしたが、 InterBEEの開催にかこつけて、リブートします！！
幕張メッセの会議室で場所をお借りして実施しますので、 ついでにぜひ覗いてみてください！
登壇者の皆さんが揃いました！ ゴリゴリの動画配信ネタ満載です！
リンク
登壇概要
- [セッション] AWS Media Services 最新サービスアップデート
- 昨年11月から現在まで約1年間の AWS Media Services に関連するサービスアップデートや新機能をご紹介します。
- [LT1] サーバレスアーキテクチャによる 動画配信サービス「hod」の自社開発
- 5ヶ月の期間で、サーバレスアーキテクチャによる動画配信サービスを作りました！
- サービスの構成はもちろん、内製開発に至るまでの経緯、苦労話や費用面のお話…などなど広くお話しします。（11/16 13:55 INTER BEE 民放技術報告会 送出・配信部門での発表内容と同様なものとなります。）
- [LT2] TVerにおけるインターネット配信の視聴体験とパフォーマンス安定化への取り組み 〜ダイジェスト版〜
- Webにあまり馴染みの無い方向けに地上波とインターネット配信のざっくりとした違いや、TVerでの視聴体験・パフォーマンス安定化の取り組みについて簡単にお話します。(フル版はInter BEE 2022 ES2-101を御覧ください)
- [LT3] クラウドを取り巻くリニア配信技術の話
- オリジナル APC/DS の自作経験を元に、TVer 向けリアルタイム配信の自社制御系を作った話や、CTV まわりの技術研究、クラウド送出技術など、昨今のクラウドを取り巻くリニア配信技術についてライトに語ります。
- [LT4] 超低遅延配信の世界を覗く。その時世界は貴方も覗く。その深淵を知るために我々はアマゾンン奥地へ・・・
- 当日をお楽しみに！
- [LT5]超ド級ローカル局がawsを始めてみた!! 知識ゼロからの出発“しくじり先生”からの脱却
- 編集マンがawsに手を出したら…しくじり先生からの復活と途中経過をまとめました。まだまだ道のりは長いです。
レポート
AWS Media Services 最新サービスアップデート
- 2021/11 からのサービスアップデートを紹介
- AWS Media Services とは
- メディア向けのフルマネージドサービス
- ハードウェアであるアプライアンス製品も提供している
- AWS Elemental MediaConvert
- 概要
- ファイルベースのトランスコーダー
- 動画ファイルを配信やアーカイブ目的で処理を行うためのサービス
- アップデート
- AV1 の拡張
- 4K 10bit 対応
- 4K 再生機むけの映像が生成可能に
- Dolby Vision のプロファイル対応に Profile 8.1 を追加
- 8.1 では HDR10 にも対応
- 音声のみの MPEG-DASH、CMAF が出力可能に
- 音声のみ MPEG-DASH はスマートスピーカーで使用されていたりする
- 黒色画面動画が生成可能に
- コンテンツの前後に差し込んだり、オーディオやキャプションのみの期間を作ったり
- 自動化 ABR のルールが追加
- ABR スタックで作成するレンディションサイズの制限バリエーションが追加
- ABR に対する要件がある場合に対応しやすくなった
- HDR10 から Dolby Vision Profile 5 への変換対応
- HDR10 メタデータから Dolby Vision メタデータを生成可能
- AV1 の拡張
- 概要
- AWS Elemental Media Connect
- 概要
- 安全で柔軟かつ信頼性の高い、グローバルな映像配信ワークフローを迅速かつ高い費用対効果で構築することが可能なライブ映像伝送サービス
- アップデート
- Fujitsu QoS のサポート
- 富士通のエンコーダーが搭載している誤り訂正を含んだプロトコル
- 富士通製のエンコーダーと MediaConnect 間で映像のやり取りができるように
- PrivateLink のサポート
- VPC 内のエンドポイントを通じて MediaConnect に直接アクセス可能に
- SRT Caller モードをサポート
- 元々は Listener モードしか対応していなかった
- SRT 機器における柔軟な組み合わせが可能に
- トラブルシューティングの簡素化のためのアラートを追加
- フローの作成時や設定中に起こる問題を確認が可能
- CDI の RGB 10 および 12bit 4:4:4 色空間をサポート
- 低遅延かつ高精細なカラーグレーディング作業が可能に
- Fujitsu QoS のサポート
- 概要
- AWS Elemental MediaLive
- 概要
- ライブエンコーディングサービス
- アップデート
- ビデオ会議をライブプラットフォームへ配信可能に
- Chime SDK 上の映像音声を RTMP(S) で出力可能に
- Dolby Atmos / Dolby Vision エンコーディングに対応
- ビデオ会議をライブプラットフォームへ配信可能に
- 概要
- AWS Elemental MediaPackage
- 概要
- 大規模にビデオ配信を行うための Just in Time Package オリジンサービス
- アップデート
- SPEKE v2.0 によるマルチキー暗号化のサポート
- 複数の暗号化キーがサポートされたため、用途に応じて異なるキーを割り当てることが可能に
- SPEKE v2.0 によるマルチキー暗号化のサポート
- 概要
- AWS Elemental MediaTailor
- 概要
- サーバーサイドのパーソナライズド広告挿入が行えるサービス
- アップデート
- チャネルアセンブリでライブソースのサポートを開始
- 既存の動画アセットから仮想ライブチャンネルを作成するだけでなく、MediaLive 等で生成したライブコンテンツもチャネルに含めることが可能に
- チャネルアセンブリでライブソースのサポートを開始
- 概要
- Amazon IVS
- 概要
- ストリーミングソフトウェアを使用してライブストリームを Amazon IVS に送信するだけで超低遅延のライブ動画を世界中で視聴できる様にするための機能を提供
- アップデート
- サムネイル画像の生成頻度が指定可能に
- 今までは 60秒単位で固定
- 最小 5秒に設定可能
- コンソールと API が東京リージョンでも利用可能に
- コントロールプレーン部分が東京リージョンでも提供
- ストリーミングチャット機能を追加
- チャットについても IVS でサポートするように
- ウェブブラウザ、モバイルアプリ向けのブロードキャスト SDK がそれぞれ利用可能に
- ベーシックチャンネルが HD/フルHD の入力に対応
- ベーシックチャンネルでも 3.5Mbps 以下のフルHD に対応
- ストリームチャット用の SDK を追加
- チャットルームの管理やメッセージの送受信、チャットルーム参加者の管理
- サムネイル画像の生成頻度が指定可能に
- 概要
サーバレスアーキテクチャによる 動画配信サービス「hod」の自社開発
- 自社開発までの経緯
- 初めての取り組みは 2019 年の水曜どうでしょうオンラインライブ配信による収益化
- その後もライブコマースやライブ配信サイトを開発
- 最初は Nuxt.js がメインだったが、途中から React.js を中心に活用
- なぜ自社開発を行ったのか
- 元々北海道 ON デマンドというサイトがあった
- 様々な悩みがあった
- デザインを変えたい
- バックエンドの可用性や負荷軽減をしたい
- 再生機能を充実させたい
- コンテンツ管理を簡単にしたい
- 外部に依頼すると高く、希望通りのサービスにできない
- 2019年ごろから内製開発の実績ができてきて、hod についても自社開発を進めることに
- 機能紹介
- 構成
- フロントは React と TS
- バックエンドは AWS と Serverless フレームワーク
- 再生部分は THEOPlayer
- 管理システムは kintone
- 認証認可は Auth0
- 決済は Stripe
- DRM は PALLYCON
- コンテンツが反映されるまで
- kintone 側で管理できるように機能を作成
- kintone 側の変更を Webhook で連携し、Lambda / Appsync 経由で DynamoDB に情報を書き込み
- フロント（hod）から DynamoDB 上のデータを参照し、コンテンツを表示する
- kintone 上に THEOPlayer を配置し、動画素材の検索とプレビューも実現
- Web システムに登録された情報が管理ページに反映されるまで
- 会員情報や購入履歴などを管理
- 動画の視聴ライセンスなども管理
- フロント側からの DynamoDB へ情報を書き込み、DynamoDB 上の変更を検知し、kintone 側へ情報を連携
- 構成
- 素材管理
- 動画素材お引越し
- まずは HDD を 20本ほど S3 に移行
- Snowball Edge を利用することで、半月程度データ移行が完了
- 運用開始後
- オンプレ上の動画サーバーと S3 を同期
- 特定のディレクトリのみ同期
- S3 上の動画は MediaConvert で暗号化含むエンコード処理を実施
- コンテンツの再生は CloudFront を経由して THEOPlayer で再生
- オンプレ上の動画サーバーと S3 を同期
- 動画素材お引越し
- 実績紹介
- 一番経費がかかっていた時期と比較し、最大 7割程度の削減が実現できた
- 一概に比較することは難しいが、2021 と 2022 を比較しコストが 40~50% 削減
- 円安の影響を受けている部分もある
- お問い合わせが激減
- 運用コストも低減
TVerにおけるインターネット配信の視聴体験とパフォーマンス安定化への取り組み 〜ダイジェスト版〜
- 資料は SpeekerDeck に
- 細かい発表は動画もすでに公開済み
- TVer とは
- 民放テレビ局のコンテンツを配信する民放公式テレビ配信サービス
- 月間の動画再生数が 2億5千万を突破
- TVer 成長の背景
- 以前は余暇時間の多くをテレビが占める
- インターネットやスマホの普及によって余暇時間の奪い合いの時代に
- 地上波とインターネットの違い
- 放送の仕組み
- 従来は電波を通して 1対多
- インターネットの通じたたくさんの 1対1 通信
- 配信設備
- 従来はテレビ塔などがメイン
- インターネット配信では配信サーバーなどが必要
- TVer では配信サーバーとしてクラウドを利用
- 視聴体験
- テレビと比較し、ネット配信は比較的新しいもの
- 地上波はテレビが必須であるため、視聴体験がほぼ固定
- 地上波において番組が見れないケースは
- 視聴者側の問題（テレビの故障）
- 放送事業者側の問題
- 自然災害など
- インターネットの視聴体験は PC、スマホ、タブレットなど多様
- ネット配信において配信が見れない時
- 視聴者側の問題（ネット回線や端末などの問題）
- 事業者側の問題（インターネットやクラウド側の問題）
- "配信が見れない時" を検知する仕組みが必要
- 放送の仕組み
- リアルタイム配信の難しさ
- 負荷対策
- リクエストに応じたサーバの増減を行う
- リクエスト数とサーバー台数を見積もる指標
- お気に入り数やいいね、出演者情報
- 負荷予測の難しさ
- silent というドラマ
- 圧倒的な再生数を記録
- 毎週前週の再生数を超えるため負荷予測が難しい
- 注目度の高い番組への対応は大変
- NewRelic で観測
- スパイクアクセスへの即時対応
- SNS でのバズ
- 番組からの誘導（「続きは TVer で！」）
- AWS のオートスケーリングはスケールに時間を要するため、スパイクアクセスへの対応は難しい場合が多い
- 予期せぬトラフィック
- 通常のパターンと異なる大量のアクセス
- スローダウンや動画の再生エラーなどに繋がる
- NewRelic を利用して検知・通知
- 負荷対策
クラウドを取り巻くリニア配信技術の話
- 総務省
- デジタル時代における放送制度のあり方に関する検討会
- 放送事業者の放送ネットワークインフラにかかるコスト負担を軽減する、という考え方がある
- キーワード
- マスター設備のクラウド化
- IP ユニキャスト方式について、小規模中継局等の代替となる
- リニア送出
- 東日本大震災を通し、臨時災害放送局が増えた
- APC/DS を自作し提供
- TVer 向けリアルタイム配信の実証実験
- リアルタイム配信の自動化機能を作成
- スペシャルライブ配信用の機能を追加
- クラウドプレイアウトの拡張も実施
- APC 的なリアルタイム制御は IaaS になってしまう
- リニア配信
- CMAF-ULL による低遅延配信
- 低遅延配信に必要となる技術は MediaStore や CloudFront に対応
- 放送と CMAF-ULL で同時に配信、遅延も同程度
- キャッシュのヒット率も普段のライブ配信とほぼ変わらない
- 低遅延配信であっても構成は変わらない、CDN もそのまま使える
- Amazon IVS 登場で簡単に低遅延ができる様になってしまった
- CTV で低遅延試してみた
- まとめ
- 放送は専用機器、安定的
- 配信は常に進化し、汎用機器やソフトウェアなど色々あるため、アジャイル
- 放送のように作り込んだ設備は合っていない
- 小さな改修はお金がかかるため、社内で内製していきましょう
- 放送業界の DevOps はじめませんか？
超低遅延配信の世界を覗く。その時世界は貴方も覗く。その深淵を知るために我々はアマゾンン奥地へ・・・
- 遅延をなぜ短くしたいのか？
- 双方向性やリアルタイム性
- SNS によるネタバレなど
- こんなところで使われている低遅延
- Chime SDK
- Slack ハドル
- 日本でも採用事例いくつか
- Chime SDK
- 双方向性やリアルタイム性
- fMP4
- HLS と MPEG-DASH 両方でサポート
- 連携して使われるのが CMAF
- 共通化を目指して作られた
- 前提としては fMP4
- 考え方はほぼ全ての低遅延に流用されている
- セグメントをさらにチャンクという単位に分割することで、低遅延に繋がる
- Apple Low Latency HLS
- HLS がベース
- プレイリストを m3u8 として利用
- 規格上 3つのセグメントファイルと 1つのキーフレームが再生に必要であるため比較的遅い
- CMAF と同様にセグメントをチャンクに分割
- Chunked Transfer Encoding でメッセージボディをチャンクに分割して配信
- チャンクは Partial Segment と呼ばれている
- 後方互換性もあり、対応していないクライアント上では HLS として動作
- fMP4 には非対応
- CloudFront のアップデート
- QUIC/HTTP3 対応
- UDP への対応
- LL-HLS Support
- Origin Shield
- CloudFront の多層化しているキャッシュレイヤーでヒット率の向上
- QUIC/HTTP3 対応
- 遅延が生じるポイント
- 一番はプレイヤー
- プレイヤー側でバッファリングすることなどに起因
- 次点でエンコードなど
- プレイヤーを含め提供したサービスが Amazon IVS
- 細かい設定はできないが低遅延配信に特化している
- MediaServices はプロ仕様
- CloudFront を使っていない（使っていることを明言されていない）
- ベースは Twitch の技術
- CloudFront で利用できる機能は適用できない
- IVS には RTMPS で打ち上げ
- メタデータを利用可能
- ストリーミングチャット機能
- ライブの保存も可能
- MediaLive を介して S3 に吐き出す
- 一番はプレイヤー
超ド級ローカル局がawsを始めてみた!! 知識ゼロからの出発“しくじり先生”からの脱却
- なぜ AWS をはじめたのか？
- イベントがライブ配信が増加
- Youtube Line などで配信が規約上できないイベントが増加
- 任意の CM を入れたいなど
- HTB さんで面白いことをやっていたのでやってみたいとおもった
- 高校サッカーの配信を広告付きで配信してみよう
- Media-JAWS に参加して情報収集
- とりあえず構築してみた
- MediaLive → MediaStore → CloudFront
- プレイヤーは THEOPlayer
- 広告は Google Analytics
- いざ配信すると問題が発生、、、CloudFront 周りの設定を失敗してしまった
- 1年後にリベンジ
- MediaStore を MediaPackage に変更
- MediaTailor を利用
- プリロールもミッドロールも無事に入った
- 視聴ログが入った
- サッカー配信もリベンジ成功
- そのほかにも様々な配信を実施
- まとめ
- 机上の理論はさておきとりあえずやってみよう
- AWS 面白いよ
おわりに
第9回 Media-JAWS「【第9回】InterBEEだしリブートしちゃうよ！」の参加レポートでした。内容の濃い話が多く、文章だけで伝えきれない部分が多いですがとても楽しく参加させていただきました。リニア配信周りは放送業界経験のない私にとっては慣れない単語が多く理解しきれない部分もあったので、後でゆっくりキャッチアップしておきたいと思います。
Youtube 上へのアーカイブもある様ですので、興味ある方はこちらもご覧ください。
そして次回は年明けの 2023/1/18に渋谷にて 第10回 Media-JAWS が開催されます！是非ご参加ください
以上、AWS 事業本部の大前でした。
2
