Pour éviter toute frustration et prévenir tout incident technique – que l’on ne peut jamais exclure malgré le soin apporté à la conception de l’application – voici quelques exemples de pratiques à éviter et les recommandations correspondantes.
La liste n’est pas exhaustive. On pourrait y ajouter tout ce qui relève du bon sens et de la modération pour pratiquer un streaming responsable.
La pratique à éviter | La bonne pratique |
---|---|
Lancer simultanément d’un grand nombre d’actions consommatrices de ressources, comme des encodages ou des retranscriptions | Procéder par vagues de 10 actions simultanées au maximum et attendre qu’elles soient terminées pour lancer la suite. |
Publier des vidéos pour les archiver aussitôt | Si ces vidéos ne doivent pas être visibles en ligne mais rester cherchables, l’Hibernation sera peut-être la meilleure solution pour vous. |
Soumission de fichiers de qualité excessive | Envoyer des fichiers vidéo inutilement lourds prend plus de temps et consomme plus de ressources pour les transcodages. Compte tenu des transcodages réalisés, le débit du fichier que vous envoyez n’a pas besoin d’être supérieur de plus de 20% au transcodage de qualité la plus élevée. Les limites que nous recommandons de ne pas dépasser pour les sources que vous déposez sont : 4K@50-60FPS : 30Mbps 4K@25-30FPS : 25 Mbps HD@50-60FPS : 13Mbps HD@25-30FPS : 10Mbps Notez que si le débit de votre « source » dépasse de plus de 50% le débit du transcodage de plus haute qualité généré, elle ne sera pas archivée. Si vous souhaitez archiver des « masters » ou des rushes en très haute qualité, privilégiez l’Hibernation, d’autant que certains formats de fichiers peu compressés ne seront pas acceptés pour du transcodage. |
Diffuser en direct à une cadence d’images inutilement élevée | Une cadence élevée n’a d’intérêt que pour des retransmissions sportives ou du gameplay. Elle est plus consommatrice de bande passante et plus exigeante pour les transcodages. A l’arrivée, les hautes cadences sont aussi plus exigeantes pour les terminaux. Dans la majorité des cas, une cadence de 25 à 30 FPS garantit une transmission, un transcodage et une lecture plus sûrs. |
Configurer une diffusion en direct avec une résolution supérieure au flux envoyé | Cette situation peut dans certains cas provoquer des erreurs. Veiller à ce que la résolution configurée pour le live soit inférieure ou égale à celle du flux reçu. Par exemple, ne configurez pas un live ne 4K alors que vous envoyez un flux en Full HD. |
Diffuser en direct depuis une connexion en WiFi ou réseau mobile (4G/5G) | Pour des raisons e sécurité, l’adresse IP de provenance du flux ne doit pas changer. Le roaming est une cause de déconnexion. Une connexion par câble doit toujours être privilégiée. A défaut, si la connexion est en WiFi, les données mobiles doivent être désactivées et inversement. |
Relancer des traitements (encodages, sous-titrages, désarchivages…) qui ne se terminent pas assez vite ou supprimer par impatience des médias en cours de traitement, pour recommencer juste après. | Il faut être patient… Si un traitement n’est pas assez rapide pour vous, il vaut mieux créer un nouveau media à côté et relancer le même traitement qu’interrompre le traitement en cours ou supprimer le média. |
Utiliser l’API alors qu’un webservice suffirait | Si la requête ne fait que de la lecture et aucune écriture sur des données publiques, il est recommandé d’utiliser un webservice. Les performances seront bien meilleures. |
Lancer un nombre de requêtes inutilement élevé sur des médias | Utilisez le service « playlist » au lieu d’appeler plusieurs fois le service « media ». |
Requêter des données qui ne seront pas utilisées | 3 exemples : – N’utilisez pas l’argument « rate » si vous n’affichez pas les votes, les notes ou les vues. – N’utilisez pas de valeurs excessives pour « &pagesize » – Ne forcez pas de langues pour lesquelles il n’existe pas de métadonnées (sous-titres, chapitres etc.) |
Faire des appels de services multiples à chaque chargement de page | Si une page appelle plusieurs services, mettez en place un cache sur vos serveurs et utilisez Ajax pour réduire les appels de services sur une page. |