Brightcove en direct : Les meilleures pratiques
Aperçu
Brightcove Live fournit un service robuste pour créer des événements en streaming en direct ou des flux 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 :
Paramètre | Remarques |
---|---|
Débit d'entrée | Le débit binaire envoyé par l'encodeur. Des débits plus élevés sont plus sensibles aux pertes de réseau et doivent donc être maintenus aussi bas que possible. |
Résolution d'entrée | Cela doit correspondre au contenu source. Il n'y a aucun avantage à le rendre supérieur à la source d'origine et plus cette valeur est élevée, plus le débit binaire est nécessaire pour la prendre en charge. |
Débit binaire d'entrée/rapport de profil supérieur | Le débit binaire en entrée doit être supérieur au débit du profil supérieur, mais un débit trop élevé peut entraîner des chutes d'images ou d'autres problèmes. Par exemple, si votre débit supérieur est de 1080p 30 ips, l'entrée devrait idéalement être d'environ 4 Mbit/s. Notez que cela est affecté par le profil. Nous recommandons généralement un débit binaire d'entrée qui est 2x (deux fois) le débit binaire de votre rendu en direct le plus élevé.
Si vous avez besoin d'une sortie supérieure à haut débit, il vaut la peine de tester le |
Profils | Les différents profils (ligne de base, principale, élevée) compressent les données en quantités ascendantes (ligne de base : la plus basse, la plus élevée : la plus élevée). Une compression plus importante améliore le taux de transmission, mais nécessite également des ressources CPU plus importantes pour décoder les données. À moins que l'encodeur ne soit fortement limité dans les ressources disponibles, le profil de base doit être évité. D'un autre côté, l'utilisation d'un profil élevé à des débits binaires élevés est plus susceptible de provoquer des sauts de trames en raison de l'augmentation des ressources CPU de décodage requises.
Regarde aussi Structure GOP au dessous de. |
Fréquence d'images | Cela devrait correspondre à la source.
Des débits plus élevés nécessiteront des débits d'entrée proportionnellement plus élevés, par exemple avec du contenu de sport d'action, un flux d'entrée à 60 ips transporte sensiblement plus de données qu'un flux à 30 ips. Des débits élevés tels que 60 ips sont plus susceptibles d'avoir des problèmes de saut d'image sur un contenu complexe à des débits binaires élevés. |
Taux d'images clés | Le paramètre le plus efficace est la durée du segment x fréquence d'images. Par exemple, si vous avez des segments de 6 secondes et 30 ips, la fréquence d'images clés 180 (6x30) entraînerait la charge de décodeur la plus faible.
Toutefois, pour tenir compte des fluctuations, il est défini sur 2 fois la fréquence d'images, par exemple 60 pour une fréquence d'images de 30 ips. |
Structure GOP | Voir Structure GOP au dessous de. |
Restrictions de
Afin de garantir une expérience de streaming de qualité optimale et homogène, Brightcove Live limite les paramètres de flux d'entrée à :
- Protocole :
rtmp
,rtp
rtp-fec
, ousrt
(tous sauf pourrtmp
les entrées MPEG2-TS)[1-1] - Résolution : Maximum 1920x1080
- Maximum 30 fps, ce qui est typique. Brightcove prend en charge jusqu'à 60 ips, mais vous devrez contacter le support Brightcove pour augmenter la limite. Lors de l'utilisation de 60 ips, Brightcove recommande d'augmenter le débit binaire pour obtenir la qualité visuelle souhaitée pour le contenu et une fréquence d'images constante.
- Moins de 10 Mbit/s
- Bitrate constant (CBR) réduit considérablement le risque de problèmes
- Le codec vidéo doit être H.264
- Tranches : Si votre encodeur a cette option, réglez-la sur
1
- Le codec audio doit être
AAC
- Fréquence d'échantillonnage audio : 44.1khz et 48khz sont les débits audio recommandés à utiliser
- Taux d'images-clés ou GOP (groupe d'images) aligné :
- UNE Image clé devrait toujours se produire toutes les 2 secondes pour les entrées et les sorties (y compris la vidéo 25fps). Cela signifie qu'une image-clé est envoyée à Brightcove à partir de l'encodeur toutes les deux secondes du flux lui-même. Ce processus peut être défini de différentes manières, mais le taux d'image-clé est le plus courant.
- Il peut être calculé de différentes manières par différents codeurs. Par exemple :
- Wirecast utilise la quantité d'images qui passent. Par conséquent, pour une vidéo à 30 ips, le réglage est de 60.
- Les codeurs élémentaires utilisent des secondes pour que le réglage correct soit '2'.
- La vidéo à 60 images par seconde ne changera que si ce paramètre est compté par les images, auquel cas toutes les 120 images équivaudraient à 2 secondes.
- S'il existe une option pour Aligné d'image-clé, Synchroniser GOP, Aligner les images clés ou quelque chose le long de ces lignes, assurez-vous que les images clés sont alignées. Lorsque les images clés ne sont pas alignées, cela provoque des problèmes de synchronisation avec la segmentation HLS.
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 prix d'une bande passante accrue.
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 :
- Instabilité du réseau affectant l'entrée :
- 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.
- 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)
- 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.
- 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.
- 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.
Type de contenu | Exemples de paramètres |
---|---|
Webcam |
|
Conférence Web |
|
Animation |
|
Tête parlante / Actualités |
|
Concert en live |
|
Sport en direct |
|
Sport en direct élevé FPS |
|
Transmux Live emplois
Réglez l'insertion des images clés de manière à ce qu'elle corresponde aux paramètres de segmentation de la demande. Par exemple, si la fréquence d'images est de 25 images par seconde et que l'on souhaite obtenir un segment de 6 secondes, l'intervalle entre les images clés doit être d'au moins une fois toutes les 300 images.
Tester les paramètres/la sortie de l'encodeur avec les appareils cibles souhaités. Ceci est particulièrement important si vous utilisez un encodeur de contribution à la radiodiffusion qui peut avoir des paramètres avancés qui résultent en un flux qui peut ne pas être compatible avec tous les appareils grand public. Il est également conseillé d'éviter les réglages particulièrement avancés - il est difficile de les définir avec précision car il existe de nombreux encodeurs et options possibles. Mais un profil général de haut niveau devrait être quelque chose comme.. :
- débit de pointe de 6 Mbps
- H264 Profil élevé
- Cadres B : 2
- couleur 8bit 4:2:0
Vérification et test
Idéalement, vous devriez commencer avec les paramètres les plus bas possibles sur votre contenu le plus complexe (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.
Test de bande passante
La première étape en vue de disposer des paramètres appropriés pour le flux d'entrée consiste à déterminer la bande passante disponible sur le site. Il existe quelques outils qui peuvent vous aider :
- SpeedOf.Me(https://speedof.me)- Déterminer la bande passante totale disponible pour les connexions HTTP est une bonne première étape. Toutefois, étant donné que le flux d'entrée doit être diffusé par le module Live via RTMP et non HTTP, la bande passante effective disponible pour les connexions RTMP risque d'être considérablement inférieure.
- Speedtest(https://www.speedtest.net)- Outil en ligne permettant de déterminer les vitesses actuelles de téléchargement vers l'amont et vers l'aval.
Bande passante en entrée
Le seul élément déterminant pour assurer la meilleure expérience au public est un flux d'entrée à la fois stable et de qualité. Un flux d'entrée de bonne qualité fournit la meilleure qualité vidéo en utilisant toujours la bande passante la plus élevée disponible sur le site.
- Bande passante d'entrée minimale : 2,5 Mbps
- Bande passante d'entrée maximale : 10 Mbps
Détermination des capacités de l'encodeur
La connaissance des capacités du logiciel et du matériel utilisés pour encoder le flux en direct et le transmettre au module Live est également un élément important. De nombreux débits peuvent être disponibles pour la transmission d'un flux d'entrée 1080p de haute qualité, mais le matériel doit également être capable de procéder à l'encodage plus vite qu'en temps réel. Certains outils d'encodage permettent d'afficher les informations relatives à l'utilisation totale en UC et à la bande passante utilisée. Par exemple, Telestream Wirecast affichera les statistiques de sortie en bas de la fenêtre Wirecast.
Ces informations sont utiles pour déterminer le flux le plus stable et de la plus haute qualité possible sur un matériel donné. Choses à regarder à Wirecast :
- L'utilisation en UC doit être inférieure à 80 %.
- Le débit des données doit être voisin du débit binaire.
- FPS doit être à la vitesse des paramètres du flux d'entrée
Structure GOP
La structure du groupe d'images (GOP) de la vidéo dépend d'abord du profil utilisé comme :
- Référence le profil ne prend en charge que les trames I et P et le codage entropique CAVLC
- 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 :
- I frame : 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).
- cadres P : sont l'unité de base entre les cadres I
- Trames B : utilisez à la fois les trames précédentes et futures, plus vous ajoutez d'images, plus la compression sera bonne, mais plus le processeur et la latence sont é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 des images clés (exemple :
clé_min
= 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
- Rendre le flux « 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.
En règle générale, nous recommandons de consacrer à la bande passante deux fois la taille de flux prévue par l'encodeur afin d'éviter tout problème de réseau lié à la bande passante.
Les options que nous recommandons sont (dans l'ordre) :
- SRT - offre une bonne combinaison de vitesse de transport (UDP) avec un certain contrôle et une certaine résistance 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.
- RTMP - étant basé sur TCP, il offre un bon niveau de résilience aux erreurs, les inconvénients sont que cela s'accompagne d'une surcharge importante. Notez que toutes les fonctionnalités telles que plusieurs pistes audio ne sont pas disponibles avec RTMP.
- RTP-FEC - fournit un transport UDP rapide avec une certaine résistance aux erreurs
- 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 de tâche (API Live uniquement)
Paramètres de travail recommandés
Champ | Valeur recommandée |
---|---|
ad_audio_loudness_level |
-23 (norme R.128 de l'UER) |
Lancer une recommandation de diffusion en direct
Une tâche doit être activée avant la connexion du codeur. En outre, l'activation d'un travail après le démarrage du flux à partir de l'encodeur n'est pas une procédure prise en charge et peut entraîner un comportement inattendu.
Slate recommandations de fichiers source
- Résolution : (mieux dans votre échelle de codage)
- FPS : (identique à votre source)
- Débit binaire : (mieux dans votre échelle de codage ou mieux)
- Audio : (même débit, canaux, fréquence d'échantillonnage et bits par échantillon que votre meilleur rendu, ou même que 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.
Article | Recommandation |
---|---|
Codec vidéo | h264 est actuellement la seule option |
Un codec audio | aac est actuellement la seule option |
Largeur | Sinon width ou height est fourni, les dimensions de la source sont utilisées. Si soit width ou height est fourni, l'autre dimension sera calculée pour maintenir le rapport hauteur/largeur de la source. |
Hauteur | Sinon width ou height est fourni, les dimensions de la source sont utilisées. Si soit width ou height est fourni, l'autre dimension sera calculée pour maintenir le rapport hauteur/largeur de la source. |
Débit | Inférieur ou égal au débit d'entrée (pour de meilleurs résultats, le débit de sortie le plus élevé doit être la moitié du débit d'entrée) |
Taux d'images clés | 2 secondes |
FAQ
- 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é. - 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é. - 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).
- Les symptômes précis du flux. Par exemple, le flux peut ne pas s'afficher du tout, ou il peut s'afficher mais saccader. Il peut aussi se figer lors de la lecture.
- Est-ce que ce flux fonctionnait correctement auparavant ?
- L'URL du point d'entrée utilisée par votre encodeur
- Le logiciel et le matériel d'encodage utilisé
- L'URL du lecteur à laquelle vous avez publié l'événement en direct
- L'identifiant vidéo de votre ressource en direct
- Les résultats du trace-route de votre encodeur jusqu'à l'hôte du point de publication
Combien de temps devez-vous commencer à diffuser après avoir créé un emploi en direct ?
Dans Brightcove Live, il existe deux conditions lorsque l'état passe dewaiting
à finishing
:
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 :
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.
Brightcove Live peut-il pousser la qualité 1080p à condition que la bande passante d'entrée soit suffisante ?
Oui, l'entrée 1080p est activée pour tous les comptes.La DRM est-elle disponible ?
Oui! Contactez votre Customer Success Manager si vous souhaitez ajouter le support DRM à votre compte live.Aide supplémentaire
Si vous n'arrivez toujours pas à diffuser correctement votre vidéo en direct, contactez-nous. Pour vous assurer une réponse rapide, vous trouverez ci-dessous une liste des éléments requis par l'assistance Brightcove pour un traitement optimal.