Recherche avancée

Médias (91)

Autres articles (47)

  • Librairies et binaires spécifiques au traitement vidéo et sonore

    31 janvier 2010, par

    Les logiciels et librairies suivantes sont utilisées par SPIPmotion d’une manière ou d’une autre.
    Binaires obligatoires FFMpeg : encodeur principal, permet de transcoder presque tous les types de fichiers vidéo et sonores dans les formats lisibles sur Internet. CF ce tutoriel pour son installation ; Oggz-tools : outils d’inspection de fichiers ogg ; Mediainfo : récupération d’informations depuis la plupart des formats vidéos et sonores ;
    Binaires complémentaires et facultatifs flvtool2 : (...)

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

  • checkasm : Remove unnecessary const on scalar parameters

    15 décembre 2023, par Martin Storsjö
    checkasm : Remove unnecessary const on scalar parameters
    

    The ffmpeg coding style doesn't usually use const on scalar
    parameters (or on the pointer values - as opposed to the type
    that is pointed to, where it has a semantic meaning), contrary
    to the dav1d coding style (where this was imported from).

    This avoids warnings about differences in the type signatures
    between declaration and definition of this function, with older
    versions of MSVC.

    The issue was observed with one version of MSVC 2017,
    19.16.27024.1, with warnings like these :

    src/tests/checkasm/checkasm.c(969) : warning C4028 : formal parameter 3 different from declaration

    The warning itself is bogus as the const here is harmless, and
    newer versions of MSVC no longer warn about this.

    Signed-off-by : Martin Storsjö <martin@martin.st>

    • [DH] tests/checkasm/checkasm.c
    • [DH] tests/checkasm/checkasm.h
  • Merge commit '4de220d2e3751c459f8739a08ac6ca52e63eba30'

    28 septembre 2017, par James Almer
    Merge commit '4de220d2e3751c459f8739a08ac6ca52e63eba30'
    

    * commit '4de220d2e3751c459f8739a08ac6ca52e63eba30' :
    frame : allow align=0 (meaning automatic) for av_frame_get_buffer()

    See https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215834.html

    Merged-by : James Almer <jamrial@gmail.com>

    • [DH] doc/APIchanges
    • [DH] libavutil/frame.c
    • [DH] libavutil/frame.h
    • [DH] libavutil/version.h
  • Why are Cb and Cr planes displaced differently from lum by the displace complex filter in ffmpeg ?

    6 mai 2017, par Neb

    I have a video encoded with the yuv420p pixel format and I want to displace its pixels. I’m using ffmpeg and its new displace filter. The filter takes as inputs (the video to be displaced and) two displacement maps respectively for X and Y axis. I decided to create the displacement maps directly into ffmpeg using the nullsrc video source filter and the geq filter to specify the value of the three planes : lum, Cb, Cr. The script is the following :

    ffmpeg INPUT.mp4 -f lavfi -i nullsrc=size=${WIDTH}x${HEIGHT}:d=0.1,geq='lum=128+30*sin(2*PI*X/400):Cb=128+30*sin(2*PI*X/400):Cr='128+30*sin(2*PI*X/400)' -f lavfi -i nullsrc=size=${WIDTH}x${HEIGHT}:d=0.1,geq='lum=128+30*sin(2*PI*X/400):Cb=128+30*sin(2*PI*X/400):Cr=128+30*sin(2*PI*X/400)' -lavfi '[0][1][2]displace' OUTPUT.mp4

    I used the example provided in the documentation of ffmpeg, since the expression used in geq is irrelevant for the purposes of the problem.

    At the and of the computation, I get the pixels of the input video not properly displaced, meaning that I can clearly see a sort of ghost carrying-color-information video under a displaced but b/w one.
    After some tests, I noticed that the displacemnt map created had only the luma plane displaced correctly while the chrominance planes were displaced, but differently from luma, which is the origin of the planes disalignment in the intput video as you can see in the following extract frames :

    Planes separated

    I also noticed that the video describing the Cb and Cr planes of the displacement maps have half resolution of the luma plane.

    My question is : how can i setup correctly the Cr and Cb planes in the geq definition so that they are exactly identical to the luma plane ?

    It would be also great if someone could explain me why ffmpeg gives me an output so much different for luma and Cb, Cr planes even if the function provided is the same.

    If, it can help, i’m using ffmpeg 3.3-static build.

    Thanks for your time.