Journal Vidéo/Images - Je vais et je viens

Posté par  .
Étiquettes : aucune
0
22
août
2005
Bonjour a tous,

Je travaille actuellement dans une société audio-visuelle, et nous sommes confrontés à un petit problème pour le moment:

Un client voudrait un système ou le visiteur pourrait grâce a une roulette avancer ou reculer dans la vidéo. Quand je dis reculer ça veut dire jouer en vitesse 1x mais dans le sens contraire, pas faire des sauts en arrière comme c'est le cas pour tout les lecteurs vidéos actuel.

Bien sur je suis au courant que vu le format de compression Mpeg des vidéos, ceci est impossible (sauf avec un tampon image par image mais ce n'est pas ça que je recherche).

Mais les besoins ne sont pas si compliqués, en fait la vidéo sera assez courte et pourra donc être une suite de .jpg (ou .png) à 25 images/seconde et cela rend la chose nettement plus faisable.

Il me faudrait donc juste un logiciel qui lorsqu'une touche est appuyée il avance d'une image tout les 25ème de seconde et qui recule d'une image quand une autre est enfoncée. Lorsqu'aucune touche n'est enfoncée l'image ne change pas.

Je programme en C/C++ et donc peut adapter quelque chose d'existant, mais s'il faut programmer "depuis rien" je ne suis pas sur que l'on soit dans les délais.

Les "complications" (toutes relatives) selon moi:
- la contrainte de temps (presque réel)
- une mauvaise réactivité après une longue inactivité du a l'arrêt du disque

Voila, donc si vous connaissez un soft, une librairie ou une manière simple et efficace de programmer ça, faites moi signe, en attendant je continue mes recherches.

Merci.

  • # peut-être une connerie

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Je vais peut-être dire une connerie, mais le truc que tu décris pourrait pas être réalisé avec un script bash, un visiualisateur (feh ou image magic) et à la limite une interface zenity pour ton client ?


    Tu convertis la vidéo en une suite de jpg avec mencoder et tu essayes ça. Il reste à voir si c'est assez rapide pour supporter du 25 images par seconde.

    Sinon, en C, un programme GTK qui fait ça ne devrait pas être compliqué. (j'avais écrit, pour apprendre GTK, un programme qui changeait une image quand on appuie sur un boutton. ça m'a pris une grosse heure de C pour faire ça et j'avais jamais fait de Gtk).


    Et ce genre de truc en python doit aussi être facile. Mais évidemment on suppose que tu as une séquence Jpg.


    Si ce n'est pas possible avec une séquence jpg, faut alors choisir un codec video qui n'est pas basé sur des différences entre les frames, genre du DV pur.
    Et dans ce cas, je te conseille de jeter un oeil à Gstreamer.

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: peut-être une connerie

      Posté par  . Évalué à 1.

      Oui merci, c'est une des hypotheses auxquelles je pense, mais si je dit au boss "ok comme ca va fonctionner", il va me coller dessus puis si a la fin mon programme met 5 secondes pour passer a l'image suivante quand on ne l'a pas touché pendant 2 heures car le systeme a arreté le disque dur on aura plus que 1 ou 2 jours pour trouver une solution :(

      Je pensait a qqchose du genre en multythreading avec une mise en tampon des images voisines, mais ca sort de mes competances.

      Ca mériterait un essait en tout cas. (a faire en extra et je fais deja pleins d'heures sup car a la boure sur un autre projet)

      La video je n'ai meme pas besoin de la convertir, je dit a la production comment je la veux et c'est eux qui se débrouillent.

      • [^] # Re: peut-être une connerie

        Posté par  (site web personnel) . Évalué à 3.

        Si tu charges une quarantaine d'images en RAM, le disque dur aura le temps de se réveiller le temps que les quarante soient passées.
        C'est faisable sans multithreading au fait (quoique mettre un gestionnaire de cache dans un autre thread serait certainement plus censé).

        Je pense que tu en as pour deux heures de boulot, un bon café, une aspirine, et c'est parti :p:p

        (man pthread_create et roulez jeunesse)

        • [^] # Re: peut-être une connerie

          Posté par  (site web personnel) . Évalué à 3.

          Si tu charges une quarantaine d'images en RAM, le disque dur aura le temps de se réveiller le temps que les quarante soient passées. C'est faisable sans multithreading au fait
          Oui mais non, si la mise en RAM des images n'est pas "threadée", avant ou après chaque image que tu vas lire, tu vas charger une autre image (même si elle est 40 frames plus loin). Il suffit d'avoir une "pause" assez longue pour que le HD "s'endorme" pour retrouver une latence assez grande lors du prochain mouvement. Donc il me semble assez indispensable de threader la mise en cache des images.

          Bon en fait il y a sans doute moyen de le faire sans thread mais ça risque d'être plus compliqué qu'avec. Par ailleurs, il ne faut pas oublier non plus que le programme (ou une partie de sa mémoire) risque d'être mis en swap, donc ça ne règle pas tous les problèmes. Une solution est de ne pas mettre de swap sur les machines concernées ou d'utiliser mlock(2) (mais sous Linux, seul root peut le faire, sous BSD par exemple tout le monde peut mlock(2)er des pages mais avec un nombre limite).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: peut-être une connerie

            Posté par  . Évalué à 2.

            (mais sous Linux, seul root peut le faire, sous BSD par exemple tout le monde peut mlock(2)er des pages mais avec un nombre limite)

            Sous Linux aussi tout le monde peut mlocker, mais le nombre limite est de zéro pour un utilisateur non s.u.

            Mauvaise foi, quand tu nous tiens ;o)

            Sinon, je ne sais pas si ce n'est que Linux : il semblerait d'après la page de man que mlock soit POSIX 1b. Qui a la norme sous le coude pour vérifier (ou un unix posix...) ?

            • [^] # Re: peut-être une connerie

              Posté par  (site web personnel) . Évalué à 2.

              Sous Linux aussi tout le monde peut mlocker, mais le nombre limite est de zéro pour un utilisateur non s.u.
              J'avoue ne jamais avoir utilisé cette fonction mais dans la man que j'ai sous les yeux il est écrit que
              seul le Super-User peut verrouiller des pages
              Pour les *BSD j'ai juste vérifié la man d'OpenBSD, j'ai lu quelque part que c'était pareil pour les autres mais j'ai pas vérifié.

              Effectiement mlock(2) est censé être plus ou moins portable.
              http://www.unix.org/onlinepubs/007908799/xsh/mlock.html(...)
              (SUSv2 est une extension de POSIX je pense)

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: peut-être une connerie

                Posté par  . Évalué à 3.

                Le « mauvaise foi » s'appliquait à ma propre remarque ;o)
                La page de man que j'ai sous les yeux dit que le code erreur EPERM est renvoyé si l'on a pas les droits s.u.

                C'était juste pour dire que tout le monde pouvait utiliser la fonction mais qu'elle ne fait ce que l'on souhaite que pour s.u. (je l'ai dit : mauvaise foi ;o)

                Par contre, plus sérieusement, la portabilité n'est pas super : EAGAIN et ENOSYS ne sont pas prévues sur la version Linux (toujours selon la page de man, SVr4 prévoit le EAGAIN) et tu dis que BSD permet aux n.u. (normal-user) de le faire.
                Mais bon, pour une fonction système, c'est un peu normal.

                • [^] # Re: peut-être une connerie

                  Posté par  (site web personnel) . Évalué à 3.

                  En fait tu as raison, c'est la page de man qui est pas à jour. Dans linux/include/linux/mm.h il y a 
                  static inline int can_do_mlock(void)
{
        if (capable(CAP_IPC_LOCK))
                return 1;
        if (current->signal->rlim[RLIMIT_MEMLOCK].rlim_cur != 0)
                return 1;
        return 0;
}
                  (qui est utilisée dans linux/mm/mlock.c:sys_mlock() Donc il suffit de mettre la ligne qui va bien dans /etc/security/limits.conf (ou utiliser les "capabilities" mais là j'y connais rien).

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # L.I.V.E.S.

    Posté par  . Évalué à 8.

    L.I.V.E.S. (Linux Video Editing System) http://www.xs4all.nl/~salsaman/lives/(...)

    il fait aussi VJ et fonctionne un peu comme ça: il transforme les videos en une succesion d'image png ou jpeg. la lecture dans les 2 sens à l'aide des touches fleches est fluide. Avidemux le fait aussi mais il y a une latance dans dans la lecture arriere. Je pense qu'il faudrait que tu regarde du coté des programmes dit "VJ" (Video Jockey)

    • [^] # Re: L.I.V.E.S.

      Posté par  . Évalué à 4.

      Je ne connais aucun outil linux sur la video il y a longtemps que j'ai quitté le metier mais il me semble que tu peux forcer avec la norme mpeg2 un encodage image/image ( ou chaque image sera compléte) du coup tu devrais pouvoir revenir en arriere.

      reste plus qu'à te trouver la librairie qui fait ça.

      ps: Tu vas exploser tes volumes dans tous les cas.

  • # tu dois dev un site ou une appli ?

    Posté par  (site web personnel) . Évalué à 2.

    en lisant Un client voudrait un système ou le visiteur pourrait moi je comprends que tu dois dev un site web ... auquel cas je pense que le Java serait le plus simple.

    Sinon, je te renvoi a mes collegues ci dessus.

    • [^] # Re: tu dois dev un site ou une appli ?

      Posté par  . Évalué à 4.

      Désolé pour le malentendu, le client c'est un musée et le visiteur interagit physiquement avec une borne multimedia. Normalement on travaille avec des lecteur video sur carte flash le tout mis en rack. On utilise des ordi seulement quand le projet sort de l'ordinaire.
      Donc appli!

  • # ffmpeg

    Posté par  (site web personnel) . Évalué à 6.

    Un collegue a fait le port de Lynkeos pour Linux. Il a utiliser la bibliotheque ffmpeg. Le passage d'une image image par image est bien gerée dnas le cas ou ca avance, un petitpeu moins vite quand tu va en arriere mais ca focntionne tres bien.
    le port : http://christophe.jalady.free.fr/lynkeos/index.html(...)

  • # MJPEG

    Posté par  . Évalué à 4.

    Cela ne va pas beaucoup t'avancer, mais le format de vidéos le plus approprié serait certainement le MJPEG, qui consiste en une série de JPEG. C'est exactement ce que tu proposes, mais dans un conteneur "standard" et qui devrait donc être manipulable facilement par des bibliothèques (ex: http://mjpeg.sourceforge.net/ ).

    L'équivalent PNG existe aussi, c'est le format MNG, mais je crois qu'il a plus vocation a remplacer les GIF animés qu'à faire des petites vidéos.

    • [^] # Re: MJPEG

      Posté par  . Évalué à 4.

      J'oubliais. Pour le disque dur -> man hdparm :) Ou alors faire un ramdisk. Ou bien utiliser un disque flash...

  • # GdkPixbufAnimation

    Posté par  (site web personnel) . Évalué à 5.

    Dans l'API de GTK il y a un truc pour de l'animation (dans GDK)

    http://developer.gnome.org/doc/API/2.0/gdk-pixbuf/gdk-pixbuf-animat(...)

    Ca me semble assez réalisable, il faut encore voir ce que ça supporte comme format.

    Et pour avancer d'une image : gdk_pixbuf_animation_iter_advance()

    Ensuite, pour être sûr que ça reste dispo il suffit peut-être de laisser tourner un thread qui s'amuse à recharger régulièrement l'image courante et celles adjacentes ?

  • # je ne sais pas si c'est pertinent mais

    Posté par  . Évalué à 2.

    Je ne sais pas comment ils font ça mais au démarrage de enlightenment 0,17, l'animation n'est qu'une suite de png... et c'est très fluide

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.