ステップ 1: 出力先のパスを設計する - MediaLive

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ステップ 1: 出力先のパスを設計する

完全な送信先パスをまだ設計していない場合は、この手順を実行します。既にパスを設計している場合は、「ステップ 2: コンソールのフィールドに入力します。」に進みます。

パスを設計するには
  1. ダウンストリームシステムのオペレーションから以前に取得した情報を収集します。

    • ダウンストリームシステムの接続タイプ – Akamai、ベーシック PUT、またはウェブ DAV。

    • ダウンストリームシステムに特別な要件がある場合は、接続フィールドの設定。

    • 配信のプロトコル -HTTP または HTTPS。

    • ダウンストリームシステムが認証リクエストを必要とする場合、ダウンストリームシステムにアクセスするためのユーザー名とパスワードです。これらのユーザー認証情報は、プロトコルではなくユーザー認証に関連することに注意してください。ユーザー認証は、ダウンストリームシステムがリクエストを受け入れるかどうかにまつわることです。プロトコルは、リクエストが安全な接続を介して送信されるかどうかに関するものです。

    • ファイル名を含む送信先パスの全部または一部。

    • 個別のサブディレクトリを設定する必要があるかどうか。

  2. ダウンストリームシステムのオペレータとの計画の一環として、冗長マニフェストを実装するかどうかを決定する必要があります。ダウンストリームシステムでカスタムマニフェストが必要かどうかも判断する必要があります。これら 2 つの決定を考慮して、該当するセクションを読んでください。

    • 冗長マニフェストを実装する場合は、「冗長な HLS マニフェスト」を読んでからこのセクションに戻ってください。

    • マニフェストのカスタムパスを実装する場合は、「HLS マニフェスト内のパスのカスタマイズ」を読んでからこのセクションに戻ってください。

    • これらの機能を実装していない場合は、このセクションを続けてお読みください。

  3. バケットに続く送信先パスの部分を設計します。詳細については、以下のセクションを参照してください。

出力のパスの構文

次の表では、これらの 3 つのカテゴリのファイルの送信先パスを構成する部分について説明します。

これら 3 つのカテゴリのファイルの送信先パスは、 まで同一です。つまりbaseFilename、 はこれらのカテゴリのファイルをすべて同じフォルダ thatMediaLive に送信します。修飾子とファイル拡張子は、ファイルのカテゴリごとに異なります。

File パスの構文
メインマニフェストファイル プロトコルドメインパス baseFilename 拡張

/index というファイル名のメインマニフェストURLの :

http://203.0.113.55/sports/delivery/curling/index.m3u8
子マニフェストファイル プロトコルドメインパス baseFilename nameModifier拡張 出力URLの高解像度レンディションの子マニフェストの 。

http://203.0.113.55/sports/delivery/curling/index-high.m3u8

メディアファイル (セグメント) protocol domain path baseFilename nameModifier optionalSegmentModifier counter extension

230 番目のセグメントの URLファイルの は、次のようになります。

http:// 203.0.113.55/sports/delivery/curling/index-high-00230.ts

これらの送信先パスは、次のように構築されます。

  • ダウンストリームシステムのオペレータからプロトコル、ドメイン、およびパスの一部が提供さているはずです。例:

    http://203.0.113.55/sports/

    プロトコルは常に HTTPまたは ですHTTPS。

  • オペレータは以下を提供した可能性があります。それ以外の場合は、以下を決定します。

    • フォルダ

    • の baseFilename

    • 修飾子

    • は segmentModifier

    次のセクションを参照してください。

  • MediaLive はカウンターの前にアンダースコアを挿入します。

  • MediaLive はカウンターを生成します。カウンターは常に 00001 から 5 桁です。

  • MediaLive は、拡張子の前にドットを挿入します。

  • MediaLive は拡張機能を選択します。

    • マニフェストファイルの場合 — 常に .m3u8

    • メディアファイル.tsの場合 — トランスポートストリーム内のファイルの場合、および fMP4 コンテナ内のファイル.mp4の場合

フォルダと の設計 baseFilename

出力先パスの folder および baseFilename 部分については、次のガイドラインに従ってください。

  • 単一パイプラインチャンネルの場合、baseFilename は 1 つだけ必要です。

  • 標準チャンネルについて、冗長マニフェストを実装しない場合は、2 つの baseFilenames が必要です。2 つの baseFilenames は、同じものでも異なるものでもかまいません。異なる baseFilenames を作成するときは、ダウンストリームシステムがその設定で機能することをあらかじめ確認します。

  • 標準的なチャンネルで冗長マニフェストを実装 する場合は、冗長マニフェストのフィールド を参照してください。

の設計 nameModifier

ファイル名の nameModifier 部分を設計します。子マニフェストとメディアファイルでは、ファイル名にこの修飾子が含まれています。この nameModifier は、個々の出力を区別するため、各出力で一意である必要があります。次のガイドラインに従ってください。

  • 動画 (および他のストリーム) の出力については、通常、動画を記述します。例えば、-high または -1920x1080-5500kpbs (解像度とビットレート)。

  • オーディオのみ、または字幕のみの出力の場合は、通常、オーディオまたは字幕を記述します。例えば、-aac-webVTT などです。

  • baseFilenamenameModifier を明確に分けるため、区切り文字を含めることをお勧めします。

  • nameModifier には、データ変数を含めることができます。

の設計 segmentModifier

送信先パスの segmentModifiers 部分を設計します。 segmentModifier はオプションで、含める場合はメディアファイル名のみが含まれます。

この修飾子の標準的な用途は、データ変数を使用してタイムスタンプを作成し、チャンネルの再開時にセグメント同士の上書きを防ぐことです。例えば、タイムスタンプ $t$- を含めるとします。セグメント 00001 の名前は /index-120028-00001 です。数分後に出力が再開した場合 (それにより、セグメントカウンターが再始動する)、新しいセグメント 00001 の名前は /index-120039-00001 になります。新しいファイルは、元のセグメント 00001 のファイルを上書きしません。ダウンストリームシステムによっては、この動作が上間しい場合があります。