Recherche avancée

Médias (1)

Mot : - Tags -/bug

Autres articles (43)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

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

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

Sur d’autres sites (8483)

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

    


  • MAC's "say" command to MP3 [closed]

    13 mars 2015, par lx0741

    I want to read a very long text with the SAY mac’s command (say -f file.txt), and to record the output to file.mp3. I thought about using ffmpeg to record all of it, but then i’ll need to wait for all the reading process to complete..

    I don’t really need to listen to it, so if there is a way to directly have an mp3 file just by hitting enter, it would be great..

    There is also this project txt2mp3mac but i can’t use it in a shell script..

    Thanks..

    Update

    Check this gist for a script that does it

Navigation