Bilou, je veux bien te répondre, mais ton adresse me donne une “Delivery Status Notification”
Salut les gars,
J’ai cru comprendre que vous avez des sites de vidéos, vous vous
démerdez comment pour envoyer la vidéo en streaming tous en l’encodant.
Par exemple j’ai des mkv qui doivent être passer en mk4.
Une petite idée ?Merci d’avance,
Yop,
On encode pas à la volée. On a des workers (powered by kombu) avec des files d’attente qui encodent les videos avec ffmpeg, et qui déclarent quand elles sont prêtes. Derrière on streamp tout ça avec nginx. Ca demande beaucoup de tests (il n’y a pas de commande magique car ça dépend de ta cible client), et surtout, des disques durs énormes pour stocker tout ça.
Pour ton cas particulier, n’oublie pas qu’il y a 3 choses à prendre en compte:
- le codec video (h264, mpeg-2, etc)
- le codec audio (mp3, aac, etc)
- le conteneur (mkv, avi, mov, etc)
Donc il ne s’agit pas juste de streamer (c’est le plus facile, il suffit de compiler nginx avec l’extension qui va bien et payer un bon serveur), mais bien de trouver la combinaison des 3 qui corresponde à sa cible. Tester si on vise : le HTML5 ? Un lecteur flash ? Un truc lisible sur téléphone mobile (et quels modèles… ?). Quelle définition ? Quelle bande passante ? Quel traffic ?
Tiens une question un peut en rapport, vous utilisez quoi pour détecter les codecs?
Dans mon cas je cherche le truc le plus simple/léger/avec le moins de dépendance possible.
Juste pour détecter si un fichier vidéo mérite d’être affiché avec la balise du même nom et avoir une chance d’être lu nativement par les utilisateurs d’un navigateur digne de ce nom (sinon j’affiche un lien basique pour télécharger le fichier, pas de conversion ou quoi que ce soit).
Bref un truc genre ça https://pypi.python.org/pypi/hachoir-metadata/
On détecte pas les codecs, on normalise tout vers des codecs standards.
Toujours sympa de partager votre expérience. Mais je me rends compte que je ne sais pas le nom des sites que vous administrez. C’est volontaire ou j’ai loupé cette info ? Je suis peut être un de vos utilisateurs :3
C’est volontaire.
pas du tout, on administre Facebook et Youtube.
@Sam
Ok, de toute façon je viens de tester les plus connu (hachoir-metadata, kaa-metadata…) et ce n’est pas terrible. Quelques tests concluants avec des .avi mais pour les .mp4 et .webm qui m’intéressaient je ne récupère pas d’infos sur les codecs.
Au final il n’y a que l’utilisation de ffmpeg (voir mediainfo) ou des wrapper l’exploitant qui fonctionne bien.
Bref j’aurais pensé trouver une petite lib qui se limitait à la lecture des headers mais ça semble raté, les seules efficace se limite au fichier audio (genre hsaudiotag).
Merci pour la réponse ;), le bug dans le mail doit venir du &.
Je vais regarder ce que je peux faire si ça marche je posterai les sources.
En gros j’ai des vidéos qui sont sur un serveur et quand je veux voir l’une d’elles je la télécharge en local ou la stream depuis vlc.
Là je voudrais donner l’accès des vidéos à quelques amis.
Pour le moment j’ai trouvé le player jwplayer qui est pas trop mal.
Ce qui risque de poser problème se sera le délais d’encodage :-/
@cyp essais mediainfo ou ffprobe
@Lezy
Il n’y a pas de solution miracle, mais tu peux par contre probablement uploader et encoder à la volée. Tu encode le fichier, et tu upload le résultat au fur et à mesure. Comme la les deux temps de processing sont en parallèle.
Nous on utilise un jwplayer custo.
Humm “kombu” ? Qu’est ce ? Ceci https://github.com/celery/kombu ? Qu’est ce que ça fait au juste ?
Oui c’est ça. C’est un gestionnaire de queues. Il permet de faire des files d’attentes, et d’empiler des messages dedans d’un côté, tout en les dépilant de l’autre. Les queues peuvent être stockées dans différents transports: redis, rabbitMQ, etc.
Nous utilisons Kombu historiquement, mais si quelqu’un doit commencer un nouveau projet, je recommande d’utiliser celery, qui est d’un plus haut niveau que kombu et demande de moins mettre les mains dans la cambouis.
Et qu’apporte ce genre d’outils par rapport à une base de donnée qui peut locker des ressources ?
- Ca ne bouffe pas de ressource dans la base de données. Poll + lock + write par 20 workers en parallèle toute la journée, c’est pas négligeable.
– Tu n’as pas à implémenter la logique de polling, de routing, de séparation de queues, de priorités, etc. Beaucoup de travail et de bug en moins.
– Tu peux mettre plusieurs workers qui consomment depuis la même queue sans te soucier de la concurence ou du locking. Ca va couler tout seul.
– C’est fait et optimisé pour ça.
– La sémantique de l’outil fait que le code est clair, tu créer une tache, tu envois une tache, tu chaine une tache, etc.
Plus d’infos:
http://blog.gomiso.com/2012/11/15/asynchronous-processing-in-web-applications-part-1-a-database-is-not-a-queue/
https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you
Intéressant.
Ça me pousse à réfléchir et à remettre en cause l’utilisation de Cassandra pour ça (car il y a des locks, de la répartition et de la consistance). J’ai ce qui faut, mais c’est pas très pratique, et un peu lourd pour ça.
J’ai peur par contre de tomber sur des outils usine à gaz et bien complexes (tel qu’on sait les faire en Java) mais c’est un sujet à creuser, en effet.
Cassandra c’est déjà du NOSQL, c’est un peu plus adapté. Mais si tu veux faire une migration en douceur, prend celery et son backend cassandra:
http://docs.celeryproject.org/en/latest/internals/reference/celery.backends.cassandra.html
Tu passes tes tâches sous celery, la sémantique change, mais ta config reste la même.
Puis quand tu es à l’aise avec celery, tu installe un backend plus adapté : redis voir carrément rabbitMQ. Et là tu déchargera cassandra, sans changer le code de tes tâches. Migration en douceur. Normalement tu devrais gagner en load average et en découplage dans ton archi (enfin, faut mesurer, comme d’hab).
Mais si tu es à l’aise avec ton système actuel et que ça bouffe pas trop, il n’y a pas de raison de changer. Il y a des choses plus prioritaires que de changer son système de queue. C’est pour cette raison qu’on garde kombu d’ailleurs, alors que celery est plus adapté : y a du boulot ailleurs.
RabbitMQ semble intéressant. Il est en tout cas assez facile de l’attaquer en Java. Après je doute qu’il soit décentralisé.
Au niveau des perfs et du load je n’ai pas de problèmes (et j’en suis très loin d’en avoir à ce niveau). C’est plus au niveau de la scalabillité et de la simplicité que ça coince.
Je n’ai pas envie de rajouter un point de faiblesse, ni pour autant rajouter des couches et avoir un code qui tourne sur une usine à gaz. Bref, les perfs, je m’en fou, par contre ça doit être simple et résistant. J’ai même pensé un temps à utiliser l’API de git.
En effet, rabbitMQ est un broker particulièrement centralisé. Si tu as besoin de répartition, soit il faux sharder les queues, soit il faut un backend qui tappe dans un truc qui se load balance tout seul.
Même si tu gardes cassandra pour cette raison, je t’invite à jeter un coup d’oeil à celery, car ça t’évite de te taper la logique des queues, du verrouillage, du routing, etc.
Après, le KISS reste une très bonne chose, ajouter un composant juste pour l’ajouter n’a effectivement aucun sens, et tu rajoute un point de faiblesse.
Il existe aussi Beanstalkd, qui à l’air assez simple d’utilisation : http://dev.af83.com/2013/03/13/why-you-should-consider-beanstalkd.html