IBC 2023 動画技術関連レポート / IBC 2023 Report

Transcript

1. 動画技術関連レポート 株式会社 AbemaTV 五藤 佑典 | 田中 優貴 | 中澤 優一郎
2. アジェンダ • 欧州放送／動画業界では AI / ML をどのように使い始めているか • 欧州を中心としたデジタル放送の規格『DVB』から ハイブリッド配信のヒントを学ぶ • 新放送規格にも重要要素となるコーディング技術の進化 • サステイナビリティへの欧州特有の温度感から進化する技術 • 欧州放送局でのＩＰ化 〜 ＩＰ化は一巡？ • 拠点間伝送の現在 • ５Ｇは番組制作に生きているか？
3. アジェンダ • 標準プロトコルに対する Multi-CDN 進化 • インターネット動画配信サービスでのマルチキャスト配信の現実的な解 • オンデマンドコンテンツに対するユーザーの選択的行動から洞察を得る調査
4. • California State University, San Bernardino グラフィックデザイン専攻 • CyberAgent Developer Expert @（株）サイバーエージェント • テクニカルプロダクトマネージャー @（株）AbemaTV 五藤 佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_
5. in Video Technology and Product Design
6. 中澤 優一郎 YUICHIRO NAKAZAWA • コンテンツエンジニアリングマネージャー @（株）AbemaTV • 2012年新卒入社
7. 田中 優貴 MASAKI TANAKA 2021年 入社
 
 地上アナログ放送の時代に放送業界へ
 番組編集作業や4K/8K制作設備の構築、
 リアルタイムCG等の運用を担当。
 
 現在はABEMAの番組制作技術、
 配信技術を統括する技術局に所属
 
 IBCへは初参加
8. Motivation AbemaTV を始めとするサイバーエージェントの動画事業を技術的に前進させる • 業界トレンドの定点観測 • ヨーロッパを中心とする技術標準化の動向キャッチアップ • 複数の海外パートナー会社との一挙ミーティング • 業界先端企業の将来への見解や実践例などの情報収集 • 汎用ソリューションの進化状況の確認 • 以前に目をつけていた技術の進化状況の確認
9. IBC 2023 および周辺関連組織視察 14日 15日 16日 17日 18日 19日 20日 Flight to Amsterdam via London IBC DAY1 IBC DAY2 IBC DAY3 IBC DAY4 Travel to België 企業訪問 Travel to France 放送局 訪問 Flight to HANEDA IBC 2023（オランダ／アムステルダム） → EVS Head Quarter（ベルギー／リエージュ） → CANAL+（フランス／パリ）
10. IBC とは IBC - International Broadcasting Convention • 欧州最大の放送関連イベント • IBC 2023 は 9/15 - 9/18 にかけて開催 • 2023 年の実績（2022 年の実績） • 来場数 43,065 人（37,071 人） • 展示数 1,250+（1,000） • オランダ・アムステルダム RAI で開催
11. IBC とは 来場者数 / 国 出展社数 広さ IBC Show 2023 43,065 / 170カ国 1250 5万㎡ NAB Show 2023 65,013 / 166カ国 1208 5.3万㎡ Inter BEE 2022 26,901 / 30カ国 810 2万㎡
12. IBC 2023 会場の雰囲気
13. 放送／動画業界では AI / ML を どのように使い始めているか
14. グローバルの AI/ML への投資背景 IABM のレポートによると • 2023 年のメディア技術への 投資予算は加速的に増加 • しかし、収益は投資に比例して増加して いるわけではない • メディア企業の投資対象は AI/ML を始めとした新技術 メディア企業は AI/ML による革新を期待 遅れを取らないように こぞって技術投資を強化
15. 欧州の制作スタイルの変化 2020 ~ 2022: パンデミックによりリモート制作の増加 ◦ 国を跨いだ制作など、地理的特性によりリモート制作が進んだ ◦ 副次的効果 ▪ クラウドを筆頭にITC領域で蓄積してきた技術的蓄積を享受できる環境が整ってきた • ex) AI/ML, 画像処理, クラウドリソース 2023 ~ : AIによるソフトウェア制作の加速 ◦ AIソリューションが制作を劇的に変える可能性が出てきており ◦ さらなるソフトウェア化進行の可能性
16. AI に対する関心の高さ AIに関するセッションは大盛況で立ち見が出るレベル
17. 放送／動画業界における AI/ML 活用 コンテンツ解析・メタデータ生成 • 映像からのメタ付け • 文字起こし 映像品質向上 • フレームレート補完 • オートフレーミング コンテンツ制作・デザイン • 素材作成、映像装飾 • ストーリーボード作成 ML技術を中心的に利用 以前からある話 モデルが洗練されてきている 生成AIが出てきたことにより 急速に進歩
18. メディア & エンターテイメントのAI活用 Paramount Pictures 「ミッション: インポッシブル」などを制作する制作会社 AI活用による時間や予算の削減に対する期待 • クリエイティブ作業の支援 ◦ 画像生成 ◦ ストーリーボード生成 ◦ マーケティング・コンテンツ ◦ クリエイティブコンテンツ • 生産性向上を行うツール ◦ 編集アシスタントツール ◦ VXアシストツール
19. メディア & エンターテイメントのAI活用 Stan. オーストラリアのOTT事業 カスタマーエクスペリエンスの向上に対する期待 • AIによるよりパーソナルなレコメンド
20. メディア & エンターテイメントのAI活用 AIに対するガバナンスの重要性 各社AIを積極的に活用し、制限しない前提 • スタッフのトレーニング • コントロールされた枠組みの中での利用 ◦ 知的財産、社会的な影響などを考え、公開モデルをどのように使うか、どのモデルを使う べきか使うべきでないかガイドライン化 ◦ 事前に承認されたどのソリューションのどのツールを使えばいいのか明確化
21. メディア & エンターテイメントのAI活用 ヨーロッパ圏のプロダクションで期待されている技術 • 合成音声/ボイスクローン技術 • 自動翻訳サービス これにより • 多言語制作の効率化による、世界規模でのコンテンツリリース ◦ アクセシビリティとアベイラビリティ • アニメーション ◦ キャラクターに合う声優の採用の難しさ ◦ 同じコンテンツを同じ声優で多言語で提供することができる ヨーロッパの20か国語以上の言語体系が存在する地域性が大きく影響
22. MediaSupplyChainにおけるセキュリティ Google Cloud CISO & Endeavor Streaming & Paramount Global & MovieLabs “セキュア・バイ・デザイン” / “セキュア・バイ・デフォルト”の取り組み パンデミックによりクラウドを活用したリモート制作が増加 • 利便性獲得の一方、クラウドセキュリティに対する意識の高まり • zero-trust security modelへの移行の必要性 ◦ 利用者や端末、エリアなどを無条件に信頼しない ◦ アクセスの都度、認証・認可を実施する AIの可能性 • 攻撃側にも防御側にも活用可能
23. AI/MLの活用事例 AWS Data Science & Analytics Demos Live Sports Commentary • 生成AI/文字起こし/自動音声技術を組み合わせたデモ • キーワードトピックを中心としたコメンタリの生成 • 欧州では多言語制作が一般的であり、同時に20言語の制作が行われ非常に高コス トで、非常に関心が高い → 精度の課題はあるが、ABEMAのニュース制作や、スポーツ実況において人的な校正 前提で使える可能性
24. AI/MLの活用事例 AWS Data Science & Analytics Demos SLO-MO • スーパースロー映像の生成 ◦ 生成AIによりフレーム数を8倍に増やし、擬似スーパースロー 映像を生成 • １フィードで様々な絵作りができる • 高価なスーパースローカメラが不要 → 競技のような場では使いづらいが、フィードのコントロー ルができない現場においては制作の幅を広げる可能性
25. AI/MLの活用事例 AWS Data Science & Analytics Demos Super resolution • GDAVSRというdeep learningの手法により現実世界のぼやけやノイズを再現し、よりリ アル高画質なビデオを生成する → SDRしか存在しない映像に対してHDRをリマスタリングするなどの用途に利用可能
26. AI/MLの活用事例 Hedge : クロマキーに変わるバーチャル制作 • AI/MLを利用した人物の抽出 • 生成AIを利用してバーチャル化
27. AI/MLの活用事例 日本テレビ&NTT Data “BlurOn” • AIモザイク処理で出展 • 小さなブースだが来場者も多く見られた • PoC展示していたクロマキーレスAIキーイングが注目を 集める
28. ABEMAにおける活用 • 字幕/音声のAIによる自動生成 ◦ 韓流のオーディション番組における日本語字幕の生成 • ニュースハイライト動画の自動生成 ◦ ニュースに要求される即時性を担保しつつ制作本数を増やすことができる • スポーツコメンタリーの自動生成 ◦ スポーツ制作において、実況解説は重要だが制作コストが高い
29. 複数の国を跨いでコンテンツ提供することが多 い欧州でのメディアアセット管理の進化
30. メタデータ管理 • スポーツメタデータ ◦ Stats PerformのOPTAがメタデータとしては主流 ◦ Dizplai ▪ OPTAと連携しハイライトテロップなどの自動生成 • AI/MLによる自動メタづけ ◦ VIONLABS ▪ 自動メタづけ ▪ ショート、サムネイル自動生成 ▪ Ad Breakポイントの検出
31. ライブ制作製品での事例 • EVS ◦ Cinematic Option ▪ 収録された映像の中から主役を決めて背景をボカす ◦ Automatic Framing ▪ 試合の内容を分析し引きの映像からカメラワーク ◦ Super Slow-mo ▪ 3倍のスローをAIを使い推定して生成 (演出としては使えるが判定などには不向き ?) リアルタイムに近い形で、かつ、すでに世界中のスポーツの現場で行われ ている作業スタイルを変えずに付加価値のある映像を作ることができる ユニのカメラを入れられない案件において 独自の味付けとなる技術
32. ABEMAにおける活用 • メタデータ自動化の未来 ◦ AIの進化により自動化の精度が向上 ◦ 主観的な情報であってもカバー可能 • AI/MLを利用することで ◦ メタ付与のカバレッジの問題の解決 ◦ コンテンツ特徴量をより多く多面的に付与することができる ◦ レコメンド・検索精度の改善、その他分析の観点にも利用可能 作品情報 (タイトル/ディスクリプ ション) コンテンツ特徴を表 すジャンル/カテゴリ などのメタデータ 人的な運用 カバレッジや 量の課題 作品情報 (タイトル/ディスクリプ ション) コンテンツ特徴を表 すジャンル/カテゴリ などのメタデータ 入稿 入稿 AIによる 自動メタ付与
33. ライブ素材の管理 ~ ハイライト制作 ライブはユーザーへのアプローチ速度が重要 Live Ingest & Managementのソリューション • Newsbridge ◦ ライブインジェスト ◦ ecosystemを意識したintegration ◦ SNSへのPublish • Wildmoka ◦ ライブ & クリップインジェスと ◦ 高機能なテンプレート編集 ◦ SNSへのPublish • Magnifi ◦ AIによるハイライト自動生成 ▪ 顔、音声、場所、オブジェクト、アクション、お よび音声キューを認識
34. ABEMAにおける活用 宣伝のSNS運用の改善 • 高速化 & 効率化に対する期待 ◦ コンテンツエンジニアリングチームとしても取り組もうとしている内容 ▪ SPOTV NowがYoutube 5分以内という運用 ▪ ABEMAも業界最速水準に持っていきたい ◦ クリエイティブの制作効率をあげる
35. MAM&編集 • Avid “Ada” ◦ ソフトウェアの使用方法 　、アセット検索を自然言語で行える ◦ 多言語対応の文字起こし・翻訳、顔認識、シーン検出、 OCRを行いメタ付与 ① 自然言語で編集内容を入力 “クラウディアがMediaCentralについてプレゼンする” ② 素材の中から 必要なものを提案 B-rollとして、直接的 ではない雑感などの 映像も合わせて提案
36. 欧州を中心としたデジタル放送の規格 DVB からハイブリッド配信のヒントを学ぶ
37. DVB 基本 DVB とは • DVB = Digital Video Broadcasting • 国際的標準規格のデジタルテレビジョン放送方式の一つ • 主に、ヨーロッパ諸国、オーストラリア、南アフリカ共和国で標準的に採用
38. なぜ DVB を学ぶのか • アメリカで開発された ATSC 3.0 と並んで インターネット時代の次世代放送規格 • DVB は伝送路における放送電波はインターネットと同等という考え方 ◦ ATSC 3.0 は放送電波が主。放送電波の上に IP を伝送 • DVB は放送とインターネット両者の 長所を組み合わせた規格策定が特徴 https://speakerdeck.com/ygoto3/ibc-2022-report
39. DVB は 5G とどのように融合するか
40. 5G Broadcast 基本 • 5G の下りの電波を使って、複数の端末に一斉に情報を伝送する技術 • 5G Broadcast による放送は何ができるようになるのか ◦ 超高速移動体への放送 ▪ 新幹線でも受信可能 ◦ 特定エリアに限定した放送 ▪ 5G 基地局を利用することでマンションやスタジアムなどのイベント会場限定して放送 ◦ 特定エリアに限定したデータ放送 ▪ 防災情報などの緊急情報をテレビ／モバイル問わず伝達
41. DVB-I Service 基本 • DVB-I ◦ UI や EPG などのユーザーサイドの標準規格 ◦ 関連サービスに関するシグナリングやメタデータ ◦ Service Discovery • DVB-I Service List ◦ インターネット配信や放送のコンテンツをリスト ▪ インターネットでも放送によるコンテンツでも同じ UI と EPG で番組情報を提供
42. DVB-I Service over 5G の 3 つのシナリオ • 5G Broadcast を使ったスタンドアローンでの DVB-I Service の提供 • 5G Media Streaming を使った DVB-I Service の提供 • Broadcast と Unicast を同時に使った DVB-I Service の提供
43. DVB-I Service over 5G のシナリオ 1 5G Broadcast スタンドアローンで DVB-I Service を提供する • DVB-DASH と DVB-I を介したファイル転送 • 代替シナリオ ◦ DVB-MABR over 5G Broadcast ▪ マルチキャスト ◦ DVB-NIP over 5G Broadcast ▪ IP ブロードキャスト ◦ DVB-IPTV over 5G Broadcast
44. DVB-I Service over 5G のシナリオ 2 5G Media Streaming を利用して DVB-I Service を提供する • アプリケーションは 5G Media Streaming システムからの情報で DVB-I Service Discovery を表示 • 5G Media Streaming のセッションを開始するための Service URL などの情報を DVB-I Service のメタデータに載せる必要がある ◦ 3GPP が現在標準化作業中
45. DVB-I Service over 5G のシナリオ 3 Broadcast と Unicast を同時に使った DVB-I サービスの提供方法には 4 つの選択肢がある • DVB-I の提供を Unicast ／DVB-DASH の提供を 5G Broadcast • 同一セッション内での Broadcast／Unicast ハイブリッドサービス • Broadcast／Unicast ハイブリッドでリアルタイム／タイムシフト視聴切替 • Broadcast／Unicast ハイブリッドサービスによる コンテンツ／要素差替
46. DVB-I by Unicast ／DVB-DASH by 5G Broadcast DVB-I の提供を Unicast ／DVB-DASH の提供を 5G Broadcast • DVB-I Service のメタデータは Unicast で取得 • コンテンツデータ（DVB-DASH）は 5G Broadcast で伝送 メリット • DVB-I Service を提供できる • 人気チャンネルを 5G Broadcast を使い、 ロングテール傾向のチャンネルは Unicast と使い分けられる
47. 同一セッション内 Broadcast／Unicast ハイブリッド 3 つのオプション • 5G Broadcast 受信機で Broadcast／Unicast 切替制御 ◦ DVB-DASH クライアントのリクエストをプロキシして Broadcast／Unicast 切替制御する • DVB-DASH クライアントで Broadcast／Unicast 切替制御 ◦ 5G Broadcast 受信機から提供される情報を基に最適な伝送ネット ワークを選択 • DVB-I クライアントで Broadcast／Unicast 切替制御 ◦ シームレスに切替可能な 2 つの DVB-I サービスインスタンスを DVB-I クライアントが取得し、切替も制御する
48. 残りの Broadcast / Unicast 同時利用 DVB-I サービス提供 Broadcast／Unicast ハイブリッドでリアルタイム／タイムシフト視聴切替 • 5G Broadcast と Unicast 両方でサービスを提供 • タイムシフト利用はしばらく Unicast で提供 • リアルタイムでの使用は Broadcast を選択 Broadcast／Unicast ハイブリッドサービスによる コンテンツ／要素差替 • 5G Broadcast と Unicast 両方でサービスを提供 • 代替言語、HDR 映像、サブタイトルなどオプショナルなコンテンツは Unicast で提供 • 特定デバイスへの広告ターゲティングにも活用可能
49. 新放送規格にも重要要素となる コーディング技術の進化
50. Adaptive Streaming に適した Open GOP 符号ツール VVC では Adaptive Streaming でも open GOP コーディングを採用しやすい Reference Picture Resampling (RPR) というコーディングツールを提供 • HLS や DASH でも Open GOP 符号効率性の恩恵を受けられるかもしれない
51. VVC 基本 • VVC = Versatile Video Coding • Joint Video Experts Team (JVET) が 2020 年 7 月に発表した動画圧縮標準規格 ◦ JVET = MPEG ワーキンググループ（ ISO/IEC JTC 1）と VCEG ワーキンググループ（ ITU-T）の統合 チーム • H.265/MPEG-H HEVC の後継規格
52. GOP 基本 RAP (Random Access Point) • 解像度切替可能なポイント • 放送だとチャンネルを合わせ たときのポイント GOP • 2 つの RAP 間のフレームの 階層的参照構造
53. GOP 基本 Closed GOP Open GOP • 解像度変更ができる • 低符号効率 • キーフレーム周りのノイズ • 高符号効率 • 解像度変更ができない
54. GOP 基本 Closed GOP Open GOP • 解像度変更ができる • 低符号効率 • キーフレーム周りのノイズ • 高符号効率 • 解像度変更ができない HLS や MPEG-DASH のような アダプティブストリーミングでは Open GOP でのコーディングを 採用することはできなかった
55. VVC の新ツール RPR Reference Picture Resampling (RPR) というツールで ストリーミングでの解像度変更が可 能に • 解像度変更後（写真では HD → 4K）に必要となる前の GOP に対する参照は 変更前のフレームをアップサン プリング／ダウンサンプリング して参照
56. VVC の新ツール RPR Reference Picture Resampling (RPR) というツールで ストリーミングでの解像度変更が可 能に • 解像度変更後（写真では HD → 4K）に必要となる前の GOP に対する参照は 変更前のフレームをアップサン プリング／ダウンサンプリング して参照 RPR の制限 • ダウンサンプリング／アップサンプリングの制限 ◦ 参照ピクチャのダウンサンプリングは 1/2 の解像度まで ◦ 参照ピクチャのアップサンプリングは 8 倍の解像度まで ◦ 制限にひっかかった場合は Closed GOP のフォールバックが必要 • エンコード時とデコード時の参照ピクチャの違い ◦ この揺らぎが発生するのは、 RASL（Random Access Skipped Leading）ピクチャの部分 ◦ DMVR（Decoder-side Motion Vector Refinement）など参照サンプルの変化に敏感に影響さ れるツールの利用で発生する ▪ エンコーダーサイドでは、 RASL にこのようなツールを利用しない制限をかける必要があ る
57. クラウドトランスコード実験 Bitmovin
58. ライブエンコーディングのパフォーマンス実験 Spin Digital
59. ブラジルの次世代地上放送規格で採用された エンハンスメントコーデック
60. SBTVD 基本 • ブラジルの地上デジタル放送規格 • 2025 年に新しい標準規格 3.0 をリリース予定 https://forumsbtvd.org.br/tv3_0/
61. SBTVD に期待されるアクセシビリティ改善と高品質化 • ブラジルにもデジタル・ディバイドの現状がある ◦ 情報格差を無くすアクセシビリティを提供することが求められる ◦ 低所得家族や地方のコミュニティがデジタル放送から平等に情報を得られる • 同時に富裕層や技術に精通した層にも満足を与えることが期待される
62. SBTVD に期待されるアクセシビリティ改善と高品質化 • ブラジルにもデジタル・ディバイドの現状がある ◦ 情報格差を無くすアクセシビリティを提供することが求められる ◦ 低所得家族や地方のコミュニティがデジタル放送から平等に情報を得られる • 同時に富裕層や技術に精通した層にも満足を与えることが期待される Video Enhancement
63. SBTVD 3.0 Video Enhancement 技術 LCEVC
64. MPEG-5 LCEVC 基本 Low-Complexity Enhancement Video Coding • コーデックに依存しないコーデック強化 • n 世代コーデックの符号効率を n+1 世代と 同等に強化 • n 世代コーデックと同等の複雑性を保ちなが ら • ソフトウェア実装可能でバッテリー消費が少 ない強化コーデック
65. LCEVC エンハンスド地上波チャンネル ショーケース • FIFA World Cup Qatar 2022 • 世界初の LCEVC エンハンスド 地上波チャンネル
66. ABEMA での活用方針 • 字幕やキャプションなどのオーバーレイ情報と同様に映像の解像度も選択的デー タとして提供する ◦ ABEMA の現在の使用コーデックは MPEG-4 AVC／H.264 ▪ 視聴者にとって選択的に HEVC レベルの品質を帯域をストリームを 1 本別で用意することな く提供するオプション • 新しい形態のアクセシビリティ手段として使う ◦ 未来のテレビとして社会インフラを目指す ▪ 帯域を効果的に使いながらデジタル・ディバイドを埋める
67. MPEG-H Audio 関連カンファレンス • MPEG-H AudioはDVB、ATSC3.0、TV2.5など世界的に採用の流れ • ブラジル Globo ◦ すでにTV2.5で導入済み ◦ W杯では実況、環境音、ファン音声、ボール周辺音などを選択可能な マルチチャンネル音声を MPEG-H Audio を使って提供 • 多言語対応が必要なヨーロッパでも注目 • NHKも多言語マルチチャンネルオーディオの制作手法について研究発表 ◦ 主となる言語（Main commentary）のオーディオバランスを 参照しSub-commentaryのレベルを自動的にメタ化 ◦ 全チャンネルのラウドネス値を低遅延でデコードして測定 放送にも 多言語・パーソナライズ ・イマーシブオーディオの波が
68. 欧州における HD/HDR 市場
69. 欧州におけるHD HDR市場 • 欧州放送局 ◦ 今後の展開の一つとして国際スポーツイベントのニュース素材で取り扱う ◦ 来期のサッカーやモータースポーツでも実施する方向
70. 欧州におけるHD HDR市場 • 放送機器メーカー複数社の声 ◦ HD HDRが多いというわけではないが、事例は聞か れる ◦ ソフトウェアベースの放送機材の割合が高く 「HDR用の機材を追加する」のではなく「HDRモード で動かす」ため、ハードルが低い ◦ 4K HDRに対応している機材を持つ放送局では4Kで の放送がなくとも「HDRに対応している機材がある から」HD HDRを作るということもある ◦ Tierの高い番組は別だが日本ほどHDRに対して品 質をシビアに考えていない印象 配信だと解像度がユーザーや環境によっても変わるので HD 4K といった意識がよりなくなっていく可能性もありそう
71. サステイナビリティへの 欧州特有の温度感から進化する技術
72. 欧州はサステイナブルな活動が活発 • 世界のSDGs達成度ランキン グは欧州が上位を占めている （日本は 21 位） • サステイナビリティ領域は欧 州のルールで市場を戦う未来 を見越して注視 https://dashboards.sdgindex.org/rankings
73. HDR は SDR よりサステイナブルではない • SDR 映像の再生にかかる電力消費は大体 120W あたり • HDR 映像の場合はコンテンツにも拠るが 300W 以上消費する ◦ 消費電力とピクセル輝度値は単調関係 ◦ HDR は広い輝度レンジを提供する結果、 HDR モニタの消費電力は高くなる
74. HDR は SDR よりサステイナブルではない BBC R&D では、HDR 映像そのものを 表示前に処理してモニターデバイスの消費 電力を下げる研究を行っている • JND (Just Noticeable Difference) とい うモデルを基準に、ピクセル値を識別 し、視覚的品質に影響が出ない程度に 修正する
75. アルゴリズム 4 種のマスク処理を映像フレームに適用する • JND モデルベースの 3 種のマスク ◦ 1 番目のマスク ▪ ピクセル調整モジュール • ガウシアンフィルターで背景を検出し、輝度を調整する ▪ 肌色検出モジュール • 認識される品質に大きく影響される肌色を検出し、そのトーンを残す ◦ 2 と 3 番目のマスク ▪ 空間補正モジュール • マスク 2 は ROI 検出でぼかし処理される可能性があるエッジを残す • マスク 3 はエッジを残しつつそのピクセル輝度の平均値を下げる
76. アルゴリズム JND モデルベースの 3 種のマスク ピクセル調整モジュール 肌色検出モジュール 空間補正モジュール
77. アルゴリズム 4 種のマスク処理を映像フレームに適用する • ROI (Region of Interest) モデルベースの 1 種のマスク ◦ 4 番目のマスク ▪ CNN (Convolutional Neural Network) ベースの検出手法 ▪ 事前にトレーニング済の Mask R-CNN によるオブジェクトのセグメンテーションし、視覚的興 味がある領域を決定 ▪ 画像は ROI モデルを適用する前に RGB 色空間への変換と 1280x720 の解像度にリサイズ
78. アルゴリズムの全体図
79. アルゴリズム適用後の電力消費結果 69W 節約 シネマホームモード ＆スポーツ 節約失敗 元々輝度が高い ドラマ
80. エコ中継車 • 電気自動車で運ぶことのできる簡易中継車（ 150kg） • 最大10時間のバッテリー駆動と補助的なソーラーパネル • 4Gでの中継を想定 • 試作段階だがこのコンセプトでよりブラッシュアップしていこうと動いている
81. “サステナビリティ” • 会場ではサステナビリティ ”だけ”をアピールする展示は見られないが … • 視察に訪れたEVSではSastainablity Report（55ページ）がAnnual Report(30ページ) よりも厚いと 冗談混じりに言っていたが取り組みの本気度が伝わった ◦ 環境対策は、もちろん重視しており社員への電気 自動車の貸出しや出張時の短距離飛行機利用の 制限なども行っているが、社内で ”より重要”と 位置付けているのは「顧客体験」と「社員の幸福」 • フランス・Canal+社では 「データセンタ集約で電力効率は高まったが 　Greenのためにやったわけではない」と あえて明言 本質的に取り組みを進めており、それぞれでサステナビリティの捉え方がハッキリしている
82. 欧州放送局でのＩＰ化 〜ＩＰ化は一巡？
83. ＩＰ化とは？ • シャトーアメーバも含め、国内の放送局の多くでは現 在もHD-SDI信号を使用し、1本の同軸ケーブルに 1.5Gbpsの映像音声信号を通している • この信号をIPパケット化し、ネットワーク層で機器間を つなぐのが「IP化」 • 番組制作の現場では、非圧縮またはビジュアルロス レスという広帯域、低遅延、信号間の同期が求めら れるため切り替えのハードルは大きかった
84. 420/8bitまでだったNDIの422/10bitのサポートが発表 ＩＰ規格の現状 • 各社様々な方式を模索、独自性をアピールしてきていた がST2110の策定により互換性をアピールする方向に • 様々なメーカー、役割の機器が相互に繋がるようになり 普及時期に入った • 放送レベルではない部分ではNDIやDanteAVなど別の 規格も引き続き IBC UPDATE!!
85. なぜIP？ • 同軸ケーブルは方向性があり相互接続性が無い • 必要になる可能性のある映像の数だけ同軸ケーブルや分配が必要 🔻　　🔻 • 双方通信が前提、相互接続性が高い • ネットワーク内に必要な映像があれば容易にアクセスできる • 多数の機器が一つのネットワークを共有するため効率的 • 同軸コネクタではなくネットワークアダプタ経由となるため、汎用性が高く 拠点間の接続も容易。ソフトウェア化しやすい。 • 高解像度/高フレームレートの信号を扱いやすい
86. 事例　CANAL+社　〜IPからITへ〜 • スポーツ・映画が２大コンテンツ • フランス国内だけでなくアフリカ各地への放送も実施 • UEFAリーグでは50試合近くを同時に放送できる必要がある など多チャンネル対応が必要 • ST2110の策定前、ST2022の頃から各拠点単独ではIP化に 取り組み • 2年前の拠点移転をきっかけにフルIPシステムに切り替え CANAL+ フランス初の民放。衛星/ケーブル/インターネット経 由で多チャンネルを放送している
87. 事例　CANAL+社　〜IPからITへ〜 • 従来放送局内に設置されていた大量の放送機材を原 則的にデータセンターに集約 • 複数のスタジオ拠点からDCにアクセスしてリソース シェア • サブの見た目は”普通”。モニタと操作パネルはその 場にあるが、本体はデータセンター • 局内のラック本数は1/8〜10に • DCとの間は400Gbps x2（800Gbps化を計画中） • 専用ハードウェア、SDIケーブルから脱却し、COTS・ ネットワークを使った、よりいっそうの「IT化」を目指す
88. 事例　WBD • パリ五輪 3800時間を49カ国、20言語で放送 • 言語対応だけではなく「知らない競技にも興味をもってもらうには ローカルな解説者が必要」 • ヨーロッパ全土にST2110ベースの巨大なスポーツプラットフォー ムを用意 ◦ 左図の通り25のPCR（日本で言うサブコン） ◦ ロンドンに専用データセンターを２ヶ所 ◦ 1200台のスイッチ、30万台以上のエンドポイント ◦ パブリッククラウドからコントロール • クラウドベースのプロダクションの活用で規模を拡大中 ◦ すでに週560時間のサッカーをクラウド完結 “The great thing about the Olympics 　　from our side is the passion of our teams”
89. IP化/ソフトウェア化/クラウド化 従来型 ソフトウェア化 IP化 パブリック クラウド化 • 汎用HWが使用できる ◦ 専用HWに比べ調達が容易 ◦ 使用開始までのリードタイムが短い • 同一HWで機能の切り替え が可能 • 機能の追加がしやすい • 直接操作するハードウェアよりも 遠隔地か らの制御がしやすい • SDI信号を受ける専用ボードが不要 ◦ 様々なフレームレートや解像度、 新しいフォーマットに対応しやすい • 双方向に通信できる ◦ 同一ネットワークに参加すれば相互に 映像のやりとりができる • 他拠点との接続性 が高い • インスタンス数の スケーリングが柔軟 ◦ 番組数に合わせて必要な規模のみを利 用することができる • 同一クラウド間の 他コンポーネントとの連 携が容易 ◦ 他社からの素材伝送や MAM、AIとの連 携等 機器間の接続 機器の内部 機器の場所 データ センター 集約
90. クラウド/リモートプロダクション
91. 分かりやすくするための簡易的な区分けとして… • High ◦ ディレイなく、高画質・高音質、スローリプレイや高品質なCGを付加するなど、完璧 な番組制作を行う ◦ GV AMPP, Ross Cloud Production, KAIROS Cloud, etc… ◦ ここまでを求める場合には、プライベークラウド・データセンター型 ＋ 専用線でハン ドリングしやすくする手法が多い ◦ オペレーションする場所は従来のサブコン型が効率的 • Middle ◦ ほぼ完成した映像に実況解説をつけるなど、シビアなタイミング制御の無い番組制 作 ◦ 各社からさまざまなクラウドソリューションが提供されている ◦ オペレーションは数名程度で行うイメージであり、場合によってはオフィスのような 場所でも対応可能 番組制作技術のレベル分け
92. High • SDIからIP,ソフトウェア化 • これが揃うと各機器メーカーの機能そのままにクラウドに移行しやすい • GrassValleyの取り組みが早い
93. High の欧州での取り組み状況 ✅ ソフトウェア化は浸透 ✅ データセンター集約も大型放送局では進みつつある 🔳 クラウドへの本格移行はこれから AWSブースでの展示 Highレベル制作 Middleレベル制作 同一試合のVTRや グラフィックのみを 多言語対応 SW:GV Audio:SSL Slow:SimplyLive Incom:Telos Graphic:Chyron
94. 冗長性や拡張機能に差異はあるものの、コンセプトが近いものは多数 Middle photo LiveU Studio 　　　HTML5 Graphic 対応 IBC UPDATE!! photo TVU Producer 　　　4K ネイティブ対応 IBC UPDATE!! photo Grabyo Producer スタッツと連携して キーフレームをうつなど photo M2 Live SONY AIエンジンと連携した自 動ハイライト生成など photo ハイライト/スロー編集で 同ブランド製品強い Simply Live その他以下など多数 nxt | cloud ATMOS Live Production (Beta) GV AMPP内
95. ABEMAでの活用方針 • スポーツコンテンツ注力の方向性は同様 • ABEMAの場合はスポーツの中でもジャンルがさまざまで映像の共有などがそこま で多くはない ⇨High制作プラットフォームの構築は効果薄？ • Highレベルの番組制作をスタジオに寄せ、Middleレベルの制作をクラウドに寄せ ていく方向が現実的 ◦ スタジオはより高スペック化 ◦ クラウドをフレキシブルに活用 そのための課題 ◦ コンテンツ量の先読みできない ◦ 技術レベルのTierが設定されてない ◦ 配信がElemental前提 High Middle Studio Capacity 溢れた番組 溢れた番組 Studio Capacity 溢れた番組 クラウド化 難度高 外部スタジオの 利用で高コスト コンテンツ種 現在の対応 今後の展望 クラウド化 可能性高
96. 拠点間伝送の現在
97. 現在の番組制作 画質や安定性を担保するにはキャリアの帯域の太い安定した回線が不可欠 • 大型イベントでは国際伝送の多くを通信キャリア側に依存 • 国内伝送でもキャリアに依存することが多い IBC 香港 POP ロンドン POP 国内 キャリア 通信衛星 ABEMA 制作拠点 パブリッククラウド 50i→59.94i
98. • 機器 ◦ Haivision Makito 　　　　1chモデルが登場 ◦ Kiloview E3　　　　　　 デュアルチャンネルEnc ◦ BlackmagicDesign　　　 RTMPのみ⇨SRT対応 ◦ Teradek, Magewell… ◦ appear Appear X 　　UHD 最大22ch ◦ AJA Bridge Live ◦ SONY（現状独自プロトコル） 8ch伝送機材登場 拠点間伝送 • 回線の帯域強化、SRTなどの伝送用プロトコル、 HEVC対応機器普及 （ビットレート低下）、 Media Connectなどのサービス普及にともない国 際伝送含めてハンドリングできつつある時代に • Haivision社の調査では伝送プロトコルで SRTが最も使われる状況 出典：Haivision Broadcast IP Transformation Report 2022 IBC UPDATE!! IBC UPDATE!! 小型機器の統合管理機能が 充実しつつある 　Haivision Hub 　Magewell Control Hub サーバー型の多チャンネル製品も増 えつつある
99. Videon • Elemental Link HDの中の人 • 特徴 ◦ 内部でHTML5グラフィックスの合成 ◦ 2chエンコード（Option） ▪ グラフィック合成の有無で 2本打ち上げるなどもできる ◦ 単体で映像収録 ◦ Dockerアプリを動作させることが可能 ▪ 映像を収録しS3にアップロード、などの活用も ◦ 遠隔での一括管理 拠点間伝送の内製化を強化していく中で遠隔管理のできる伝送機材として期待 配信エンコーダーとしてもLIVEマーク等の有無を打ち上げられるとクラウド収録などにも繋 げられる期待
100. Live Frame Rate Conversion (FRC) • M2A CloudFrame Rate Converter ◦ W杯前に一度コンタクト済み • Comprimato Live Standards Conversion いずれも内部的には Insyncの”Frame Former”を使用 Insync Technology “Frame Former” • 従来型放送機材での実績も多い Insync Technologyのソフトウェアベース FRC ◦ EC2にインストールすることでクラウドでの処理も可能 ◦ M2Aのコンポーネントの一つとしても活用されている • ライブFRCはキャリアで行うことが多かったが今後は自らの範疇で行う可能性もあり注目 • プラットフォーム連携においても活用の可能性 　　　　　他ソリューションとも品質・コスト比較、見極めを実施したい
101. 伝送品質の監視 QoE/QoS監視 Telestream Argus ◦ ABR ▪ QoE/QoS監視 ◦ Loudness reporting ◦ SCTEマーカーの監視 ◦ パケットの破損など ➡ ABEMAのマスター監視のオペレーション自動化に対する期待
102. ５Ｇは番組制作に生きているか？
103. 5G 番組制作段階での利用例 • 活用事例 3セッション 1. イタリア・Radiotelevisione Italiana Private 5Gで同じスタジオ内の別場所間を低遅延で繋ぎJazz Jam Session番組の制作 2. ブラジル・GloboTV Private 5Gでリアリティーショーのカメラを高ビットレートSRT伝送して番組制作 3. イギリス・BBC 昨年のチャールズ三世戴冠式で番組中継用に大規模なPrivate 5Gネットワークを構築 ◦ Ofcomと協力し、3855MHzを中心に80MHzの帯域を使用 どのセッションもPrivate 5G(日本におけるローカル5G)の事例。Public 5Gを事例は聞かれず
104. 現時点における5G活用のハードル 様々な場所から高品質に映像を伝送・配信できる可能性を秘めており活用に向けた期 待をしている • Private 5Gを構築するのは配信場所が多岐に渡るため難しい • Public 5Gにおいて帯域確保や低遅延のスライシングを期待したいが ◦ 5G SAエリアの展開が進んでいない ◦ エリア内でもスライシングサービスを享受できるエリアは限られている ◦ 限られた周波数帯域の中で一般ユーザーへの影響（犠牲）との兼ね合い
105. BBCによる実証実験 • 数十万人以上が集まる戴冠式後のパレード沿道から中継 • 通常のキャリアでは通常の通信すらままならない状況 • 下り：上り　２：７の上り重視のネットワーク設計 • 基地局のセルを７個設置。パケロスゼロのハンドオーバーを実現 • 約30台が接続され、LiveU等を使用して中継映像を伝送 • BBC以外の複数の国際放送局にも SIMを提供 出典：BBC YouTube Content Creation Award Winner
106. バーチャルプロダクション
107. バーチャルプロダクション • インカメラVFXはこなれてきた？ ◦ LEDパネルメーカーでもバーチャルプロダクションの展 示がなされていた • その他 ◦ Brainstorm Infinityset ▪ プログラミングベースからの脱却 Edisonを前面に押し出す ◦ ZeroDensity ▪ Avid社と提携　iNEWSと連携 ◦ mo-sys ▪ マーカー式トラッカーの小型化 カメラと完全一体化
108. Volumetric 映像のトレンド 3D空間をそのまま映像としてキャプチャ VRなど自由視点の映像をユーザーに届けられる VRコンテンツの裾野の広がりがあまりなく活用が思っているほど進んでいない？ カンファレンスも話の軸が見えづらかった • スマホを活用した3Dキャプチャ ◦ 気軽に使えるかもしれないがプロユースには … • AIを使用した簡易的な3D化 ◦ 写真を元に推定した 3Dデータを作成する • 低遅延でのキャプチャ（ライブに近い形での活用）
109. 標準プロトコルに対する Multi-CDN 進化
110. Multi-CDN の基本 Multi-CDN はどんなときに有効な手段か？ • パフォーマンス ◦ 特定地域の CDN パフォーマンスの低下による QoE の犠牲を回避する • キャパシティ ◦ 特定の CDN のネットワークにトラフィックが集まりキャパシティ問題が発生した場合に回避する • コスト ◦ CDN コストを抑えることを目的に地域や時間によって CDN を使い分ける • トラフィックのコミット ◦ 契約条件となっているトラフィックのコミットを達成するために制御する
111. ABEMA でも Multi-CDN 配信を利用 ABEMA でも FIFA World Cup Qatar 2022 全 64 試合無料配信時 Multi-CDN でパフォーマンスとキャパシティを確保 https://speakerdeck.com/cyberagentdevelopers/playback-quality-control-in-multi-device-and-large-scale-live-video-streaming
112. Multi-CDN の基本 Multi-CDN を実現するアーキテクチャの種類 大きく分けて 4 つ 1. DNS-based CDN 切替 2. オンザフライのマニフェスト書き換えによる CDN 切替 3. サーバーサイドでの切り替え 4. クライアントサイドでの切り替え
113. Multi-CDN の基本 Pro • 動画データの URL は固定 のまま Con • 切替遅延 DNS-based CDN 切替 https://www.muvi.com/blogs/multi-cdn-switching-in-streaming-businesses
114. Multi-CDN の基本 Pro • 再生リセットなしで CDN 切替 可能 • セッションリセットの数に Con • マニフェスト書換によるエラー リスク、サーバーが CDN の 可用性を認識する オンザフライのマニフェスト書き換えによる CDN 切替 https://www.muvi.com/blogs/multi-cdn-switching-in-streaming-businesses
115. Multi-CDN の基本 Pro • 実装の単純さ Con • ページ読込遅延 • 複数クライアントからの集合的 データでの CDN 切替判断は 個別クライアントの状況に最適 化が難しい サーバーサイド CDN 切替 https://www.muvi.com/blogs/multi-cdn-switching-in-streaming-businesses
116. Multi-CDN の基本 Pro • クライアント自体で取得した QoS データの正確性 • シームレスな再生セッション内の CDN 切替 Con • 実装の複雑さ クライアントサイド CDN 切替 https://www.muvi.com/blogs/multi-cdn-switching-in-streaming-businesses
117. HLS / DASH 標準仕様の Multi-CDN 切替制御 HLS / DASH のプロトコル標準に準拠した Content Steering • HLS / DASH で同一サーバー＆プロトコルで制御可能 • 動画プレイヤーへ特別な実装は必要としない • 後方互換性 • 既存の BaseURL の動作を補完
118. HLS / DASH 標準仕様の Multi-CDN 切替制御 Content Steering の概要 オリジン CDN2 プレイヤー CDN1 マニフェスト CDN Steering サーバー { "VERSION": 1, "TTL": 1, "RELOAD-URL": "https://steeringserver.com?session=abc", "SERVICE-LOCATION-PRIORITY": ["beta", "alpha"] } GET "https://steeringserver.com?session=abc &_DASH_pathway=beta &_DASH_throughput=14500" <BaseURL serviceLocation="alpha">https://cdn1.com/</BaseURL> <BaseURL serviceLocation="beta">https://cdn1.com/</BaseURL> <Content-Steering defaultServiceLocation="beta" queryBeforeStart="true">https://steeringserver.com</Conte nt-Steering>
119. HLS / DASH 標準仕様の Multi-CDN 切替制御 Content Steering の概要 オリジン CDN2 プレイヤー CDN1 マニフェスト CDN Steering サーバー { "VERSION": 1, "TTL": 1, "RELOAD-URL": "https://steeringserver.com?session=abc", "SERVICE-LOCATION-PRIORITY": ["beta", "alpha"] } GET "https://steeringserver.com?session=abc &_DASH_pathway=beta &_DASH_throughput=14500" <BaseURL serviceLocation="alpha">https://cdn1.com/</BaseURL> <BaseURL serviceLocation="beta">https://cdn1.com/</BaseURL> <Content-Steering defaultServiceLocation="beta" queryBeforeStart="true">https://steeringserver.com</Conte nt-Steering> HLS / DASH の Content Steering が抱えるトレードオフ • TTL ◦ デフォルト 300 秒 ◦ QoE 最適化するには長すぎる • スケーラビリティ ◦ Steering サーバーはマニフェスト CDN と 同様にスケールする必要がある • コスト ◦ TTL の短縮は Steering へのリクエストが トラフィックの増加
120. HLS / DASH 標準仕様の Multi-CDN 切替制御 Content Steering の概要 オリジン CDN2 プレイヤー CDN1 マニフェスト CDN Steering サーバー { "VERSION": 1, "TTL": 1, "RELOAD-URL": "https://steeringserver.com?session=abc", "SERVICE-LOCATION-PRIORITY": ["beta", "alpha"] } GET "https://steeringserver.com?session=abc &_DASH_pathway=beta &_DASH_throughput=14500" <BaseURL serviceLocation="alpha">https://cdn1.com/</BaseURL> <BaseURL serviceLocation="beta">https://cdn1.com/</BaseURL> <Content-Steering defaultServiceLocation="beta" queryBeforeStart="true">https://steeringserver.com</Conte nt-Steering> HLS / DASH の Content Steering が抱えるトレードオフ • TTL ◦ デフォルト 300 秒 ◦ QoE 最適化するには長すぎる • スケーラビリティ ◦ Steering サーバーはマニフェスト CDN と 同様にスケールする必要がある • コスト ◦ TTL の短縮は Steering へのリクエストが トラフィックの増加 Edge に Steering Server 機能を展開することで トレードオフに対応する
121. HLS / DASH 標準仕様の Multi-CDN 切替制御 Content Steering @ Edge の概要 マニフェスト CDN Steering サーバー群 @ Edge マニフェスト更新 サーバー Steering マスター オリジン CDN2 プレイヤー CDN1
122. HLS / DASH 標準仕様の Multi-CDN 切替制御 Content Steering @ Edge の概要 マニフェスト CDN Steering サーバー群 @ Edge マニフェスト更新 サーバー Steering マスター オリジン CDN2 プレイヤー CDN1 HLS / DASH Content Steering の トレードオフの解消 • TTL ◦ 10 - 30 秒 ▪ プレイヤーバッファ時間と同程度 ▪ QoE 最適化可能な精度のバランシ ング • スケーラビリティ ◦ Steering サーバー群が展開される Edge や CDN はそのまま冗長化されている • コスト ◦ 短かい TTL でも Steering マスターへのリ クエストは増加しない
123. HLS / DASH 標準仕様の Multi-CDN 切替制御 現在このアーキテクチャはどの範囲まで実装可能か • HLS / DASH Content Steering サポート済の既存プレイヤー ◦ AVPlayer ◦ HLS.js ◦ DASH.js ◦ … • 実装要件をサポートする Edge プラットフォーム ◦ Fastly Compute@Edge ◦ Akamai EdgeWorkers ◦ AWS Lambda@Edge ◦ … • アーキテクチャが準拠する標準仕様 ◦ IETF RFC 8216bis (HLS) ◦ ISO/IEC 23009-1 (DASH) ◦ ETSI TS 103 998 (DASH-IF Content Steering)
124. インターネット動画配信サービスでの マルチキャスト配信の現実的な解
125. Multicast 基本 Unicast が基本のインターネット配信において放送波のようなスケーラビリティをもたら す技術 地上波 = 1 チャンネル 1 ストリーム
126. Multicast 基本 Unicast = 1 再生クライアント 1 ストリーム
127. Multicast 基本 Unicast = 1 再生クライアント 1 ストリーム Multicast = 1 チャンネル 1 ストリーム（ホップ間）
128. CP 制御 通信事業者制御 課題はどこを Multicast するのか Multicast 第 1 世代 • OTT サービスの配信に利用しづらい • 通信事業者自身のサービスにのみメリット Multicast Multicast フィード パッケージング Multicast ルーター STB
129. CP 制御 通信事業者制御 CP 制御 課題はどこを Multicast するのか Multicast ABR • OTT に寄せた • 実施しているのは通信事業者のオウンドサービスがほとんど Multicast Unicast フィード パッケージング Unicast オリジン Multicast サーバー (UC to MC) Multicast ゲートウェイ (MC to UC)
130. CP 制御 通信事業者制御 CP 制御 課題はどこを Multicast するのか Multicast ABR • OTT に寄せた • 実施しているのは通信事業者のオウンドサービスがほとんど Multicast Unicast フィード パッケージング Unicast オリジン Multicast サーバー (UC to MC) Multicast ゲートウェイ (MC to UC) CP 側のインテグレーションが必要 CDN によるログ機能や アクセス制御が失われている アプリにも 実装が必要
131. Multicast-Assisted Unicast Delivery • CDN への統合 ◦ コンテンツプロバイダは通常通りにオリ ジンにコンテンツを載せる • コンテンツプロバイダが複数になっ ても CDN 経路が増えない • クライアントアプリケーションに変更 なし ◦ 通常通りに Unicast でコンテンツをリク エスト
132. Multicast-Assisted Unicast Delivery Multicast フィード パッケージン グ Unicast オリジン Root プロキシ Edge プロキシ CDN Unicast CDN セレクタ CP 制御 通信事業者制御 CP 制御 CDN セレクタから CDN リスト取得 Multicast ゲートウェイを CDN の 1 つとして経路取得
133. Multicast でも CDN の情報可視性を保つ
134. Multicast でも CDN の情報可視性を保つ 1 2 Root Proxy の役割 • 1 回目に Edge Proxy からリクエスト を受けた場合は CDN にコンテンツを GET リクエスト • 次に Edge Proxy からリクエストを受 けた場合は GET を HEAD に変えて CDN にリクエスト • これにより CDN でのログやアクセス 制御を可能にする
135. オンデマンドコンテンツに対する ユーザーの選択的行動から洞察を得る調査
136. ブリストル大学 Iain D.Gilchrist 教授のリサーチ オンデマンドでコンテンツが消費されると 視聴者は番組のどの部分が面白いかより選択するようになる その行動パターンを見つけることで、 どうすれば放送後の視聴体験が向上するか洞察を与えてくれる
137. 4 つの消費パターンの発見 1. Constant Audience 2. Linear Decline 3. Concaved Curve 4. Selective Consumption
138. パターン 1：Constant Audience • データの特徴 ◦ 番組を全部見るパターン ▪ 制作者としては一番嬉しい理想的なパターン • どんな番組がこのパターンにフィットしていたか ◦ 今シーズン放送中のドラマ、メロドラマ ◦ チャレンジ系番組 - クイズやゲームショー ◦ 変身系 • 共通する番組の特徴 ◦ リアルタイムの番組放送時もオンデマンド配信時も多くの視聴者 を集める番組
139. パターン 2：Linear Decline • データの特徴 ◦ 視聴者がランダムなポイントで再生をやめる ▪ プロットの直線さは一定 ▪ 傾きもシリーズ内でだいたい一定 • どんな番組がこのパターンにフィットしていたか ◦ ドキュメンタリー ◦ 野生動物観察系番組 ◦ 音楽番組 ◦ トーク中心系ラジオ • 共通する番組の特徴 ◦ カジュアルで全部見なくてもいい構成 ◦ タイムフィラーとして視聴されていたり、BGM として流されていたりする ▪ 再生の終わりは番組の要素に関係なく、外部の出来事だと推測される
140. パターン 3：Concaved Curve • データの特徴 ◦ 多くの視聴者が番組最初の方で離脱 ◦ 残った視聴者は残り続ける • どんな番組がこのパターンにフィットしていたか ◦ 単発の番組 ▪ 単発であればジャンル関係ない • 共通する番組の特徴 ◦ ない ▪ 番組の親近感の方が要因としては関連性が高そう ▪ コンテンツをサンプリングして見る価値なしと判断したらやめる 視聴者とコンテンツを割と見たのでそのまま最後まで見る視聴 者
141. パターン 4：Selective Consumption • データの特徴 ◦ パターン 1 〜 3 までにフィットしない ▪ 番組の特定のパートだけ視聴し、積極的にほかのパートを避けている • どんな番組がこのパターンにフィットしていたか ◦ 音楽番組 ◦ スポーツ番組 ◦ ライブクッキング番組 ◦ マガジン形式の番組 ◦ ライフスタイル系番組 • 共通する番組の特徴 ◦ 番組内に単発の要素を持つ番組に多い ▪ 音楽番組の中のトークパート ▪ スポーツ番組の中のトークパートやインタビューパート ▪ ライブクッキングやマガジン形式の番組は生放送じゃないアーカイブコンテンツのパート ▪ 変身、査定、オークションなどがメインコンテンツのライフスタイル系番組は最後の発表の瞬間にスキップ
142. パターン 1：Constant Audience の心理的背景を洞察 • 授かり効果 ◦ 一度何かを所有すると ,それを手に入れる以前に支払って もいいと思っていた以上の犠牲を払ってでも ,その所有して いる物を手放したがらない現象 • 番組に対して何らかの所有感がある ◦ 時間を忘れて視聴している • 番組自体が包括的に物語になっている
143. パターン 2：Linear Decline の心理を洞察 • 視聴者は空き時間を埋めているだけ ◦ 再生をやめるかどうかは時間にしか関わらない ◦ もし再生をやめる視聴者の割合が一定であれば、指数関 数的なカーブになるはず • ストーリーがあるコンテンツがいくつか集まったよう な番組構成
144. パターン 3：Concaved Curve の心理を洞察 • サンクコスト効果 ◦ お金や労力、時間を投資した結果、たとえ今後のコストが メリットを上回っても、同じことを続けてしまう現象 ◦ 最初に離脱する視聴者は多いが、その後離脱は緩やかに なっていく • 残っている視聴者は番組を楽しんでいる場合もあ るが、最後まで見ることに何らかのコミットメントを 感じている場合もある
145. パターン 4：Selective Consumption の心理を洞察 • 踏み固められた小道 ◦ 公園の舗装された意図して作られた道とは別にある道じゃない道。意図された道じゃないけど歩行 者がわざわざ通ることを選んで何度も通り踏み固められてできた小道 • とにかく興味がある部分にスキップしたい
146. どう改善するか 2 つの改善パターン • Lean-back 型消費 ◦ 放送した番組から一部差し替えてオンデマンド 配信を提供 ▪ 旬が過ぎた情報や埋め合わせコーナー の除去 ▪ 番組全体と短縮バージョンの選択肢を 提供 ▪ カスタマイズバージョンの提供 - 視聴者 がどのコーナーをどの順番で見るか選 べる • Lean-forward 型消費 ◦ コンテンツのナビゲーションを強化 ▪ チャプタライゼーション ▪ イベントマーカー ▪ スキップボタン ▪ その他インタラクティブ
147. スポーツ視聴にちょっと良い クロスデバイス技術
148. TV SYNC NaitiveWaves 社 NaitiveWaves EXP • 2 つのデバイス間の再生タイミング同期機能が 視聴を邪魔しないデザイン • 同期したいデバイス側の「 TV SYNC」ボタンを 押して同期先の音声を聞かせるだけ • 試合はテレビで見ている途中で、スマホでス タッツを確認しながら見たくなったときなど、ボ タンを押して放っておくだけでいいので、視聴 を邪魔しない
149. まとめ • 動画関連領域での AI / ML のユースケースには まだ革新的なものは現れていないが、使い方を絞りながらも自然に業務 やソリューションに取り入れ始めている • 『DVB』では 5G Broadcast と Unicast の組み合わせの選択肢を 増やし、DVB-I Service と番組伝送を連携を最適化 • VVC や LCEVC など次世代コーディング技術はこれまでにないアプロー チで放送や配信のアクセシビリティを向上 • 欧州のサステナビリティへの温度感は高い（NAB Show 比） • 欧州放送局でのＩＰ化は、各メーカーの機材がST2110の策定により互 換性を持ち始め普及時期に入ったことに進んでいる • 拠点間伝送は SRT などのプロトコル・機材普及にともない国際伝送含 めてハンドリングできつつあるがフレームレートの差は課題 • 番組制作における Private 5G 事例は増えてはいる • Multi-CDN やマルチキャスト配信技術は現実的な解を模索 • 放送局もインターネットの利点であるユーザー行動ログから改善のため の洞察を得る研究に投資