
Recherche avancée
Autres articles (94)
-
ANNEXE : Les plugins utilisés spécifiquement pour la ferme
5 mars 2010, parLe site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)
-
Les sons
15 mai 2013, par -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir
Sur d’autres sites (8323)
-
FFMPEG : how to pick a random jpeg file from folder
12 mai 2018, par J. J.I run a batch script in expert mode with the program myffvideoconverter.
My ffmpeg code is : -i example.jpg
I would like to choose a random jpeg file from the folder automatically instead the file "example.jpg"
Is it possible ?
Is it possible to copy the used file into a different folder automatically to make sure that no jpeg will be used two times ? Thank you for your help. -
FFmpeg tee muxer
14 février 2013, par deed02392I'm trying to use the Tee muxer recently introduced to FFmpeg, to both output a stream over UDP and render the output in an SDL window.
This is because I want to measure latency in my live broadcast system between the input to FFmpeg and its output (i.e. the encoding process latency).
Can anyone explain how to use it properly ? This is what I have tried :
ffmpeg -re -i ......\sample_ipod.m4v -f tee "[f=mpegts]udp ://127.0.0.1:1233|[f=sdl]foo"
I understood this should result in an output stream to UDP and that I could specify additional formats by enclosing like [f=sdl] to mean
-f sdl
. Then because the sdl muxer requires an argument (the window title) I provided this in the same way the example gives for the stream.Hope some FFmpeg expert can shed some light on this. I've even scanned the code that adds the Tee muxer to no avail.
-
Do FFMPEG H264 compression presets affect the video quality ? [closed]
14 novembre 2013, par angainorI am definitely not an FFMPEG expert, but according to this document :
A preset is a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression (compression is quality per filesize). General usage is to use the slowest preset that you have patience for. Current presets in descending order of speed are : ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo.
So as I understand it, the
ffmpeg
presets should not affect the quality of the output video, but should only determine the compression ratio / output file size. Consequently, assuming the same quality setting (I will use-crf 24
), the files should be larger for e.g.,faster
preset than for theslower
preset. That would be the only reason to use a slower preset - to get a smaller file size.This turns out not to be the case. I encode a HD stream from a handycam using different presets, everything else is the same :
ffmpeg -y -i "$fname" -vf yadif=1,scale=-1:720 -acodec aac -ab 128k -ac 2 -strict experimental -vcodec libx264 -vpre slow -threads 2 -crf 24 "$outp"
Surprisingly, I get the smallest file size for
veryfast
preset ! For example :slower
: output bitrate 3500kbps, encoding speed 17 fps, file size 29MBveryfast
: output bitrate 3050kbps, encoding speed 34 fps, file size 25MB
Which I think is not as it should be. Now I wonder, is that due to a worse encoding quality for the
veryfast
preset ? Or in my case usingslower
does simply not make sense for some reason ?