よくある質問（FAQ）

一般的な質問（General）

GUI（グラフィカルユーザーインターフェース）はありますか？

いいえ、お客様が既にプレイリストを生成し、ライブラリ管理、権利などを処理するスケジューリングシステムを持っていると想定しています。

自分で配信スケジュールを作成する必要がありますか？

はい。

既存の自社のプレイリスト形式をサポートしてもらえますか？

SMILをサポートしており、既存のプレイリスト形式には通常、メディアIDを参照しているため、私たちが使用するための正しい情報が含まれていないと想定しています。したがって、お客様によるいくらかの統合作業が必要となる可能性があります。

すでにRemix VOD2Liveを使用していますが、他のユースケースにアクセスするにはどうすればよいですか？

新しいUnified Virtual Channelソリューションを既存のRemixユースケースと並行して使用できますが、それは完全なシステムであるため、別々に実行されます。

24/7リニアチャンネルとはどういう意味ですか？

これは、従来のテレビチャンネルのように、中断なく再生を続けるチャンネルです。

どんなフォーマットがサポートされていますか？

すべての機能はHLS（トランスポートストリームおよびフラグメント化されたmp4/CMAF）およびDASH出力に対してサポートされています。

SmoothStreamingの場合、単純なVOD2Liveチャンネルを管理するためにAPIを使用することができますが、プレイリスト間のトランジションはできません。

新しいAPIを使用して統合しなければ、この新しい機能を利用できないのでしょうか？

はい。新機能を構築するためにコンポーネント製品を使用して自前で開発しない限り、この新しい機能を利用することはできません。

ブラックアウトなどのことができるようになりますか？

はい、必要な時間に「ブラックアウト」プレイリストへのトランジションをスケジュールすることができます。

ライセンスはどのようになっていますか？

Virtual Channelは、チャンネル数と機能に基づいてライセンスされています。チャンネルごとに基本料金があり、DRM、広告挿入用のSCTE 35などのタイムドメタデータ、ライブソースのスティッチングを有効にするためのアドオンがあります。

チャンネル数は出力チャンネル数に基づきます。例えば、定期的に新しいプレイリストにトランジションする単一のチャンネルは、1つのチャンネルライセンスしか使用しません。同じ配信ポイント/サーバーマニフェストを使用する複数の出力形式も1つのチャンネル数に含まれます。つまり、DASH（/.mpd）、HLSトランスポートストリーム（/.m3u8）、HLS fMP4（/.m3u8?hls_fmp4）を提供する場合や、動的なトラック選択フィルタを使用する場合も、全て1つのチャンネル数としてカウントされます。

システム展開（Deployment）

どのようにスケーリングするのか？

Virtual Channelのスケーリングは、Unified Originのライブチャンネルのスケーリングと同様で、総ビットレート、出力数、出力セグメントの長さに依存します。

参考として、 Apple's recommended HLS ladder を使用したテストを実施しました。このテストは全レンディションで合計82Mbit、セグメント長3.2秒、3つの出力形式（HLSトランスポートストリーム、HLS fMP4、DASH）で、総出力は約250Mbitでした。

EC2 C6g instance （具体的にはc6g.medium）でテストを行ったところ、約30%のCPU使用率で快適に動作しました。このインスタンスの基礎ネットワークスループットは0.5Gbitであるため、この規模のチャンネルを安全に運用できるのは1つだけです。

どのようにシステムを監視できますか？

すべてのコンテナはログ情報をSTDOUTおよびSTDERRに出力します。これらは標準のDockerツールで監視することができ、Docker log driver を設定することで外部システムに送信することも可能です。

リソース使用状況のメトリクスは、標準的なツールを使用して収集できます。

冗長/高可用性セットアップでのデプロイメント方法は？

高可用性セットアップを実行する最も簡単な方法は、単純にVirtual Channelの2つの独立したコピーを実行し、正確に同じプレイリストとトランジションを両方のシステムに送信することです。入力が同じであれば、Virtual Channelは常に同一の出力を生成し、同じメディアタイムラインとセグメンテーションを持つため、アクティブ/アクティブまたはアクティブ/パッシブクラスタで簡単に使用できます。

システムの状態はその履歴に依存するため、既存のシステムの冗長コピーを作成する際には、既存のシステムをバックアップし、それを新しいインスタンスに復元する必要があることに注意が必要です。

システムをバックアップする方法は？

バックアップする必要がある2つのコンポーネントがあります：/channels ディレクトリとRedisデータベース。

/channels ディレクトリは単純にコピーすることができます。

Redisデータベースは、3つのステップでバックアップできます。

# 保存プロセスを開始します：
docker compose exec -it redis redis-cli bgsave

# 次に、/dataに書き込まれたdump.rdbファイルを確認します：
docker compose exec -it redis ls -alF /data

# それがコンテナ内にある場合、コンテナから外部にコピーしてください。
docker compose cp redis:/data/dump.rdb .

システムを復元する方法は？

Warning

バックアップを復元すると、データベースが上書きされるため、システム上の既存の状態が上書きされます。

Virtual Channelシステムを開始する前に、以下の手順に従ってください。すでに実行中のシステムに復元する場合は、まず実行中のコンテナを停止する必要があります。

# 実行中のコンテナを停止してください。
docker compose stop

バックアップから``/channels``ディレクトリの内容を新しいインスタンスにコピーします。

Redisデータベースを復元するには、appendonlyモードをオフにする必要があります。そうしないと、Redisはrdbファイルを無視します。これは、 docker-compose.yaml ファイルの redis セクションで --appendonly yes を --appendonly no に変更することで行うことができます。

redis:
  image: redis:7.0.4
  restart: always
  entrypoint: redis-server --appendonly no
  logging: *default-logging
  volumes:
    - redis_data:/data

これが完了したら、ダンプファイルをコンテナのストレージボリュームにコピーできます。

# ローカルディレクトリから dump.rdb を Redis のデータボリュームにコピーしてください。
docker compose run --rm --volume $PWD:/backup --entrypoint /bin/bash redis -c 'cp /backup/dump.rdb /data/dump.rdb'

その後、通常通りシステムを起動します：

# Virtual Channelを起動してください。
docker compose up -d

システムが実行されていることを確認したら、新しいappendonlyファイルの書き込みを開始するように指示します：

# c新しい appendonly ファイルを作成してください。
docker compose exec redis redis-cli BGREWRITEAOF

その後、 docker-compose.yaml の設定を appendonly モードに戻してください。

redis:
  image: redis:7.0.4
  restart: always
  entrypoint: redis-server --appendonly yes
  logging: *default-logging
  volumes:
    - redis_data:/data

コンテンツ（Content）

すべてのコンテンツはエンコードを完全に一致させる必要がありますか？

いいえ、すべてのコンテンツが完全に同じエンコードである必要はありませんが、DASHやHLSの要件を満たすためには、全体的に似たプロファイルである必要があります。Virtual ChannelはUnified Remixを使用してVODプレイリストを処理し、スケジュールされたソースメディア間で「最適なトラック」を見つけるためのアルゴリズム（ヒューリスティック）を持っています。このアルゴリズムにより、完全に一致しないトラックでも、最も適したものを選択して再生に使用します。

ベストプラクティスとしては、希望するターゲットエンコードプロファイルを設定し、Virtual ChannelがVODを処理する際にできるだけそのプロファイルに一致するようにすることです。ライブソースは同じ方法で処理されないため、あいまいなマッチングはできません。つまり、ライブソースを使用する場合は、そのエンコードプロファイルをターゲットとしてVODプレイリストに使用する必要があります。これは、ライブストリームから短いクリップをキャプチャし、それをターゲットとして使用することで簡単に実行できます。

チャンネルのロゴ/バグ（透かし）やその他のダイナミックグラフィックを追加することは可能ですか？

Virtual Channelはトランスコードを行わないため、ソースメディアに含まれていないグラフィックを追加することはできません。

しかし、この問題を解決するための代替手法があり、詳細については喜んでお話しします（サポートにご連絡ください。）。例えば、ストリーム内のタイムドメタデータを使用してクライアント側でオーバーレイをトリガーする方法などがあります。

チャンネル/トランジションの作成

プレイリストでVODとライブソースを混在させるにはどうすればよいですか？

1つのプレイリスト内でVODとライブを混在させることはできませんが、APIを使用して別のソースへのトランジションをトリガーすることは可能です。例えば、VOD2Liveプレイリストからライブソースへのトランジション、さらにライブソースからVOD2Liveプレイリストへのトランジションを行うことができます。

すでに実行中のプレイリストに変更を加えることはできますか？

変更は、新しいプレイリストを送信し、システムが古いプレイリストから新しいプレイリストに切り替える時間を指定することで行えます。これをトランジションと呼びます。

特定の時間（例：6時間後、12時間後、24時間後）に1つのプレイリストから別のプレイリストに移行するにはどうすればよいですか？

新しいプレイリストとトランジション時間をAPIに送信し、 PUT /channels/{channel}/transitions/{transition} エンドポイントを使用します。このとき、 {transition} はトランジションを実行したい時間（UTC、ISO8601形式）に設定します（例： 2021-03-22T21:00:00Z ）。

チャンネルを特定の時間長のVOD2LIVEまたはLIVEクリップに移行するにはどうすればよいですか？

単一のトランジションには“時間長”の概念はありません。目的のコンテンツの再生時間は、連続する2つのトランジション間の差で実現されます。

例を挙げるとわかりやすいでしょう。例えば、あるプレイリストAを連続再生するチャンネルがあるとします。T1の時点でプレイリストBに移行し、30分後にプレイリストAに“戻りたい”とします。

この目的を達成するためには、2つのトランジションを作成します：

• T1の時点でプレイリストBへの最初のトランジション

• T2 = T1 + 30分の時点でプレイリストAへの2回目のトランジション

VOD2Liveプレイリストの開始時間、DRM、およびその他のオプションを設定するにはどうすればよいですか？

設定パラメータ vod2live_start_time は開始時間を設定するために使用され、SMILの<head>内で必須のパラメータです。サーバーマニフェスト作成時に通常mp4splitに渡す他の設定パラメータも、SMILプレイリストの<head>内でVirtual Channelに渡すことができます。

チャンネルが準備完了したことをどうやって確認できますか？

チャンネル作成のためにSMILを送信すると、ステータスURLが返されます。このURLにアクセスすることで、ジョブの処理状況をいつでも確認できます。プロセスが Success ステータスに達したら、視聴者が利用できる状態になります。

PUT操作を実行してから、チャンネルやトランジションが再生可能になるまでにどれくらい時間がかかりますか？

ライブチャンネルやトランジションの作成には、以下の2つの基本的なステップが含まれます：

• Unified Remixを実行して、SMILプレイリストを処理し、リミックス（Remix）されたmp4を作成する。

• mp4splitを実行して、リミックスされたmp4に基づいた .isml サーバーマニフェストを作成する。

このプロセスには、主に次の2つの要因に依存して、変動する時間がかかります：

• プレイリストの複雑さ（プレイリストの長さ、エントリー数、メディアの複雑さはすべてUnified Remixの処理時間に影響します）。

• I/O速度。メディアがクラウドストレージにある典型的なケースでは、リモートストレージへのネットワークスループットが重要な要因です。

つまり、PUT操作を実行してからチャンネルやトランジションが利用可能になるまで、非常にシンプルなプレイリストの場合は数秒、長く複雑なプレイリストの場合は数分の遅延が発生することがあります。

デフォルトでは、Virtual Channelはリミックスされたmp4と対応するismlを作成した後、トランジション時間がまだ到達していないかを確認します。

チャンネルやトランジションの作成ジョブに変動する時間がかかる場合、指定された日時にチャンネルやトランジションが確実に再生可能になるようにするには、どうすればよいですか？

正しい手順は、必要な再生開始時点を設定したうえで、チャンネルやトランジションを十分に前もって作成することです。推奨される手順は以下の通りです：

• チャンネルを作成する際に、 vod2live_start_time オプションを再生を開始したい日時に設定します（必ずUTC時間で指定してください）。

• トランジションを作成する際に、トランジション時間をアクティブにしたい日時に設定します（こちらも必ずUTC時間で指定してください）。

• Virtual Channelがチャンネルやトランジションの作成操作を実行できるように、PUT操作は十分前もって行ってください。

チャンネルがセットアップされ、指定された開始時刻前にOriginへのリクエストが行われた場合、クライアントは404を受け取り、Apacheのエラーログに FMP4_404 VOD2Live starts at 2021-03-22T21:00:00Z のようなログメッセージが書き込まれます。

指定された開始時刻に達すると、Originはその時点でリクエストの応答を開始します。

過去の時刻や数秒後の未来をトランジション時間として指定した場合、どうなりますか？

A transition time in the past will just fail. For the one a few seconds in the future, the outcome will depend on the duration of the transition creation job. In fact, transition time is checked in several points:

• at PUT time, transition time must not be in the past

• at PUT time, transition time must not be earlier than vod2live start time

• at transition job completion time, transition time must not be in the past

In our example, let's imagine that, at time T1, a job for a transition at time T1+Delta_T is submitted successfully.

If the transition creation job takes a time Tj to complete, the transition will be successful only if T1+Tj<Delta_T.

Remember that by using the force query parameter, you can disable all these checks if you know what you're doing.

過去のトランジション時間を指定すると、ジョブは失敗します。数秒後の未来を指定した場合は、トランジション作成ジョブの所要時間によって結果が異なります。実際、トランジション時間は以下のポイントで確認されます：

• PUT操作時に、トランジション時間は過去であってはいけません。

• PUT操作時に、トランジション時間はvod2live_start_timeよりも早くてはいけません。

• トランジションジョブ完了時に、トランジション時間が過去であってはいけません。

例えば、T1時点で、T1+Delta_Tの時刻にトランジションを行うジョブが正常に送信されたとします。

トランジション作成ジョブにかかる時間をTjとすると、トランジションが成功するのは、T1+TjがDelta_Tより小さい場合のみです。

なお、 force クエリパラメータを使用すると、これらのチェックをすべて無効にすることが可能ですが、その際は十分に注意してください。

もし複雑なトランジションを数秒後の未来にスケジュールする必要がある場合、どうすればうまく動作させることができますか？

他に選択肢がない場合、次のテクニックを使用することで、トランジションを事前に計算して後で再利用し、必要なときにジョブ完了時間をほぼ瞬時にすることができます。

このテクニックを使用する前提は以下の通りです：

• トランジション先のSMILプレイリストを事前に把握していること

• トランジションを実行したい正確な時間は事前にわからないが、未来の推定時刻T（例：深夜まで、次の2日以内）までには必要であることを見積もれること

これが推奨されるワークフローです：

1. トランジション先のSMILを準備します。

2. 推定の最遅時刻TでそのSMILにトランジションするようにスケジュールします。

3. トランジションが成功するのを待ちます。

4. 実際にトランジションを行いたい正確な時間がわかったら、その時間にスケジュールします（数秒後でも可）。

5. トランジションが成功するのを待ちます。

6. T時刻にスケジュールした最初のトランジションを削除します。

このテクニックは、時間がかかるステップ（リミックスされたmp4とismlサーバーマニフェストの計算）が、十分前もって行われるステップ2で実行されるために機能します。ステップ4で実際のトランジションをスケジュールし、同一のSMILを送信すると、Virtual Channelは事前に計算されたリミックス済みのmp4とismlサーバーマニフェストファイルを完全に再利用するため、トランジションジョブの所要時間が大幅に短縮されます。この場合、ジョブはほぼ瞬時に完了します。最後に、実際には不要なT時刻のトランジションを削除します。

What should I pay attention to when providing a start time (vod2live_start_time option) for my channel?

• convert your date/time from local time to UTC

• format your time string in one of the two supported ISO8601 formats (with or without decimal digits for seconds): - 2021-03-22T21:00:00Z - 2021-03-22T21:00:00.000000Z

チャンネルの開始時間（vod2live_start_time オプション）を指定する際に注意すべき点は何ですか？

推奨事項はvod2live_start_timeオプションに関するものと同様です。具体的には：

• ローカル時間をUTCに変換すること。

• 時間文字列を、秒の小数点以下の桁数の有無に応じたサポートされているISO8601形式のいずれかでフォーマットすること： - 2021-03-22T21:00:00Z - 2021-03-22T21:00:00.000000Z

• トランジション時間が未来の時刻であることを確認し、理想的には少なくとも数分後に設定すること。

チャンネルやトランジションを作成する際にSMILでミスをした場合はどうなりますか？

ジョブのステータスが Success または Failed の状態になるのを待ってから、修正したSMILを使用してPUT操作を再実行してください。

もしchannel/transitioがすでにアクティブである場合は、channel/transitioを削除して新しいものを作成する必要があります。

メディアセグメントのパスにUUIDが表示されるのはなぜですか？

DASH/HLSでメディアセグメントのURIを確認すると、UUIDが含まれていることに気付くかもしれません。例えば：

initialization="9cc198d6-f951-54e0-bb9f-cc63f5913434-$RepresentationID$.dash"
media="9cc198d6-f951-54e0-bb9f-cc63f5913434-$RepresentationID$-$Time$.dash">

DASHの場合、あるいは

#EXTINF:1.92, no desc
../9cc198d6-f951-54e0-bb9f-cc63f5913434.isml/9cc198d6-f951-54e0-bb9f-cc63f5913434-audio_eng=128000-video=400000-11098588.ts

このUUIDは、チャンネルやトランジションの作成時に提供されたSMILプレイリストの完全なハッシュから計算されます。Virtual Channelは、内部でSMILとUUIDのマッピングを保持しており、同じSMILプレイリストがチャンネルやトランジションの作成に使用されるたびに、以前に作成されたismlサーバーマニフェストを再利用できます。

UUIDは、SMILコンテンツのハッシュに基づいて一貫して計算されます。これにより、Virtual Channelの異なるインスタンスが同じSMILに対して常に同じUUIDを生成することが保証されます。この点は、キャッシュ効率や高可用性の観点で重要な場合があります。

チャンネルの削除/変更

既存のチャンネルやトランジションをいつ変更できますか？

既存のチャンネルやトランジションの更新は、以下のすべての条件が満たされている場合にのみ許可されます：

• チャンネル/トランジション作成ジョブが完了していること（成功または失敗のいずれか、つまりステータスが Failed または Success であること）。

• Success の場合、スケジュールされたチャンネル/トランジションの開始時間にまだ達していないこと。このチェックは force クエリパラメータを指定することで無効化できますが、非常に慎重に使用する必要があります。

チャンネル／トランジションはいつ削除できますか？

削除は、以下のすべての条件が満たされている場合にのみ許可されます：

• チャンネル/トランジション作成ジョブが成功または失敗で完了していること（ステータスが Failed または Success であること）。

注意点として、削除操作ではチェックが行われません：チャンネルがライブ状態で削除すると、再生が中断されます。

トランジションを削除すると、そのコンテンツを再生中のデバイスは停止しますが、チャンネル自体は動作を続け、以前のトランジションのコンテンツを使用します。

これをさらにわかりやすくするため、いくつかのシナリオの例を挙げます。

|---------------------|-------------|---------->
ch1                  tr1           tr2
                                              ^
Viewer 1:                               <-----|>
                                       ^
Viewer 2:                        <-----|>
                            ^
Viewer 3:             <-----|>

The above is a sketch of a channel with two transitions, with viewers reproducing it at different points in time. In angular brackets, their DVR window is represented. Viewer 1 is on the Live edge, while Viewer 2 and 3 are using the "restart/catch-up" functionality.

Example 1: Transition 2 is deleted From the deletion moment on, Viewer 1 and 2 will be affected and their players will hang. Viewer3 will not be affected at all. Any other viewer joining the stream at this point will experience a channel only having tr1:

上記は、2つのトランジションを持つチャンネルの概要で、異なる時間帯に視聴者が再生している様子を示しています。DVRウィンドウは角括弧で表されています。Viewer 1はライブエッジにおり、Viewer 2と3は“再スタート/追っかけ”機能を使用しています。

例1: トランジション2が削除された場合 削除の瞬間から、Viewer 1と2は影響を受け、プレイヤーが停止します。Viewer 3は全く影響を受けません。この時点でストリームに参加する他の視聴者は、tr1のみを持つチャンネルを体験することになります。

 |---------------------|------------------------>
ch1                   tr1

例2: トランジション1が削除された場合 削除の瞬間から、Viewer 2と3が影響を受けます。Viewer 3のプレイヤーは停止します。Viewer 2のプレイヤーは、トランジション1のプレイリストにどの程度依存しているかによって、 停止する可能性 があります。Viewer 1は全く影響を受けません。この時点でストリームに参加する他の視聴者は、tr2のみを持つチャンネルを体験することになります。

|-----------------------------------|---------->
ch1                                tr2

チャンネルを削除するとどうなりますか？

チャンネルを削除すると、Virtual ChannelのOriginサービスはすぐにコンテンツの提供を停止します。チャンネルに属するすべてのトランジションが削除され、チャンネルに関するすべての詳細（ジョブステータス、ログ、ステータスの詳細）も削除されます。

チャンネルのSMILが他のチャンネルまたはトランジションで使用されていない場合、対応するサーバーマニフェストとリミックスされたmp4も削除されます。

削除されたチャンネルの履歴を保持する必要がある場合は、Virtual Channelsから削除する前に必要なすべての詳細を保存する必要があります。

トランジションを削除するとどうなりますか？

トランジションを削除すると、Virtual ChannelのOriginサービスはすぐにそれを属するチャンネルから削除します。トランジションに関するすべての詳細（ジョブステータス、ログ、ステータスの詳細）も削除されます。

トランジションのSMILが他のチャンネルまたはトランジションで使用されていない場合、対応するサーバーマニフェストとリミックスされたmp4も削除されます。

削除されたトランジションの履歴を保持する必要がある場合は、Virtual Channelsから削除する前に必要なすべての詳細を保存する必要があります。

既存のチャンネル/遷移を更新するにはどうすればよいですか？

同じチャンネル/トランジションのエンドポイントに対して、新しいSMILペイロード（メディアの再生やスケジュールを指定するためのXMLデータ）を使用してPUT操作を実行してください。

ただし、vod2live_start_timeやトランジション時間が過去のチャンネル/トランジションについては、 force クエリパラメータを指定しない限り変更は許可されません（forceを使用することは推奨されません。実行中のストリームを中断する可能性があるためです）。

既にライブ配信状態のチャンネルを更新できますか？

いいえ、Virtual Channelsはそのような操作を許可しません。もし間違いを犯し、既存のチャンネルを完全に削除したい場合は、DELETE操作を実行し、その後PUTでチャンネルを再作成することができます。ただし、この操作は再生を中断させることになりますので注意してください。

既存のチャンネルを新しいコンテンツに切り替えたいだけであれば、トランジションを実行すべきです。ただし、視聴者は「再スタート/追いつき」機能やシークバーを戻すことで、トランジション前のコンテンツにアクセスできることに注意してください。

すでにライブ状態のチャンネルを更新し、実行中のストリームを中断させることを確実に行いたい場合は、 force クエリパラメータを指定して操作を強制することができます。

まだアクティブでないチャンネルやトランジションを更新することはできますか？

はい、指定された開始時刻に達していない場合は、別のPUT操作を実行することでチャンネルやトランジションを変更できます（例：新しいSMILプレイリストを提供する）。既存のチャンネルやトランジションは完全に上書きされます。

マニフェスト編集（Manifest Edit）

Manifest Editが必要な編集を実行できるかどうかを知るにはどうすればよいですか？

Plugins Library の章を読むことをお勧めします。あなたのニーズを満たすプラグインを探し、その詳細や設定方法を確認し、必要な編集が実行できるかどうかを確認してください。

もしあなたのユースケースがまだサポートされていない場合は、support@unified-streaming.com または feedback@orca.co.jp までご連絡ください。私たちは常にフィードバックや新しいユースケースを求めており、プラグインライブラリの拡充に努めています。

yamlパイプライン構成ファイルが正しいかどうかをどのように知ればよいですか？

ベースチャンネルまたはバリアントのいずれかのパイプライン作成エンドポイントにPUTすると、APIはパイプライン構成ファイルに対して可能なすべてのチェックを実行します。200 OKステータスが返されると、パイプラインが正しいことが確認され、再生URIにアクセスしたときに機能します。

マニフェストがManifest Editを通過したことを確認する方法は？

Manifest Editを通過した各マニフェストには、ヘッダーに追加のコメントセクションがあり、パイプライン構成ファイルの内容全体が報告されます。たとえば：

<!-- Original: Created with Unified Streaming Platform (version=1.11.22-28062) Edited by Manifest Proxy
Edited by Unified manifest-edit, using the following pipeline:
mpd:
- manifest_edit.plugins.mpd.descriptor_add:
    # This plugin will add an UTCTiming tag to manifests that do not already
    # have one. You can choose the scheme by selecting one of the following:
    # one or more of the following:
    #  http-iso
    #  http-xsdate
    #  http-ntp
    #  ntp
    #  http-head
    #  direct
    # Additionally, you must provide the value that will be used, in the
    # format required by the scheme you have selected.
    plugin_config:
      name: "UTCTiming"
      schemeIdUri: "urn:mpeg:dash:utc:ntp:2014"
      value: 'https://time.akamai.com/?ntp'

-->

そのセクションが存在する場合、マニフェストは言及されたパイプラインを通過しており、それ以外の場合は通過していません。

Manifest Editがマニフェストを全く変更しないようです。何をチェックすべきですか？

推奨されるチェックリストは：

• パイプラインPUT操作が200 OKを返すことを確認します

• 正しいURIからマニフェストを取得していることを確認します（ベースチャンネルURIまたは ?python_pipeline_config={variant} クエリパラメータを使用している場合は、変種PUTエンドポイント）

• マニフェストがパイプラインを通過していることを確認するために、Unified manifest-editによって編集 というコメントヘッダーが存在するかどうかを確認します

• 上記が正しい場合、ヘッダーに報告されているパイプラインが期待しているものであることも確認してください

• パイプラインのプラグイン構成セクションにタイプミス/間違いがないかを確認します。ほとんどのプラグインは、特定の要素（トラック、適応セットなど）を編集するために、要素のプロパティ（言語="en"など）に一致する要素を最初に選択します。正規表現にタイプミスがあるか、またはマニフェストに期待される要素が含まれていない場合、パイプラインはマニフェストに影響を与えません。

ベースチャンネルエンドポイントを使用すべきですか、それともバリアントエンドポイントを使用すべきですか？

一般的に、バリアントの使用が推奨されます。バリアントはオーバーヘッドを生じさせず、URIクエリパラメータによってアクティブなマニフェスト編集の使用ケースを一意に識別できます。オリジナルと編集済みのマニフェスト用にURIを分離することで、マニフェストを処理する下流のエンティティのニーズに基づいて、リクエストを最も適したエンドポイントにルーティングすることが可能になります。

ベースチャンネルエンドポイントは、プレイアウトURIにクエリパラメータを含めたくない、または含められない場合に適しています。この場合、選択肢はベースチャンネルエンドポイントの使用のみとなります。注意すべき点として、オリジナルの編集されていないマニフェストへのアクセスを失い、チャンネルに対して1つのマニフェスト編集の使用ケースのみをアクティブにできるようになります。