L'appartement

Aller au contenu | Aller au menu | Aller à la recherche

Tag - flash

Fil des billets

vendredi, janvier 28 2011

Streamer vos vidéos avec Amazon Cloudfront

Dans la plupart des cas de diffusion de vidéos, le pseudo-streaming (ou progressive download) suffit. Il s'agit dans ce cas de diffuser les contenus en format FLV ou MP4. Le seaking (la possibilité d'avancer sur une partie de la vidéo qui n'est pas encore téléchargée) pouvant être géré par l'ajout de keyframes dans le fichier multimédia et l'utilisation d'un serveur web supportant correctement le pseudo-streaming. Je citerais par exemple :

Dans un certain nombre d'autres cas, il peut-être intéressant, voir nécessaire, de diffuser ses vidéos par le biais d'un "vrai" serveur de streaming de type RED5 ou Adobe Flash Media Server. On peut notamment citer :

  • la diffusion de flux en direct
  • la diffusion de vidéos d'une durée importante
  • une protection plus avancée contre le téléchargement des contenus multimédias[1].

Il est depuis quelques temps possible de diffuser en streaming ses vidéos à peu de frais et sans rentrer dans la gestion lourde d'un RED5 ou d'un AFMS.

C'est Amazon Webservices qui propose cette fonctionnalité via son service Amazon Cloudfront. Je vous propose une introduction sur le service et la diffusion de vidéos via le lecteur Flash JW Player.

Qu'est-ce qu'Amazon Cloudfront ?

Amazon Cloudfront est un CDN (Content Delivery Network).

En résumé, le service diffuse vos contenus non pas depuis un unique centre de données mais depuis plusieurs répartis sur la planète. Les requêtes des internautes sont automatiquement routées sur l'emplacement le plus proche de celui-ci. Ceci réduit la latence pour les visiteurs de l’autre bout du monde et diminue la charge sur votre site.

Mais, en l'occurrence, ce n'est pas cette fonctionnalité (sauf si vous avez une audience internationale importante) qui nous intéresse, mais plutôt la possibilité de créer en quelques clics un serveur de diffusion en streaming administré par Amazon Webservices.

Combien ça coûte ?

Comme tous les autres services AWS (Amazon WebServices), le service est facturé à l'utilisation (pay-per-use). Vous payez principalement en fonction :

  • du volume de données stockées
  • du volume de données en entrée et en sortie
  • du nombre de requêtes GET/POST/PUT/LIST

Consultez la grille de tarification pour les détails

Le calcul n’est pas forcément évident mais vous pourrez suivre au jour le jour votre consommation directement sur votre compte Amazon Webservices.

Notez qu'AWS propose également une calculatrice de coût

J'essayerais d'ajouter prochainement à cet article un cas concret en terme de coût – contenu - fréquentation

Comment l'utiliser ?

Si vous n'êtes pas familier avec Amazon Webservices sachez, pour résumer, qu'AWS tourne autour :

  • de plusieurs API permettant de communiquer avec les différents services. Des kits de développement pour plusieurs langages sont d’ailleurs fournis par Amazon et l'écosystème est plutôt bien fourni.
  • d'une interface web de gestion.

Pour commencer, vous devez vous inscrire et fournir un numéro de carte bancaire, seul moyen de paiement actuellement accepté. Certains services nécessitent également une activation du compte par callback téléphonique. Précisez donc un numéro de téléphone valide. A ce stade, vous ne payez rien. Je le répète, le paiement se fait à l’utilisation.

Créer un espace de stockage Amazon S3

Pour diffuser vos contenus via Cloudfront, vous ne pouvez actuellement pas les héberger ailleurs que chez Amazon. Le service de stockage d'Amazon est plus connu. Il s'agit de S3 (Simple Storage Service). Le service est également facturé à l'utilisation.

Je passe sur le détail de création et d'envoi de vos fichiers sur AWS S3. On trouve pas mal de documentation sur le sujet.

Istance S3 Un bucket Amazon S3 contenant les fichiers FLV. Ne tenez pas compte des fichiers XML ;)

Disons donc qu'il est nécessaire de créer un bucket Amazon S3 qui sera lié à votre serveur Adobe Flash Media Server sur Cloudfront.

Pensez-bien à rendre les fichiers de votre bucket public et déposez ensuite un fichier FLV ou MP4 sur celui-ci

Créez un serveur Adobe Flash Media Server

Sur la console AWS, créez maintenant une distribution Amazon CloudFront de type Streaming (Adobe Flash Media Server) et liez là à votre bucket en cliquant sur « Create distribution ». Choisissez le bucket S3 qui contient vos vidéos.

Vous obtiendrez ceci : Instance Cloudfront

A ce stade, vos vidéos sont accessibles en streaming ! Essayez simplement d'en lire une avec VLC ou un lecteur gérant correctement ce type de diffusion. L'adresse est de la forme :

rtmp://IDENTIFIANT_MACHINE.cloudfront.net/cfx/st/monfichier.flv (ou mp4)

Il s'agit d'une diffusion en RTMP sur le port avec un failover sur le port 80 en cas de pare-feu un peu trop exigeant.

Si ça ne fonctionne pas, vérifiez que votre fichier vidéo est bien public sur votre bucket Amazon S3 en y accédant directement en HTTP. Par exemple : http://monbucket.amazonaws.com/monfichier.flv (ou mp4)

Si votre serveur de streaming est bien fonctionnel (bravo bravo !), vous pouvez l'utilisez avec un lecteur flash supportant la diffusion en RTMP

Option : vous pouvez créer un CNAME sur votre zone DNS pour remplacer l'URL de Cloudfront par la votre :

stream IN CNAME  IDENTIFIANT_MACHINE.cloudfront.net

Utiliser JW Player avec Amazon Cloudfront

A ce stade, je vais supposer que vous n'avez pas de difficulté à installer JWplayer et à le faire fonctionner, dans un premier temps, avec une vidéo hébergée chez vous.

Vous devez maintenant utiliser les éléments de configuration suivant pour diffuser la vidéo hébergée sur le cloud Amazon :

Préciser dans votre configuration JW Player les variables suivantes :

provider=rtmp
streamer=rtmp://IDENTIFIANT_MACHINE.cloudfront.net/cfx/st
file=monfichier.flv (ou mp4)

Dans le cas de l'utilisation de la balise object, on obtient donc :

file=monfichier.flv&streamer=rtmp://IDENTIFIANT_MACHINE .cloudfront.net/cfx/st&provider=rtmp

Et c’est tout ! Vous voici prêt à diffuser des contenus via « votre » serveur de streaming !

Notes

[1] même si, vous en conviendrez, il n'existe aucun moyen d'empêcher le téléchargement. Et ne me parlez pas de DRM !

vendredi, novembre 27 2009

Les vidéos de votre site intégrées et lisibles directement sur Facebook

Vous souhaitez, à l'instar de Youtube ou Dailymotion, que vos visiteurs, également utilisateurs de Facebook, puissent ajouter directement les vidéos de votre site sur leur mur ? C'est très simple.

Première étape, intégrer les balises méta demandées par Facebook

Le ''wiki developer'' de Facebook est assez explicite sur les balises meta à intégrer dans le head de vos pages contenant des vidéos. (exemple dans le code source de cette page)

<meta name="title" content="video_title" /> 
<meta name="description" content="video_description" /> 
<link rel="image_src" href="video_screenshot_image_src url" /> 
<link rel="video_src" href="video_src url"/>
<meta name="video_height" content="video_height" />
<meta name="video_width" content="video_width" /> 
<meta name="video_type" content="Content-Type header field" />

Deuxième étape : demandez à facebook de whitelister votre domaine

Pour cette étape :

1. connectez vous sur l'application Facebook Developper

2. postez un message sur Developer Help Contact Form en précisant la catégorie de demande Embedding Videos On Facebook. Dans le champ Link, précisez bien le domaine sur lequel vous souhaitez cette autorisation.

3. patientez en attendant un message de Facedebouc

that's all folks !

lundi, avril 13 2009

Réflexion sur l'externalisation : l'exemple de l'hébergement de vidéo

Quand nous[1] avons décidé le refactoring theatre-contemporain.tv, un débat interne s'est engagé sur l'intérêt de passer ou non par un service tiers (gratuit ou « low cost ») pour héberger les vidéos.

Le site existant depuis 2001 (quand même !) et disposant déjà de plus d'un millier de vidéos, nous avons été démarché par DailyMotion pour héberger nos vidéos chez eux. Entre la simplicité de mise en œuvre de cette solution et l'économie de bande passante réalisée, le choix aurait pu pencher en faveur de l'externalisation chez DM.

La mésaventure du site de vidéos Wat.tv (filiale de TF1) , resté indisponible un bon moment parce que quelqu'un a « oublié » de renouveler le nom de domaine, est cependant assez révélatrice des problèmes que peut poser le modèle du tout hébergé/externalisé[2]

On peut les résumer ainsi :

  • Vous n'avez pas la main sur vos propres contenus
  • Vous devez vous contenter des fonctionnalités offertes par le service tiers. L'aspect "métier" de vos besoins n'est pas pris en compte.
  • Vous ne connaissez pas la pérennité de l'offre du service tiers (Alors que ces derniers jours, on lit ici ou là que Dailymotion et Youtube n'ont pas atteint le seuil de rentabilité, ou que de la pub est de plus en plus insérée dans la vidéo)
  • Vous êtes dépendant des changements d'humeur (et de CGU) du fournisseur que vous avez choisi

Certes, il existe tout de même quelques services qui proposent des contrats d'hébergements de vidéos disposant d'une vrai garantie de service (payants bien entendu), mais là encore, il faut être certain de la pérennité de leurs modèles économiques.

De notre côté, nous avons choisi de faire péter notre bande passante ;) ; Tout est développé/géré/hébergé en interne.

Il persiste un service tiers ; le processus d'encodage des vidéos passe par Heywatch qui propose une API REST très performante et ne fait - finalement - que nous fournir de la puissance de calcul. En fonction du succès, nous envisagerons de gérer le traitement directement sur notre infrastructure.

D'autre part, si Heywatch venait à fermer ou à changer ses conditions, la migration d'un webservice vers un autre resterait assez triviale et ne remettrait pas en cause toute notre conception.

Enfin, le CRIS, qui se positionne comme un "Centre de Ressources" pouvait-il se permettre de faire sous-traiter l'archivage à un service gratuit ou low-cost dont ce n'est pas forcément la vocation ?

Le site a été développé et mis en ligne dans un temps record. Dans 2 semaines, les internautes pourront poster leur vidéos. Finalement pas compliqué de faire un Youtube Like. Prochaine étape, concurrencer Google ;)

Il convient donc de toujours bien peser le pour et le contre d'une externalisation. Même si elle semble souvent plus simple à mettre en oeuvre le gain à postériori n'est pas forcément avantageux !

Notes

[1] L'équipe de CRIS/theatre-contemporain.net

[2] idem d'ailleurs sur Gmail qui a aussi subit quelques soucis