avr
15

MipCube TV Hack : Mood

L’événement

Le MipCube c’est quoi ? Et bien c’est l’un des plus grands salons sinon le plus grand salon mondial de la télévision. Il se déroule chaque année depuis 50 ans en France à Cannes. Différentes compétitions ont été organisées lors de l’événement. Gamific.TV a été retenu pour le MipCube Lab destiné à élire LA startup du moment concernant la télévision. Quant à moi, j’ai été sélectionné pour le hackathon : le TV Hack. L’événement a été co-organisé par une équipe rodée à ce type de compétitions : BeMyApp.

L’événement a été couvert par plusieurs médias dont entre autres par ZDNet, Clubic et par Olivier Ezratti. Normalement des vidéos devraient être disponibles prochainement dont notamment un reportage sur la chaîne de TV France24. Je partagerais ça sur Twitter et Google+ le moment venu !

L’idée

Nous avions à notre disposition beaucoup de chose : Kinect, Leap Motion, Startekit Gadgeteer,  Creative interactive gesture camera Intel Raspberry, Arduino et enfin une TV connectée Samsung (3D même !). J’avais quelques idées en tête puis c’est en rencontrant Christophe Dupont et en discutant avec lui que l’idée s’est précisée. Finalement on a formé rapidement notre binôme pour le hack. Christophe est développeur Android et a pas mal de matériel sous le coude : smartphones, tablette… De mon coté j’ai l’expérience TV et les compétences Web, bref on se complète très bien !

Notre idée est simple : analyser l’humeur des téléspectateurs en temps réel pour permettre une meilleur appréciation de la perception des programmes TV par le public. Typiquement en utilisant une caméra intelligente qui pourrait reconnaître des mouvements (applaudissement, lever les bras…) et les sons (rires, cris de joie…). Avec de telles données, les chaînes TV pourraient adapter leur contenu ou l’attitude de leur présentateur/animateur en temps réel. Il serait également facile de construire un Best-of de l’émission en récupérant les passages les plus marquant.

Notre implémentation

On a rapidement fait le choix d’utiliser la Kinect ainsi qu’une tablette Android. Le principe est le suivant : la TV diffuse une vidéo watermarkée par Civolution. Le watermarking permet grâce au SDK de Civolution de synchronisé la tablette avec le flux live. Dans la réalité, Civolution est déjà utilisé par certaines chaînes de la TNT donc une application réelle est tout à fait réalisable. On va au delà de la simple démonstration dans notre cas. A chaque synchronisation, l’information est envoyé à notre serveur.

Sur le PC connecté à la Kinect, j’ai écris deux scripts en Processing : un pour traiter les images et un second pour traiter le son. Le principe du premier est donc de reconnaître un mouvement de main : l’applaudissement. Pour se faire, j’ai utilisé SimpleOpenNI. Les exemples fournis sont assez pratique mais on se rend vite compte que la Kinect est très sensible : il ne faut pas de surface vitrée derrière soit et éviter les mouvements parasites. Typiquement développer une application Kinect dans un openspace n’est pas forcément adapté. Lorsque le mouvement est détecté, j’effectue une requête POST sur le serveur Node.js que l’on a développé. L’événement est ensuite enregistré dans MongoDB.

Pour traiter les sons, là encore j’ai utiliser un exemple fourni par Processing (LiveSpectrum). Lorsqu’un pic de décibel est détecté sur une certaine plage de fréquence, là encore une requête POST est envoyée au serveur. Il est possible d’aller beaucoup plus loin en faisant de la reconnaissance vocale.

Le serveur Node.js comme je viens de l’évoqué reçoit tout les événements ainsi que les synchronisations avec le flux live. Ainsi il fourni une API pour l’application Android permettant de récupérer la liste des événements ainsi que leur position précise sur le flux vidéo. Ces informations permettent au téléspectateurs de revoir le moment sur lequel il a agit (applaudissement, rire…) et de le partager sur Twitter. Les événements sont également envoyer via Websocket (Socket.io) à la TV Connectée. Celà permet d’afficher un retour direct sur l’écran. Là encore notre solution est très proche de la réalité : on pourrait très bien envoyer ces événements sur une application HbbTV diffusé par la chaîne de TV.

Nous avons également réalisé un tableau de bord, permettant de suivre l’évolution des interactions sur un flux live. Interface simple utilisant Twitter Bootstrap et la bibliothèque Javascript HighCharts. Le superviseur peut à tout moment cliquer sur le passage qu’il souhaite pour le revoir.

Perspectives

L’événement en lui même a été une excellent expérience. Au delà de l’environnement technique et de l’ambiance, il a permis de confirmer encore davantage le besoin pour la télévision de continuer sa transformation et de devenir TV Connectée à 200%. Chez Gamific.TV nous en sommes persuadé et c’est une bonne chose que l’écosystème se dynamise ainsi, avec un tel engouement. Je serais d’ailleurs présent jeudi 18 avril à l’événement NantesJS pour une session live coding Javascript sur TV Connectée. Si vous êtes dans le coin, n’hésitez pas à venir nous voir et en discuter.

Sinon, comme le dit Olivier Ezratti… il va VRAIMENT falloir que je travaille l’anglais. A commencer par l’ouverture d’une version anglaise de ce blog dont le premier billet traitera du hack pour donner un retour aux anglophones.

PS : Sinon bien sûr, un grand merci à l’équipe BeMyApp ainsi qu’au sponsor de l’événement (EVS) qui propose une solution qui méritera d’être utilisé le plus souvent possible : permettre au téléspectateur de choisir la caméra qu’il souhaite (imaginez les applications possibles pour un match de foot, une étape du Tour de France ou encore un concert… !). Bref, c’était un bon moment passé à Cannes avec tout les hackers !

fév
14

Prise en main de Couchbase

Cette semaine je me suis déplacé à la Cantine Numérique de Nantes pour assister à la soirée nosql du JUG. Thématiques abordées : Couchbase et MongoDB. Maintenant que je commence à avoir une bonne prise en main de Mongo, la présentation de Tugdual Grall aidant (comment ne pas être convaincu par un triathlète !), je me suis décidé a tester Couchbase. Pour moi ce n’est pas une inconnue non plus car j’ai beaucoup utilisé Memcached jusqu’à présent. De plus, avant de passer sur Mongo, j’utilisait CouchDB lorsque j’ai pris mes distances avec SQL. Je vais vous parler de mon cas : développeur sous MacOS ayant une expérience de MongoDB. C’est parti pour la prise en main de Couchbase !

Installation

Tout d’abord, au niveau du téléchargement MongoDB et CouchBase sont similaires : tout deux proposent des téléchargements pour Windows, Mac et Linux. Le code source est également disponible. Concernant MacOS, le fichier à télécharger fait la même taille : 50Mo grosso modo. L’avantage de Couchbase est qu’il fournit un wizard pour l’installation ainsi qu’une icône pour la barre du haut. Celle ci permet notamment d’effectuer des mises à jour, de gérer le serveur et d’accéder à l’interface d’administration graphique. MongoDB lui se contente de fournir une archive à placer typiquement dans /opt par exemple. Il n’y a pas d’interface graphique ni de système de mise à jour. Pour la configuration de base, on suit les étapes qui aboutiront à la configuration d’un bucket.

Interface d’administration

Le gros point fort de Couchbase : avec l’interface d’administration on peut tout faire ! C’est à la fois un outil qui peut être mis à disposition des administrateurs systèmes mais qui est également très pratique pour les développeurs. Toutes les opérations possibles sont disponibles dans cette interface. Bien sûr ces opérations sont également accessibles via une API REST et un outil en ligne de commande.

L’écran d’accueil est un dashboard qui nous montre l’état du cluster : serveurs up/down, mémoire utilisée, espace disque utilisé, opérations par secondes… Bref une belle interface de monitoring. On peut également avoir le détail sur l’ensemble des serveurs. Lorsque vous installer CouchDB sur une autre machine, vous aurez la possibilité de rejoindre le cluster existant uniquement en connaissant l’adresse IP et le mot de passe administrateur. Il n’y a pas d’opérations supplémentaires. L’inverse est également possible : depuis l’interface vous pouvez faire rejoindre un serveur existant à votre cluster (mais les données seront supprimées sur ce dernier ! un message vous avertira). C’est beaucoup plus simple qu’avec MongoDB ! Le failover se configure simplement également.

On a également accès aux logs et aux paramètres : notamment des alertes par email ou la compaction des bases.

Tester Couchbase avec l’interface graphique

Comme je le disais, le développeur peut utiliser cette interface d’administration. Il peut notamment créer directement des documents et les éditer en JSON dans le navigateur. Il peut également les supprimer.

On a également la possibilité de créer des vues. Finalement ce sont des opérations de type Map / Reduce que le développeur va créer en développement par exemple. Il va pouvoir tester son fonctionnement sur un sous ensemble de données puis passer sa vue en production avec cette fois-ci l’utilisation de toutes les données. C’est CouchDB qui gère en tâche de fond l’exécution du calcul, soit sur une base d’intervalles de temps soit sur un certain nombre de requêtes. L’affichage du résultat n’est donc pas forcément en temps réel. La syntaxe semble similaire à MongoDB :

Ecrire du code

Bien sûr une fois pris en main à ce niveau-là on veut tout de suite voir ce que ça donne au niveau du code. Tout comme pour MongoDB, il existe de nombreux drivers. En ce qui concerne Java, il y en a quatre : Ektorp, JRelax, jcouchdb et CouchDB4J. Je n’en ai testé aucun. CouchDB4J me paraît intéressant : il propose une API simple. En général, je ne suis pas pour le mapping lorsque l’on travaille en nosql, c’est une perte de temps et cela rigidifie l’application. Je vous mets un bout de code pour la forme :

Session s = new Session(« localhost »,5984);
Database db = s.getDatabase(« foodb »);

Document doc = db.getDocument(« documentid1234″);
doc.put(« foo », »bar »);
db.saveDocument(doc);

Document newdoc = new Document();
newdoc.put(« foo », »baz »);
db.saveDocument(newdoc);

ViewResult result = db.getAllDocuments();
for (Document d: result.getResults()) {
System.out.println(d.getId());
Document full = db.getDocument(d.getId());
}

Il n’y a que très peu de différences avec le driver officiel Java pour MongoDB. Les drivers Java fournis en exemple par Couchbase sont des projets communautaires.

Concernant Node.js, il existe le paquet Cradle. Il n’est également pas officiel mais semble très actif. On peut l’installer directement avec npm. La syntaxe est bien dans l’esprit de node.js avec la notion de callback nécessairement utilisée. Cradle supporte également les vues.

Il y a pas mal de pull requests et des tâches en cours. C’est plutôt bon signe.

Bien sûr vous pouvez aussi vous contentez d’utiliser uniquement l’API HTTP. C’est un choix à faire.

Architecture

Pour une fois, je n’en parle pas trop. L’objectif de l’article était de prendre en main Couchbase et de voir rapidement ce qu’on pouvait en faire. Celà dit c’est toujours intéressant de savoir ce qu’il y a sous le capot. Typiquement, il s’agit d’un serveur HTTP qui expose une API pour effectuer toutes les opérations sur les bases en appliquant le principe  du Fire and forget (port 8092). Il est également possible de s’y connecter avec le protocole memcached (port 11211/11210). Toute la gestion du cluster (dont notamment le fail over) est développé en Erlang. Le reste est écrit en C.

Conclusion

L’interface graphique m’a convaincu, l’entreprise qui supporte le projet aussi et l’architecture de la solution semble véritablement bien huilée. Memcached est une solution connue et utilisée depuis longtemps : Couchbase contribue au projet pour son « Object-Managed Cache ». La gestion de cluster par Erlang est également un gage de crédibilité. Maintenant la prochaine étape pour moi : c’est de faire un PoC et d’écrire du code. Je crois que je vais ressusciter mon URL Shortener et enfin le mettre en ligne : https://github.com/loicguillois/lgu.me

 

déc
10

HackDay Connected TV

Il était temps ! Il y a quelques semaines a eu lieu un évènement à Paris autour de la TV Connectée sous la forme d’un hackathon. Le principe ? Réunir des développeurs, des graphistes, des hackers, des acteurs de la TV connectée ou non pour un seul objectif : mettre en oeuvre en un week-end un projet innovant faisant usage de la TV Connectée au sens large. A l’initiative de cet évènement : France Télévision et Joshfire. Pour l’occasion, nous avions à notre disposition un certain nombre d’API et d’outils, dont certains créateurs étaient avec nous (Mesagraph, Stupeflix, Moodstocks, Movies.io).

Gamific.TV était représenté par William (CEO) et moi même (Lead TV). Celui ci à d’ailleurs écrit un article (beaucoup) plus rapidement que moi. Franck (Lead Mobile) est également passé nous voir, c’était bien sympa !

Les projets

Rapidement des équipes se sont montées tandis que d’autres personnes ont abandonné l’aventure. Finalement, pas mal de projets intéressants. Toutes les infos sont ici. Bien que nous avions à disposition des Google TV, personne n’est parti dans cette direction ! Au final il y avait beaucoup d’applications Web et mobiles (second screen). Techniquement c’était intéressant de voir beaucoup de projets Node.js et utilisant MongoDB, certains se sont appuyés sur les Websockets !

Mon coup de cœur va au projet Hyper-titles dont l’idée simple est d’amener une touche d’interactivité entre la télévision et votre smartphone. Des évènements peuvent être planifié afin de se déclencher sur le téléphone : lancer une application, vibrer, prendre une photo, allumer le flash… Je suis certain qu’à l’avenir ce type d’usage s’intégrera dans les programmes TV dès leur conception.

Le gagnant du hackathon est une gagnante, qui a développé une application mobile permettant de naviguer facilement sur le programme TV : LinkedTV. Elle a utilisé des technos innovantes pour la manipulation de données (RDF, SPARQL, Android Mobile, BorderCloud).

Notre projet : QRPub

Nous sommes partis sur une idée simple : rendre la publicité ludique. Pour y arriver, nous avons imaginé un système de jeu basé sur la rapidité. Sur les publicités apparaissent des QRCode durant le passage du spot, et chaque scan permet de gagner des points qui seront cumulés sur son compte ! Plus on scanne rapidement, plus on a de points ! Nous aurions eu plus de temps, nous aurions utilisé du watermarking audio ou vidéo, cela aurait été moins intrusif. Quoi qu’il en soit, nous avons développé pour arriver à une démo fonctionnelle :

  • un backoffice pour éditer les jeux et avoir le tableau des gagnants
  • un écran TV pour simuler un mode de fonctionnement HbbTV
  • une application mobile  pour créer son compte et voir les points gagnés

Nous avons utilisé node.js et mongodb pour développer notre projet. Finalement, nous sommes restés dans le classique au niveau des modules utilisés :

  • Express.js (web application framework)
  • Jade (templating)
  • cron (tâches de fond)
  • socket.io (websockets)
  • async (traitements asynchrones / parallèles)
  • qrcode (génération de QRCode coté serveur à la volée)
  • mobile-agent (détection de navigateurs mobiles : android, ios, windows phone…)
  • forever (gestion de processus node.js)

Le choix a été fait dès le départ de créer une seule application pour le mini backoffice, l’écran TV et l’application Web Mobile. L’avantage c’est qu’on évite de perdre du temps à bootstraper son application, moins de code à écrire, pas de cross-domain… C’est parfait pour un hackathon.

L’architecture est assez simple : on crée les jeux dans le backoffice en attribuant un certain nombre de sponsors avec pour chacun un timestamp de synchronisation avec la vidéo et une phrase à afficher. Une tâche de fond va parcourir l’ensemble des jeux chaque seconde. Dès qu’un sponsor doit être affiché un QRCode est généré et envoyé par WebSocket aux TV Connectées. De là l’application TV affiche ce QRCode qui peut ensuite être scanné. Les utilisateurs qui disposent d’un smartphone équipé d’un logiciel de scan de QRCode (comme Digit Eyes sur iPhone) peuvent scanner. Ils obtiendront une URL unique qui leur permettra de gagner des points. La reconnaissance du smartphone se fait par son adresse IP dans un premier temps. Celui ci à la possibilité à ce moment là de créer un compte et de se connecter. Les événements sont remontés en temps réel au niveau du tableau de bord du backoffice (points gagnés, création de compte…).

Conclusion

Au final, il y a un peu moins de 200 lignes de codes dans le backend et quelques pages HTML (enfin… Jade). Je n’ai pas utilisé Map/Reduce mais j’aurais pu, notamment pour traiter les résultats des jeux avec une grosse volumétrie de joueurs. De même le coût CPU pour la génération d’un QRCode à la volée est loin d’être négligeable… dans la vraie vie il faut prévoir de les précalculer ou de mettre en place un cache intelligent. Une erreur aussi, j’avais mis en dur l’IP du serveur pour la génération du QRCode… ce qui m’a valu une sueur froide durant la démo et une perte de temps inutile. Au final, la réflexion qui en ressort c’est que le moyen de synchro utilisé n’est pas forcément adapté ! On l’a vu récemment avec SFR et sa pub sur la 4G qui proposent aux utilisateurs de synchroniser avec Shazam (via l’audio donc). Je pense que c’est vraiment l’avenir car mine de rien pour scaner un QRCode il faut que celui ci soit de la bonne taille et avec les tailles de TV hétérogènes c’est un vrai problème. De plus, la distance avec la TV et le type de smartphone influence aussi la rapidité de synchronisation… L’expérience ludique peut rapidement devenir frustrante.

Bien sûr un hackathon ce n’est pas uniquement du développement et des démos. Nous avons pu voir pas mal de projets variés et échanger notamment avec les développeurs, graphistes, etc. des autres projets. Merci notamment à Serge Versille qui a eu la gentillesse de m’héberger et avec qui on a pu discuter Web, TV Connectée et business.

Go back to top