J'ai enfin réussi à me botter le cul pour faire un truc qui me tenait à cœur : des packages pour MediaInfo plus propres que ce qui était fait avant (j'avoue : ils avaient été fait à l'arrache).
Pour info, MediaInfo fournit des informations techniques (format, version de l'encodeur, paramétrage de l'encodeur, bitrate...) et les tags (artiste, acteurs, age...) à propos de vos fichiers video et audio (du classique AVI à des formats plus inhabituels comme NSV en passant par FLV, MPEG-4 voir les flux satellites TS même si ils contiennent 20 chaines de TV et/ou radio).
Il existe 3 versions :
- une interface graphique pour les pressés
- une ligne de commande pour ceux qui veulent faire des batches (ou les amateurs de terminaux ;-) )
- un bibliothèque partagée avec des bindings C, C++, Java, Python pour ceux qui veulent récupérer les infos dans leurs programmes.
Étant assez maniaque sur la forme, et faute de contributeurs en nombre suffisant ([troll] et bons, on est allé jusqu'à me proposer un package qui a empaqueté un binaire même pas conçu sur cet distrib', et du coup qui marche pas car cherche des dépendances compilées d'une autre manière sur cette distrib'... Si je citais le nom de la distrib utilisée... ;-) [troll]), et surtout vu le bordel que c'était avant de faire le ménage, j'ai préféré faire les packages moi-même, et jouer avec OBS (comme ça, j'ai pu découvrir les contraintes des packageurs, et adapter le source en fonction)
J'ai réussi tant bien que mal avec OBS à créer des packages CentOS, RHEL, Fedora, openSUSE et Debian (mes tentatives avec Ubuntu sous OBS n'ont malheureusement pas abouties, à cause d'OBS qui ne contient pas les paquets "universe". Mais ça marche très bien quand on lance la création de paquet sur une Ubuntu installée, et le paquet Debian marche bien dessus aussi.)
J'ai aussi ajouté de quoi s'intégrer au menu des gestionnaires de fenêtres (merci freedesktop.org pour essayer de standardiser tout ça) ainsi que le menu contextuel pour KDE3 et 4.
J'ai maintenant besoin de gentils testeurs pour me dire si tout ça fonctionne bien, de l'installation à l'intégration dans le gestionnaire de fenêtre. Ca se passe ici :
http://mediainfo.sourceforge.net/en/Download (tout en bas, en test pour le moment)
Bon, je préviens tout de suite, le GUI multi-plate-forme en est qu'à ses débuts et à 5% des fonctionnalités de la version Windows, mais je compte bien à terme qu'il soit le seul et unique. Il peut rester des endroits "orientés Windows", j'essaye de gommer au fur et à mesure. Le CLI est le .so sont quand à eux identiques à la version Windows.
Je profite du journal pour chercher des experts capables de :
- faire un menu contextuel pour Gnome
- me trouver les extensions MIME qui vont bien pour KDE (j'arrive à avoir un menu contextuel pour un .avi par exemple, mais pas un .ts)
- intégrer ces packages dans les dépôts officiels des distributions.
Bon, j'ai essayé de ne pas trop troller (car après avoir joué avec rpm et deb, KDE et Gnome, il y aurait tant à dire...), on va voir ce que ce journal va donner en commentaires!
Journal MediaInfo cherche beta-testeurs
1
déc.
2008
# Y'a pas Debian GNU/Hurd sur ARM ?
Posté par zebra3 . Évalué à 5.
Je peux t'aider un peu, pour ce qui est du menu contextuel GNOME. Il y a plusieurs méthodes :
* Via nautilus-action : c'est le plus simple, ça se fait avec une interface graphique en trente secondes,
* Avec une extension Nautilus en Python : dans le package Debian, il y a des exemples, c'est relativement simple à écrire.
* Avec une extension « standard » Nautilus : en C/GTK, mais là, je n'ai jamais essayé.
Pour les extensions MIME, je suppose qu'un « file -i » doit suffire (il renvoie le type sous la forme application/type), puisque Konqueror utilise sûrement ce genre d'infos pour déterminer les types.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Y'a pas Debian GNU/Hurd sur ARM ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Je ne m'attendais clairement pas à passer autant de temps sur le sujet, chaque distrib se plaignant de choses différentes suivant l'humeur. Bon, j'arrive à faire des fichiers de conf qui passe presque partout, c'est déjà pas mal.
Y'a pas Debian GNU/Hurd sur ARM ?
Si tu me files une machine, je te le fais ;-)
(MediaInfo est connu pour fonctionner entre autres sur des ARM, il n'y a pas de raisons :-D )
(j'ai dit que j'étais maniaque, pas pour rien ;-) )
C'est d'ailleurs dommage que OBS ne fourni pas pour Mr tout le monde des machines PPC. On fait avec ce qu'on a (donc i386 et x86_64), ce qui est déja beaucoup.
* Via nautilus-action : c'est le plus simple, ça se fait avec une interface graphique en trente secondes,
Ca à l'air vachement bien pratique tout ça.
Vais intégrer le .shema qui en résulte dans les packages...
Merci!
Pour les extensions MIME, je suppose qu'un « file -i » doit suffire
Le coup de Linux plus mieux bien car ne se base pas sur les extensions, j'en suis revenu... file -i me sort un "video/mp2t", ce qui est juste. mon fichier .desktop prend "video/*", qui marche avec un avi, mais pas avec ce fichier. Pire, si je renomme le fichier en .avi, le menu contextuel apparait (en même temps que Dragon player...). Si le simple fait de changer l'extension change le menu contextuel, ben... Dire que les extensions ça ne compte pas, c'est pas très vrai!
Donc au final, non, toujours bloqué sur ça. Et ne croit plus que Linux ça se base sur les type MIME.
[^] # Re: Y'a pas Debian GNU/Hurd sur ARM ?
Posté par tanguy_k (site web personnel) . Évalué à 5.
Je ne m'attendais clairement pas à passer autant de temps sur le sujet, chaque distrib se plaignant de choses différentes suivant l'humeur.
Et c'est bien dommage, a mon avis Linux gagnerait beaucoup de part de marche si le systeme de packaging etait d'avantage standardise.
Il est plus simple de faire un package qui tourne sur tous les Windows, c'est un comble quand meme :/
[^] # Re: Y'a pas Debian GNU/Hurd sur ARM ?
Posté par zebra3 . Évalué à 2.
Donc au final, non, toujours bloqué sur ça. Et ne croit plus que Linux ça se base sur les type MIME.
Dommage... En même temps, je citais ça de tête, car c'est ce qu'il y a de plus logique (et c'est d'ailleurs un avantage sur Windows).
C'est ce que Nautilus fait en partie : lors de l'affichage, on se base sur l'extension, et lors de la sélection est fait un test du type MIME, le tout pour des raisons de perf. C'est pourquoi je supposais que c'était le cas aussi pour KDE.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# MediaInfoLib vs TagLib
Posté par tanguy_k (site web personnel) . Évalué à 2.
MediaInfo a un spectre beaucoup plus large: TagLib a été crée pour les fichiers musicaux uniquement.
MediaInfoLib pourrait t'il remplacer TagLib notamment en terme de rapidité de traitement ?
Je vois aussi que MediaInfo a pas mal de dépendances contrairement a TagLib qui n'en a aucune. http://mediainfo.sourceforge.net/en/Support/Build_From_Sourc(...)
Pour construire MediaInfoLib, WxWidgets est-il nécessaire ?
En tout cas je suis très intéressé; pour les fichiers vidéos, MediaInfoLib n'a à ma connaissance aucun équivalent ! Bravo !
[^] # Re: MediaInfoLib vs TagLib
Posté par Zenitram (site web personnel) . Évalué à 4.
MediaInfo, le CLI, n'a que peu de dépendances : libmediainfo (normal) et libzen une bibliothèque à moi que j'utilise sur un autre projet donc on m'a conseillé d'en faire un .so à part. Si c'est juste ça qui te dérange, il existe un package "all in one" qui compile les 3 packages en une ligne de commande, sans dépendances autre que la libc et c++. Pas mal de monde utilise ce binaire "transportable partout".
Ah si, libmediainfo utilise aussi libz, parce que bon pas la peine de réinventer la roue (des fichiers .mov ont des headers compressés), mais pareil : inclu dans le binaire "all in one".
Reste le GUI, qui ajoute une dépendance sur libwsgtk, mais la je vois pas trop comment faire, linux n'a pas d'API graphique "de base" : soit Wx, soit Qt, soit GTK, mais il faut une dépendance.
Après, si tu parles de construire à partir des sources, oui il y a plus de dépendances, car je fais d'autres choses : doxygen, dos2unix, pkg-config sont optionnels et m'aident à faciliter le port Unix. Mais encore une fois, si tu veux un gros trucs bien bourrin, le "all in one" est un tar.bz2 qui ne demande que gcc-c++ (si la libz n'est pas trouvée, elle est téléchargée et compilée) pour tourner. C'est rapide, juste un ./CLI_COmpile à lancer, sans te soucier des dépendances.
libmediainfo n'a pas besoin de wxwidgets pour être construit (j'ai viré la dépendance sur wxbase car ça faisait un x10 sur la taille de la lib pour très peu de choses. Remplacé par libzen pour le multi-plate-forme à moindre coût. Surtout pour les petits ARM qui n'aiment pas du tout Wx...)
Au niveau rapidité de traitement, TagLib est plus rapide car ne s'intéresse qu'aux tags, alors que MediaInfo parse plus d'octets pour détecter les données techniques. MediaInfo est très rapide pour ce qu'il fait, mais ne peut concurrencer TagLib qui fait "moins" (mais bien, ce n'est pas une critique, juste un objectif différent)
De plus, TagLib gère l'écriture, MediaInfo pas (encore).
Seul point avantageux (à moins que ça ai changé) : MediaInfo débusque des tags que TagLib ne trouve pas (un tag APE caché derrière un tag ID3, ou des tags ASF encapsulés dans un tag Id3v2 par exemple)
Bref, TagLib est un "concurrent" de MediaInfo (tout comme Hachoir, souvent présenté ici), mais les logiciels n'ont pas le même objectif : le choix de ta lib va dépendre de si tu veux faire plus de choses qu'avec TagLib : non, TagLib sera ton choix (plus stable, plus rapide). Oui (video, données techniques), prend (Lib)MediaInfo qui te sort plus d'infos.
[^] # Re: MediaInfoLib vs TagLib
Posté par tanguy_k (site web personnel) . Évalué à 2.
La question des dépendances est assez importante pour moi car j'integre dans mon svn le code source des libs externes et je les "CMakifie" avec un flag a la compile pour desactiver tout ca si besoin. Ca permet ensuite de creer tres facilement des binaires pour VC++ 2003, 2005, 2008, MinGW, Linux et bientot Mac.
Donc si libmediainfo ne depend que de libzen et zlib, c'est plus que parfait ! Pour info TagLib depend optionnellement de la zlib aussi, donc c'est vraiment pareil.
Au passage, un patch CMake pour libmediainfo t'interesserait ?
En regardant ton code source, ca te permettrait de virer autotools et tous les fichiers *.sln, *.bat, *.sh... (le temps que t'as du y passer !)
CMake est une vrai petite merveille pour faire du multiplateforme - Y'a pas mieux !
[^] # Re: MediaInfoLib vs TagLib
Posté par tanguy_k (site web personnel) . Évalué à 4.
Regarde les diff:
http://code.google.com/p/phonon-vlc-mplayer/source/detail?r=(...)
http://code.google.com/p/phonon-vlc-mplayer/source/detail?r=(...)
Et surtout les CMakeLists.txt
MediaInfoLib et ZenLib compilent donc chez moi (VC++2005), faut encore que j'integre le .def (d'ailleurs on n'utilise plus les .def, c'est mieux d'integrer les delspec directement dans les headers, c'est moins prise de tete)
Ca m'a pris 15min !
si tu passais a CMake, tu pourrais virer tous tes scripts ! J'imagine que t'as du passer un temps de ouf dessus !
CMake te ferait gagner ENORMEMENT de temps !
CMake supporte tout les compilos actuels (meme Borland il me semble - je sais que tu l'aimes bien :) et est vraiment multiplateforme.
Pour ce qui est de ZenLib, c'est interessant mais certainement redondant par rapport a des libs genre QtCore. Apres faut voir si c'est dans la politique du projet d'integrer un dependance externe (Boost, QtCore ou meme GLib...)
On peut surement continuer a discuter de ca en priver :)
La je vais faire les courses et manger :)
mais avant demain les CMakeLists.txt permettront de compiler MediaInfoLib sous VC++2005, Linux GNU GCC, VC++2008 et MinGW
[^] # Re: MediaInfoLib vs TagLib
Posté par Zenitram (site web personnel) . Évalué à 2.
De plus, tu peux choisir un un un les parsers que tu veux compiler si tu cherche la légèreté (comme dit précédemment, MediaInfo passe sans problèmes sur des petits composants embarqués
Au passage, un patch CMake pour libmediainfo t'interesserait ?
Yep, je prend!
Pour le moment, je n'ai pas encore vu d'intérêt à CMake malgré tout le bien qu'on en dit, car je trouve les autotools immondes mais très adaptables (cf ./configure --help de MediaInfoLib), acceptant pas mal de modes de compilation.
Et ça fait aussi MinGW, Linux et Mac (MediaInfo compile très bien sous Mac aussi, pas de soucis. Enfin, plus de soucis, car j'ai quand même dû adapter au bizarreries d'Apple quand même ;-) ).
Je ne remplacerai sans doute pas tout car mes petits scripts font tout ce dont j'ai besoin actuellement, mais je l'intégrerai au projets et ça remplacera au fur et à mesure le reste. Par contre, une petite contrainte : pas de fichier dans les répertoire "sources" (quand j'avais testé CMake au début, c'était un fichier txt par répertoire, pour bien te pourrir tes sources... mais je crois que ça a changé)
MediaInfoLib et ZenLib compilent donc chez moi (VC++2005), faut encore que j'integre le .def (d'ailleurs on n'utilise plus les .def, c'est mieux d'integrer les delspec directement dans les headers, c'est moins prise de tete)
si tu me dis comment ça marche ;-)
si tu passais a CMake, tu pourrais virer tous tes scripts ! J'imagine que t'as du passer un temps de ouf dessus !
Comme dis plus haut, les scripts font pas mal de petites choses, comme packaging aussi donc bon, ça sera viré... plus tard.
Pour ce qui est de ZenLib, c'est interessant mais certainement redondant par rapport a des libs genre QtCore. Apres faut voir si c'est dans la politique du projet d'integrer un dependance externe (Boost, QtCore ou meme GLib...)
Oui, c'est redondant, je "refais la roue". Le problème que j'ai avec Boost et compagnie est leur poids : c'est trop lourd pour des petits projets comme le mien. Mes donneurs d'ordre (j'essaye de vivre de MediaInfo, donc bon faut que j'écoute ceux qui me payent :-D ) ont souvent pour objectif un truc très léger, et Boost Qtcore et compagnie mangent trop (en RAM et en disque) tout en étant difficilement packageable. Je refais des trucs, c'est un choix. J'avais commencé avec WxBase au départ, j'ai regretté (c'est bien quand tu as un projet Wx, mais sinon le poids, la dépendance... non), je crains d'avoir les mêmes problèmes avec les autres.
On peut surement continuer a discuter de ca en priver :)
Oui, on va arrêter de polluer ici :)
[^] # Re: MediaInfoLib vs TagLib
Posté par tanguy_k (site web personnel) . Évalué à 2.
Je comprends tout a fait, QtCore4.dll (mode release) sur mon PC fait 1.92Mo :/
J'ai longtemps utilise Boost, c'est plus leger que QtCore (le decoupage est "mieux" fait) mais mon avis est que l'API n'est pas aussi bien.
Si jamais tu refais l'interface graphique en Qt, alors il serait interessant d'etudier la possibilite d'utiliser QtCore aussi pour MediaInfoLib.
Ce que je fais dans ce genre de cas c'est de "mimer" l'API de Qt (ou autre), au moins ca limite le "reinventage" de roue
[^] # Re: MediaInfoLib vs TagLib
Posté par Zenitram (site web personnel) . Évalué à 2.
J'oubliais : cette page est trop vieille, j'ai viré toutes les dépendances, il reste juste hors packaging libzen et libz.
Faut que je vire cette page (ou la réactualise, en prenant en compte que par exemple TntUnicodeControls est juste pour Windows)
# Remarques rapides
Posté par imalip . Évalué à 6.
1/Définir la version de lib dans configure.ac (un truc du genre LIB_REVISION), le réutiliser dans Makefile.in, et s'en reservir dans libzen.pc.in. Ca évite de faire un coup de sed dans debian/rules.
2/Dans le meme ordre d'idée, il est normalement possible d'installer les headers, le .pc, etc au moment du "make install". Ca évite de te les réinstaller a la paluche pour chaque type de package. Ca évite aussi aux gens qui compilent a la main d'installer aussi a la main.
3/Dans le package debian, utilise "$(MAKE) [...] install" au lieu de install-strip. dh_strip s'en occupe par la suite et permet une certain flexibilité (genre il vérifie une variable d'environnement pour ne pas stripper, ca permet de recompiler avec symboles de débug sans modifier le package source).
4/Si tu décides d'appeler les autotools (autogen), il te faut un build-depend dessus. Sinon ca ne marchera pas le jour ou quelqu'un essaiera de compiler dans un pbuilder ou sur un buildd.
Si tu veux un coup de main pour le coté packaging, n'hésite pas a me contacter par message privé, mais je préviens je suis un peu surchargé en ce moment...
[^] # Re: Remarques rapides
Posté par Zenitram (site web personnel) . Évalué à 3.
OK.
4/Si tu décides d'appeler les autotools (autogen), il te faut un build-depend dessus.
Bizarre, car OBS était déjà assez tatillon dessus. Mais vu que je construis le .tar.bz2 sous Windows, oui j'ai besoin d'utiliser les autotools ensuite.
Build-Depends: automake, libtool (etc...)
suffit?
Pour le reste, je suis malheureusement allé aussi loin que ce que je comprenais. Les autotools sont encore un peu mystiques pour moi (je crois que je ne suis pas seul sur ça), et j'ai pallié dans le debian rules et le .spec (pour rpm) à ce que je n'arrivais pas à faire dans le configure.ac ou Makefile.am. sur ça, j'ai besoin d'aide.
Si tu veux un coup de main pour le coté packaging, n'hésite pas a me contacter par message privé
Faut pas le dire 2 fois!
[^] # Re: Remarques rapides
Posté par imalip . Évalué à 2.
suffit?
A priori, automake, autoconf, libtool devraient etre suffisant, oui.
Les autotools, sont effectivement assez cryptiques au premier (et au 2eme et 3eme) abbord; mais une fois qu'on a compris les truc, c'est tres flexible.
Un truc que je n'ai toujours pas trouve avec CMake, c'est comment on faisait correctement un paquet source (l'equivalent de "make dist" avec les autotools).
Comme j'ai dit, je suis un peu surcharge en ce moment, preparation de la saison 2009 oblige, mais si je peux aider...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.