方法:アップロード(リアルタイム)
方法:アップロード(リアルタイム)
はじめに
アップロードに関する基本的な知識に基づいて、アセットの作成中にリアルタイムでアップロードする方法を確認しましょう。この手法では、最終サイズが判明する前に、録画、レンダリング、またはストリーミング中にファイルをアップロードできます。
リアルタイムアップロード API を使用すると、録画完了からわずか数秒でアセットが Frame.io で再生可能となり、ワークフローの効率が大幅に向上します。
デモビデオ
この機能の手短なプレビューについては、動画デモをご覧ください。デモでは、Adobe Media Encoder からリアルタイムでレンダリングがアップロードされ、レンダリング完了後わずか 5 秒でビデオが Frame.io で再生可能となる様子を示しています。
前提条件
まだの場合は、C2C の実装:設定ガイドをご確認ください。
認証および承認プロセス中に、access_token の取得が必要になります。
例として、基本アップロードガイドと同じテスト用アセットを使用します。
これらの概念を基に説明していくため、基本アップロードガイドを精読しておくことをお勧めします。
リアルタイムアセットの作成
リアルタイムアップロードは、変更されたアセット作成プロセスから始まります。アセットの作成時には最終的なサイズが不明なため、is_realtime_upload を true に設定し、filesize パラメーターを省略(または null に設定)します。
API endpoint specification
Documentation for /v2/devices/assets can be found here.
Extension and filename
Real-time assets require a file extension. If the filename isn’t known when creating the asset, you can use the extension field instead (format: '.mp4'). This approach is preferred when you plan to update the asset name later.
リアルタイムアセットに対する応答は、標準的なアセット作成と比較すると簡略化されています。
upload_urls が存在しないことに注意してください。リアルタイムアップロードの場合、ファイルの作成時にオンデマンドでアップロード URL が生成されます。
アップロード URL の要求
以前の応答の asset_id を使用して、ファイルの前半(10,568,125 バイト)の URL を要求してみましょう。
API endpoint specification
Documentation for /v2/devices/assets/{asset_id}/realtime_upload/parts can be found here.
要求パラメーターについて:
parts:URL が必要なアップロードパートのリスト。1 回の呼び出しで複数の URL を要求すると、効率性が向上します。number:1 から始まる連番のパート番号。数字はスキップでき、パーツは任意の順序でアップロードされますが、連続的に統合されます。10,000 を超えることはできません(AWS の制限)。size:バイト単位のパートサイズ。AWS S3 マルチパートアップロードの制限事項に準拠している必要があります。is_final:これが最後のファイルパートであるかどうかを示します。
応答には、要求されたアップロード URL が含まれます。
upload_urls リストは parts 要求の順序に直接対応しています。
次に、基本アップロードガイドに従って、最初のチャンクをアップロードします。
次に、2 番目と最後のパートの URL を要求します。
次の重要な追加事項に注意してください。
- 最後のパートの
is_finalはtrueに設定されており、このチャンクの後にアップロードが完了することを示しています asset_filesizeは、パートにis_final: trueがある場合の必要な合計ファイルサイズを示します
応答で URL を受信した後、次の手順に従います。
最後のチャンクをアップロードします。
Final part handling
When the final part is uploaded, Frame.io begins assembling the complete file. This process includes a 60-second grace period for any remaining parts to complete. We recommend uploading the final part only after all other parts have been successfully uploaded.
以上です。Frame.io に移動して、正常にアップロードされたリアルタイムアセットを確認します。🎉
アセット名の管理
アセットの作成時にファイル名が不明な場合は name を指定せずに、extension フィールドを使用できます。
システムでデフォルトの名前が割り当てられます。
アップロード URL を要求する際に asset_name フィールドを含めることで、この名前を更新できます。
名前は、アセットがデフォルト名のままになっている場合にのみ更新されます。Frame.io UI で名前が変更されている場合、または以前に更新された場合、要求は無視されます。
URL 要求の最適化
効率性を向上するために、個別にではなく、現在データが利用可能なパートの数だけ URL を要求します。この方法は、アップロード速度がデータ生成よりも遅くなる可能性がある大容量ファイルに特に便利です。
メディアファイルヘッダーの処理
一部のメディア形式では、ファイル全体が完了するまで書き込まれないヘッダーがファイルの先頭に必要となります。この場合、ヘッダーが AWS の最小パートサイズである 5 MiB(5,242,880 バイト)よりも小さい場合に問題が発生します。
当社の推奨事項:
- メディアデータの最初の 5,242,880 バイトをアップロードしないでおきます
part_number=2で始まるパートのアップロードを開始します- ファイルが完了したら、予約済みデータにヘッダーを追加します
part_number=1の URL を要求し、この結合されたチャンクをアップロードします
この方法により、最初のチャンクの最小サイズ要件を満たしながら、適切なファイル構造を維持できます。
最適なパフォーマンスのためのパートサイズの調整
AWS では、アップロード戦略に影響する次の制限が設けられています。
- 最大ファイルサイズ:5 TiB(5,497,558,138,880 バイト)
- パートの最大数:10,000
- 最小パートサイズ:5 MiB(5,242,880 バイト)
サイズを固定すると、トレードオフが生じます。
- 10,000 個のパートすべてに最小サイズ(5 MiB)を使用すると、合計ファイルサイズが 52.4 GB 以下に制限されます
- 最大ファイルサイズを均等に分散するには、550 MB 以下のチャンクが必要となり、小さいファイルを効率的にストリーミングするには大きすぎます
これらの制約のバランスを取るための数式が必要です。レスポンシブアップロードの小さなパートから始め、必要に応じて非常に大きなファイルを処理できるようにします。
推奨されるパートサイズの式
Python で推奨される方法は次のとおりです。
… part_number は 1~10_000 で、format_bytes_per_second はファイルが 1 秒あたりに消費すると予想される平均バイト数です。この式の計算方法については、後で詳しく説明します。
Scalar value
The scalar variable and calculation might be a little perplexing at first glance, but it is a mathematical tool that ensures no matter what value we use for format_bytes_per_second, if we feed all allowed part_number values from 1 to 10_0000 into the function, we will receive a set of values that totals to exactly our 5 TiB filesize limit — well, as exactly as possible. We show our work further in on how we came to this formula.
Floor Rounding
By using floor rounding, we leave some bytes on the table, but ensure that regular rounding over 10,000 part does not accidentally cause us to exceed our maximum allowed filesize. At most, 10,000 bytes, or 10 KB will be left on the table this way, an acceptable tradeoff.
この式の重要な特徴は次のとおりです。
- 10,000 のパートをアップロードする場合、アップロードされるデータの合計量は、5 TiB のファイルサイズ制限の 10 KB 以内になります。
- 最初のうちはペイロードを効率的な小さめに最適化し、短いクリップや中程度の長さのクリップでの応答性を向上させます。
- 非常に長いクリップでは、ファイルの最後のパートが書き込まれてからフレーム内で再生可能になるまでの応答性が低下します。
ほとんどのクリップは 3 番目が影響を及ぼし始めるサイズに達しないことから、2 番目を取ることによるトレードオフは軽減されます。ごく少数のファイルの応答性の低下と引き換えに、大部分のファイルの応答性の向上を達成しています。 **
この式のより高度で効率的なバージョン(静的スカラーとデータレートを事前計算して組み込んだ匿名 part_size_calculator 関数を生成)は、次のようになります。
式の性能
いくつかの一般的なファイル形式について、上式の出力の特徴を調べてみましょう。
例 1:Web 形式
約 5.3 MB/秒以下の web 再生可能な形式(ほとんどの H.264/H.265/HEVC ファイル)の場合、ペイロードサイズの増加は次のようになります。
テーブル列キー
Total Parts:AWS にアップロードされたファイルパートの合計数。Payload Bytes:part_numberがTotal Partsに等しい場合の AWS PUT ペイロードのサイズ。Payload MB:Payload Bytesはメガバイト単位で表示されます。Total File Bytes:Total Parts順次パートがアップロードされたときに、ファイルでアップロードされた合計バイト数。Total File GB:Total File Bytesは GB 単位で表示されます。
これらの値は、リアルタイムアップロード、特に H.264 などの web 再生コーデックの場合に適切にバランスがとれています。ほとんどは 10.7 GB 未満であるため、1,000 パート以内で完了します。ペイロードサイズは 21.6 MB を超えることはありません。
パートの半分まで進んだとしても、ペイロードサイズは 413.5 MB を超えることはありません。アップロードの合計は 707 GB で、多くの web ファイルに十分な容量です。
許容されるパート数の終わりに近づくと、ファイルサイズが急増し始めます。ただし、1.7 GB を超えることはなく、AWS の制限であるパートあたり 5 GiB を大幅に下回っています。
例 2: Prores 422 LT
ProRes 422 LT のデータレートは 102 Mbps で、次のようなテーブルを生成します。
このテーブルは、web 用に最適化された数式と比較した有用な特性を示しています。最初の 1,000 個のパート内で、8 GB のファイルをアップロードできます。初期ペイロードが大きいほど、最初に URL を要求する必要がなくなり、データレートが高くなるほどアップロードの効率性が向上します。アップロードプロセスの最終段階におけるペイロードサイズは引き続き大きくなります。
例 2:Camera Raw
最後に、280MB/s のデータレートの Camera Raw 形式を試してみましょう。データがこれほど高速になると、最初に 5 MiB チャンクでアップロードしようとするのは意味を成さなくなります。
初期のペイロードがより効率的になるだけでなく、上位設定では 0.5 ギガ以上を節約しているため、ネットワーク呼び出しがネットワークイベントの悪影響を受けにくくなります。
仕事の成果
サンプルアップローダーにすべてをまとめる前に、まずどのようにしてこの数式にたどり着いたのかを確認しましょう。
ここで必要なのは、許可されたパートの最後に大きく重いペイロード(ほとんどのアップロードで到達不可能)を引き換えに、最初の部分で軽量かつ効率的なペイロードを取得するため数式を考え出すことでした。この計算式では、すべてのアップロードでメリットが得られます。同時に、アルゴリズムで約 5 TiB のファイルサイズ制限(パート番号は **10,000)を達成したいと考えました。
微積分を解き明かす時が来ました。
グラフを飛躍的に成長させるための数式は次のようになります。
…n はパート番号です。各パートが少なくとも数式のデータレート(r と呼びます)であることも確認します。
ここで、最初の **10,000 個の自然数(1,2,3,…)に対するこの式の和を示す式を見つける必要があります。シグマ Σ 記号は和を表します。これを数式に追加しましょう。
1~10,000 の間の一連の自然数として n を再定義します。
この方程式はこの時点では、まだあまり役立ちません。直観的ですが、n=10,000 と r=5,242,880 に設定すると、次のような結果385,812,135,000(385 GB)が出ます。結果はファイルサイズの上限である 5 TiB をはるかに下回るだけでなく、式を操作してこの結果を出す方法もありません。
それでは解いていきましょう。
…x は、結果として 5 TiB を得るために解くことができるスカラーです。次に方程式をファイルサイズ制限に等しく設定し、x を解くことができます。
多くの場合、和は for または while ループのように反復的に解く必要があります。しかし結果として、完璧な公式があることがわかりました。これは、最初の n 自然数の二乗の和を簡単に計算する方法として知られています。
多項式として再配置すると、分かりやすくなります。
変数の x と r を次のように両側に追加できます。
最後に、新しい数式を 5 TiB と等しくなるように設定します。
後は、合計パート数を n=10,000 に設定してx を解くだけです。これにより、指定されたデータレートの静的スカラーを計算できます。
これを手作業で行う代わりに、Wolfram Alpha に接続してみましょう。
ゴールに近くなってきました。データレートが最小パートサイズ(5 MiB)の場合、静的スカラーは次のようになります。
計算の世界では、これは 16.33293799427617 の float64 値を表します。この例では、パートサイズを決定する数式は次のようになります。
ここでは、s はパートサイズを意味します。
まだ問題が 1 つあります。実環境では、非整数バイトのペイロードを持つことはできません。各値を四捨五入する必要があります。Python を使用して、以下のように切り捨てます。
このガイドに記載されている元の関数の具体的な例にたどり着きました。
基本的なアップローダーの構築
このガイドのすべての学習内容を活用して、リアルタイムでレンダリングされるファイルをアップロードするための、Python のような簡単な疑似コードをいくつか見てみましょう。
Advanced uploading
The code above only demonstrates the basic flow of uploading a file in real time. In reality, this logic will need to be enhanced with error handling and advanced upload techniques.
次のステップ
リアルタイムアップロードにより、統合の応答性を可能な限り高めることができます。アセットは、記録が完了してから数秒後に Frame.io で再生可能になります。後述のガイドでは、高度なアップロードテクニックと要件について説明します。ガイドの説明は基本アップロードを念頭に置いて書かれていますが、ガイドの大部分はリアルタイムアップロードにも適用できます。
まだの場合は、当社チームにお問い合わせください。そのうえで、次のガイドに進んでください。ご連絡をお待ちしております。