> This page is for Kamera zu Cloud. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://next.developer.frame.io/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://next.developer.frame.io/_mcp/server. # Leitfaden: Uploads (Echtzeit) ## Einführung Aufbauend auf unseren Grundkenntnissen zum Hochladen wollen wir uns nun damit befassen, wie man Assets in Echtzeit hochlädt, während sie erstellt werden.Mit diesem Ansatz werden Dateien während der Aufnahme, des Renderns oder des Streamings hochgeladen, noch bevor deren endgültige Größe bekannt ist. Die Echtzeit-Upload-API gestattet es, dass Assets bereits wenige Sekunden nach Abschluss der Aufnahme in Frame.io abgespielt werden können, was die Effizienz des Workflows erheblich steigert. ## Demovideo Um sich einen kurzen Überblick über diese Funktion zu verschaffen, sehen Sie sich bitte unsere [Videovorführung](https://f.io/qjwfGmTa) an.Die Demo zeigt, wie ein Rendering in Echtzeit aus Adobe Media Encoder hochgeladen wird, wobei das Video bereits 5 Sekunden nach Abschluss des Renderings in Frame.io abgespielt werden kann. ## Voraussetzungen Wenn Sie es noch nicht getan haben, lesen Sie bitte den Leitfaden [C2C implementieren: Einrichtung](./implementing-c2c-setting-up).Sie benötigen den `access_token`, den Sie während des [Authentifizierungs- und Autorisierungsprozesses](./implementing-c2c-authentication-and-authorization) erhalten haben.Für unsere Beispiele verwenden wir das [Test-Asset](https://f.io/Rq1q5CzB) aus dem Leitfaden zu einfachen Uploads.Es wird empfohlen, sich mit dem [Leitfaden zu einfachen Uploads](./how-to-basic-upload) vertraut zu machen, da wir auf diesen Konzepten aufbauen werden. ## Ein Echtzeit-Asset erstellen Echtzeit-Uploads beginnen mit einem angepassten Verfahren zur Erstellung von Assets.Legen Sie beim Erstellen des Assets `is_realtime_upload` auf `true` fest und lassen Sie den Parameter `filesize` weg (oder setzen Sie ihn auf `null`), da die endgültige Größe zum Zeitpunkt der Erstellung noch nicht bekannt ist: ```shell { curl -X POST https://api.frame.io/v2/devices/assets \ --header 'Authorization: Bearer [access_token]' \ --header 'Content-Type: application/json' \ --header 'x-client-version: 2.0.0' \ --data-binary @- <<'__JSON__' { "name": "C2C_TEST_CLIP.mp4", "filetype": "video/mp4", "is_realtime_upload": true } __JSON__ } | python -m json.tool ``` Die Dokumentation für `/v2/devices/assets` findet sich [hier](/camera-to-cloud/api-reference/device-asset-create). Echtzeit-Assets benötigen eine Dateierweiterung.Falls der Dateiname beim Erstellen des Assets noch nicht bekannt ist, können Sie stattdessen das Feld `Erweiterung` verwenden (Format: `'.mp4'`).Dieser Ansatz ist vorzuziehen, wenn Sie beabsichtigen, den Namen des Assets später zu ändern. Die Vorgehensweise bei der Erstellung von Echtzeit-Assets ist im Vergleich zur Erstellung von Standard-Assets vereinfacht: ```json { "id": "{asset_id}", "name": "C2C_TEST_CLIP.mp4" } ``` Beachten Sie, dass `upload_urls` fehlt – für Echtzeit-Uploads generieren wir die Upload-URLs nach Bedarf, sobald die Datei erstellt wird. ## Upload-URLs anfordern Lassen Sie uns eine URL für die erste Hälfte unserer Datei (10.568.125 Byte) anfordern, wobei wir die `asset_id` aus der vorherigen Antwort verwenden: ```shell { curl -X POST https://api.frame.io/v2/devices/assets/{asset_id}/realtime_upload/parts \ --header 'Authorization: Bearer [access_token]' \ --header 'Content-Type: application/json' \ --header 'x-client-version: 2.0.0' \ --data-binary @- <<'__JSON__' { "parts": [ { "number": 1, "size": 10568125, "is_final": false } ] } __JSON__ } | python -m json.tool ``` Die Dokumentation zu `/v2/devices/assets/{asset_id}/realtime_upload/parts` finden Sie [hier](/camera-to-cloud/api-reference/device-create-realtime-upload-parts). Die Anfrageparameter verstehen: * `parts`: Eine Liste der Upload-Teile, für die wir URLs benötigen.Die Anfrage mehrerer URLs in einem einzigen Aufruf erhöht die Effizienz. * `number`: Die fortlaufende Artikelnummer, beginnend mit 1.Nummern können übersprungen und Teile in beliebiger Reihenfolge hochgeladen werden, sie werden jedoch der Reihe nach zusammengesetzt.Darf 10.000 nicht überschreiten (AWS-Limit).* `size`: Teilgröße in Byte.Die [Einschränkungen für mehrteilige Uploads bei AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts.html) müssen eingehalten werden.* `is_final`: Gibt an, ob es sich um den letzten Dateiteil handelt. Die Antwort enthält die angeforderten Upload-URLs: ```json { "upload_urls": [ "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part_01_path]" ] } ``` Die Liste `upload_urls` entspricht direkt der Reihenfolge der Teileanfragen unter `parts`. Laden Sie nun den ersten Chunk wie im Leitfaden zu einfachen Uploads beschrieben hoch: ```shell head -c 10568125 ~/Downloads/C2C_TEST_CLIP.mp4 | \ curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part_01_path] \ --include \ --header 'content-type: video/mp4' \ --header 'x-amz-acl: private' \ --data-binary @- ``` Fordern Sie als Nächstes eine URL für den zweiten und letzten Teil an: ```shell { curl -X POST https://api.frame.io/v2/devices/assets/{asset_id}/realtime_upload/parts \ --header 'Authorization: Bearer [access_token]' \ --header 'Content-Type: application/json' \ --header 'x-client-version: 2.0.0' \ --data-binary @- <<'__JSON__' { "asset_filesize": 21136250, "parts": [ { "number": 2, "size": 10568125, "is_final": true } ] } __JSON__ } | python -m json.tool ``` Beachten Sie folgende wichtige Ergänzungen: * Für den letzten Teil wird `is_final` auf `true` gesetzt, was bedeutet, dass der Upload nach diesem Chunk abgeschlossen sein wird * `asset_filesize` gibt die gesamte Dateigröße an, die erforderlich ist, wenn ein Teil `is_final: true` hat Nachdem Sie die URL in der Antwort erhalten haben: ```json { "upload_urls": [ "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part_02_path]" ] } ``` Laden Sie den letzten Chunk hoch: ```shell tail -c 10568125 ~/Downloads/C2C_TEST_CLIP.mp4 | \ curl -X PUT https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part_02_path] \ --include \ --header 'content-type: video/mp4' \ --header 'x-amz-acl: private' \ --data-binary @- ``` Sobald der letzte Teil hochgeladen ist, beginnt Frame.io mit der Zusammenführung der vollständigen Datei.Dieser Vorgang umfasst eine Nachfrist von 60 Sekunden, damit noch ausstehende Teile abgeschlossen werden können.Wir empfehlen, den letzten Teil erst dann hochzuladen, wenn alle anderen Teile erfolgreich hochgeladen wurden. Das ist alles!Rufen Sie Frame.io auf, um Ihr erfolgreich hochgeladenes Echtzeit-Asset anzuzeigen.🎉 ## Asset-Namen verwalten Falls der Dateiname bei der Erstellung des Assets noch nicht bekannt ist, können Sie das Feld `extension` ohne `name` verwenden: ```shell { curl -X POST https://api.frame.io/v2/devices/assets \ --header 'Authorization: Bearer [access_token]' \ --header 'Content-Type: application/json' \ --header 'x-client-version: 2.0.0' \ --data-binary @- <<'__JSON__' { "extension": ".mp4", "filetype": "video/mp4", "is_realtime_upload": true } __JSON__ } | python -m json.tool ``` Das System weist dann einen Standardnamen zu: ```json { "id": "{asset_id}", "name": "[new file].mp4" } ``` Sie können diesen Namen aktualisieren, indem Sie bei der Anfrage von Upload-URLs ein Feld `asset_name` angeben: ```shell { curl -X POST https://api.frame.io/v2/devices/assets/{asset_id}/realtime_upload/parts \ --header 'Authorization: Bearer [access_token]' \ --header 'Content-Type: application/json' \ --header 'x-client-version: 2.0.0' \ --data-binary @- <<'__JSON__' { "asset_name": "C2C_TEST_CLIP.mp4", "asset_filesize": 21136250, "parts": [ { "number": 2, "size": 10568125, "is_final": true } ] } __JSON__ } | python -m json.tool ``` Der Name wird nur aktualisiert, wenn das Asset noch seinen Standardnamen trägt; wurde es in der Frame.io-Benutzeroberfläche umbenannt oder bereits zuvor aktualisiert, wird die Anfrage ignoriert. ## URL-Anfragen optimieren Um die Effizienz zu steigern, rufen Sie die URLs für so viele Teile ab, wie Ihnen derzeit Daten vorliegen, anstatt sie einzeln abzufragen.Dieser Ansatz ist besonders bei großen Dateien von Vorteil, bei denen die Upload-Geschwindigkeit hinter der Datengenerierung zurückbleiben könnte. ## Header für Mediendateien verarbeiten Bei einigen Medienformaten sind am Anfang der Datei Header erforderlich, die erst geschrieben werden, wenn die gesamte Datei vollständig ist.Dies stellt eine Herausforderung dar, wenn der Header kleiner ist als die von AWS festgelegte Mindestgröße von 5 MiB (5.242.880 Byte). Unsere Empfehlung: 1. Reservieren Sie die ersten 5.242.880 Byte der Mediendaten, ohne sie hochzuladen 2. Beginnen Sie mit dem Hochladen der Teile, beginnend mit `part_number=2` 3. Wenn die Datei vollständig ist, stellen Sie den Header an den Anfang der reservierten Daten 4. Fordern Sie eine URL für `part_number=1` an und laden Sie diesen kombinierten Chunk hoch Dieser Ansatz stellt sicher, dass Ihr erster Chunk die Mindestgrößenanforderung erfüllt und gleichzeitig die korrekte Dateistruktur beibehalten wird. ## Teilgröße für optimale Leistung skalieren AWS legt Limits fest, die sich auf die Upload-Strategie auswirken: * Maximale Dateigröße: 5 TiB (5.497.558.138.880 Byte) * Maximale Anzahl Teile: 10.000 * Minimale Teilgröße: 5 MiB (5.242.880 Byte) Eine feste Teilgröße schafft Kompromisse: * Bei Verwendung der Mindestgröße (5 MiB) für alle 10.000 Teile wird die Gesamtdateigröße auf ca. 52,4 GB begrenzt * Um die maximale Dateigröße gleichmäßig zu verteilen, wären Chunks von etwa 550 MB erforderlich, die für ein effizientes Streaming kleinerer Dateien zu groß sind Wir benötigen eine Formel, die diese Begrenzungen in Einklang bringt: Sie sollte zunächst kleine Teile für responsive Uploads nutzen und gleichzeitig sicherstellen, dass wir bei Bedarf auch sehr große Dateien verarbeiten können. ### Empfohlene Formel für die Teilgröße Hier ist unser Lösungsvorschlag in Python: **`Python`** ```python title="Python" import math from typing import Callable # Constants MINIMUM_PART_SIZE = 5_242_880 MAXIMUM_PART_COUNT = 10_000 MAXIMUM_FILE_SIZE = 5_497_558_138_880 # Maximum uniform data rate that allows for 10,000 parts MAXIMUM_DATA_RATE = MAXIMUM_FILE_SIZE // MAXIMUM_PART_COUNT def part_size(part_number: int, format_bytes_per_second: int) -> int: """ Returns the payload size for a specific part number given the file's expected data rate. """ if part_number < 1: raise ValueError("part_number must be greater than 0") if part_number > 10_000: raise ValueError("part_number must be less than 10,000") # Make sure we never go above the maximum data rate or fall below the # minimum part size, even if the data rate is lower. data_rate = min(format_bytes_per_second, MAXIMUM_DATA_RATE) data_rate = max(data_rate, MINIMUM_PART_SIZE) # Calculate a scalar given our data rate. We will explain this step # futher on in the guides. scalar = -(2 * (125 * data_rate - 68_719_476_736)) / 8_334_583_375 part_size = math.floor(scalar * pow(part_number, 2)) + data_rate return part_size ``` ... wobei `part_number` zwischen `1` und `10_000` (einschließlich) liegt und `format_bytes_per_second` die voraussichtliche durchschnittliche Anzahl an Bytes angibt, die Ihre Datei pro Sekunde verbrauchen wird.Wir werden später noch [näher darauf eingehen](/camera-to-cloud/how-to-upload-realtime#showing-our-work), wie man zu dieser Formel gelangt ist. Die Variable `scalar` und die Berechnung mögen auf den ersten Blick etwas verwirrend wirken, doch handelt es sich um ein mathematisches Hilfsmittel, das sicherstellt, dass wir – unabhängig davon, welchen Wert wir für `format_bytes_per_second` verwenden – bei Eingabe aller zulässigen Werte für `part_number` von `1` bis `10_000` in die Funktion eine Reihe von Werten erhalten, deren Summe *genau* unserem Dateigrößenlimit von 5 TiB entspricht – nun ja, so genau wie möglich.Im Folgenden [erläutern wir näher](/camera-to-cloud/how-to-upload-realtime#showing-our-work), wie wir zu dieser Formel gelangt sind. Durch die Verwendung der Abrundung auf die nächste ganze Zahl lassen wir zwar einige Bytes ungenutzt, stellen jedoch sicher, dass eine reguläre Rundung bei Werten über 10.000 nicht versehentlich dazu führt, dass wir unsere maximal zulässige Dateigröße überschreiten.Auf diese Weise bleiben höchstens 10.000 Byte bzw. 10 KB ungenutzt – ein akzeptabler Kompromiss. Die wesentlichen Merkmale dieser Formel sind: * Beim Hochladen von 10.000 Teilen wird die Gesamtdatenmenge weniger als 10 KB unter unserem Dateigrößenlimit von 5 TiB liegen. * Optimiert zu Beginn auf kleinere, effizientere Payloads, um die Reaktionsgeschwindigkeit bei kurzen und mittellangen Clips zu erhöhen. * Bei sehr langen Clips kommt es zu einer verzögerten Reaktionszeit zwischen dem Ende des Schreibvorgangs und dem Zeitpunkt, zu dem der Clip im Frame wiedergegeben werden kann. Der Kompromiss zwischen dem zweiten und dritten Punkt wird dadurch gemildert, dass die meisten Clips nicht die Größe erreichen, bei der Punkt drei zum Tragen kommt.Wir tauschen eine verbesserte Reaktionsgeschwindigkeit bei den *MEISTEN* Dateien gegen eine geringere Reaktionsgeschwindigkeit bei einigen wenigen ein. Eine weiterentwickelte und effizientere Version unserer Formel (die eine anonyme Funktion `part_size_calculator` generiert, in der unser statischer Skalar und die Datenrate bereits vorberechnet und integriert sind) könnte wie folgt aussehen: **`Python`** ```python title="Python" def create_part_size_calculator(format_bytes_per_second: int) -> Callable[[int], int]: """ Returns a function that takes in a `part_number` and returns a `part_size` based on `data_rate`. """ # Make sure we never go above the maximum data rate or fall below the # minimum part size, even if the data rate is lower. data_rate = min(format_bytes_per_second, MAXIMUM_DATA_RATE) data_rate = max(data_rate, MINIMUM_PART_SIZE) static_scalar = -(2 * (125 * data_rate - 68_719_476_736)) / 8_334_583_375 def part_size_calculator(part_number: int) -> int: """Calculates size in bytes of upload for `part_number`.""" if part_number < 1: raise ValueError("part_number must be greater than 0") if part_number > 10_000: raise ValueError("part_number must be less than 10,000") return math.floor(static_scalar * pow(part_number, 2) + data_rate) return part_size_calculator ``` ### Wie sich die Formel bewährt. Betrachten wir die Ausgabeeigenschaften der obigen Formel für verschiedene gängige Dateiformate. **Beispiel 1**: Webformat Bei im Web abspielbaren Formaten mit einer Bitrate von ca. 5,3 MB/s oder weniger (die meisten H.264-/H.265-/HEVC-Dateien) ergibt sich folgende Entwicklung der Payload-Größe: | Teile insgesamt | Payload in Byte | Payload in MB | Gesamte Datei in Byte | Gesamte Datei in GB | | ----------: | ------------: | ---------: | ----------------: | -------------: | | 1 | 5.242.896 | 5,2 MB | 5.242.896 | 0,0 GB | | 1000 | 21575817 | 21,6 MB | 10695361357 | 10,7 GB | | 5000 | 413566329 | 413,6 MB | 706957655928 | 707,0 GB | | 10000 | 1638536679 | 1.638,5 MB | 5497558133921 | 5.497,6 GB | **Table columns key** (Legende zu den Tabellenspalten) – `Total Parts` (Teile insgesamt): Die Gesamtzahl der auf AWS hochgeladenen Dateiteile.- `Payload Bytes` (Payload in Byte): Die Größe der AWS-PUT-Payload, wenn `part_number` dem Wert von `Total Parts` entspricht.- `Payload MB` (Payload in MB): Wie `Payload Bytes`, aber in Megabyte.- `Total File Bytes` (Gesamte Datei in Byte): Die Gesamtzahl der Bytes, die für die Datei hochgeladen wurden, wenn die `Total Parts` als aufeinanderfolgende Teile hochgeladen wurden.- `Total File GB` (Gesamte Datei in GB): Wie `Total File Bytes`, aber in GB. Diese Werte sind für Echtzeit-Uploads gut ausbalanciert, insbesondere bei Codecs für die Web-Wiedergabe wie H.264; die meisten liegen unter 10,7 GB und sind daher innerhalb von 1.000 Teilen abgeschlossen.Die Payload-Größe würde niemals 21,6 MB überschreiten. Wenn wir uns durch die Hälfte unserer Teile durcharbeiten würden, würde die Payload-Größe dennoch niemals 413,5 MB überschreiten.Der Upload würde insgesamt 707 GB betragen, was für die allermeisten Webdateien mehr als ausreichend ist. Erst wenn wir uns dem Ende unserer zulässigen Teileanzahl nähern, beginnt die Dateigröße, stark anzusteigen.Allerdings überschreitet sie niemals 1,7 GB und liegt damit deutlich unter dem AWS-Limit von 5 GiB pro Teil. **Beispiel 2**: Prores 422 LT Prores 422 LT [hat eine Datenrate von 102 MBit/s](https://www.wolframalpha.com/input?i=-%282+%28-68%2C719%2C476%2C736+%2B+125+12%2C750%2C000%29%29%2F8%2C334%2C583%2C375) und generiert eine Tabelle wie folgt: | Teile insgesamt | Payload in Byte | Payload in MB | Gesamte Datei in Byte | Gesamte Datei in GB | | ----------: | ------------: | ---------: | ----------------: | -------------: | | 1 | 12750016 | 12,8 MB | 12750016 | 0,0 GB | | 1000 | 28857758 | 28,9 MB | 18127308783 | 18,1 GB | | 5000 | 415443954 | 415,4 MB | 735107948432 | 735,1 GB | | 10000 | 1623525817 | 1.623,5 MB | 5497558133958 | 5.497,6 GB | Diese Tabelle zeigt nützliche Eigenschaften im Vergleich zu unserer Web-optimierten Formel auf.Innerhalb der ersten 1.000 Teile können wir 8 GB mehr der Datei hochladen.Größere anfängliche Payloads bedeuten, dass wir zu Beginn nicht zu schnell URLs abfragen müssen, wodurch der Upload bei der höheren Datenrate effizienter wird.Die Größe unserer Payload bleibt gegen Ende des Upload-Vorgangs weiterhin groß. **Beispiel 2**: Camera Raw Probieren wir zum Schluss ein Camera-Raw-Format mit einer Datenübertragungsrate von 280 MB/s aus.Angesichts dieser rasanten Datenübertragung ergibt es einfach keinen Sinn, zu Beginn zu versuchen, die Daten in 5-MiB-Chunks hochzuladen: | Teile insgesamt | Payload in Byte | Payload in MB | Gesamte Datei in Byte | Gesamte Datei in GB | | ----------: | ------------: | ---------: | ----------------: | -------------: | | 1 | 280000008 | 280,0 MB | 280000008 | 0,3 GB | | 1000 | 288091460 | 288,1 MB | 282701200139 | 282,7 GB | | 5000 | 482286516 | 482,3 MB | 1737245341542 | 1.737,2 GB | | 10000 | 1089146065 | 1.089,1 MB | 5497558133870 | 5.497,6 GB | Frühe Payloads sind nicht nur effizienter, sondern wir sparen zudem am oberen Ende über ein halbes Gigabyte ein, wodurch diese Netzwerkaufrufe weniger anfällig für Störungen im Netzwerk sind. ### Unsere Arbeit präsentieren Bevor wir alles in einem Beispiel-Uploader zusammenführen, wollen wir uns zunächst ansehen, wie wir zu unserer Formel gelangt sind. Wir mussten eine Formel entwickeln, bei der große, ressourcenintensive Payloads am Ende der uns zur Verfügung stehenden Teileanzahl – die die meisten Uploads niemals erreichen werden – gegen leichte, effiziente Payloads am Anfang eingetauscht werden, von denen jeder Upload profitieren kann.Gleichzeitig wollten wir sicherstellen, dass unser Algorithmus *genau* bei der Teilenummer 10.000 in den Bereich des Dateigrößenlimits von 5 TiB fällt. Es war an der Zeit, sich mit der Analysis zu befassen. Wir möchten, dass unser Graph exponentiell wächst, daher sollte unsere Formel in etwa so aussehen: ```math n^2 ``` ... wobei `n` die Teilnummer ist.Wir möchten außerdem sicherstellen, dass jeder Teil mindestens die Datenrate unserer Formel erreicht, die wir mit `r` bezeichnen: ```math n^2 + r ``` Nun müssen wir eine Formel finden, die uns die Summe *dieser* Formel für die ersten 10.000 natürlichen Zahlen (1, 2, 3 ...) angibt.Das Sigma-Zeichen `Σ` steht für die Summe.Fügen wir es unserer Formel hinzu: ```math Σxn^2 + r ``` ... und definieren `n` als die Folge der natürlichen Zahlen zwischen 1 und 10.000 (einschließlich).Diese Gleichung ist für uns noch nicht besonders nützlich.Die Formel ist zwar intuitiv richtig, doch wenn wir `n=10,000` und `r=5,242,880` wie gewünscht eingeben, gibt sie [einfach ein Ergebnis aus](https://www.wolframalpha.com/input?i=%CE%A3n%5E2+%2B+r+where+n+%3D+1+to+10%2C000+and+r+%3D+5%2C242%2C880): `385,812,135,000` (385 GB).Das Ergebnis liegt nicht nur weit unter unserer Dateigrößenbeschränkung von 5 TiB, es gibt auch keine Möglichkeit, die Formel so anzupassen, dass sie dieses Ergebnis liefert. Versuchen wir doch einmal, am Rad zu drehen: ```math Σxn^2 + r ``` ... wobei `x` ein Skalar ist, den wir berechnen können, um als Ergebnis 5 TiB zu erhalten.Nun können wir die Gleichung unserem Dateigrößenlimit gleichsetzen und nach `x` lösen: ```math Σxn^2 + r = 5,497,558,138,880 ``` Häufig müssen Summen iterativ berechnet werden, beispielsweise in einer `for`- oder `while`-Schleife.Es stellt sich jedoch heraus, dass es für uns [eine perfekte Formel](https://www.math-only-math.com/sum-of-the-squares-of-first-n-natural-numbers.html) gibt: eine bekannte Methode, um die Summe der Quadrate der ersten `n` natürlichen Zahlen günstig zu berechnen: ```math Σn^2 = n(n+1)(2n+1)/6 ``` Wenn man sie in ein Polynom umformuliert, lässt sie sich leichter überblicken: ```math Σn^2 = (2n^3 + 3n^2 + n)/6 ``` Wir können unsere Variablen `x` und `r` auf beiden Seiten hinzufügen: ```math Σxn^2 + r = x(2n^3 + 3n^2 + n)/6 + rn ``` Und schließlich setzen wir unsere neue Formel gleich 5 TiB: ```math x(2n^3 + 3n^2 + n)/6 + rn = 5,497,558,138,880 ``` Nun müssen wir nur noch `x` berechnen, indem wir `n=10.000` setzen, also unsere Gesamtteilzahl.Auf diese Weise können wir einen statischen Skalar für eine bestimmte Datenrate berechnen.Anstatt dies von Hand zu erledigen, [geben wir es in Wolfram Alpha ein](https://www.wolframalpha.com/input?i=x%282n%5E3+%2B+3n%5E2+%2B+n%29%2F6+%2B+r+*+n+%3D+5%2C497%2C558%2C138%2C880+solve+for+x+where+n+%3D+10%2C000): ```math x = -(2 (125 r - 68719476736)) / 8334583375 ``` Jetzt kommen wir der Sache schon näher!Wenn unsere Datenrate der minimalen Teilgröße (5 MiB) entspräche, [würden wir einen](https://www.wolframalpha.com/input?i=x%282n%5E3+%2B+3n%5E2+%2B+n%29%2F6+%2B+r+*+n+%3D+5%2C497%2C558%2C138%2C880+solve+for+x+where+n+%3D+10%2C000+and+r+%3D+5%2C242%2C880) statischen Skalar erhalten von: ```math 136,128,233,472 / 8,334,583,375 ``` In der Welt der Informatik entspricht dies einem Float64-Wert von `16.33293799427617`.Unsere Formel zur Bestimmung der Teilegröße würde in diesem Fall wie folgt lauten: ```math s = 16.33293799427617n^2 + 5,242,880 ``` Wobei `s` unsere Teilgröße ist. Wir haben noch ein weiteres Problem.In der Praxis ist eine Payload mit nicht ganzzahligen Bytes nicht zulässig.Wir müssen jeden Wert runden.Wir verwenden Python und runden ab: **`Python`** ```python title="Python" math.floor(16.33293799427617 * pow(part_number, 2)) + 5_242_880 ``` Wir sind nun bei einem konkreten Beispiel für die in dieser Anleitung vorgestellte ursprüngliche Funktion angelangt. ## Einen einfachen Uploader aufbauen Werfen wir einen Blick auf einen einfachen, Python-ähnlichen Pseudocode zum Hochladen einer Datei, die in Echtzeit gerendert wird, und nutzen dabei alles, was wir in dieser Anleitung gelernt haben: **`Python`** ```python title="Python" import math from datetime import datetime, timezone from typing import Callable # The minimum size, in bytes, for a single, non-final part upload. MINIMUM_PART_SIZE = 5_242_880 # The maximum filesize in MAXIMUM_PART_COUNT = 10_000 # The maximum size, in bytes, for an AWS upload. MAXIMUM_FILE_SIZE = 5_497_558_138_880 # The data rate at which every part is an equal size, and could not # be any uniformly larger without violating the maximum total file # size if 10_000 parts were to be uploaded. it works out to # ~549.8 MB per payload. By enforcing this we actually never need # to check if a part exceeds the maximum allowed part size, as our # parts will never exceed ~549.8 MB. MAXIMUM_DATA_RATE = MAXIMUM_FILE_SIZE // MAXIMUM_PART_COUNT def create_part_size_calculator(format_bytes_per_second: int) -> Callable[[int], int]: """ Returns a function that takes in a `part_number` and returns a `part_size` based on `data_rate`. """ ... def upload_render(data_stream: DataStream, channel: int = 0) -> None: """ Uploads an asset for data_stream, which is a custom IO class that pulls remaining upload data from an internal buffer or file, depending on how well the upload is keeping pace with the render. Uploads to `channel` """ asset = c2c.asset_create( extension=data_stream.extension, filetype=data_stream.mimetpye, channel=channel, offset=datetime.now(timezone.utc) - data_stream.created_at() ) calculate_part_size = create_part_size_calculator(data_stream.data_rate()) next_part_number = 0 while True: next_payload_size = calculate_part_size(next_part_number) # Waits until one or more chunks worth of data is ready for upload. Cache # whether our data stream has completed writing the file, and the current # number of bytes we have remaining to upload at this time. available_bytes, stream_complete = data_stream.wait_for_available_data( minimum_bytes=next_payload_size ) # Build the list of parts to request based on our available data. parts = [] while available_bytes > 0: payload_size = calculate_part_size(next_part_number) if available_bytes < payload_size and not stream_complete: break payload_size = min(payload_size, available_bytes) parts.append( c2c.RealtimeUploadPart( part_number=next_part_number, part_size=payload_size, is_final=False ) ) available_bytes -= payload_size next_part_number += 1 # If our stream is done writing, mark the last part as final. if stream_complete: parts[-1].is_final = True # Create the part URLs using the C2C endpoint. response = c2c.create_realtime_parts( asset_id=asset.id, asset_name=None if not stream_complete else data_stream.filename, asset_filesize=None if not stream_complete else data_stream.size(), parts=parts ) # Upload each part to its URL. for part, part_url in zip(parts, response.upload_urls): part_data = data_stream.read(bytes=part.size) c2c.upload_chunk(part_data, part_url, data_stream.mimetype) if stream_complete: break ``` Der obige Code veranschaulicht lediglich den grundlegenden Ablauf des Hochladens einer Datei in Echtzeit.In der Praxis muss diese Logik jedoch um [Fehlerbehandlung](/camera-to-cloud/how-to-handle-errors) und [erweiterte Upload](/camera-to-cloud/how-to-advanced-uploads)-Techniken erweitert werden. ## Als Nächstes Echtzeit-Uploads bieten die Möglichkeit, Ihre Integration so responsiv wie möglich zu gestalten, da die Dateien bereits wenige Sekunden nach Abschluss der Aufnahme in Frame.io abgespielt werden können.In einer [späteren Anleitung](/camera-to-cloud/how-to-advanced-uploads) werden erweiterte Upload-Techniken und -Anforderungen behandelt.Auch wenn diese Anleitung ursprünglich für einfache Uploads verfasst wurde, gilt der Großteil der darin enthaltenen Informationen dennoch für Echtzeit-Uploads. Falls Sie dies noch nicht getan haben, empfehlen wir Ihnen, sich an unser Team zu wenden und anschließend mit der nächsten Anleitung fortzufahren.Wir freuen uns darauf, von Ihnen zu hören!