Recherche avancée

Médias (0)

Mot : - Tags -/optimisation

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

Autres articles (49)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • List of compatible distributions

    26 avril 2011, par

    The table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
    If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

Sur d’autres sites (6561)

  • ffmpeg slower than downloading

    7 août 2017, par Krylic

    When trying to get a clip of a video from a remote source
    Input source :

    ffprobe version 3.3.2-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2007-2017 the FFmpeg developers
    Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'http://website.com/video.mp4':
     Metadata:
       major_brand     : mp42
       minor_version   : 0
       compatible_brands: mp42mp41
       creation_time   : 2017-07-13T15:44:58.000000Z
     Duration: 00:57:32.42, start: 0.000000, bitrate: 1939 kb/s
       Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 720x480 [SAR 10:11 DAR 15:11], 1745 kb/s, 29.97 fps, 29.97 tbr, 29970 tbn, 59.94 tbc (default)
       Metadata:
         creation_time   : 2017-07-13T15:44:58.000000Z
         handler_name    : Mainconcept MP4 Video Media Handler
         encoder         : AVC Coding
       Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s (default)
       Metadata:
         creation_time   : 2017-07-13T15:44:58.000000Z
         handler_name    : Mainconcept MP4 Sound Media Handler

    Current command :
    ffmpeg version 3.3.2-static
    ffmpeg.linux -threads 2 -y -ss 3273 -i "http://website.com/video.mp4" -an -movflags +faststart -preset veryfast -codec copy /outputfolder/trimmed_video.mp4
    This 5m35.102s to create a 45mb 2min file.

    If I download the file using wget it takes 28s and using ffmpeg only takes 0.243s

    If I add -vn OR -an to the output portion of the command it completes the trim in about 2.101s. Meaning it’s faster to download the two stream and merge them myself.

    Can anyone explain this behaviour and why my first command takes so long when on a lot of other video files it’s very fast ?

  • Why are Cb and Cr planes displaced differently from lum by the displace complex filter in ffmpeg ?

    10 janvier 2024, 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 :

    



    enter image description here

    



    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.

    


  • Merge remote-tracking branch ’rbultje/vp9-32bit-lpf’

    27 décembre 2014, par Michael Niedermayer
    Merge remote-tracking branch ’rbultje/vp9-32bit-lpf’
    

    * rbultje/vp9-32bit-lpf :
    vp9/x86 : add myself to copyright holders for loopfilter assembly.
    vp9/x86 : make filter_16_h work on 32-bit.
    vp9/x86 : make filter_48/84/88_h work on 32-bit.
    vp9/x86 : make filter_44_h work on 32-bit.
    vp9/x86 : make filter_16_v work on 32-bit.
    vp9/x86 : make filter_48/84_v work on 32-bit.
    vp9/x86 : make filter_88_v work on 32-bit.
    vp9/x86 : make filter_44_v work on 32-bit.
    vp8/x86 : save one register in SIGN_ADD/SUB.
    vp9/x86 : store unpacked intermediates for filter6/14 on stack.
    vp8/x86 : move variable assigned inside macro branch.
    vp9/x86 : simplify ABSSUM_CMP by inverting the comparison meaning.
    vp8/x86 : remove unused register from ABSSUB_CMP macro.
    vp9/x86 : slightly simplify 44/48/84/88 h stores.
    vp9/x86 : make cglobal statement more conservative in register allocation.
    vp9/x86 : save one register in loopfilter surface coverage.

    Merged-by : Michael Niedermayer <michaelni@gmx.at>

    • [DH] libavcodec/x86/vp9dsp_init.c
    • [DH] libavcodec/x86/vp9lpf.asm