Recherche avancée

Médias (91)

Autres articles (100)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, 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 (...)

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

Sur d’autres sites (12821)

  • FFMPEG X264 reduce bitrate for unchanging input

    8 juin 2021, par GroovyDotCom
    ffmpeg -f lavfi -i smptebars=duration=1000:size=640x360:rate=30 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 -f mpegts video.ts


    


    As can be seen when running this command, the encode size continues to grow rapidly even though :

    


      

    1. The input source never changes. It is exactly the same image again and again.

      2. 


    2. The encoder has been told to insert a keyframe only once every 1000 frames

      3. 


    


    Is there some configuration option I could add to change this behaviour ? I can understand it would need to send an empty P frame but right now it seems to be sending much much more ?

    


    UPDATE
After Tim Roberts comment, I realized we can get a clearer picture of the file growth if I change the command to 1 FPS and do the encode in real-time.

    


    ffmpeg -f lavfi -re -i smptebars=duration=1000:size=640x360:rate=1 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 out.ts

    


    Now I see that it is going up almost exactly 1KB per frame. That seems like a lot for a P-frame that does nothing.

    


    So, just for kicks, I got rid of the TS muxing.

    


    ffmpeg -f lavfi -re -i smptebars=duration=1000:size=640x360:rate=1 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 out.h264

    


    Now the file grows by 1k every 17 frames - a 17X improvement !

    


    This seems to point to ffmpeg doing something weird in the TS muxer that inflates an 80 byte P-frame into 1K.

    


  • FFMPEG X264 reduce bitrate for unchanging input

    8 juin 2021, par GroovyDotCom
    ffmpeg -f lavfi -i smptebars=duration=1000:size=640x360:rate=30 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 -f mpegts video.ts


    


    As can be seen when running this command, the encode size continues to grow rapidly even though :

    


      

    1. The input source never changes. It is exactly the same image again and again.

      2. 


    2. The encoder has been told to insert a keyframe only once every 1000 frames

      3. 


    


    Is there some configuration option I could add to change this behaviour ? I can understand it would need to send an empty P frame but right now it seems to be sending much much more ?

    


    UPDATE
After Tim Roberts comment, I realized we can get a clearer picture of the file growth if I change the command to 1 FPS and do the encode in real-time.

    


    ffmpeg -f lavfi -re -i smptebars=duration=1000:size=640x360:rate=1 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 out.ts

    


    Now I see that it is going up almost exactly 1KB per frame. That seems like a lot for a P-frame that does nothing.

    


    So, just for kicks, I got rid of the TS muxing.

    


    ffmpeg -f lavfi -re -i smptebars=duration=1000:size=640x360:rate=1 -preset ultrafast -vcodec libx264 -tune zerolatency -b 900k -g 1000 out.h264

    


    Now the file grows by 1k every 17 frames - a 17X improvement !

    


    This seems to point to ffmpeg doing something weird in the TS muxer that inflates an 80 byte P-frame into 1K.

    


  • fate : update checksums for fate-lavf-ffm and fate-lavf-mxf

    24 juin 2017, par James Almer
    fate : update checksums for fate-lavf-ffm and fate-lavf-mxf

    <@jamrial> durandal_1707 : 04aa09c4bc broke fate-lavf-ffm and fate-lavf-mxf
    
<@durandal_1707> how so ?
    
<@jamrial> one byte changes
    
<@durandal_1707> jamrial : just update checksums
    
<@jamrial> durandal_1707 : but why did they change at all ? the commit you reverted didn't affect them
    
<@jamrial> why does reverting it affect these tests ?
    
<@jamrial> i don't think updating the checksum without knowing what changed is a good idea
    
<@durandal_1707> jamrial : the lavfi core is in weird state after removal of recursive code
    
<@durandal_1707> jamrial : the change is that older ones would get progressive flag set and new one doesnt
    
<@jamrial> alright
    • [DH] tests/ref/lavf/ffm
    • [DH] tests/ref/lavf/mxf

Navigation