
Recherche avancée
Autres articles (75)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 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 (...) -
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)
Sur d’autres sites (12508)
-
imdct15 : remove the AArch64 assembly
4 janvier 2017, par Rostislav Pehlivanovimdct15 : remove the AArch64 assembly
Prep work for the next commit, which will add a new FFT algorithm
which makes the iMDCT over 3x faster than it is currently (standalone,
the FFT is with some framesizes over 10x faster).The new FFT algorithm uses the already thouroughly SIMD’d power of two
FFT which already has SIMD for AArch64, so users of that platform will
still see an improvement.The previous FFT+SIMD was barely 2.5x faster than the C versions on these
platforms.Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
-
FFMPEG hardware acceleration in Windows Scheduled Task [closed]
25 mars 2022, par cfairerI'm setting up an unattended Windows 10 machine that will stream video from an RTSP nest cam feed using FFMPEG and Apache.
As it will be unattended and will lose power for six hours a day, I have created a Scheduled Task to run at boot without a user logged to run ffmpeg.


It all works fine with conventional encoders for task started automatically or manually by Windows Task Scheduler :
ffmpeg.exe -i rtsp ://user:pw@nestcam:554 -vf scale=1280:720 -vcodec libx264 -g 20 -r 10 -b:v 1120000 -crf 31 -map 0 -map -0:a -acodec aac -sc_threshold 0 -f hls -hls_time 2 -segment_time 2 -hls_flags delete_segments -hls_list_size 20 C :\webpages\video\stream.m3u8


It works fine when I use hardware acceleration too, but only outside Task Scheduler (e.g. a command prompt) :
ffmpeg.exe -init_hw_device qsv=hw -filter_hw_device hw -i rtsp ://user:pw@nestcam:554 -vf hwupload=extra_hw_frames=64,format=qsv -c:v h264_qsv -g 20 -r 10 -b:v 1120000 -crf 31 -map 0 -map -0:a -acodec aac -sc_threshold 0 -f hls -hls_time 2 -segment_time 2 -hls_flags delete_segments -hls_list_size 20 C :\webpages\video\stream.m3u8


The hardware accelerated version fails when executed by Windows Task Scheduler, whether started automatically or manually. The relevant output is as follows :
[AVHWDeviceContext @ 00000184ba5cc800] Failed to create Direct3D device
Device creation failed : -1313558101.
Failed to set value 'qsv=hw' for option 'init_hw_device' : Unknown error occurred
Error parsing global options : Unknown error occurred


Why can't the ffmpeg task started by Task Scheduler see the hardware-accelerated hardware ? Any ideas on how to resolve this ?


The hardware-accelerated version reduces the load on the CPU by about 75% (ie 50% down to 13%), so it's a significant benefit.


Thanks


-
FFMPEG Multiple outputs from BlackMagic input
24 septembre 2018, par leo_dragonsI’m currently needing help to achieve multiple outputs from one input.
Right now, the outputs are set like this :ffmpeg -re -f decklink -i "DeckLink Mini Recorder" -y -pix_fmt yuv420p -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 128k -ar 44100 -async 1 -b:v 2300k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 1280x720 -bufsize 1000k -maxrate 3072k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_720p"
ffmpeg -re -i "rtmp://10.0.0.172:1935/Testing/live_720p" -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 114k -ar 44100 -async 1 -b:v 900k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 854x480 -bufsize 400k -maxrate 1000k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_480p_hq"
ffmpeg -re -i "rtmp://10.0.0.172:1935/Testing/live_720p" -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 114k -ar 44100 -async 1 -b:v 550k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 854x480 -bufsize 400k -maxrate 500k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_480p_lq"
ffmpeg -re -i "rtmp://10.0.0.172:1935/Testing/live_720p" -c:v h264 -preset fast -tune zerolatency -c:a aac -ac 2 -b:a 114k -ar 44100 -async 1 -b:v 450k -g 5 -probesize 32 -framerate 30 -movflags +faststart -s 640x360 -bufsize 400k -maxrate 500k -shortest -f flv "rtmp://10.0.0.172:1935/Testing/live_360p"This uses quite a lot of processing power, and also generates unnecessary latency (since I have to stream to WOWZA first, then back to FFMPEG and then back to WOWZA).
And I want to optimize this.
I’ve been trying several methods, but I only managed to overflow the decklink buffer. How could I solve this ?