> This page is for Camera to 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.

# Comment effectuer un chargement (en temps réel)

## Présentation





En nous appuyant sur nos connaissances de base sur le chargement, explorons le chargement de ressources en temps réel pendant leur création. Cette approche permet de charger des fichiers pendant l’enregistrement, le rendu ou le streaming avant de connaître leur taille finale.





L’API de chargements en temps réel permet aux ressources d’être lisibles dans Frame.io quelques secondes seulement après la fin de l’enregistrement, ce qui améliore considérablement l’efficacité du workflow.





## Vidéo de démonstration

Pour un aperçu rapide de cette fonctionnalité, regardez notre [vidéo de démonstration](https://f.io/qjwfGmTa). La vidéo de démonstration montre le chargement d’un rendu depuis Adobe Media Encoder en temps réel, la vidéo étant lisible dans Frame.io seulement 5 secondes après la fin du rendu.

## Conditions préalables

Si vous ne l’avez pas encore fait, consultez le guide [Implémentation C2C : configuration](./implementing-c2c-setting-up). Vous aurez besoin de l’élément `access_token` obtenu au cours du [processus d’authentification et d’autorisation](./implementing-c2c-authentication-and-authorization). Nous utiliserons la même [ressource de test](https://f.io/Rq1q5CzB) que dans le guide de chargement de base pour nos exemples. Une connaissance du [guide de chargement de base](./how-to-basic-upload) est recommandée, car nous nous appuierons sur ces concepts.

## Création d’une ressource en temps réel

Les chargements en temps réel commencent par un processus de création de ressource modifié. Lors de la création de la ressource, définissez `is_realtime_upload` sur `vrai` et omettez le paramètre `filesize` (ou définissez-le sur `null`), car la taille finale n’est pas connue lors de la création :

```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
```




<Info title="Spécification de point d’entrée de l’API">
  [Rendez-vous sur cette page](/camera-to-cloud/api-reference/device-asset-create) pour consulter la documentation `/v2/devices/assets`.
</Info>

<Warning title="Extension et nom de fichier">
  Les ressources en temps réel nécessitent une extension de fichier. Si le nom de fichier n’est pas connu lors de la création de la ressource, vous pouvez utiliser le champ `extension` à la place (format : `’.mp4’`). Cette approche est préférable lorsque vous prévoyez de mettre à jour le nom de la ressource plus tard.
</Warning>


La réponse pour les ressources en temps réel est simplifiée par rapport à la création de ressource standard :





```json
{
    "id": "{asset_id}",
    "name": "C2C_TEST_CLIP.mp4"
}
```

Notez que `upload_urls` est absent. Pour les chargements en temps réel, nous générerons les URL de chargement à la demande pendant la création du fichier.

## Demande d’URL de chargement

Demandez une URL pour la première moitié du fichier (10 568 125 octets), en utilisant le paramètre `asset_id` de la réponse précédente :

```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
```




<Info title="Spécification de point d’entrée de l’API">
  [Rendez-vous sur cette page](/camera-to-cloud/api-reference/device-create-realtime-upload-parts) pour consulter la documentation `/v2/devices/assets/{asset_id}/realtime_upload/parts`.
</Info>


Comprendre les paramètres de requête :




* `parts` : une liste des parties de chargement pour lesquelles nous avons besoin d’URL. Demandez plusieurs adresses URL au sein d’un appel unique pour améliorer l’efficacité.

* `number` : le numéro de partie séquentiel, commençant à 1. Les numéros peuvent être ignorés et les parties chargées dans n’importe quel ordre, mais elles seront assemblées de manière séquentielle. Ne peut pas dépasser 10 000 (limite AWS). * `size` : taille de la partie en octets. Doit respecter les [restrictions de chargement multi-parties AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts.html). * `is_final` : indique s’il s’agit de la partie finale du fichier.

La réponse contient les URL de chargement demandées :





```json
{
    "upload_urls": [
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part_01_path]"
    ]
}
```

La liste `upload_urls` correspond directement à l’ordre de la requête `parts`.

Chargez maintenant le premier bloc comme dans le guide de chargement de base :





```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 @-
```





Demandez ensuite une URL pour la deuxième et dernière partie :





```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
```





Notez ces ajouts importants :




* `is_final` est défini sur `vrai` pour la dernière partie, signalant que le chargement se terminera après ce bloc.
* `asset_filesize` fournit la taille totale du fichier, qui est requise lorsqu’une partie inclut le paramètre `is_final: true`.




Après avoir reçu l’URL dans la réponse :





```json
{
    "upload_urls": [
        "https://frameio-uploads-production.s3-accelerate.amazonaws.com/parts/[part_02_path]"
    ]
}
```





Chargez le bloc final :





```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 @-
```




<Warning title="Gestion de la partie finale">
  


Lorsque la partie finale est chargée, Frame.io commence à assembler le fichier complet. Ce processus inclut un délai de grâce de 60 secondes pour que toutes les parties restantes se terminent. Nous recommandons de charger la partie finale seulement après que toutes les autres parties ont été chargées avec succès.



</Warning>


Et voilà ! Accédez à Frame.io pour voir votre ressource en temps réel chargée avec succès. 🎉





## Gestion des noms de ressource

Si le nom du fichier n’est pas connu lors de la création de la ressource, vous pouvez utiliser le champ `extension` sans paramètre `name` :

```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
```





Le système attribue un nom par défaut :





```json
{
    "id": "{asset_id}",
    "name": "[new file].mp4"
}
```

Vous pouvez mettre à jour ce nom en incluant un champ `asset_name` lors de la demande d’URL de chargement :

```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
```





Le nom ne se met à jour que si la ressource conserve encore son nom par défaut ; si elle a été renommée dans l’interface utilisateur Frame.io ou mise à jour précédemment, la demande est ignorée.





## Optimisation des demandes d’URL





Pour plus d’efficacité, demandez des URL pour autant de parties que vous avez actuellement de données disponibles, plutôt qu’individuellement. Cette approche est particulièrement utile pour les gros fichiers où la vitesse de chargement peut avoir du mal à suivre le rythme de la génération de données.





## Gestion des en-têtes de fichiers multimédias





Certains formats multimédias nécessitent des en-têtes au début du fichier, qui ne sont pas écrits tant que le fichier entier n’est pas terminé. Cela devient problématique lorsque l’en-tête est plus petit que la taille de partie minimale d’AWS de 5 Mio (5 242 880 octets).





Notre recommandation est la suivante :




1. Réservez les 5 242 880 premiers octets de données multimédias sans les charger.
2. Commencez à charger des parties en commençant par `part_number=2`.
3. Lorsque le fichier est terminé, ajoutez l’en-tête aux données réservées.
4. Demandez une URL pour `part_number=1` et chargez ce bloc combiné.





Cette approche garantit que votre premier bloc respecte l’exigence de taille minimale tout en préservant la structure appropriée du fichier.





## Adapter la taille des parties pour des performances optimales





AWS impose des limites qui affectent la stratégie de chargement :



* Taille de fichier maximale : 5 Tio (5 497 558 138 880 octets)
* Nombre maximal de parties : 10 000
* Taille de partie minimale : 5 Mio (5 242 880 octets)




Une taille de partie fixe crée des compromis :



* L’utilisation de la taille minimale (5 Mio) pour les 10 000 parties limite la taille totale du fichier à environ 52,4 Go.
* Répartir uniformément la taille maximale de fichier nécessiterait des blocs d’environ 550 Mo, ce qui est trop volumineux pour un flux efficace de fichiers plus petits.




Nous avons besoin d’une formule qui équilibre ces contraintes, en commençant par de petites parties pour des chargements réactifs tout en nous assurant de pouvoir gérer de très gros fichiers si nécessaire.





### Formule de taille de partie recommandée





Voici notre approche suggérée en 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

```

... où `part_number` est compris entre `1` et `10_000`, inclusivement et où `format_bytes_per_second` est le nombre moyen d’octets que votre fichier devrait consommer par seconde. Nous verrons [plus loin](/camera-to-cloud/how-to-upload-realtime#showing-our-work) comment nous sommes parvenus à cette formule.
<Info title="Valeur scalaire">
  La variable `scalar` et le calcul peuvent sembler un peu déroutants au premier abord, mais il s’agit d’un outil mathématique qui garantit que peu importe la valeur que nous utilisons pour `format_bytes_per_second`, si nous alimentons toutes les valeurs `part_number` autorisées de `1` à `10_0000` dans la fonction, nous recevrons un ensemble de valeurs qui totalise *exactement* notre limite de taille de fichier de 5 Tio (aussi exactement que possible). Nous [expliquons](/camera-to-cloud/how-to-upload-realtime#showing-our-work) plus loin comment nous sommes arrivés à cette formule.
</Info>

<Info title="Arrondi à l’inférieur">
  


En utilisant l’arrondi à l’inférieur, nous laissons quelques octets de côté, mais nous nous assurons que l’arrondi régulier sur 10 000 parties ne nous fait pas accidentellement dépasser notre taille de fichier maximale autorisée. Au maximum, 10 000 octets (ou 10 Ko) seront laissés de côté de cette façon, un compromis acceptable.



</Info>


Les caractéristiques importantes de cette formule sont les suivantes :




* Lors du chargement de 10 000 parties, la quantité totale de données chargées sera à 10 Ko près notre limite de taille de fichier de 5 Tio.
* Cela permet d’obtenir des payloads plus petites et plus efficaces au début pour augmenter la réactivité des clips courts et de longueur moyenne.
* Les clips très longs auront une réactivité réduite entre la fin de l’écriture d’un fichier et le moment où il devient lisible dans un cadre.




Le compromis entre le deuxième et le troisième point est atténué par le fait que la plupart des clips n’atteindront pas une taille nécessitant l’utilisation du troisième point. Nous échangeons une réactivité accrue de la *PLUPART* des fichiers contre une réactivité diminuée de très peu.

Une version plus avancée et efficace de notre formule (qui génère une fonction `part_size_calculator` anonyme avec notre scalaire statique et le débit de données précalculés et intégrés) pourrait ressembler à ceci :

**`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

```





### Performances de la formule.





Examinons les caractéristiques de sortie de la formule ci-dessus sur plusieurs types de fichiers courants.

**Exemple 1** : format web

Pour les formats lisibles sur le Web avec un débit d’environ 5,3 Mo/s ou moins (la plupart des fichiers H.264/H.265/HEVC), nous obtiendrons une progression de la taille de payload qui ressemble à ceci :




| Nombre total de parties | Octets de payload | Mo de payload | Taille totale du fichier (octets) | Taille totale du fichier (Go) |
| ----------: | ------------: | ---------: | ----------------: | -------------: |
| 1 | 5,242,896 | 5,2 Mo | 5,242,896 | 0,0 Go |
| 1,000 | 21,575,817 | 21,6 Mo | 10,695,361,357 | 10,7 Go |
| 5,000 | 413,566,329 | 413,6 Mo | 706,957,655,928 | 707,0 Go |
| 10 000 | 1 638 536 679 | 1 638,5 Mo | 5,497,558,133,921 | 5 497,6 Go |
**Clé des colonnes du tableau** - `Nombre total de parties` : le nombre total de parties de fichier chargées sur AWS. - `Octets de payload` : la taille du payload PUT AWS lorsque `part_number` est égal à `Nombre total de parties`. - `Mo de payload` : comme `Octets de payload`, mais en mégaoctets. - `Taille totale du fichier (octets)` : le nombre total d’octets chargés pour le fichier lorsque les parties séquentielles `Nombre total de parties` ont été chargées. - `Taille totale du fichier (Go)` : comme `Taille totale du fichier (octets)`, mais en Go.

Ces valeurs sont parfaitement équilibrées pour les chargements en temps réel, en particulier pour les codecs de lecture web comme H.264 ; la plupart seront inférieurs à 10,7 Go et seront donc terminés dans les 1 000 parties. La taille de payload ne dépasserait jamais 21,6 Mo.





Si nous traitions la moitié de nos parties, la taille du payload ne dépasserait jamais 413,5 Mo. Le chargement totaliserait 707 Go, ce qui est largement suffisant pour la grande majorité des fichiers web.





Ce n’est qu’une fois que nous approchons de la fin de notre nombre de parties autorisé que la taille du fichier commence à augmenter drastiquement. Cependant, elle ne dépasse jamais 1,7 Go, ce qui est bien en dessous de la limite AWS de 5 Gio par partie.

**Exemple 2** : Prores 422 LT Prores 422 LT [a un débit de données de 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) et génère un tableau comme suit :
| Nombre total de parties | Octets de payload | Mo de payload | Taille totale du fichier (octets) | Taille totale du fichier (Go) |
| ----------: | ------------: | ---------: | ----------------: | -------------: |
| 1 | 12,750,016 | 12,8 Mo | 12,750,016 | 0,0 Go |
| 1,000 | 28,857,758 | 28,9 Mo | 18,127,308,783 | 18,1 Go |
| 5,000 | 415,443,954 | 415,4 Mo | 735,107,948,432 | 735,1 Go |
| 10,000 | 1,623,525,817 | 1 623,5 Mo | 5,497,558,133,958 | 5 497,6 Go |




Ce tableau révèle des propriétés utiles par rapport à notre formule optimisée pour le Web. Dans les 1 000 premières parties, nous pouvons charger 8 Go de fichier en plus. Des payloads initiaux plus importantes signifient que nous n’aurons pas besoin de demander des URL trop rapidement au début, ce qui rend le chargement plus efficace pour le débit de données plus élevé. La taille de notre payload à la fin du processus de chargement reste importante.

**Exemple 2** : Camera Raw

Essayons enfin un format Camera RAW dont le débit de données est de 280 Mo/s. Avec des données arrivant si rapidement, essayer de charger par blocs de 5 Mo au début n’a tout simplement pas de sens :




| Nombre total de parties | Octets de payload | Mo de payload | Taille totale du fichier (octets) | Taille totale du fichier (Go) |
| ----------: | ------------: | ---------: | ----------------: | -------------: |
| 1 | 280,000,008 | 280,0 Mo | 280,000,008 | 0,3 Go |
| 1,000 | 288,091,460 | 288,1 Mo | 282,701,200,139 | 282,7 Go |
| 5,000 | 482,286,516 | 482,3 Mo | 1,737,245,341,542 | 1 737,2 Go |
| 10,000 | 1,089,146,065 | 1 089,1 Mo | 5,497,558,133,870 | 5 497,6 Go |




Non seulement les payloads précoces sont plus efficaces, mais nous économisons plus d’un demi-gigaoctet à la limite supérieure, ce qui rendra ces appels réseau moins sensibles aux événements réseau défavorables.





### Présentation de notre travail





Avant de rassembler notre travail dans un exemple de système de chargement, voyons comment nous sommes arrivés à notre formule.





Nous devions concevoir une formule qui remplaçait des payloads importants et lourds à la fin de nos parties autorisées (que la plupart des chargements n’atteindront jamais) par des payloads légers et efficaces près du début, où chaque chargement peut en tirer parti. En même temps, nous voulions nous assurer que notre algorithme atteindrait approximativement la limite de taille de fichier de 5 Tio *exactement* au numéro de partie 10 000.





Il était indispensable d’effectuer des calculs.





Nous voulons que notre graphe présente une croissance exponentielle. Notre formule devrait donc probablement ressembler à ceci :





```math
n^2
```

... où `n` est le numéro de partie. Nous voulons également nous assurer que chaque partie représente, au minimum, le taux de données de notre formule, que nous appellerons `r` :

```math
n^2 + r
```

Maintenant, nous devons trouver une formule qui peut nous indiquer la somme de *cette* formule pour les 10 000 premiers nombres naturels (1, 2, 3, ...). Le symbole sigma `Σ` désigne la somme. Ajoutons-le à notre formule :

```math
Σxn^2 + r
```

…et redéfinissons `n` comme la série des nombres naturels compris entre 1 et 10 000, inclus. Cette équation ne nous est pas encore très utile. Sa forme intuitive est bonne, mais si nous définissons `n=10 000` et `r=5 242 880` comme nous le voulons, elle [produit simplement un résultat](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 Go). Non seulement le résultat est largement inférieur à notre limite de taille de fichier de 5 Tio, mais il n’y a aucun moyen de manipuler la formule pour produire ce résultat.

Ajoutons donc un paramètre d’ajustement :





```math
Σxn^2 + r
```

... où `x` est un scalaire que nous pouvons résoudre pour obtenir 5 Tio comme résultat. Maintenant, nous pouvons définir l’équation pour qu’elle soit égale à notre limite de taille de fichier et la résoudre pour `x` :

```math
Σxn^2 + r = 5,497,558,138,880
```

Souvent, les sommes doivent être résolues de façon itérative, comme dans une boucle `for` ou `while`. Mais il s’avère qu’il existe une formule parfaite pour nous : [un moyen connu](https://www.math-only-math.com/sum-of-the-squares-of-first-n-natural-numbers.html) de calculer de manière économique la somme des carrés pour les `n` premiers nombres naturels :

```math
Σn^2 = n(n+1)(2n+1)/6
```





En la reformulant sous forme de polynôme, tout devient plus clair :





```math
Σn^2 = (2n^3 + 3n^2 + n)/6
```

Nous pouvons ajouter nos variables, `x` et `r`, des deux côtés :

```math
Σxn^2 + r = x(2n^3 + 3n^2 + n)/6 + rn
```





Et enfin, nous définissons notre nouvelle formule égale à 5 Tio :





```math
x(2n^3 + 3n^2 + n)/6 + rn = 5,497,558,138,880
```

Il ne nous reste plus qu’à résoudre `x` en définissant `n=10 000`, notre nombre total de parties. Cela nous donnera un moyen de calculer un scalaire statique pour un débit de données donné. Plutôt que de le faire à la main, [saisissons-le dans Wolfram Alpha](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
```

Nous sommes sur le point d’arriver à un résultat ! Si notre débit de données était la taille minimale de partie (5 Mio), [nous obtiendrions](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) un scalaire statique de :

```math
136,128,233,472 / 8,334,583,375
```

En informatique, cela représente une valeur float64 de `16,33293799427617`. Notre formule pour déterminer la taille de partie dans cette instance serait :

```math
s = 16.33293799427617n^2 + 5,242,880
```

Où `s` est notre taille de partie.

Nous avons encore un problème. Dans le monde réel, nous ne pouvons pas avoir une payload avec des octets non entiers. Nous devons arrondir chaque valeur. Nous allons utiliser Python pour arrondir vers le bas :





**`Python`**

```python title="Python"
math.floor(16.33293799427617 * pow(part_number, 2)) + 5_242_880
```





Nous sommes arrivés à un exemple concret de la fonction originale présentée dans ce guide.





## Création d’un outil de chargement de base





Examinons du pseudocode simple de type Python pour charger un fichier rendu en temps réel, en utilisant tout ce que nous avons appris dans ce guide :





**`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

```




<Warning title="Chargement avancé">
  Le code ci-dessus ne démontre que le flux de base du chargement d’un fichier en temps réel. En réalité, cette logique devra être améliorée avec la [gestion des erreurs](/camera-to-cloud/how-to-handle-errors) et les techniques de [chargement avancé](/camera-to-cloud/how-to-advanced-uploads).
</Warning>


## Étapes suivantes

Les chargements en temps réel offrent un moyen de rendre votre intégration aussi réactive que possible, avec des ressources qui deviennent lisibles dans Frame.io quelques secondes après la fin de l’enregistrement. Dans un [prochain guide](/camera-to-cloud/how-to-advanced-uploads), nous aborderons les techniques et exigences relatives aux chargements avancés. Bien qu’il soit écrit en pensant aux chargements de base, la majorité du guide s’applique également aux chargements en temps réel.

Si ce n’est pas déjà fait, nous vous encourageons à contacter notre équipe, puis à passer au guide suivant. Nous nous ferons un plaisir de répondre à vos questions.