
Recherche avancée
Autres articles (20)
-
Déploiements possibles
31 janvier 2010, parDeux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
Version mono serveur
La version mono serveur consiste à n’utiliser qu’une (...) -
Encoding and processing into web-friendly formats
13 avril 2011, parMediaSPIP automatically converts uploaded files to internet-compatible formats.
Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
All uploaded files are stored online in their original format, so you can (...) -
Les tâches Cron régulières de la ferme
1er décembre 2010, parLa gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
Le super Cron (gestion_mutu_super_cron)
Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)
Sur d’autres sites (5237)
-
how can I get the compression progress percentange using arthenica.ffmpegkit ?
28 février 2023, par user44551I have an app in Kotlin to compress a video using arthenica.ffmpegkit. I searched in the documentation but it's not clear to me how to get the compression progress in percentage or even if it's possible.


-
how to capture continuous Realtime progress stream of output (from ffmpeg)
6 décembre 2022, par user206904I am having trouble showing the progress of ffmpeg through my script. I compile my script to exe with ps2exe and ffmpeg output on standard error instead of outputting on standard out
So I used to pipe 1 option


my script.ps1 now is :


# $nb_of_frames= #some_int
& $ffmpeg_path -progress pipe:1 -i input.mp4 -c:v libx264 -pix_fmt yuv420p -crf 25 -preset fast -an output.mp4



then I compile it with ps2exe. (to reproduce you don't need the compile, just use the above command with pipe:1 directly in cmd or PowerShell you will get the same behavior)


Normally with ffmpeg you get a progress reporting (that is interactive), one line containing the information and it keeps getting updated as 1 single line without spamming the console with 100s of lines, it looks like this.


frame= 7468 fps=115 q=22.0 size= 40704kB time=00:05:10.91 bitrate=1072.5kbits/s speed= 4.8x



But this does not appear in the compiled version of my script, so after digging I added
-progress pipe:1
to get the progress to appear on std out

Now I get a continuous output every second that looks like this :


frame=778
fps=310.36
stream_0_0_q=16.0
bitrate= 855.4kbits/s
total_size=3407872
progress=continue
...
frame=1092
fps=311.04
stream_0_0_q=19.0
bitrate= 699.5kbits/s
total_size=3932160
progress=continue 



I would like to print some sort of updatable percentage out of this, I can compute a percentage easily if I can capture that frame number, but in this case, I don't know how to capture a real-time output like this and how to make my progress reporting update 1 single line of percentage in real-time (or some progress bar via symbols) instead of spamming on many lines


(or if there is a way to make the default progress of FFmpeg appear in the compiled version of my script that would work too)


edit : a suggestion based on the below answer


#use the following lines instead of write-progress if using with ps2exe
 #$a=($frame * 100 / $maxFrames)
 #$str = "#"*$a
 #$str2 = "-"*(100-$a)
 #Write-Host -NoNewLine "`r$a% complete | $str $str2|"




Thanks


-
pthread_frame : use better memory orders for frame progress
9 décembre 2016, par Wan-Teh Changpthread_frame : use better memory orders for frame progress
This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn’t need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().Signed-off-by : Wan-Teh Chang <wtc@google.com>
Signed-off-by : Anton Khirnov <anton@khirnov.net>