Aperçu

Brightcove Live fournit un service robuste pour créer des événements en direct ou des diffusions en direct 24 heures sur 24, 7 jours sur 7. Ce guide présente les meilleures pratiques pour optimiser vos diffusions en direct

Contexte du contenu

Le type de contenu diffusé doit être pris en compte car il a un impact sur les paramètres requis pour maintenir la qualité de l'entrée. Notez qu'il existe des compromis et que l'utilisation des paramètres les plus élevés possibles peut entraîner des problèmes tels que des images sautées.

Sur la base des informations ci-dessous, nous vous recommandons de tester différentes combinaisons de paramètres pour la qualité et les performances avant votre événement en direct.

Les principaux paramètres d'entrée sont décrits dans le tableau suivant :

Principaux problèmes liés au streaming

Il existe plusieurs problèmes généralement rencontrés liés à des problèmes avec l'expérience de streaming de l'encodeur à Brightcove :

1. Instabilité du réseau affectant l'entrée :
   1. Bien qu'Internet soit généralement assez fiable, il n'est pas infaillible et des problèmes surviennent. Les problèmes sont plus susceptibles d'être remarqués sur des débits binaires plus élevés.
   2. S'il faut plus de temps pour télécharger la vidéo qu'en temps réel, cela peut entraîner une dérive d'entrée (l'heure à laquelle la vidéo est reçue est sensiblement plus tardive que lorsqu'elle a été envoyée)
2. Surcharge du transcodeur entraînant des sauts de trames : bien que nous fassions tout pour nous assurer que nos transcodeurs ont suffisamment de surcharge, des pics parfois soudains dans la complexité du contenu, des hoquets/rattrapages de réseau ou d'autres interruptions de nos transcodeurs peuvent provoquer des sauts de trames. Plus l'entrée est complexe, plus il est probable que des trames sautées seront rencontrées. Il existe également un problème connu où les modifications d'une image fixe pendant une durée prolongée, par exemple plus de 5 minutes, et un changement soudain du contenu de l'action peuvent provoquer une surcharge.
3. Encodeur envoyant des durées d'images variables : la fréquence d'images doit être constante et elle doit être telle qu'elle autorise un intervalle d'image-clé constant. Par exemple, pour une fréquence d'images telle que 29,97 alias 30000/1001 ou 23,976 alias 24000/1001, il n'est pas possible de définir une image clé à intervalle régulier et doit donc être évitée.
4. L'encodeur envoie des images clés dont la durée n'est pas cohérente, la fréquence d'images clés doit être au moins 2 fois supérieure à la fréquence d'images en secondes. Par exemple, pour une fréquence d'images de 30 images par seconde, l'intervalle d'image-clé doit être de 60 images, soit 2 secondes et doit être un intervalle maximum d'une fois par segment. Par exemple, si vous avez un segment de 6 secondes, l'intervalle maximal serait de 180 images à 30 ips.

Types de contenu

En règle générale, un contenu plus complexe nécessitera l'utilisation du plus élevé de ces paramètres et, en tant que tel, est plus susceptible aux images sautées. Le tableau ci-dessous présente quelques exemples par ordre de complexité. Notez qu'il ne s'agit que d'exemples et que pratiquement chaque configuration d'encodeur est différente. Des tests et des vérifications doivent être effectués.

Vérification et test

Idéalement, les clients devraient commencer avec les paramètres les plus bas possibles sur leur contenu le plus complexe (contenu le plus changeant) et tester avec leur contenu en augmentant les différents paramètres jusqu'à ce que la sortie soit acceptable. En effet, en général, plus les paramètres sont élevés, plus les problèmes sont susceptibles d'être rencontrés dans le réseau ou le transcodage.

Structure GOP

La structure du groupe d'images (GOP) de la vidéo dépend d'abord du profil utilisé comme :

1. Référence le profil ne prend en charge que les trames I et P et le codage entropique CAVLC
2. Principale et Haute prend en charge les trames I, B et P et le codage entropique CABAC

Les profils Main et High aboutissent généralement à une meilleure compression avec une meilleure qualité, mais nécessitent également des calculs supplémentaires pour coder et décoder, car ils peuvent être plus sensibles aux trames sautées. De plus, comme ces profils utilisent des trames B (bidirectionnelles), ils induisent un certain retard dans le processus de codage.

Le profil de base nécessite moins de CPU pour coder et décoder, mais comme il offre moins de compression, il nécessite un débit binaire plus élevé pour maintenir la qualité et est donc plus sensible aux problèmes de réseau.

Remarques sur les types de trames et leur impact probable sur les performances :

1. I frames : utilise le plus de bande passante. Il est préférable d'ajouter des changements de scène complets ou aux limites des segments, c'est-à-dire que plus le contenu change, plus vous en avez besoin (longueur GOP plus courte).
2. cadres P : sont l'unité de base entre les cadres I
3. Images B : utilisez à la fois des images précédentes et futures. Plus vous en ajoutez, meilleure sera la compression, mais plus le processeur et la latence seront élevés

L'utilisation de j'encadre devrait idéalement être limité au début des segments (critique si vous utilisez le passthrough) ou aux changements de scène. Tout ou un nombre élevé de trames I doit être évité car cela peut entraîner une charge excessive entraînant des sauts de trames.

Remarques supplémentaires :

• Utilisez des options pour empêcher le placement dense d'images clés (exemple : min_keyin = 3+).
• Utilisez des options assurant une cadence régulière d'insertion d'images clés. Par exemple, au lieu de spécifier la longueur du GOP en secondes, spécifiez-la en fractions ou en images exactes.

Débit

• Bande passante d'entrée minimale : 2,5 Mbps
• Bande passante d'entrée maximale : 10 Mbps

• Faites en sorte que le flux soit « presque CBR », avec max_bitrate = 1,1 * target_bitrate.
• Utilisez le mode de contrôle de débit strictement conforme à HRD, si disponible.

Protocole

Il est important de noter qu'Internet n'est pas un réseau de diffusion garanti et que, bien qu'une connexion Internet puisse être considérée comme « bonne », elle peut ne pas être suffisante pour une diffusion vidéo en direct fiable et de haute qualité. Une petite interruption dans le chemin entre l'encodeur du client et la plate-forme de transcodage Brightcove, telle qu'une petite quantité d'encombrement chez un FAI, un basculement imprévu entre les routeurs ou des problèmes similaires peuvent entraîner une interruption de la sortie vidéo. Dans la diffusion en direct à enjeux élevés, il est normal d'avoir plusieurs réseaux dédiés constitués soit de fibre dédiée, soit d'une bande passante satellite réservée, soit d'une bande passante engagée sur un réseau géré. Cela a un coût substantiel et, dans la plupart des cas, il est possible d'obtenir un assez bon résultat sur Internet. Si, toutefois, il est essentiel de maintenir un transport sans défaut, veuillez envisager AWS Direct Connect ou un FAI qui peut fournir un certain niveau de bande passante dédiée.

Les options que nous recommandons sont (dans l'ordre) :

1. SRT : offre une bonne combinaison de vitesse de transport (UDP) avec un certain contrôle et une certaine résilience aux erreurs. Non disponible sur tous les encodeurs, bien qu'il existe des outils qui peuvent traduire à partir de RTP local tels que srt-transmit.
2. RTMP : étant basé sur le protocole TCP, il offre un bon niveau de résilience aux erreurs. L'inconvénient est que cela entraîne une surcharge importante. Notez que toutes les fonctionnalités telles que plusieurs pistes audio ne sont pas disponibles avec RTMP.
3. RTP-FEC : fournit un transport rapide basé sur UDP avec une certaine résilience aux erreurs
4. RTP : fournit un transport rapide et des fonctionnalités avancées sans résilience aux erreurs

Encodeurs pris en charge

Voir Encodeurs pris en charge pour les événements en direct pour la liste des encodeurs connus pour fonctionner avec Live. Notez que d'autres encodeurs peuvent également fonctionner, mais n'ont pas été testés.

CDN pris en charge

• Akamai
• Amazon CloudFront

Nouvelles tentatives

Nous vous recommandons d'activer les nouvelles tentatives pour la connexion RTMP depuis l'encodeur. Un grand nombre de tentatives avec un intervalle de relance de 5 secondes atténuera les problèmes de connectivité intermittents entre l'encodeur et le point d'entrée.

Paramètres du travail

Paramètres de travail recommandés

Exigences d'entrée

Le tableau suivant indique les exigences pour le flux en direct d'entrée.

Remarques

• ^[1-1] Si vous avez plusieurs pistes vidéo/audio dans votre entrée TS, nous choisirons la première pour chacune. Nous vous recommandons également fortement d'utiliser FEC, car le TS simple sur UDP sur Internet est très peu fiable. Pour FEC, nous pouvons noter que plus les valeurs que vous utilisez pour les lignes/colonnes sont petites, plus la correction d'erreur sera fiable (au détriment d'une bande passante accrue).

Slate recommandations de fichiers source

• Résolution : (meilleure dans votre échelle d'encodage)
• FPS : (identique à votre source)
• Débit : (meilleur dans votre échelle d'encodage ou mieux)
• Audio : (débit, canaux, fréquence d'échantillonnage et bits par échantillon identiques à ceux de votre meilleur rendu, ou identiques à ceux de votre entrée)

Recommandations de sortie

Vous trouverez ci-dessous les paramètres de sortie recommandés, mais notez que pour de nombreux encodeurs, l'entrée RTMP est limitée à 10 Mbit/s (vidéo+ audio) et à une cadence d'images de 30 ips.

FAQ

Combien de temps devez-vous commencer à diffuser après avoir créé un emploi en direct ?

Dans Brightcove Live, deux conditions s'appliquent lorsque l'état passe de waiting à finishing :

1. si le travail est dans le attendre état (pas encore commencé) et le max_waiting_time_ms s'est écoulée, le travail est terminé/désactivé.
2. Si le travail est dans le débranché état (démarré, mais déconnecté) et le reconnect_time s'est écoulée, le travail est terminé/désactivé.

Si la event_length est supérieure à 30 minutes, le travail se terminera dans 30 minutes. Si la event_length est inférieure à 30 minutes, le travail se terminera dans event_length .

Par exemple, si le event_length est de 60 minutes, le travail en direct se terminera dans 30 minutes. Si la event_length est de 15 minutes, alors, le travail en direct se terminera dans 15 minutes

Les reconnect_time n'a aucun effet sur l'état d'attente.

Quelles sont les limitations sur les job_settings en direct simultanés ?

Un maximum de 5 actifs en attente, non commencé les travaux sont autorisés à tout moment.

Limitations supplémentaires sur les tâches simultanées :

• Le nombre de channel (24x7) jobs est limité à 0 ou à un petit nombre par région (selon le type de compte).
• Le nombre de simultanément fonctionnement event emplois est limité par région, généralement à 100.
• Le nombre de simultanément en attente de connexion event les emplois sont limités à 5.
• Le nombre d'emplois SEP par région est limité à 3 ou 10 (voir Régions AWS prises en charge).

Chacune de ces limites peut être ajustée au niveau du compte par l'assistance. Contactez votre Customer Success Manager si vous avez besoin d'une capacité supplémentaire.

Est-ce que Brightcove Live peut fournir une qualité de 1080p à condition que la bande passante d'entrée soit suffisante ?

Oui, l'entrée 1080p est activée pour tous les comptes.

Les DRM sont-ils disponibles ?

Oui ! Contactez votre Customer Success Manager si vous souhaitez ajouter le support DRM à votre compte live.