Recherche avancée

Médias (0)

Mot : - Tags -/signalement

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (82)

  • 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 (...)

  • 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) (...)

  • 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

Sur d’autres sites (10448)

  • FFmpeg - How to scale and then drawtext ?

    19 janvier 2015, par vanderjas

    I’m trying to scale and crop a video and then apply some text over the top.

    I’m able to achieve each of these successfully using the following filters :

    Scale & Crop

    -vf scale=-1:640,crop=640:640:0:0

    Draw Text

    -vf drawtext="fontfile=Gotham-Book.ttf: text=TextHere:fontsize=72:fontcolor=gray@0.25:x=10:y=10”

    I presume I need to use some kind of filter complex but I am not having any luck.

    Can anyone help ?

    Thanks in advance !

  • is this ffmpeg command optimized ?

    22 juin 2017, par Bob Ramsey

    I have a requirement to take a video, add some plain text, and then add some rotated text at different times, locations, and durations. I want to use processor power in the most efficient way this will run 20,000 times (yes, really, we’re personalizing a video for students at a U.)This is what I finally came up with :

    ffmpeg -y -i INPUT.mp4 -filter_complex
     "drawtext=enable='between(t,14,16)':fontfile=tahoma.ttf:fontsize=54:fontcolor=green:x=10:y=text_h + 10:text='Dana Scully',
      drawtext=enable='between(t,19,23)':fontfile=tahoma.ttf:fontsize=16:fontcolor=red:x=150:y=220:text='Dana Scully  \<dana.scully\@fbi.gov\>',
      drawtext=enable='between(t,99,104)':fontfile=tahoma.ttf:fontsize=28:fontcolor=green:x=480:y=text_h + 160:text='Dana Scully',
      drawtext=enable='between(t,14,16)':fontfile=tahoma.ttf:fontsize=16:fontcolor=yellow:x=40:y=25:text='Dana Scully  \<dana.scully\@fbi.gov\>',
      drawtext=enable='between(t,180,186)':fontfile=tahoma.ttf:fontsize=88:fontcolor=green:x=20:y=430:text='Dana Scully'[text];
      color=c=#111111:s=1280x720:d=1,format=yuv444p[colorbk];
      [colorbk]drawtext=fontfile=tahoma.ttf:fontsize=16:fontcolor=purple:x=(w-text_w)/2:y=(h-text_h)/2:text='by',drawtext=fontfile=tahoma.ttf:fontsize=32:fontcolor=green:x=(w-text_w)/2:y=((h-text_h)/2)+50:text='Dana Scully',rotate=(-.5):ow=1280:oh=720:c=#111111,chromakey=#111111:similarity=0.01,format=yuva444p,colorkey=#111111:0.1[rotated];
      [text][rotated]overlay=eval=frame:x='if(gte(t,134),(if(lte(t,137),20,NAN)), NAN)':y=100[out];[out]scale=iw*.25:-1"
      -crf 20 test.mp4

    Is that about as optimized as it is going to get ? I thought ffmpeg would already handle the threads based on the computer’s processor, so no real need to mess with it. The processing will all be done on AWS VMs.

    Rotating the text is what really slows it down.

    Any ideas ?

  • ffmpeg decoding yuv420p to rgb shifts luminance/brightness down

    6 avril 2013, par glopes

    I'm recording video from a grayscale camera into an MPEG4 video file using FFMPEG. Recently I noticed a weird effect : if I playback the file using FFMPEG or windows media player, the output frames are noticeably darker (by about 10 brightness values) than the original source.

    I thought the encoding step was doing this until I opened the same file in VLC and it gave me back the correct result. I played around with FFMPEG command lines to decode a single frame and realized that if I decode a frame into GRAY8 pixel format, the brightness/luminance values are preserved. Here's the command and ffmpeg output :

    ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt gray gray.bmp

    ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
     built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
     configuration: --enable-w32threads
     libavutil      52. 18.100 / 52. 18.100
     libavcodec     54. 92.100 / 54. 92.100
     libavformat    54. 63.104 / 54. 63.104
     libavdevice    54.  3.103 / 54.  3.103
     libavfilter     3. 42.103 /  3. 42.103
     libswscale      2.  2.100 /  2.  2.100
     libswresample   0. 17.102 /  0. 17.102
    Input #0, avi, from 'video.avi':
     Metadata:
       encoder         : Lavf53.32.100
     Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
       Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 128
    0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
    Output #0, image2, to 'gray.bmp':
     Metadata:
       encoder         : Lavf54.63.104
       Stream #0:0: Video: bmp, gray, 1280x680 [SAR 17:18 DAR 16:9], q=2-31, 200 kb
    /s, 90k tbn, 30 tbc
    Stream mapping:
     Stream #0:0 -> #0:0 (mpeg4 -> bmp)
    Press [q] to stop, [?] for help
    frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
    video:851kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.002524%

    However, if I decode the same frame into an rgb color pixel format, I end up again with the darker frames :

    ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt bgr24 rgb.bmp

    ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
     built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
     configuration: --enable-w32threads
     libavutil      52. 18.100 / 52. 18.100
     libavcodec     54. 92.100 / 54. 92.100
     libavformat    54. 63.104 / 54. 63.104
     libavdevice    54.  3.103 / 54.  3.103
     libavfilter     3. 42.103 /  3. 42.103
     libswscale      2.  2.100 /  2.  2.100
     libswresample   0. 17.102 /  0. 17.102
    Input #0, avi, from 'video.avi':
     Metadata:
       encoder         : Lavf53.32.100
     Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
       Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 128
    0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
    Output #0, image2, to 'rgb.bmp':
     Metadata:
       encoder         : Lavf54.63.104
       Stream #0:0: Video: bmp, bgr24, 1280x680 [SAR 17:18 DAR 16:9], q=2-31, 200 k
    b/s, 90k tbn, 30 tbc
    Stream mapping:
     Stream #0:0 -> #0:0 (mpeg4 -> bmp)
    Press [q] to stop, [?] for help
    frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
    video:2550kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000843%

    This happens with every single grayscale video that I encode to MPEG4 with FFMPEG. My best guess so far is it has to do with how the container pixel format gets converted to/from. Since I'm using MPEG4, the file pixel format is YUV420P. I have no idea how ffmpeg encodes from GRAY8 to YUV420P, but maybe it stores just the luminance values in Y... if this happens, then decoding from this to RGB could produce darker pixels by the scaling factor that is applied to the luminance matrix ?

    To sum it up :

    1) How can encoding a grayscale video to YUV420P with FFMPEG and decoding back produce wrong (darker) brightness values when decoding to RGB versus GRAY8 ? Presumably once the frames are in YUV420P format it shouldn't matter whether the source is actually grayscale or not so the result should be equivalent, no ?

    2) How does VLC avoid this situation ? I was under the impression that VLC used FFMPEG as well for video decoding, but somehow they managed to figure out how to produce the correct values without requiring me to indicate explicitly that the video was grayscale.