ApsaraVideo Live permet une mise à niveau transparente du streaming standard vers le Real-Time Streaming (RTS). Si vous utilisez déjà le streaming standard, vous pouvez activer RTS pour utiliser les deux services simultanément.
Prérequis
Vous avez activé le service ApsaraVideo Live et effectué les configurations requises pour le streaming standard, comme décrit dans la rubrique Démarrage rapide d'ApsaraVideo Live. Les configurations pour le streaming standard doivent être effectuées dans l'ordre suivant :
Étape 1 : Activer RTS
Connectez-vous à la console ApsaraVideo Live.
Dans le volet de navigation de gauche, choisissez Live + > RTS.
Sélectionnez le domaine de diffusion sur lequel vous souhaitez activer RTS.
-
Activez l'interrupteur RTS et sélectionnez un mode de latence en fonction de vos besoins métier : Sub-second (End-to-End Latency: 400-800 ms) ou Half-second (End-to-End Latency: 200-400 ms).
Consultez la compatibilité et les limites de chaque option de latence avant de faire votre choix.
Latence inférieure à la seconde
Fonctionnalités : Offre une latence de bout en bout comprise entre 400 ms et 800 ms avec une compatibilité élevée. Ce mode est idéal pour les scénarios de diffusion en direct à faible latence qui nécessitent une compatibilité avec le streaming standard et d'autres protocoles d'ingestion ou de lecture.
Prise en charge des protocoles : Prend en charge ARTC (basé sur WebRTC) pour l'ingestion et la lecture des flux. Il est rétrocompatible avec le streaming standard et prend en charge l'ingestion RTMP, l'extraction depuis l'origine ainsi que les protocoles de lecture courants tels que RTMP, FLV et HLS.
Outils d'ingestion et de lecture : Compatible avec les outils standards du secteur. Nous recommandons d'utiliser le SDK d'ingestion Alibaba Cloud et le SDK du lecteur ApsaraVideo.
-
Autres remarques : Si le flux ingéré contient des images B ou utilise un codec audio autre qu'Opus, le système transcode automatiquement le flux pour la lecture web, ce qui entraîne des frais de transcodage.
Lors de l'utilisation du SDK Web ApsaraVideo pour la lecture, le moteur WebRTC sous-jacent ne prend pas nativement en charge les images B et nécessite le codec audio Opus. Pour garantir une expérience de lecture fluide, le système déclenche automatiquement un transcodage en fonction du contenu du flux ingéré :
Si le flux ingéré contient à la fois des images B et de l'audio AAC, le système transcode automatiquement la vidéo pour supprimer les images B et l'audio pour convertir l'AAC en Opus. Des frais de transcodage vidéo standard sont appliqués en fonction de la résolution source.
Si le flux ingéré ne contient pas d'images B mais contient de l'audio AAC, le système déclenche un transcodage audio uniquement pour convertir l'AAC en Opus. Des frais de transcodage audio uniquement sont appliqués.
Si vous avez également configuré un modèle de transcodage, le système effectue la suppression des images B et la conversion en Opus en plus des opérations définies dans le modèle. Des frais combinés de transcodage sont appliqués.
Lors de l'utilisation du SDK natif ApsaraVideo pour la lecture, aucun transcodage automatique n'est déclenché et aucun frais supplémentaire n'est encouru, car le SDK natif prend en charge à la fois les images B et l'AAC.
Latence d'une demi-seconde
Fonctionnalités : Atteint une latence de bout en bout comprise entre 200 ms et 400 ms. Ce mode convient aux scénarios exigeant la latence la plus faible possible.
Prise en charge des protocoles : Prend en charge ARTC (basé sur WebRTC) pour l'ingestion et la lecture des flux. Ce mode n'est pas compatible avec le streaming standard et ne prend pas en charge l'ingestion RTMP, l'extraction depuis l'origine ni la lecture via des protocoles courants comme RTMP, FLV et HLS.
Outils d'ingestion et de lecture : Pour l'ingestion de flux, vous pouvez utiliser OBS avec le protocole WHIP ou le SDK d'ingestion Alibaba Cloud. Pour la lecture de flux, vous devez utiliser le SDK du lecteur ApsaraVideo.
-
Autres remarques : Les fonctionnalités cloud telles que le transcodage et l'enregistrement ne sont pas disponibles pour le domaine de diffusion dans ce mode. Toutefois, vous pouvez utiliser une configuration de transfert de flux pour rendre le flux disponible sur un autre domaine.
Cliquez sur Configure Stream Relay et sélectionnez un domaine d'ingestion associé à un domaine de diffusion qui n'a pas activé le mode de latence d'une demi-seconde ni la récupération après sinistre à double flux. Ce domaine recevra le flux RTMP transféré. Par exemple, vous pouvez transférer le flux vers un domaine d'ingestion
push.example.com, qui est associé au domaine de diffusionpull.example.com. Une fois la configuration terminée, vous pouvez extraire le flux depuispull.example.comen utilisant des protocoles de streaming standard et utiliser des fonctionnalités cloud comme le transcodage et l'enregistrement.
Le déploiement de la configuration RTS sur le réseau peut prendre plusieurs minutes. Attendez quelques minutes avant d'effectuer des tests.
Si vous devez associer un domaine d'ingestion à plusieurs domaines de diffusion, consultez la rubrique Associer un sous-domaine de diffusion à un domaine de diffusion principal.
RTS et le streaming standard peuvent partager le même domaine de diffusion. Cependant, étant donné que RTS utilise UDP et que le streaming standard utilise TCP, leurs technologies sous-jacentes diffèrent. Nous recommandons d'utiliser un domaine de diffusion dédié pour RTS.
Étape 2 : Générer les URL d'ingestion et de diffusion
Méthode 1 : Générer les URL dans la console
Après avoir activé RTS, vous pouvez utiliser l'outil de test de flux dans la console. Cliquez sur Generate URLs**, saisissez un nom d'application et un nom de flux, et l'outil génère les URL d'ingestion et de diffusion RTS basées sur ARTC.
Dans la console, vous devez d'abord activer l'interrupteur Real-Time Streaming et sélectionner un mode de latence : latence inférieure à la seconde (latence de bout en bout de 400 ms à 800 ms, prend en charge l'ingestion RTMP/ARTC et la lecture HLS/FLV/RTMP/ARTC) ou latence d'une demi-seconde (latence de bout en bout de 200 ms à 400 ms, prend en charge uniquement l'ingestion et la lecture ARTC). La liste des URL générées inclut plusieurs formats de protocole pour l'ingestion et la lecture, tels que artc://, rtmp:// et http://.
Méthode 2 : Construire manuellement les URL
Avant de construire les URL d'ingestion et de diffusion, déterminez si le flux sera transcodé et si la signature d'URL est activée. Préparez ensuite les informations requises : domaine d'ingestion, domaine de diffusion, nom d'application, nom de flux, ID de modèle de transcodage (le cas échéant) et jeton d'accès (le cas échéant).
|
Type d'URL |
Format |
Règle de construction |
|
URL d'ingestion |
Prend en charge les formats RTMP, RTS et SRT. Nous recommandons d'utiliser le format RTMP pour l'ingestion de flux. Exemple : RTMP : Remarque
RTS prend également en charge la lecture de flux via des URL RTS. |
domaine d'ingestion + nom d'application + nom de flux + jeton d'accès |
|
URL de diffusion |
Prend en charge les formats RTMP, FLV, M3U8 et RTS. Nous recommandons d'utiliser le format RTS pour la lecture de flux. Exemple : RTS : |
domaine de diffusion + nom d'application + nom de flux + jeton d'accès |
|
URL de flux transcodé Remarque
Si vous configurez un modèle de transcodage, vous devez utiliser l'URL de flux transcodé correspondante. |
Prend en charge les formats RTMP, FLV, M3U8 et RTS. Nous recommandons d'utiliser le format RTS pour la lecture de flux. Exemple : RTS : |
domaine de diffusion + nom d'application + nom de flux_ID de modèle de transcodage + jeton d'accès |
Pour les domaines d'ingestion et de diffusion associés, utilisez des noms d'application et de flux identiques pour l'ingestion et la lecture des flux.
Une URL de flux transcodé nécessite un modèle de transcodage. Vous pouvez trouver l'ID du modèle de transcodage dans la console. Pour plus d'informations, consultez la rubrique Transcodage de flux en direct.
Le jeton d'accès (auth_key) est une chaîne chiffrée requise uniquement lorsque la signature d'URL est activée. Vous pouvez utiliser l'algorithme MD5 pour générer le jeton d'accès. Pour plus d'informations, consultez la rubrique Composants d'URL signée.
Lorsque vous personnalisez l'URL, remplacez directement {Transcoding Template ID} ou {Access Token} par les données réelles. N'incluez pas les symboles {} autour des données réelles.
Étape 3 : Démarrer l'ingestion et la lecture RTS
Après avoir activé RTS et généré les URL, vous pouvez utiliser l'option Try RTS dans la console pour tester l'ingestion et la lecture RTS. L'outil prend en charge la diffusion depuis votre caméra ou le partage de votre écran.
L'outil de test de flux dans la console utilise un domaine de signalisation proxy pour des tests rapides. Si vous intégrez le SDK Web dans votre propre application, vous devez configurer un certificat SSL pour vos domaines et définir l'en-tête de réponse Access-Control-Allow-Origin correct.
ApsaraVideo Live propose également des démos mobiles et web pour essayer RTS.
Vous pouvez également intégrer les SDK suivants dans vos applications :
|
Type de SDK |
Documentation |
|
Mobile |
|
|
Web |
Si vous rencontrez des problèmes de lecture, utilisez d'abord l'outil de dépannage en libre-service. Cet outil peut diagnostiquer rapidement les problèmes de lecture courants et fournir des solutions. Pour plus d'informations, consultez la rubrique Dépannage en libre-service.
Vérifier la latence de bout en bout
Vous pouvez ajouter une URL d'étalonnage temporel à l'ingestion de flux pour vérifier la latence de RTS en la comparant à l'heure standard. L'exemple suivant utilise OBS pour l'ingestion de flux.
Dans l'interface principale d'OBS, ajoutez l'URL d'étalonnage temporel en tant que source de navigateur dans la section Sources, puis cliquez sur Start Streaming.