Méthode incrémentale, agile mais modeste, on commence simple, on valide les étapes techniques une à une, on monte progressivement dans les fonctionnalités quand c'est possible. Autrement dit, on commence par une merde qui fonctionne, on la transforme en légume bio goûtu petit à petit. Le tout est aussi de planifier la durée des phases d'expérimentation pour ne pas trop tazonner sur des bidules.

Installation d'un ordinateur puissant équipé d'une carte d'acquisition susceptible d'avaler les flux vidéos produits en direct

• Pc Linux / Mac ?
  • hackintosh http://www.makeuseof.com/answers/hardware-specs-recommend-custombuilt-hackintosh/ http://tonymacx86.blogspot.fr/search/label/CustoMac http://lifehacker.com/5841604/the-always-up+to+date-guide-to-building-a-hackintosh http://hackintosh.com/
• Carte acquisition : Decklink quad vs Decklink studio x 4
• Exemple Régie livestream http://store.livestream.com/products/livestream-studio-hd500?tab=techspec
• Connectique avec les caméras Astro : comment véhiculer un signal HD jusqu'à la régie ? HF ? Avec fil ?
• Connectique avec retour audio : 2 micros audio salle pré-mixés sur la console façade renvoyé vers ordinateur pour acquisition (check synchro son image à faire)
• Où installer la régie vidéo (1 Pc + écran + controlleur midi), en régie lumière ?

Développement d'un logiciel de régie vidéo et de streaming

• Acquisition des 4 flux vidéos (a priori 3 flux HD (1 caméra fixe fond de salle, 1 caméra sur scène proximité, 1 caméra mobile salle-scène, 1 en rab) et un flux IP issu de la caméra asservie)
• Envoi de ces flux encodés en H264 (format précis à préciser) vers le serveur via liaison SDSL au moins 4 à 5 MBits
• Interface de réalisation live présentant un retour visuel des 4 à 5 flux vidéos avalés et du flux vidéos réalisé, du volume audio du son récupéré
  • Possibilité de démarrer et arrêter l'envoi du stream vers le serveur
  • Possibilité de passer d'un flux à l'autre avec fondu enchainé (ou fondu au noir)
  • Possibilité d'afficher une signature graphique en transparence par dessus le flux réalisé
  • Possibilité d'intercaler un titrage en transparence entre 2 changements de flux (titrage type : Nom du groupe à venir / en train de jouer), boite de saisie à prévoir
  • Enregistrement de la réalisation en local pour upload à la fin du concert
  • Encodage du flux réalisé au format adéquat pour envoi au serveur

• Mockup Régie streaming vidéo multicanaux https://moqups.com/labomedia/Qcsb4m1j/p:ade90122fla concurrence ;)

• Le soft de streaming vendu par livestream http://store.livestream.com/products/livestream-studio-software

Mise en place d'un serveur de stream capable de :

• streamer les 4 flux bruts sous forme de vidéo de taille et de qualité réduite (vignette)
• transcoder les flux selon les plateformes visées (desktop, ios, android, windows mobile, …)
• streamer les 4 flux en qualité optimale
• servir les flux audio et vidéos à un nombre d'internaute à définir
• discuter avec l'application web pour optimiser les échanges client-serveur

• Possibilité d'assister au live en direct en regardant le flux réalisé depuis l'astro
• Possibilité de revoir ses réalisations et celles d'autres internautes

• Possibilité d'assister au live en direct en choisissant parmi une des caméras proposée
• Possibilité de piloter une caméra asservie en rentrant dans une file d'attente
• Possibilité de mémoriser “sa” réalisation en enregistrant les points où l'on change de caméra
• Idée d'inviter des réalisateurs à distance pour un live

• Possibilité d'éditorialiser les contenus présentés en page d'accueil (annonce de direct, mise en avant de précédents lives)

Le player sera HTML5 avec fallback Flash, grâce au bon support général de la balise

<video>

et pour maximiser le nombre de plateformes et navigateurs sur lesquels lire la video (desktop, tablettes, mobiles). La detection de la plateforme utilisée devrait se faire côté client, mais peut s'envisager côté serveur afin de proposer le bon format vidéo (les players videos tout prêts font deja la detection). Wowza devra proposer le transcoding des vidéos pour toutes ces plateformes.

A noter qu'a priori, la balise video est independante des sources videos, donc que les players du marché devraient pouvoir lire des flux Live sans problèmes. Mais à tester.

Outils de detection de navigateur/plateforme :

• Modernizr (côté client)
• Detect Mobile Browser (côté client et/ou serveur)
• MobileDetect (côté serveur)
• PHP Browser detection (côté serveur)

Players vidéos HTML5 (avec fallback flash, et contrôle javascript) :

• FlowPlayer : gratuit avec watermark. Live Streaming OK (HLS y compris) (conseillé par pas mal de monde)
• JWPlayer : gratuit avec watermark. Live Streaming OK. Payant (cher) pour HLS (Apple Live streaming). Voir les prix
• LeanBackPlayer : gratuit. Quelques extensions gratuites. Live Streaming ??
• MediaElement : gratuit. Live streaming ??
• MediaFront : gratuit. Vieux machin ?? Live Streaming ??
• Projekktor : licence GPL + quelques plugins gratuits/payants. Live streaming ??
• SublimeVideo : gratuit avec watermark. Live Streaming ??
• VideoJS : gratuit. Live Streaming OK (conseillé par pas mal de monde)
• Video For Everybody : gratuit. Live Streaming ??

Autres ressources :

• Comparaison des players vidéos HTML5 du marché (pas super a jour, mais c'est déjà pas mal)
• Activer support des balises video et audio dans tous les navigateurs : HTML5Media

1. 8 au 12 octobre : Atelier test flumotion @ Labomedia
2. 15 octobre : Finalisation cahier des charges régie et site web
3. 15 octobre au 15 novembre : installation serveur de stream dév, premiers développements streaming et player web
4. 1er novembre au 1er décembre : développement front et backoffice web, régie vidéo
5. 1er décembre : tests de stream, réglages, installation physique de la régie

• Benjamin : Cahier des charges web et +
• Nicolas : Veille Tehnique et tests Wowza + Dev Site Web
• Olivier : régie vidéo webcam > HD

Ces spécifications décriront notamment :

• le contenu des écrans de l’utilisateur final
• le contenu des bases de données
• les différentes transactions informatiques et leurs cheminement entre les utilisateurs et les bases de données
• les traitements à effectuer pour chaque transaction
• les liaisons avec les applications existantes (messagerie, base de données existantes,…)
• l’interface utilisateur

Ces spécifications définiront ou préciseront les choix suivants :

• hébergement des serveurs : dans l’entreprise ou chez un fournisseur de service (ISP)
• outils de sécurisation des transactions et des données
• volumes : nombre et fréquence des transactions entre les utilisateurs et les applications)
• architecture et fonctionnalité des serveurs (serveur web, serveur applications,…)
• procédures et ressources pour assurer la gestion et la maintenance des applications
• évolutivité de la solution
• plan de formation
• documentation
• impact sur l’organisation actuelle
• mesures de qualité

Tout d’abord les contraintes imposées par le demandeur :

• standards techniques (hardware, protocoles, langages, …)
• standards propres à l’organisation
• ressources : disponibilité des membres, réutilisation de matériel

Par ailleurs les points suivants seront clairement définis :

• maquette ou démonstration fonctionnelle : objectifs, représentativité par rapport au projet global, critères d’acceptation
• calendrier des prestations : début, fin, phases
• planning de mise en service et de migration
• test de l’application : recettes intermédiaires

' Les spécifications administratives permettent de préciser les points suivants :'

• détail des coûts (investissement, fonctionnement, maintenance,…)
• modalités de paiement
• conditions d’exécution : lieux de travail, disponibilité des outils
• clauses légales

' La méthode d’analyse et les critères d’évaluation doivent être définis avant l’émission du cahier des charges afin de s’assurer que les éléments requis pour l’évaluation se trouvent effectivement dans les offres.'

• qualité de l’offre par rapport au cahier des charges
• délais d’exécution
• prix
• références
• qualité des personnes