Splitter des vidéos en Javascript

vdaubry · Février 22, 2015, 9:20

Salut !

J’ai une petite question, je me suis dis que vous auriez peut être une idée :)

Pour splitter des vidéos j’utilise ffmpeg en ligne de commande, c’est top mais pour simplifier la sélection des segment de la vidéo, j’ai essayé de faire une interface graphique en JS :

C’est assez basique :

J’ouvre une video
Un slider pour sélectionner un marker de début et un marker de fin
J’appelle en ajax une fonction en node qui exécute ffmpeg avec les paramètres pour splitter la video

Ca marche, mais je me suis un peu cassé les dents sur 2 problèmes :

D’abord pour appeler ffmpeg, ça me semble un peu lourd de démarrer un serveur web juste pour exécuter une commande shell
Je sais que c’est impossible à faire directement dans le browser, mais est ce que vous voyez une solution plus légère sachant que tout tourne en local :
Une app / extension chrome ? Browserify ? autre ?
2eme problème : quand on sélectionne un fichier avec un input type file, le browser ne donne pas accès au chemin complet vers le fichier
On a que le nom du fichier, du coup la seule solution que j’ai trouvé c’est de déposer les vidéos à splitter dans un dossier “videos” du projet pour savoir à l’avance ou elles se trouvent…
Est ce que vous voyez une autre solution ?

Au final je me dis que ce serait cool d’avoir un utilitaire utilisable par des non-tech. Donc démarrer un serveur node ça le fais pas trop
Pour faire ça il faudrait peut être packager l’appli dans une app native mac, windows, etc
J’ai entendu parlé de Node webkit , vous savez si ça peut régler ces 2 problèmes ?

Je suis ouvert à d’autres pistes sinon :)

Merci pour vos conseils !

celine · Février 22, 2015, 9:46

Je suis une grande fan de ffmpeg mais sinon pour le tout public, il existe des tas de logiciels tels que OpenShot (sous Linux / BSD), VirtualDub (sous Windows) et il me semble même que c’est possible avec VLC.

A part pour le fun, je ne vois pas trop l’intérêt d’une telle solution.

vdaubry · Février 22, 2015, 10:42

Mac OS X :)

Si t’as un outil bien et gratos qui fait ça je suis preneur ! (et sinon oui y a aussi une part de fun ;)

jsys · Février 22, 2015, 3:15

Avec node WebKit tu peux régler tes problèmes puisque tu as accès au disque dur local et au chemin des fichiers.
Voir : https://github.com/nwjs/nw.js/wiki/File-dialogs

vdaubry · Février 22, 2015, 3:20

Merci ! je vais creuser node WebKit du coup.

celine · Février 22, 2015, 4:20

Avidemux par exemple ;-)

vdaubry · Février 22, 2015, 4:43

Cool ! c’est ce que je cherchais merci.

augustin · Février 25, 2015, 9:59

L’architecture impliquant un serveur web ne me choque pas du tout.

Outre le fait que tu n’as effectivement probablement pas le choix (à part des solutions extrêmement hacky), cela présente plusieurs avantages :

separation of concern : tu as l’UI et celui qui travaille (ffmpeg) à deux endroits distincts
mise en place d’une API : potentiellement, tu peux externaliser ce serveur, le rendre accessible de partout (I <3 WEB), ou à l’inverse, exécuter la commande depuis n’importe quelle machine
tu vois ton programme comme l’app JS. Mais tu devrais voir ton programme comme celui qui exécute les commandes ffmpeg et la page web comme un mode d’interaction avec ce programme, tout comme la command line en est un autre, ou l’UI d’un programme Natif encore un autre.

En outre, on aimerait bien que le browser puisse faire plus de choses sur le système, mais je pense que si ça n’est pas possible aujourd’hui, il y a de bonnes raisons à cela (sécurité avant tout probablement, même si je n’ai pas encore assez creusé la question).

Nombreux sont les programmes avec une architecture client/serveur (ex les debuggeurs, mongodb, etc.), je pense que c’est une bonne architecture à conserver et à reproduire à outrance !

Cool ton projet en tout cas. J’essaierai d’y jeter un coup d’oeil à l’occasion.

vdaubry · Février 25, 2015, 10:50

Je suis d’accord avec toi dans le cas d’une appli client / serveur !

Mais là l’idée c’était de faire un client lourd en local : si je veux splitter une vidéo de 500Mo, c’est pas mal d’éviter de l’uploader, puis la downloader.
Sans parler du fait qu’un service en ligne d’édition de vidéo y a des couts pas négligeable, impossible de proposer ça gratuitement.

Sur la techno si je suis parti sur du JS c’était avant tout pour avoir quelque chose de cross platform et de rapide à développer.

Pour la partie separation of concern en plus ça se discute, à partir du moment ou il y un appel de commande shell on est déjà sur de la délégation. Au final une API c’est un moyen de communiquer avec un autre programme (en l’occurence FFmpeg), pas uniquement via HTTP.

Je suis totalement partisan du modele client / serveur pour à peu près tout les besoins, mais il reste des cas particuliers ou un client lourd fait vraiment du sens. La pour de l’édition de vidéo c’est justifié (encore plus si on est sur une petite app gratos ;)

augustin · Mars 3, 2015, 8:32

Je trouve ça réducteur de dire que tu n’es pas dans une situation client/serveur.

Sans nécessairement parler d’un Sass, où tu uploaderais tes vidéos pour les retoucher ensuite, tu pourrais très bien héberger ces vidéos sur ta freebox et bosser sur ton réseau local. Et puis un jour tu fais une démo à ton pote et ça marche comme de par magie à distance.

Ou encore tu pourrais avoir un digital ocean (ou EC2) qui crawle youtube grâce à la merveilleuse librairie https://github.com/rg3/youtube-dl et ton interface web qui compile ces vidéos.

Au final, tu as un client qui envoie des commandes (action légère qui passe par le réseau), à un serveur qui les exécute (action lourde, locale).

Enfin, c’est ce que j’en dis !

Btw, bien joué pour les github awards, je suis tombé sur ton profil github et le repo html5-video-splitter a immédiatement retenu mon attention ! :-)

vdaubry · Mars 15, 2015, 9:03

Ha c’est marrant que tu parles de youtube-dl ! je viens justement de finir un wrapper pour lancer plusieurs download en parallèle :

je voulais voir si j’arrivais à faire tourner une job queue qui démarre des process shell, sans dépendance à des process externes. Donc sans installer ni de bases de données (Redis, Postgres, etc) ni de queue (RabbitMQ, etc)

Au final la conclusion c’est que ça “marche” avec SQLite, mais les accès concurrents posent des problèmes c’est pas hyper robuste…