Recherche avancée

Médias (91)

Autres articles (36)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
    Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
    Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
    Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

Sur d’autres sites (6218)

  • avfilter/formats : Fix heap-buffer overflow when merging channel layouts

    13 août 2020, par Andreas Rheinhardt
    avfilter/formats : Fix heap-buffer overflow when merging channel layouts
    

    The channel layouts accepted by ff_merge_channel_layouts() are of two
    types : Ordinary channel layouts and generic channel layouts. These are
    layouts that match all layouts with a certain number of channels.
    Therefore parsing these channel layouts is not done in one go ; instead
    first the intersection of the ordinary layouts of the first input
    list of channel layouts with the ordinary layouts of the second list is
    determined, then the intersection of the ordinary layouts of the first
    one and the generic layouts of the second one etc. In order to mark the
    ordinary channel layouts that have already been matched as used they are
    zeroed. The inner loop that does this is as follows :

    for (j = 0 ; j < b->nb_channel_layouts ; j++)
    if (a->channel_layouts[i] == b->channel_layouts[j])
    ret->channel_layouts[ret_nb++] = a->channel_layouts[i] ;
    a->channel_layouts[i] = b->channel_layouts[j] = 0 ;

    (Here ret->channel_layouts is the array containing the intersection of
    the two input arrays.)

    Yet the problem with this code is that after a match has been found, the
    loop continues the search with the new value a->channel_layouts[i].
    The intention of zeroing these elements was to make sure that elements
    already paired at this stage are ignored later. And while they are indeed
    ignored when pairing ordinary and generic channel layouts later, it has
    the exact opposite effect when pairing ordinary channel layouts.

    To see this consider the channel layouts A B C D E and E D C B A. In the
    first round, A and A will be paired and added to ret->channel_layouts.
    In the second round, the input arrays are 0 B C D E and E D C B 0.
    At first B and B will be matched and zeroed, but after doing so matching
    continues, but this time it will search for 0, which will match with the
    last entry of the second array. ret->channel_layouts now contains A B 0.
    In the third round, C 0 0 will be added to ret->channel_layouts etc.
    This gives a quadratic amount of elements, yet the amount of elements
    allocated for said array is only the sum of the sizes of a and b.

    This issue can e.g. be reproduced by
    ffmpeg -f lavfi -i anullsrc=cl=7.1 \
    - af 'aformat=cl=mono|stereo|2.1|3.0|4.0,aformat=cl=4.0|3.0|2.1|stereo|mono' \
    - f null -

    The fix is easy : break out of the inner loop after having found a match.

    Reviewed-by : Nicolas George <george@nsup.org>
    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

    • [DH] libavfilter/formats.c
  • How can I use ffmpeg to create a seamless looping gif ? [closed]

    27 juin 2024, par DavidNyan10

    I have an MP4 file which contains animation repeating in a loop. Let's just say, for example, a video of rain. However, when loop is turned on, the video cuts off at the wrong place and does not make a nice smooth animation. The part where it loops is obvious. It's just that the video contains more than one cycle of the loop, but not an exact integer of the full cycle.

    &#xA;

    My goal is to turn this video into a gif with a seamless loop. In other words, I want the last frame of the video to match the first frame.

    &#xA;

    My approach : I found a "Seamless loop creator" website on Google, tried it out, and it worked REALLY well. I thought all my problems have been solved. But little did I know, I've been only looking at the few seconds at the beginning and at the end of the video, not paying attention to what's in the middle. The sneaky pesky little website cuts off the video right in the middle, stitch the "seamless transition" at the beginning and end of the video, and put an ugly cross-fade in the middle where the frames don't line up. That is stupid. This of course, isn't noticable on rain videos, but on videos like a character jumping, the crossfade is very visible.

    &#xA;

    My second approach : I'd use FFMPEG to get the first frame of the video, then starting from the last frame of the video and backwards, it'd try to find a frame that matches exactly with the first frame.

    &#xA;

    Steps :

    &#xA;

      &#xA;
    1. Get the first frame and save it as a PNG or something I don't know
    2. &#xA;

    3. Reverse the original video
    4. &#xA;

    5. Match the image to each frame of the video in step 2. It is now easier because it's not doing it backwards frame by frame.
    6. &#xA;

    7. When a frame match is found, cut off all the frames before this matched frame.
    8. &#xA;

    9. Reverse back the video
    10. &#xA;

    &#xA;

    Can I achieve something like this in ffmpeg, preferably a one-liner in windows cmd ?

    &#xA;

    Follow-up question : Would it be better to leave the last frame the same as first frame or should I remove it ? For example, when it's looping, it would repeat that exact frame two times, is that good ? Or which one provides better results ? And if it's better to not include the last frame (the one that matches), how would I do it in my process above ?

    &#xA;

    I tried ChatGPT, expecting a ready-made code. Put it in the command prompt and lost my original video file. Had to use a recovery tool because the file was overwritten.

    &#xA;

  • ffmpeg adts streaming with ezstream for icecast

    18 avril 2015, par Roberto Arosemena

    I’m trying to use ezstream to stream to an icecast server, my problem is while encoding the audio, I decode it from mp3 with madplay and I’m trying to encode it with ffmpeg so the output is aac, someone told me to use adts to be able to stream aac the problem is that the encoding doesn’t stream the audio, it shows the timer on the console but it goes from 0:00:00 to 0:00:40 to 0:01:30, etc until the song ends instead of going second by second, this is my config :

    <ezstream>
      <url>http://localhost:8100/t</url>
      <sourcepassword>password</sourcepassword>
      <format>MP3</format>
      <filename>/home/vybroo/server/audio/play.m3u</filename>
      <reencode>
         <enable>1</enable>
         <encdec>
            <format>MP3</format>
            <match>.mp3</match>
            <decode>madplay -b 16 -R 44100 -S -o raw:- @T@</decode>
            <encode>ffmpeg -f s16le -ar 44.1k -ac 2 -i - -b:a 32k -ar 44.1k -f adts -</encode>
         </encdec>
      </reencode>
    </ezstream>

    is the enconding config wrong ?, what should i change so it streams second by second correctly