Recherche avancée

Médias (91)

Autres articles (56)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

Sur d’autres sites (6449)

  • creating thumbnail on mips using FFMPEG is quite slow for some containers

    6 juillet 2012, par Spottsworth

    I'm using the following command to get a thumbnail from a video file. It uses the seek option to grab a thumbnail. The problem is that this command takes up quite some time especially with certain containers such as MPEG-2 TS. (As much as 40 seconds). If I vary the point (duration) at which I want to grab the thumbnail , it does not seem to have an impact on the time taken. Of course when I run this on my Linux workstation, it hardly takes 2 seconds to produce the thumbnail. Any suggestions to speed up the process on my MIPS board ?

    ./ffmpeg -ss 18 -i input.ts -vf select='eq(pict_type\,PICT_TYPE_I)' -vframes 1 -an -s 150x100 thumb.jpg

  • Creating thumbnails with FFmpeg

    3 janvier 2012, par Calin-Andrei Burloiu

    I am using FFmpeg to extract thumbnails from specific positions of video files.

    I found on the web two approaches to do this :

    1. With -ss (seek) parameter before -i (input) parameter :

      ffmpeg -y -ss $SEEK_POINT -i input.ogv -vcodec mjpeg -vframes 1 -an -s 120x90 -f rawvideo output.jpg

    2. With -ss (seek) parameter after -i (input) parameter :

      ffmpeg -y -i input.ogv -vcodec mjpeg -ss $SEEK_POINT -vframes 1 -an -s 120x90 -f rawvideo output.jpg

    The first method generates a bad thumbnail with gray spots, but works very fast. The error returned is [theora @ 0x8097240] vp3: first frame not a keyframe.

    The second method always works but show an error which cause the extraction to take a lot of time. This amount of time is not fixed and it depends on the seek point as I noticed. Sometimes it takes a few seconds and other times several minutes to extract a thumbnail. I get the error Buffering several frames is not supported. Please consume all available frames before adding a new one. in the following output :

    Input #0, ogg, from 'input.ogv':
     Duration: 00:21:52.76, start: 0.000000, bitrate: 844 kb/s
       Stream #0.0: Video: theora, yuv420p, 800x600 [PAR 4:3 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
       Stream #0.1: Audio: vorbis, 44100 Hz, stereo, s16, 192 kb/s
       Metadata:
         ENCODER         : Lavf52.102.0
    Incompatible pixel format 'yuv420p' for codec 'mjpeg', auto-selecting format 'yuvj420p'                                                                        
    [buffer @ 0x9250840] w:800 h:600 pixfmt:yuv420p                                
    [scale @ 0x92508a0] w:800 h:600 fmt:yuv420p -> w:120 h:90 fmt:yuvj420p flags:0x4
    Output #0, rawvideo, to 'output.jpg':
     Metadata:
       encoder         : Lavf53.2.0
       Stream #0.0: Video: mjpeg, yuvj420p, 120x90 [PAR 4:3 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc
    Stream mapping:
     Stream #0.0 -> #0.0
    Press ctrl-c to stop encoding
    [buffer @ 0x9250840] Buffering several frames is not supported. Please consume all available frames before adding a new one.                                    
    frame=    0 fps=  0 q=0.0 size=       0kB time=10000000000.00 bitrate=   0.0kbit
    Last message repeated 15448 times
    frame=    1 fps=  0 q=3.4 Lsize=       3kB time=0.04 bitrate= 598.8kbits/s    
    video:3kB audio:0kB global headers:0kB muxing overhead 0.000000%

    How can I extract thumbnails without any problems using FFmpeg from a custom position of a video regardless of the input format ?

  • Using lcov With FFmpeg/Libav

    21 novembre 2011, par Multimedia Mike — Programming, code coverage, ffmpeg, lcov, libav

    Last year, I delved into code coverage tools and their usage with FFmpeg. I learned about using GNU gcov, which is powerful but pretty raw about the details it provides to you. I wrote a script to help interpret its output and later found another script called gcovr to do the same, only much better.

    I later found another tool called lcov which is absolutely amazing for understanding code coverage of your software. I’ve been meaning to use it to further FATE test coverage for the multimedia projects.



    Click for larger image

    Basic Instructions
    Install the lcov tool, of course. In Ubuntu, 'apt-get install lcov' will do the trick.

    Build the project with code coverage support, i.e.,

    ./configure —enable-gpl —samples=/path/to/fate/samples \
     —extra-cflags="-fprofile-arcs -ftest-coverage" \
     —extra-ldflags="-fprofile-arcs -ftest-coverage"
    make
    

    Clear the coverage data :

    lcov —directory . —zerocounters
    

    Run the software (in this case, the FATE test suite) :

    make fate
    

    Let lcov work its magic :

    lcov —directory . —capture —output-file coverage.info
    mkdir html-output
    genhtml -o html-output coverage.info
    

    At this point, you can aim your web browser at html-output/index.html to learn everything you could possibly want to know about code coverage of the test suite. You can sort various columns in order to see which modules have the least code coverage. You can drill into individual source files and see highlighted markup demonstrating which lines have been executed.

    As you can see from the screenshot above, FFmpeg / Libav are not anywhere close to full coverage. But lcov provides an exquisite roadmap.