Contactez nous
|
+1 888 882-1880
Du lundi au vendredi, de 8h00 à 20h00 (heure de l'Est)

UTILISATION DU MOTEUR DE CALCUL DE GOOGLE POUR LE TRANSCODAGE VIDÉO

bsp-admin-1 on July 23, 2012

Pour ceux d'entre nous qui travaillent dans le monde de l'informatique en nuage, la chose la plus excitante qui est ressortie de la conférence Google I/O en 2012 n'était pas des parachutistes portant des Glass, ni une nouvelle tablette. La grande nouvelle, c'est que Google se lance dans l'infrastructure en nuage en tant que service, actuellement dominée par Amazon Web Services (AWS). Plus précisément, Google a lancé un nouveau service appelé Google Compute Engine pour concurrencer Amazon EC2.

C'est passionnant. Le monde a besoin d'un autre service de machines virtuelles en nuage robuste, performant et bien conçu. Avec toutes nos excuses à Rackspace et à d'autres, il s'agit depuis longtemps d'un espace à un seul joueur - EC2 est de loin le leader. Google possède manifestement l'expertise et l'envergure nécessaires pour devenir un concurrent sérieux, s'il s'y tient.

Comment cela se présente-t-il ? Les premiers rapports sont positifs. Google Compute Engine (GCE) est bien conçu, bien exécuté et basé sur une infrastructure que Google utilise depuis des années. Les performances sont bonnes, notamment en ce qui concerne les entrées/sorties de disque, les temps de démarrage et la cohérence, qui n'ont jamais été le point fort d'EC2. Mais dans quelle mesure GCE est-il adapté au transcodage vidéo en nuage ? Nous disposons de quelques résultats préliminaires, tout en reconnaissant que d'autres tests doivent être effectués. Voici quelques tests de base de transcodage vidéo et de transfert de fichiers à l'aide du logiciel Zencoder sur GCE et EC2.

Vitesse de transcodage des données brutes

La performance est notre priorité absolue, c'est pourquoi Zencoder utilise les serveurs les plus rapides que nous puissions trouver. Sur EC2, nous utilisons des instances Cluster Compute, qui sont des machines rapides à double CPU en deux tailles : 4XL et 8XL. Nous les avons comparées au type d'instance GCE le plus rapide, qui est actuellement un serveur mono-CPU à 8 cœurs.

ServeurUNITÉ CENTRALE
GCE 8-coreIntel Xeon (Sandy Bridge - probablement E5-2670) - 8 cœurs à 2,60 GHz
EC2 cc1.4xlargeDouble Intel Xeon X5570 - 8 cœurs à 2,93 GHz/cœur
EC2 cc2.8xlargeDouble Intel Xeon E5-2670 - 16 cœurs à 2,60 GHz/cœur

Ces tests ont été effectués à l'aide d'une vidéo source H.264 aux résolutions 640×360 et 1280×720, et ont été encodés par Zencoder en utilisant les mêmes paramètres de transcodage de sortie en un seul passage (profil H.264 Baseline, AAC, transcodage de qualité constante en un seul passage, etc.)

Google Compute Engine vs. Amazon EC2

ServeurRésolutionEncodages simultanésTemps (secondes)Coût par millier
EC2 cc1.4xlarge640×360615.87$0.96
EC2 cc2.8xlarge640×36069.93$1.10
GCE 8-core640×360621.05$1.13
GCE 8-core640×36016.01$1.94
EC2 cc1.4xlarge640×36015.96$2.15
EC2 cc1.4xlarge1280×720648.58$2.92
EC2 cc2.8xlarge640×36014.99$3.33
EC2 cc2.8xlarge1280×720630.74$3.42
GCE 8-core1280×720668.15$3.66
EC2 cc1.4xlarge1280×720112.89$4.65
GCE 8-core1280×720116.01$5.16
EC2 cc2.8xlarge1280×720110.92$7.28

En utilisant les paramètres par défaut de Zencoder, les deux types d'instances EC2 sont plus rapides que GCE. Les résultats économiques sont un peu plus proches, et il n'y a pas de gagnant clair entre les instances EC2 4XL et GCE. Le GCE est donc une option viable pour le transcodage lorsque le coût est plus important que la vitesse brute, bien que les clients d'AWS puissent utiliser les instances réservées et les instances Spot pour réduire davantage les coûts. Nous avons remarqué que les instances EC2 à 16 cœurs étaient environ deux fois plus rapides que les instances GCE à 8 cœurs lorsqu'elles étaient chargées avec 6 transcodes simultanés.

Étant donné que les vitesses d'horloge sont similaires, mais que le nombre de cœurs est deux fois moins élevé, c'est ce à quoi on peut s'attendre. Toutefois, si Google ajoute des machines similaires à 16 cœurs, les vitesses de transcodage pourraient être comparables.

Vitesses de transfert

Lors du transcodage vidéo dans le nuage, les E/S réseau sont presque aussi importantes que l'unité centrale. C'est particulièrement vrai pour les clients qui travaillent avec du contenu à haut débit (diffuseurs, studios et créateurs). Comment les vitesses de transfert de GCE se comparent-elles à celles d'EC2 ? Pour le savoir, nous avons effectué quatre séries de tests de référence :

  • Amazon S3 vers Amazon EC2
  • Amazon S3 vers Google Compute Engine
  • Google Cloud Storage vers Amazon EC2
  • Google Cloud Storage vers Google Compute Engine

Pour ce faire, nous avons testé le même fichier vidéo de 1 Go stocké sur Google Cloud Storage (GCS) et sur Amazon S3. Le transfert a été effectué à l'aide de 10 connexions HTTP (Zencoder procède ainsi par défaut pour optimiser les vitesses de transfert, ce qui permet d'accélérer considérablement les transferts de fichiers volumineux par HTTP).

Vitesses de transfert GCE vs EC2

 Vitesse de transfert (Mbps)Largeur de bande du serveur
S3 à GCE470.961 Gbps
S3 vers EC2 c1.xlarge644.291 Gbps
S3 vers EC2 cc2.8xlarge1458.3210 Gbps
GCS à GCE202.601 Gbps
GCS vers EC2 c1.xlarge378.281 Gbps
GCS vers EC2 cc2.8xlarge641.3410 Gbps

C'est intéressant. Nous nous attendions à ce que le transfert d'Amazon à Amazon soit rapide, et il l'a été. Mais nous nous attendions également à ce que le transfert de Google à Google soit rapide, ce qui n'a pas été le cas. En fait, il semble que GCS soit plus lent que S3, et que le transfert GCE soit plus lent qu'EC2, de sorte que même si vous utilisez Google pour le calcul, il est préférable d'utiliser S3 pour le stockage. Le transfert a été 2,3 fois plus rapide de S3 à GCE que de GCS à GCE.

D'autres tests sont nécessaires

Considérez ces résultats comme préliminaires. D'autres tests doivent être effectués pour tenir compte d'un plus grand nombre de variables.

  • Différences d'une instance à l'autre. C'est particulièrement vrai pour le transfert de fichiers, qui peut varier considérablement en fonction des conditions du réseau et de la variabilité des instances.
  • Applications supplémentaires. Ces tests ne couvrent que le transcodage, qui est un test lié à l'unité centrale. Les autres applications sont limitées par le disque, la mémoire, etc., et ces tests ne concernent rien d'autre que le transcodage.
  • Évolutivité. L'évolutivité est extrêmement importante pour quiconque utilise le cloud pour le transcodage vidéo. D'autres tests sont nécessaires pour comparer GCE à EC2 lorsqu'il s'agit d'une échelle énorme - des dizaines de milliers de serveurs (ou plus). À quel moment les utilisateurs rencontrent-ils des problèmes de capacité ? Des problèmes de performance ? Limites de conception ? L'instabilité ?

L'avenir de l'infrastructure en nuage

Même si EC2 l'emporte dans ces premiers tests, nous sommes enthousiastes à propos de Google Compute Engine. Pour devenir un concurrent sérieux dans le domaine du transcodage haute performance, Google doit ajouter des instances plus importantes dotées d'unités centrales plus rapides. Mais il est facile d'ajouter de nouveaux types d'instances. Rien n'empêche Google de le faire. Ce qui est difficile, c'est de construire une plateforme en nuage robuste, performante, complète et évolutive, et Google semble y être parvenu. Si Google s'engage à long terme en faveur de ce produit et de ses développeurs, le monde de la virtualisation en nuage vient peut-être de se doter d'un deuxième acteur légitime.

SOUS-TITRAGE POUR LE WEB, LES MOBILES ET LA TV CONNECTÉE

bsp-admin-1 on July 13, 2012

Le sous-titrage est une bonne chose pour l'accessibilité et la facilité d'utilisation, et constitue une nouvelle étape dans la marche vers la maturité de la vidéo sur internet. Malheureusement, le sous-titrage n'est pas une technologie ou une "fonctionnalité" unique de la vidéo qui peut être "activée". Il existe un certain nombre de formats, de normes et d'approches.

Le sous-titrage est une sorte de désordre, tout comme le reste de la vidéo numérique, et représente un défi particulier pour les éditeurs multi-écrans. Si vous souhaitez publier aujourd'hui des vidéos pour le web, la téléphonie mobile et la télévision connectée, que devez-vous savoir sur le sous-titrage ?

Cet article présente les principes de base : le fonctionnement des sous-titres codés, les formats à connaître et la manière d'activer les sous-titres codés pour chaque écran.

Fonctionnement des sous-titres codés

La première chose à comprendre est la manière dont les sous-titres codés sont fournis, stockés et lus. Il existe aujourd'hui deux approches principales.

  • Incorporé dans une vidéo. CEA-608, CEA-708, DVB-T, DVB-S, WST. Ces formats de sous-titres sont écrits directement dans un fichier vidéo, soit sous forme de piste de données, soit intégrés dans le flux vidéo lui-même. La télévision de radiodiffusion utilise cette approche, tout comme iOS.
  • Stocké dans un fichier séparé. DFXP, SAMI, SMPTE-TT, TTML, EBU-TT (XML), WebVTT, SRT (texte), SCC, EBU-STL (binaire). Ces formats transmettent les informations sur les sous-titres à un lecteur en même temps que la vidéo, plutôt que de les intégrer dans la vidéo elle-même. Cette approche est généralement utilisée pour la lecture vidéo par navigateur.

Différences entre sous-titres et sous-titres codés

Qu'en est-il des sous-titres ? S'agit-il de la même chose que les sous-titres codés ? Il existe trois grandes différences.

  • Objectifs. Les sous-titres codés sont une fonctionnalité d'accessibilité, rendant la vidéo accessible aux malentendants, et peuvent inclure des indices sur la personne qui parle ou sur les sons qui se produisent : par exemple, "On frappe à la porte". Les sous-titres sont une fonctionnalité d'internationalisation, qui rend la vidéo accessible aux personnes qui ne comprennent pas la langue parlée. En d'autres termes, vous utiliserez les sous-titres pour regarder une vidéo en sourdine, et vous utiliserez les sous-titres pour regarder une vidéo dans une langue que vous ne comprenez pas. Remarque : cette distinction est valable en Amérique du Nord, mais la plupart des pays du monde ne font pas de distinction entre les sous-titres et les sous-titres codés.

  • Stockage. Historiquement, les sous-titres ont été intégrés dans la vidéo et les sous-titres ont été stockés à l'extérieur (voir CEA-608 ci-dessous). Cela a du sens d'un point de vue conceptuel, car les sous-titres doivent toujours être fournis avec une vidéo ; l'accessibilité à 100 % pour les malentendants est imposée par la législation. En revanche, les sous-titres ne sont nécessaires qu'occasionnellement; une vidéo en langue allemande diffusée en Allemagne n'a pas besoin d'être sous-titrée en allemand, alors que la même vidéo diffusée en France devrait l'être.

  • Lecture. Étant donné que les sous-titres sont transmis avec la vidéo et interprétés/affichés par un téléviseur ou un autre appareil grand public, les téléspectateurs peuvent les activer et les désactiver à tout moment à l'aide du téléviseur lui-même, mais ils disposent rarement d'options pour sélectionner une langue. Dans ces situations, lorsque des sous-titres sont ajoutés à des fins de traduction, il s'agit généralement de sous-titres en dur (voir ci-dessous) qui ne peuvent donc pas être désactivés. Toutefois, lors du visionnage d'un DVD/Blue-Ray/VOD, l'appareil de lecture contrôle l'affichage des sous-titres et la langue dans laquelle ils sont affichés.

Formats et normes

Il existe des dizaines de formats et de normes pour le sous-titrage codé et les sous-titres. Voici un aperçu des plus importants pour la vidéo sur internet.

  • CEA-608. Également appelés Line 21, les sous-titres CEA-608 constituent la norme NTSC, utilisée par la télévision analogique aux États-Unis et au Canada. Les sous-titres de la ligne 21 sont encodés directement dans une zone cachée du flux vidéo par les dispositifs de diffusion. Si vous avez déjà vu des barres et des points blancs en haut d'un programme, il s'agit du sous-titrage de la ligne 21.
  • SCC. Ce fichier contient des sous-titres au format Scenarist Closed Caption. Il contient des timecodes SMTPE avec les données de légende encodées correspondantes en tant que représentation des données CEA-608.
  • CEA-708. Il s'agit de la norme de sous-titrage pour les flux de télévision numérique ATSC (DTV) aux États-Unis et au Canada. Il n'existe actuellement aucun format de fichier standard pour stocker les sous-titres CEA-708 en dehors d'un flux vidéo.
  • TTML. Le TTML (Timed Text Markup Language) décrit la synchronisation du texte et d'autres médias tels que l'audio ou la vidéo. Voir la recommandation TTML du W3C pour plus d'informations.
  • DFXP. Il s'agit d'un profil de TTML défini par le W3C. Les fichiers DFXP contiennent du TTML qui définit quand et comment afficher les données de légende. DFXP est l'abréviation de Distribution Format Exchange Profile (profil d'échange de format de distribution). DFXP et TTML sont souvent utilisés comme synonymes.
  • SMPTE-TT. La Society of Motion Picture and Television Engineers - Timed Text est une extension du profil DFXP qui prend en charge trois extensions présentes dans d'autres formats de sous-titrage et éléments d'information, mais pas dans DFXP : #data, #image et #information. SMPTE-TT est également le format Safe Harbor de la FCC. Si un producteur de contenu vidéo fournit des sous-titres dans ce format à un distributeur, il s'est acquitté de son obligation de fournir des sous-titres dans un format accessible. Toutefois, les producteurs de contenu vidéo et les distributeurs sont libres de convenir d'un format différent.
  • SAMI. Synchronized Accessible Media Interchange est basé sur HTML et a été développé par Microsoft pour des produits tels que Microsoft Encarta Encyclopedia et Windows Media Player. SAMI est pris en charge par un certain nombre de lecteurs vidéo de bureau.
  • EBU-STL. Il s'agit d'un format binaire utilisé par la norme UER, stocké dans des fichiers .STL séparés.
  • EBU-TT. Il s'agit d'un format plus récent soutenu par l'UER, basé sur TTML. L'EBU-TT est un sous-ensemble strict du TTML, ce qui signifie que les documents EBU-TT sont des documents TTML valides, mais que certains documents TTML ne sont pas des documents EBU-TT valides parce qu'ils incluent des caractéristiques non prises en charge par l'EBU-TT.
  • SRT. Il s'agit d'un format créé par SubRip, un outil open source basé sur Windows qui permet d'extraire des sous-titres d'une vidéo. SRT est largement pris en charge par les lecteurs vidéo de bureau.
  • WebVTT. Il s'agit d'un format de texte similaire à SRT. Le groupe de travail sur la technologie de l'application hypertexte du Web (WHATWG) a proposé WebVTT comme norme pour le sous-titrage vidéo HTML5.
  • Sous-titres difficiles à lire (hard subtitles). Par définition, les sous-titres en dur ne sont pas des sous-titres codés. Les sous-titres en dur sont des textes superposés qui sont encodés dans la vidéo elle-même, de sorte qu'ils ne peuvent pas être activés ou désactivés, contrairement aux sous-titres codés ou aux sous-titres non codés. Dans la mesure du possible, il est généralement préférable d'opter pour des sous-titres logiciels ou des sous-titres codés, mais les sous-titres en dur peuvent être utiles lorsqu'ils sont destinés à un appareil ou à un lecteur qui ne prend pas en charge les sous-titres codés.

Le sous-titrage pour tous les appareils

Quels formats sont utilisés par quels appareils et quels acteurs ?

  • HTML5. Les sous-titres ne sont pas encore largement pris en charge par les navigateurs, mais cela changera avec le temps. Il existe deux normes concurrentes : TTML, proposée par le W3C, et WebVTT, proposée par le WHATWG. À l'heure actuelle, Chrome offre une prise en charge limitée de WebVTT ; Safari, Firefox et Opera travaillent tous à la prise en charge de WebVTT ; et Internet Explorer 10 prend en charge à la fois WebVTT et TTML. En attendant que les navigateurs prennent en charge un format de manière native, un lecteur HTML5 comme Video.js peut prendre en charge les sous-titres par le biais de Javascript, en analysant un fichier externe (Video.js prend actuellement en charge les sous-titres WebVTT).
  • iOS. Apple adopte une approche différente et utilise les sous-titres CEA-608 à l'aide d'une version modifiée de l'encodage CEA-708/ATSC. Cela signifie que, contrairement à HTML5, les sous-titres doivent être ajoutés au moment du transcodage. Brightcove Zencoder peut ajouter des sous-titres aux vidéos HTTP Live Streaming pour iOS.
  • Android. La prise en charge des lecteurs vidéo est encore fragmentée et problématique. La prise en charge des légendes dépendra évidemment de la version du système d'exploitation et du lecteur utilisé.
  • Autres appareils mobiles. Certains ne prennent pas du tout en charge les sous-titres codés, et les sous-titres en dur peuvent être la seule option.
  • Roku. Prise en charge des sous-titres par le biais de fichiers SRT externes.
  • Autres plateformes de télévision connectée. Certaines ne prennent pas encore en charge le sous-titrage. Mais cela ne saurait tarder. Tous les téléviseurs, consoles, boîtiers de câblodistribution et lecteurs Blu-Ray disponibles sur le marché aujourd'hui veulent diffuser du contenu internet en continu et, d'ici un an et demi, le sous-titrage deviendra une obligation. Sony, Samsung, Vizio, Google TV, etc. finiront donc par intégrer la prise en charge des sous-titres dans leurs cadres de développement d'applications. Malheureusement, les formats utilisés ne sont pas encore clairs. Il est fort probable que les différentes plateformes continueront à prendre en charge une variété de formats incompatibles pendant de nombreuses années.

Exigences en matière de sous-titrage codé

Le paysage du sous-titrage évoluera et se développera au fil du temps, mais en 2012, voici les exigences les plus courantes pour la prise en charge du sous-titrage sur les appareils les plus courants.

  • Un lecteur web avec des commandes côté lecteur pour activer et désactiver le sous-titrage.
  • Un fichier externe contenant des données de sous-titrage, probablement dans un format tel que WebVTT, TTML ou SRT. Plusieurs fichiers peuvent être nécessaires (par exemple, SRT pour Roku et WebVTT pour HTML5).
  • Un transcodeur qui prend en charge les sous-titres intégrés pour la diffusion en direct HTTP sur iPad/iPhone, comme Zencoder. Zencoder peut accepter des informations de sous-titrage dans une variété de formats, y compris TTML, de sorte que les éditeurs pourraient utiliser un seul fichier TTML pour la lecture sur le web et comme entrée dans Zencoder pour la vidéo iOS.

Au-delà, les choses se compliquent. D'autres formats d'entrée peuvent être nécessaires pour d'autres appareils, et des sous-titres en dur sont probablement nécessaires pour assurer une compatibilité totale avec les appareils existants.

Zencoder et sous-titres Brightcove

Brightcove Zencoder prend en charge le sous-titrage pour deux formats : Les sous-titres de style CEA-608 pour les appareils iOS utilisant HLS, et les fichiers MP4 avec les pistes de sous-titres CEA-608. Du côté de l'entrée, nous prenons en charge les pistes de sous-titres SCC, SAMI, DFXP/TTML/SMPTE-TT et CEA-608 dans les fichiers MP4.

Jusqu'à présent, nous avons choisi de nous concentrer sur les sous-titres intégrés, car ces formats sont ajoutés aux fichiers vidéo au moment du transcodage. Ainsi, si nous ne prenions pas en charge le sous-titrage pour l'iPad ou l'iPhone, nos clients publiant sur ces appareils ne pourraient pas utiliser les sous-titres codés. À l'avenir, nous élargirons la gamme des formats de sous-titres que nous acceptons et nous pourrons proposer des services tels que la conversion de format pour les fichiers de sous-titres externes (par exemple, TTML vers WebVTT).

En attendant, avec un seul fichier de sous-titres et le bon lecteur HTML5, les clients de Brightcove ont tout ce qu'il faut pour créer des vidéos sous-titrées pour le Web, les mobiles et les périphériques TV connectés.

APP CLOUD : RAPPORT D'EXPÉRIENCE D'UN DÉVELOPPEUR WEB

bsp-admin-1 on February 24, 2012

Au cours de mes 13 années d'expérience en tant que développeur et concepteur de sites web, je me suis adapté sans effort aux nouvelles technologies, en commençant par Java, puis PHP, et plus tard Ruby. Pendant longtemps, j'ai été immergé dans le "Flash steamer", explorant les principales bibliothèques d'interface utilisateur telles que Prototype et jQuery tout en restant au fait de l'évolution rapide des normes web.

Cependant, comme beaucoup de développeurs web, je n'ai pas franchi le pas vers les applications mobiles. Je manquais d'expérience dans les langages de bas niveau comme C++ ou Objective-C et je n'avais pas le temps de les apprendre. L'idée de créer de "petites" applications en Java - un langage que je trouvais volumineux et extensif - ne m'attirait pas non plus.

J'ai exploré plusieurs outils de développement multiplateforme, mais ils n'ont jamais répondu à mes attentes :

  • Les "usines" d'applications qui intègrent les flux RSS dans des modèles préconstruits créent des applications génériques et peu inspirées.
  • Les cadres convertissant JavaScript ou ActionScript en code natif nécessitaient des chaînes d'outils complexes pour la création et la compilation des applications.
  • Les cadres qui enveloppent les pages web dans des coquilles natives offrent peu d'infrastructures pour le déploiement d'applications basées sur les données dans des environnements de production.

Lorsque j'ai découvert App Cloud, un cadre de travail permettant de créer des applications mobiles natives à l'aide de HTML, CSS et JavaScript, j'étais sceptique. Serait-il différent des autres ? Pouvait-il tenir ses promesses ? Après avoir développé ma première application, je peux dire en toute confiance que la réponse est "Oui !". Voici pourquoi.

APP CLOUD PARLE LE LANGAGE DES DÉVELOPPEURS

App Cloud s'appuie sur les compétences de base des développeurs web : HTML pour structurer le contenu, CSS pour le mettre en forme et JavaScript pour le modifier. Il n'est pas nécessaire d'apprendre de nouveaux langages pour créer des applications riches et axées sur le contenu. Les technologies web ont toujours excellé par leur simplicité. Comparez la complexité de la création d'un tableau dans iOS à la facilité de création d'une liste HTML de base : c'est sans appel !

Le SDK d'App Cloud prend également en charge presque toutes les bibliothèques JavaScript, ce qui me permet d'appliquer les astuces que j'ai apprises au cours de mes années de développement web.

SUR LA VOIE RAPIDE AVEC APP CLOUD

Je passe fréquemment de BBEdit à vim lorsque je code, car ce sont les outils qui me conviennent le mieux. App Cloud me permet de continuer à utiliser ces éditeurs familiers. Comme il s'appuie sur des technologies web standard, je peux également déboguer et tester mon code avec Chrome Developer Tools. Contrairement aux systèmes encombrants liés à XCode ou Eclipse, App Cloud offre flexibilité et liberté.

L'ITÉRATION RAPIDE AVEC L'APPLICATION DE L'ATELIER

L'application d'atelier App Cloud pour iOS et Android permet d'effectuer des tests en temps réel pendant le développement. Après avoir apporté des modifications au code, il me suffit de cliquer sur "Rafraîchir" pour voir immédiatement les mises à jour. Pour les développeurs web habitués aux processus itératifs (coder, rafraîchir, répéter), cette fonctionnalité est inestimable.

Bien que de nombreux tests puissent être effectués sur des navigateurs de bureau, rien ne vaut l'observation des performances d'une application sur des appareils réels. L'application Atelier permet de le faire facilement et en toute transparence.

TIRER PARTI DES CARACTÉRISTIQUES PROPRES À L'APPAREIL

App Cloud propose une API JavaScript simple pour accéder aux fonctionnalités propres à l'appareil, telles que l'appareil photo ou la photothèque. Par exemple, scanner un code QR est aussi simple que :

bc.device.getQRCode(
function (data) { /* handle success */ },
function (error) { bc.device.alert("Oops! " + error.errorMessage); }
);

COMPILATION SIMPLIFIÉE DES APPLICATIONS

La compilation d'applications avec d'autres outils, comme les kits de développement Android, s'apparente souvent au montage d'un meuble IKEA : fastidieux et frustrant. Avec App Cloud Studio, les applications sont compilées dans le nuage en quelques clics. En quelques minutes, l'application est prête à être téléchargée et déployée sur les différents magasins d'applications, sans nécessiter d'outils particuliers.

OPTIMISATION DU CONTENU : MOINS, C'EST MIEUX

Dans les applications axées sur le contenu, le contenu lui-même est souvent le goulot d'étranglement. App Cloud optimise les performances en :

  • Suppression des données inutiles, compression des flux et mise en cache du contenu. Par exemple, le flux de mon blog est passé de 39 Ko à 4 Ko, soit une réduction de 90 %.
  • Transcodage des images pour réduire la taille des fichiers. Une image est passée de 125 Ko à 425 pixels de large à 8 Ko à 200 pixels de large, soit une réduction de 94 %.

Ces optimisations améliorent considérablement les temps de chargement, qui sont essentiels à l'engagement des utilisateurs.

LA FLEXIBILITÉ AU-DELÀ DU DÉPLOIEMENT

Contrairement à d'autres outils, App Cloud Studio me permet de modifier les données, la conception et les paramètres après le déploiement, sans qu'il soit nécessaire de recompiler ou de redistribuer l'application. Cette flexibilité me permet de créer plusieurs applications à partir d'un seul modèle en intervertissant les flux de données et en ajustant les paramètres.

LA COLLABORATION FACILITÉE

App Cloud facilite le partage des applications avec les collègues. Des captures d'écran peuvent être partagées directement à partir de l'application de l'atelier, ou des modèles peuvent être distribués via des URL ou des codes QR, ce qui permet une collaboration et des tests efficaces.

GESTION COMPLÈTE DE L'INFORMATIQUE EN NUAGE

App Cloud offre tout ce dont j'ai besoin pour gérer et monétiser les applications, de la diffusion de publicités natives à l'analyse en temps réel. Je peux suivre les installations, le temps d'utilisation et d'autres indicateurs clés.

En outre, App Cloud offre gratuitement des améliorations de performance et des mises à jour de fonctionnalités. Les améliorations futures, telles que les notifications push et les achats in-app, rendront la plateforme encore plus puissante.

App Cloud combine la simplicité du développement web avec la fonctionnalité des applications natives, ce qui en fait un outil indispensable pour les développeurs qui cherchent à créer des applications mobiles efficaces, évolutives et attrayantes.

PARAMÈTRES D'ENCODAGE POUR UNE VIDÉO IPAD/IPHONE PARFAITE

bsp-admin-1 on January 24, 2012

Tout éditeur vidéo sérieux prend déjà en charge l'iPad et l'iPhone ou doit réfléchir sérieusement à la possibilité de le faire. Pour certains grands éditeurs, la diffusion sur iPad représente un tiers du total des vidéos vues, voire plus.

L'encodage pour iOS est cependant un peu délicat. Ces appareils ont connu plusieurs générations de capacités techniques, et les paramètres vidéo idéaux pour l'iPhone 4 ne le sont pas pour l'iPhone 3GS ou l'iPad.

Heureusement, quelques profils d'encodage suffisent pour diffuser des vidéos de haute qualité sur tous les appareils iOS, du premier iPhone à l'iPad 2, et même pour préparer les futures générations d'appareils mobiles.

Paramètres généraux

Comme la plupart des vidéos actuelles, utilisez la vidéo h.264 et l'audio AAC lorsque vous ciblez iOS.

On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio.

En ce qui concerne la vidéo, utilisez plusieurs profils pour cibler chaque appareil. L'iPhone 3GS et les modèles antérieurs ne prennent en charge que le profil h.264 Baseline, niveau 3.0 (et certains prennent en charge une version plus limitée), tandis que les appareils plus récents prennent en charge les profils Main et High.

Pour une expérience utilisateur optimale, le HTTP Live Streaming (HLS) est indispensable. Apple l'exige pour toutes les applications vidéo de l'App Store qui diffusent des contenus de plus de 10 minutes, et c'est le seul véritable format de diffusion en continu pris en charge par iOS. Le HLS est également adopté par Android (version 3+), Roku et une série d'autres destinations.

Approche générale

RésolutionProfilBitrate@ 16:9@ 4:3AudioCommentaires
1024×768[email protected]2Mbps1024×5761024×76856kbps HE-AAC 
960×640[email protected]1.5Mbps960×540854×64056kbps HE-AAC 
640×432[email protected]1Mbps640×360576×43256kbps HE-AAC 
480×320[email protected]600kbps480×272426×32056kbps HE-AAC 
400×288[email protected]400kbps400×224384×28856kbps HE-AAC 
400×288[email protected]200kbps400×224384×28856kbps HE-AACdécimer le taux de rafraîchissement
N/A (Audio uniquement)    56kbps HE-AAC 

Pourquoi ces recommandations ?

  • Il ne s'agit que de recommandations. Des résolutions et des débits différents sont parfaitement valables et peuvent même être préférables dans certaines circonstances. Par exemple, un contenu extrêmement complexe peut justifier des débits binaires plus élevés.
  • 720p est la plus grande vidéo lisible sur l'iPad 1 et l'iPhone 4, et l'iPad 2/iPhone 4S lit tout ce qui va jusqu'à 1080p. Mais comme l'écran natif ne fait que 1024 pixels de large, il n'est pas indispensable d'aller jusqu'à 720p ou 1080p. Sauf, bien sûr, si vous souhaitez réutiliser une vidéo ailleurs - le 720p est une excellente résolution pour la lecture en plein écran sur le web, et le 1080p est tout à fait approprié pour les téléviseurs connectés. Selon les rumeurs, les futurs iPad auront une résolution quatre fois supérieure à celle de l'iPad actuel ; envisagez donc d'ajouter le 720p pour vous prémunir contre l'avenir.
  • Le profil h.264 est important. L'iPad 1 et l'iPhone 4 prennent tous deux en charge le profil principal. L'iPad 2/iPhone 4S prend en charge le profil High, qui est légèrement meilleur que le profil Main, mais étant donné le nombre d'appareils iPad 1 dans le monde, il est probablement préférable de s'en tenir au profil Main. Pour un ciblage optimal des appareils, il convient d'encoder à la fois en profil principal et en profil élevé.
  • Ces six résolutions et débits binaires permettent de couvrir assez bien les différentes bandes passantes. Vous pouvez certainement en faire plus, alors ajoutez ou soustrayez des résolutions et des profils à votre guise.
  • Les utilisateurs de l'ancien iPhone/iPod Touch disposeront de trois flux, dont une vidéo de qualité raisonnable 480×320 (la résolution de l'écran de ces appareils). Les utilisateurs de l'iPad et de l'iPhone 4 pourront utiliser les six flux.
  • L'échelle de résolution de l'iPad est assez bonne, de sorte que les vidéos qui sont redimensionnées ont généralement une bonne apparence.
  • Dans la mesure du possible, ces paramètres permettent de diviser les dimensions de la résolution par 16. Cela permet une compression plus efficace. Les gains d'efficacité sont faibles, en particulier pour les résolutions élevées, mais ils commencent à faire la différence pour les résolutions plus faibles.
  • Veillez à ce que l'audio soit identique sur chaque vidéo. Si les spécifications audio changent d'une version à l'autre, l'utilisateur peut entendre des bruits parasites et des clics pendant la lecture lorsqu'il passe d'un flux à l'autre.

Autres paramètres

  • Définissez la vitesse en fonction du délai d'exécution souhaité. Pour ces recommandations, nous allons utiliser la vitesse 2, qui améliore légèrement la compression par rapport à la ligne de base, mais reste raisonnablement rapide.
  • Veillez à ce que chaque segment soit à peu près de la même taille en utilisant un pic bitrate\_cap de 150% du débit cible, mais dans un délai long. buffer\_size (par exemple, cinq secondes, ou 5 fois la durée de la bitrate\_cap).
  • Brightcove choisit automatiquement l'emplacement des images clés lorsque vous définissez le type sur " segmenté ". Si vous encodez en MP4 pour une segmentation séparée en HLS, définissez forced\_keyframe\_rate à "0.2" ou "0.1" (pour des intervalles d'images clés de 5 ou 10 secondes, respectivement).
  • Si vous pouvez accepter des débits binaires légèrement imprévisibles, ajouter de la qualité au mixage et modifier les paramètres d'enregistrement, vous serez en mesure d'améliorer la qualité de l'enregistrement. video\_bitrate à max\_video\_bitrate pour optimiser la taille du fichier. Le codeur utilisera le débit maximal si nécessaire et un débit inférieur s'il peut obtenir la qualité souhaitée avec moins de bits.
  • Régler le max\_frame\_rate à 30 et le max\_audio\_sample\_rate à 48000.
  • La première génération d'appareils iOS n'autorise qu'un seul fichier h.264 reference\_frameIl faut donc l'activer sur les flux de la ligne de base pour une compatibilité maximale.

Intégration de Brightcove Video Cloud et de Google Analytics

bsp-admin-1 on November 1, 2011

Dans cet article, nous vous présentons un programme d'intégration de Google Analytics qui vous permet de mesurer les vidéos à l'aide de Google Analytics. Le programme d'intégration Google Analytics peut être utilisé si vous avez un contrat Video Cloud et que vous disposez déjà de Google Analytics.

L'UTILISATION DE VIDÉOS EN LIGNE : BRICOLAGE VS. SOCIAL VS. OVP

bsp-admin-1 on July 13, 2011

De plus en plus d'entreprises découvrent le potentiel diversifié des vidéos en ligne : leur immense popularité auprès des utilisateurs, leur capacité à susciter des émotions, les excellentes opportunités de marketing, l'augmentation significative des ventes de produits et même l'amélioration du classement dans les moteurs de recherche. Cependant, nombre d'entre elles négligent les défis et les obstacles uniques associés à l'exploitation efficace des vidéos.

Même avec un concept vidéo cohérent et des clips produits par des professionnels, une question essentielle demeure : Comment les vidéos doivent-elles être intégrées au site web de l'entreprise ? Il existe trois options principales.

1. SOLUTIONS DIY

La première option est une solution individuelle. Un employé (que l'on espère qualifié) encode les vidéos, programme un lecteur Flash ou configure un lecteur disponible gratuitement, télécharge les vidéos sur un serveur HTTP et les intègre au site web.

Si cette approche peut fonctionner pour un petit nombre de vidéos avec un nombre limité de vues, elle devient rapidement impraticable lorsqu'il s'agit d'un plus grand nombre de vidéos ou d'un trafic plus important. Cette solution bricolée peut devenir désorganisée, sujette aux erreurs, exigeante en termes de maintenance et chronophage.

2. LES SITES DE VIDÉO SOCIALE

La deuxième option consiste à utiliser des sites de vidéos sociales comme YouTube. En téléchargeant des vidéos sur ces plateformes, les entreprises reçoivent des codes d'intégration pour intégrer les vidéos dans leurs sites web. Ces sites offrent des statistiques relativement solides sur l'utilisation des vidéos, et les vidéos peuvent être découvertes non seulement sur le site web de l'entreprise, mais aussi par le biais de la recherche sur YouTube.

Cette solution présente toutefois des inconvénients importants. En téléchargeant des vidéos sur YouTube, les entreprises renoncent partiellement à leurs droits, ce qui permet à YouTube de commercialiser les vidéos, avec pour conséquence que des publicités de concurrents pourraient être diffusées avant le contenu de l'entreprise. En outre, YouTube conserve le contrôle de l'apparence et des spécifications techniques de la vidéo, ce qui rend les entreprises dépendantes des décisions de la plateforme. Dans ce scénario, les entreprises cèdent le contrôle à YouTube et doivent accepter les changements ou les limitations qui leur sont imposés.

3. PLATES-FORMES VIDÉO EN LIGNE (OVPS)

C'est là que Brightcove intervient en tant que troisième option, la plus professionnelle. Un OVP combine la personnalisation d'une solution bricolée avec les capacités techniques d'un site de vidéo sociale, tout en offrant une sécurité juridique et un contrôle total.

Bien sûr, un PVO nécessite un investissement, mais il n'est pas différent des autres outils et systèmes professionnels que les entreprises utilisent couramment. Pour un coût relativement faible, les clients ont accès à un système complet, bien entretenu et constamment amélioré.

PRINCIPAUX AVANTAGES DE L'OVPS

  • Une diffusion fiable : Les vidéos sont diffusées via des réseaux de diffusion de contenu (CDN), ce qui garantit des performances sans solliciter les serveurs de l'entreprise.
  • Des analyses détaillées : Les OVP fournissent des statistiques détaillées sur les vidéos visionnées, ce qui permet aux entreprises de mesurer l'efficacité et d'en tirer des enseignements pour les productions futures.
  • Contrôle total : Les vidéos restent sous le contrôle total de l'entreprise, avec la possibilité d'intégrer la monétisation par le biais de connexions à des serveurs publicitaires ou à des réseaux publicitaires.
  • Optimisation des flux de travail : Les OVP minimisent les tâches et les risques techniques, rationalisant ainsi les processus de production et de distribution vidéo.

Les plateformes vidéo en ligne sont conçues spécifiquement pour l'utilisation professionnelle des vidéos. Elles permettent aux entreprises d'optimiser les flux de travail, de réduire les défis techniques et d'utiliser les vidéos sur Internet de manière efficace, sécurisée et rentable. En investissant dans une plate-forme vidéo en ligne, les entreprises peuvent exploiter tout le potentiel des vidéos en ligne tout en gardant un contrôle total et en garantissant un succès à long terme.

10 CONSEILS POUR L'ENCODAGE ET LA LECTURE DE VIDÉOS DE HAUTE QUALITÉ

bsp-admin-1 on June 17, 2011

L'équipe chargée de la communauté et des connaissances a examiné les tendances de recherche sur notre site d'assistance, les nombreuses demandes adressées à notre équipe d'assistance à la clientèle et les forums afin de déterminer le type de sujets que vous recherchez et sur lesquels vous posez des questions. L'une des tendances observées concerne les questions relatives aux meilleures pratiques d'encodage et aux conseils pour une lecture vidéo de haute qualité.

L'encodage est un sujet très vaste, mais nous avons établi une liste des 10 principaux éléments à prendre en compte lors de l'encodage de vos vidéos en vue de leur chargement dans Brightcove.

1. Encoder pour une prise en charge étendue des appareils

Afin de garantir la prise en charge d'un grand nombre de périphériques, nous vous recommandons d'encoder vos vidéos en h.264. Le chargement de vidéos au format h.264 vous permet de personnaliser davantage votre contenu Brightcove. De plus, ces vidéos sont diffusées avec une qualité supérieure et une bande passante réduite par rapport à de nombreux autres encodages.

Le format H.264 permet une prise en charge étendue des appareils, car il offre les meilleures options pour la diffusion de vidéos mobiles et est le seul format qui peut être lu sur nos lecteurs intelligents HTML5. Les lecteurs intelligents diffuseront votre vidéo en Flash ou en HTML5, selon les capacités de l'appareil de l'utilisateur. Cela vous permet d'utiliser un seul lecteur Brightcove qui peut diffuser la vidéo en Flash ou en HTML5. Vous n'avez donc pas besoin de créer et de gérer des lecteurs distincts pour chaque environnement de spectateur et vos lecteurs existants peuvent se charger automatiquement en mode Flash ou HTML5 sans aucun travail personnalisé ou JavaScript supplémentaire de votre part.

2. Utiliser la diffusion en continu à plusieurs débits

Si vous avez un public diversifié qui regarde vos vidéos depuis le monde entier avec de grandes différences de bande passante et de connectivité internet, l'utilisation de la diffusion en continu à plusieurs débits est indispensable.

Pour ceux qui disposent d'une bande passante plus large, une vidéo de haute qualité (peut-être même votre source) sera diffusée automatiquement. Les internautes disposant d'une bande passante plus faible n'auront pas à subir de longs délais de mise en mémoire tampon, mais pourront au contraire regarder instantanément une vidéo de qualité légèrement inférieure.

En revanche, si vos vidéos sont uniquement visionnées, par exemple, sur un réseau interne doté d'une connexion internet très puissante, vous pouvez vous contenter de télécharger une seule vidéo de haute qualité avec un seul rendu.

3. Préserver votre fichier source sous forme de rendu

Si votre fichier vidéo source est au format h.264, vous pouvez choisir de conserver votre fichier source original comme rendu disponible. Cette option vous permet de conserver un master h.264 dont le niveau de qualité peut être encore plus élevé que le rendu de qualité supérieure de Brightcove.

De plus, lorsque vous sélectionnez cette option, votre vidéo source h.264 est disponible immédiatement, dès que le téléchargement est terminé, et vous n'avez pas besoin d'attendre que la vidéo soit transcodée pour qu'elle soit disponible dans le module médias et dans vos lecteurs.

4. Capturer des vidéos à une fréquence d'images constante

Pour éviter les bégaiements lors de la lecture, enregistrez la vidéo à une fréquence d'images constante de 25 à 30 images par seconde et filmez à une fréquence d'images constante d'environ 24 images par seconde.

5. Tenez compte du contenu que vous téléchargez

Les vidéos factuelles ou d'actualité requièrent généralement une qualité inférieure à celle d'une vidéo plus longue et pleine d'action ou d'un film sur la nature, qui nécessitera une qualité nettement supérieure.

Si vous produisez des vidéos de screencast avec très peu d'action, hormis le changement occasionnel d'une diapositive, veillez à exporter la vidéo au format h.264 avec le même rapport hauteur/largeur que votre enregistrement et utilisez certaines de ces techniques pour configurer votre lecteur.

Encodage en une passe ou en deux passes

En général, un encodage en deux passes produit un meilleur transcodage qu'un encodage en une passe. Cependant, l'encodage en deux passes prend beaucoup plus de temps. Pour les vidéos comportant beaucoup de mouvements, nous recommandons de prendre le temps d'exporter en deux passes. Vous pouvez également effectuer un test de comparaison pour déterminer s'il y a une différence notable et garder un œil sur les transitions ou les zones de mouvement intense. Si vous ne constatez pas de différence notable, conservez la méthode à un seul passage et gagnez du temps.

6. Télécharger le fichier source de meilleure qualité

Bien que Brightcove puisse préserver la qualité de votre fichier source et créer plusieurs niveaux de rendus, nous ne pouvons pas créer des rendus de meilleure qualité que le fichier source que vous nous fournissez. Nous vous proposons une liste de recommandations de fichiers sources et de paramètres d'exportation pour vous aider à créer un fichier source de qualité optimale à charger dans votre compte Brightcove.

7. Ne pas ignorer la qualité audio

La plupart des gens se concentrent sur la meilleure qualité d'image possible dans leurs vidéos et ignorent complètement le son. Cependant, les spectateurs de vos vidéos sont beaucoup plus susceptibles d'abandonner si la qualité audio est mauvaise ou hachée que si la vidéo est d'une qualité légèrement inférieure.

En général, si un utilisateur ne peut pas entendre ce qui est dit dans une vidéo, il n'y a pas lieu de continuer à la regarder. Veillez à utiliser un bon microphone lors de l'enregistrement de vos vidéos et tenez compte des paramètres sonores recommandés.

Meilleures pratiques en matière de réglage audio

  • Codec. Sélectionnez "AAC" lors de l'encodage d'une vidéo h.264.
  • Fréquence d'échantillonnage. En cas de doute, choisissez 44,1 kHz ou 48 kHz.
  • Débit binaire. Utilisez 128-160 kbps, ou 192 kbps+ pour les contenus à forte composante audio.

8. Désentrelacement des vidéos analogiques

Si vous travaillez avec du contenu filmé sur bande, nous vous recommandons vivement de cocher la case Désentrelacement de la vidéo source lors de l'exportation afin d'éviter tout effet d'entrelacement sur votre contenu Brightcove. Si votre contenu a été enregistré au format numérique et n'est pas entrelacé, il n'est pas nécessaire de le désentrelacer.

9. Modifier les paramètres de transcodage

Si vous disposez d'un compte d'édition professionnelle ou d'entreprise, vous avez la possibilité de modifier vos paramètres de transcodage directement dans Brightcove Studio. Par défaut, six rendus sont disponibles dans votre profil de transcodage. Cependant, si vous avez une clientèle très diversifiée qui visionne vos vidéos sur différents appareils et vitesses de connexion, vous pouvez ajouter des rendus supplémentaires (jusqu'à 10). Les paramètres de conversion par défaut de Brightcove fournissent un bon ensemble de rendus de base qui devrait répondre aux besoins de la plupart des éditeurs et des spectateurs.

10. Autoriser le lissage vidéo

Les lecteurs Brightcove peuvent utiliser le lissage vidéo pour améliorer la qualité perçue de la lecture vidéo. Il y a cependant un compromis entre la qualité supplémentaire que vous pouvez obtenir en utilisant le lissage vidéo et la charge de CPU supplémentaire que le lissage vidéo impose au client.

Avec des débits binaires vidéo plus élevés, les avantages du lissage vidéo sont moins perceptibles. Les spectateurs, en particulier ceux qui disposent d'ordinateurs moins puissants, peuvent percevoir une qualité vidéo plus hachée en raison de la perte d'images, ce qui peut l'emporter sur les avantages du lissage vidéo.

Par défaut, Brightcove utilise le lissage vidéo pour les vidéos dont le débit est inférieur à 950 kbps et n'utilise pas le lissage vidéo pour les vidéos dont le débit est supérieur ou égal à 950 kbps.

Vous pouvez modifier le comportement par défaut du lissage vidéo en incluant l'option videoSmoothing dans le code de publication de votre lecteur et lui attribuer la valeur " true " (lissage vidéo toujours utilisé) ou " false " (lissage vidéo jamais utilisé).

PARAMÈTRES D'ENCODAGE POUR LA DIFFUSION DE VIDÉOS HD DE QUALITÉ

bsp-admin-1 on January 20, 2011

Brightcove permet aux éditeurs de diffuser du contenu HD sur le Web. Mais vous devez vous assurer que vous encodez correctement vos fichiers sources pour profiter de nos capacités de diffusion en continu de haute qualité. Pour ceux d'entre nous qui pensent que " 4:2:2 pulldown " ressemble à une langue étrangère, il est utile d'avoir une explication simple sur la manière de fournir un véritable flux vidéo haute définition.

Étape 1 : Savoir comment ça marche

Brightcove utilise la technologie de diffusion en continu à plusieurs débits pour offrir aux spectateurs la meilleure qualité vidéo que leur vitesse Internet peut supporter. Cela signifie que nous créons jusqu'à six rendus de votre vidéo à des résolutions et des débits différents pour une grande variété de connexions Internet, des lignes de bureau T3 ultra-rapides aux connexions mobiles 3G parfois peu performantes. Nos lecteurs vidéo détectent la vitesse Internet des spectateurs et leur proposent le rendu approprié de votre vidéo.

Si vous souhaitez utiliser les paramètres par défaut de Brightcove, il vous suffit de charger un fichier à la résolution et au débit les plus élevés dont vous disposez. Les paramètres par défaut prennent en charge la quasi-totalité des codecs vidéo et des conteneurs utilisés aujourd'hui, et votre rendu de la meilleure qualité sera une résolution très respectable de 1280×960 (1280×720 pour les formats 16:9) à environ 1,8 Mbps. Cela dit, si vous êtes prêt à prendre quelques mesures supplémentaires, vous serez en mesure de diffuser du contenu vidéo HD via Brightcove.

Étape 2 : Téléchargement en H.264 et préservation du fichier source en tant que rendu

Étant donné que le processus de conversion de Brightcove limite le rendu de la meilleure qualité à 1280×960 à 1,8 Mbps, la clé pour obtenir la meilleure qualité possible de Brightcove est de charger votre vidéo dans un format que nous pouvons diffuser par le biais de nos lecteurs sans nécessiter de conversion . Ce format est le h.264.

Les vidéos H.264 peuvent être lues sur les PC, les appareils iOS et les appareils Android. En raison de sa grande compatibilité avec les appareils et les systèmes d'exploitation, il s'agit du format vidéo préféré de Brightcove. Ainsi, Brightcove vous offre la possibilité de préserver une source H.264 et de l'ajouter à la liste des rendus disponibles de la vidéo. Le résultat final est constitué des six rendus par défaut de Brightcove, ainsi que de votre fichier source tel que vous l'avez encodé sur votre machine.

Étape 3 : Encodage de votre fichier source en HD adapté au Web

Lors de l'encodage d'une vidéo pour Brightcove, la qualité et l'accessibilité de la lecture sont les éléments clés à prendre en compte. Il n'y a aucune raison d'inclure un rendu source de 10 Mbps si peu d'utilisateurs finaux, voire aucun, ne disposent de vitesses Internet suffisantes pour diffuser une vidéo à 10 Mbps. De même, un fichier source de 2 Mbps sera pratiquement impossible à distinguer du rendu de 1,8 Mbps de Brightcove.

Le contenu vidéo en 1920×1080 nécessite des débits binaires exceptionnellement élevés (entre 6-8 Mbps et plus) pour s'afficher clairement, il est donc préférable de s'en tenir à une résolution de 1280×960 ou 1280×720 pour vos vidéos. La plupart des utilisateurs d'écrans inférieurs à 35″ ne verront pas la différence.

Enfin, vous devez choisir un débit d'encodage. Nous suggérons un débit compris entre 3 et 6 Mbps. Le choix du côté de cette fourchette dépend de votre volonté de sacrifier un peu de qualité pour une meilleure accessibilité ou vice versa. N'oubliez pas ceci : Si un spectateur ne dispose pas d'une connexion Internet suffisamment puissante pour afficher votre rendu source, ce n'est pas la fin du monde. Brightcove pourra lui proposer l'un des rendus inférieurs créés par notre moteur d'encodage.

COMMENT ENCODER UNE VIDÉO POUR UNE UTILISATION MOBILE

bsp-admin-1 on September 30, 2010

Il existe des centaines d'appareils mobiles et il est pratiquement impossible de les prendre tous en charge. Mais la bonne nouvelle, c'est que les appareils mobiles s'améliorent.

Les smartphones modernes peuvent en effet lire des vidéos de haute qualité, et l'utilisation des smartphones est en augmentation. Cela ne veut pas dire que le 3GP est révolu ou que tout le monde possède un smartphone. Mais l'utilisation des smartphones augmente, et il n'est pas surprenant que les utilisateurs de smartphones soient plus enclins à regarder des vidéos sur leur téléphone.

Par conséquent, si vous souhaitez prendre en charge plus de 90 % des appareils mobiles, vous devez disposer d'au moins deux types de vidéo : 3GP + MPEG-4 pour les appareils moins sophistiqués et h.264 + MP4 pour les smartphones. C'est une bonne nouvelle. Une seule vidéo de sortie peut couvrir tous les utilisateurs de smartphones : iPhone/iPad/iPod, Android et (pour la plupart) Blackberry. Vous pouvez également inclure la PSP, la PS3 et la Xbox 360 pour faire bonne mesure.

Bien entendu, si une sortie universelle pour smartphone peut satisfaire la plupart des utilisateurs de smartphones, il est possible d'obtenir de meilleurs résultats avec plusieurs sorties mobiles. Par exemple, l'iPad a une résolution native de 1024×768, soit cinq fois plus que les 480×320 des anciens iPhones. Par conséquent, si vous encodez votre vidéo en 480×320, vous ne profiterez pas des capacités presque haute définition de l'iPad.

Heureusement, vous pouvez bien cibler les appareils mobiles en utilisant une poignée de profils d'encodage standard. Commencez par le profil universel pour smartphone pour une large compatibilité. Ajoutez ensuite une version du profil Smartphone avancé pour les appareils les plus perfectionnés et complétez votre liste d'appareils mobiles avec un profil ancien pour une compatibilité maximale (soit notre profil Smartphone ancien ci-dessous, soit une vidéo 3GP pour une compatibilité encore plus large).

Les valeurs par défaut suivantes constituent le point de départ de ces profils. Brightcove Zencoder utilise ces paramètres par défaut, mais vous pouvez les reproduire facilement dans l'outil d'encodage que vous utilisez.

Valeurs par défaut

  • Vidéo : h.264, niveau 3.0
  • Profil audio de base : AAC, 1-2 canaux

1. Profil universel de smartphone

Il s'agit d'un excellent profil de départ pour une large compatibilité avec les smartphones modernes. Il fonctionne sur presque tous les appareils, bien qu'il ne profite pas des résolutions plus élevées et de la complexité des codecs possibles sur les appareils les plus récents.

Joue sur

  • iOS : iPhone, iPad, Apple TV, iPod Touch, iPod Classic, iPod 5.5G
  • Blackberry : Bold 9000, Curve 8910, 8900, 8520, Pearl 9XXX, Storm, Storm 2, Torch, Tour, Bold 9650 + 9700
  • Android : Tous ( ?)
  • Autres : PSP (3.30+), PS3, Xbox 360, web

Ne joue pas

  • iPod 5G
  • PSP (avant 3.30)
  • Blackberry Curve 9330, 9300, 8530, 83XX
  • Pearl 8XXX, 88XX

Paramètres

Défauts, plus :

  • Audio_bitrate : 128 (ou moins)
  • Taux d'échantillonnage : 44100 (ou moins)
  • Taille : 480×320
  • Max_frame_rate : 30
  • Débit vidéo : 1500 (ou moins)

1b. Profil universel pour smartphone B : résolution plus élevée

Ce profil est plus performant sur l'iPhone 4g, l'iPad, l'Apple TV, le nouvel iPod Touch, le Droid, la PS3 et la Xbox, grâce à l'augmentation de la résolution vidéo. Les pixels supplémentaires sont cependant inutiles sur les anciens iPhones, et la vidéo ne sera pas lue sur les Blackberry et certains téléphones Android.

Joue sur

Tout ce qui précède, moins les appareils Blackberry et peut-être des appareils Android plus faibles.

Paramètres

Profil universel de smartphone (ci-dessus), plus :

  • Taille : 640×480

2. Profil avancé du smartphone

Les nouveaux appareils iOS permettent des résolutions plus élevées et une plus grande complexité d'encodage (ce qui signifie une meilleure compression). En particulier, les utilisateurs d'iPad et d'Apple TV ne devraient pas avoir à regarder des vidéos de 480×320 sur leurs magnifiques écrans, il est donc logique de fournir une version de meilleure qualité si vous voulez offrir une bonne expérience à ces utilisateurs.

Joue sur

  • iOS : iPhone 4G, iPad, Apple TV*, iPod Touch plus récent
  • Android : Nexus One, Droid, peut-être d'autres (Note : certains utilisateurs signalent des problèmes avec les vidéos 720p)
  • Autres : PS3, web

Ne joue pas

  • iOS : iPod 5G/5.5G/Classic, iPhone 3GS et avant, ancien iPod Touch PSP, ancien Apple TV*
  • Blackberry : tous
  • Android : autres
  • Autres : PSP, PS3, Xbox 360, web

Paramètres

Défauts, plus :

  • Profil H264 : principal
  • Niveau H264 : 3.1
  • Audio_bitrate : 160 (ou moins)
  • Taux d'échantillonnage : 48000
  • Taille : 1280×720 (max) ou 960×640 (native iPhone 4)
  • Max_frame_rate : 30
  • Débit vidéo : 5000 (ou moins)

*2b. Profil B pour smartphone avancé : avec compatibilité avec l'ancienne Apple TV

Pour prendre en charge les appareils Apple TV plus anciens, utilisez le paramètre Profil avancé du smartphone, plus l'un des éléments suivants.

Paramètres

Profil avancé du smartphone (ci-dessus), plus l'un des éléments suivants :

  • Taille : 960×540
  • Taux d'image maximum : 24

3. Profil de l'ancien smartphone

Ce profil s'applique au dernier grand ensemble d'appareils mobiles basés sur la norme H.264 : notamment les anciens iPods et certains Blackberries. En contrepartie, la vidéo est nettement plus petite : 320×240, à 768 kbps maximum.

Joue sur

Tout ce qui précède, plus :

  • iPod 5G, PSP (avant 3.30)
  • Blackberry Curve 9330, 9300, 8530, 83XX
  • Pearl 8XXX, 88XX

Paramètres

Défauts, plus :

  • Audio_bitrate : 128 (ou moins)
  • Taux d'échantillonnage : 44100 (ou moins)
  • Taille : 320×240
  • Max_frame_rate : 30
  • Débit vidéo : 768 (ou moins)
  • Niveau H264 : 1.3

4. Anciens profils 3GP A et B

Enfin, un ou deux profils 3GP permettront d'étendre la prise en charge à de nombreux autres appareils mobiles. Vous pouvez notamment les utiliser sur la plupart des appareils pris en charge ci-dessus dans le cadre du profil Smartphone hérité. Ainsi, si vous encodez une vidéo 3GP à 320×240, vous n'aurez peut-être pas besoin d'encoder une autre vidéo H.264 à 320×240. Notez que la prise en charge des vidéos 3GP est encore en version bêta chez Zencoder. Enfin, ces vidéos auront un aspect épouvantable, mais c'est le prix à payer pour la prise en charge des téléphones 3GP.

Joue sur

Difficile à dire. Il existe des milliers de types d'appareils 3GP, et chacun est légèrement différent. Considérez-les comme un point de départ.

 Profil AProfil B
Format3gp3gp
Vidéo_codecmpeg4mpeg4
Taille320×240176×144
Mode_aspectcoussinetcoussinet
Taux de rafraîchissement155
Haut de gammevraivrai
Débit vidéo19252
Bitrate_cap19258
Taille du tamponN/A16
Audio_bitrate2416
Canaux audio11
Taux d'échantillonnage1600016000

Résumé

Si vous souhaitez créer une vidéo mobile, commencez par le profil universel pour smartphone. Pour une meilleure qualité, complétez-le par une vidéo du profil Smartphone avancé. Pour une plus grande compatibilité, ajoutez un ou deux profils hérités en utilisant le format MP4 ou 3GP. Il suffit de 1 à 3 profils pour prendre en charge la plupart des appareils mobiles.

Modifications

Les anciens appareils iPhone/iPod demandent le profil "H.264 Baseline Low Complexity". L'expression "faible complexité" n'est pas une norme H.264 ; elle signifie simplement "seulement 1 cadre de référence". Il n'est pas certain que les appareils Apple respectent vraiment cette règle, mais pour une véritable compatibilité, vous devriez probablement utiliser le profil Baseline et limiter les images de référence à 1. Vous pouvez le faire dans Zencoder avec la nouvelle fonction h264_reference_frames de la mise en place.

23 novembre 2010 : Quelques personnes ont posé des questions sur la vidéo du Palm Pre. Les spécifications publiées pour le Palm Pre sont très similaires à celles des autres smartphones :

  • Résolution native 480×320 (avec prise en charge de 640×480)
  • Vidéo H.264, H.263 ou MPEG-4
  • MP3 et AAC audio (ainsi que quelques autres codecs)

Si ces spécifications sont exactes et complètes, les profils Universal et Legacy ci-dessus devraient fonctionner sur le Palm Pre.

24 janvier 2011 : Pour diffuser une vidéo 3GP sous la forme d'un flux RTMP, il est nécessaire de l'accompagner d'un "hinted". Ajouter "hint": 1 à votre demande d'API pour l'activer.

Produits

Services

CARACTÉRISTIQUES

Solutions

Ressources

Entreprise

2025 Brightcove Inc. Tous droits réservés.

Vie privée
Conditions générales d'utilisation
Linkedin X-twitter Facebook Instagram Rss