
Recherche avancée
Autres articles (97)
-
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 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 (...) -
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 (...)
-
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 (10316)
-
ffmpeg : how to reduce CPU and bandwidth usage when grabbing still frames from live video stream ?
3 septembre 2017, par Ryan GriggsI am using ffmpeg to grab still images from live camera feeds (rtsp ://192.168.1.88:554/11). The input feeds are 1920x1080 h.264 video.
We may need to grab frames from as many as 10-15 cameras simultaneously.
All cameras are on the local network (100Mbit Ethernet).
I am executing ffmpeg with options to grab one frame every 10 seconds, or 1/10 FPS, and convert to 640x360 JPG output, written to a file in a temporary directory.
I notice that when a single instance of ffmpeg is running, the system’s bandwidth usage increases to over 100kbps. So I’m assuming ffmpeg is streaming the video live all the time, instead of reconnecting to the stream every 10 seconds to grab a new image.
Is there any way to prevent this, and possibly force ffmpeg to only request data when it needs a new grab ? I realize it would have to start/stop the stream and listen for keyframes etc to ensure a valid still frame is captured, but I’m wondering if this is possible and/or worth it.
Also, the CPU usage goes to about 12-15% for a single ffmpeg process (running on a Raspberry Pi 3). I’m concerned that 1) the PI will overheat if more ffmpeg processes are added, and 2) this amount of CPU usage per camera feed will limit the number of simultaneous feeds being captured to a less-than-optimal number.
TL ;DR
What are your suggestions for the most CPU- and bandwidth-optimized ffmpeg video-to-JPG conversion at a 1/10fps (or possibly 1/5fps) rate ? -
How to use Visual Studio Compiled libs with MSYS pkg-config
18 août 2017, par maxhapFirst a bit of background.
I’m trying to compile ffmpeg on windows with the libass extensions/configuration option.
Using the visual studio project libass-msvc I built libass using Visual Studio as a static lib.
I then installed MinGW with MSYS and pkg-config. Following the instructions on the ffmpeg MSVC installation guide I configured the environment to build with the MSVC linker and to build in x64.
When I try to configure libass for compilation using ./configure —enable-libass —toolchain=msvc I get the following error in the log file :
File not found ass/ass.h
pkg-config can not find libassI have tried the following to fix this.
-
Create a .pc file for libass and add this to the PKG_CONFIG_PATH environment variable. See file content below. (After doing this pkg-config libass —version prints 0.81, not the right version number but at least something.)
-
Copy libass .h files into a MinGW/include/ass folder and the .lib file into the MinGW/libs folder.
-
Add libass include and bin folders to PATH environment variable
-
Download libass and dependencies source then try to build it using MSYS with MSVC compiler. My aim here was to be able to use "make install" and let MinGW install libass to the correct locations. After hours of trying to fix linker errors, I abandoned this idea as some of the libass dependencies make files only work with the GCC GNU compiler.
-
Compile libass with GCC GNU using MinGW make/make install then try and install libass using the GNU libs. Again this led to linker errors (I know this was a bad idea but was worth a try).
-
Tried using extra lib and include build configuration options —extra-cflags="ffmpeg-dir/extra/include" \
— extra-ldflags="ffmped-dir/extra/ffmpeg_build/lib" then adding the libs and .h files into those locations
.pc file
libass.pc:
prefix=/MinGW
includedir=libass-directory/include
libdir=libass-director/x64/bin/
Name: libass
Description: Libass project
Version: 0.13.7I am now completely stuck and out of ideas if anyone could give any insight or suggestions into what I’m doing wrong that would be fantastic.
Thanks in advanced !
-
-
ffmpeg removing silence makes mp3 longer ?
13 août 2017, par pocketg99I’ve been using the following command to attempt to remove silent segments from an mp3 file
ffmpeg -i "podcasts/audio1.mp3" -af silenceremove=1:0:-50dB "/tmp/pod-sil.mp3"
For some reason the resulting mp3 is twice as log as the input mp3. It is not half as fast. There does not appear to be any duplicated audio. There is some silence, but not an hour’s worth. For a given portion of the input file, you can find the same thing in the output file by going to twice the timestamp of the input file.
The files are long so I have not yet listened to them all the way through. I really have no idea where the extra length is coming from, the files seem normal.
Here is the full output from ffmpeg
ffmpeg version 2.8.11-0ubuntu0.16.04.1 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
configuration: --prefix=/usr --extra-version=0ubuntu0.16.04.1 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
[mp3 @ 0x21880e0] Skipping 0 bytes of junk at 0.
[mp3 @ 0x21880e0] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'podcasts/audio1.mp3':
Duration: 01:00:00.20, start: 0.000000, bitrate: 320 kb/s
Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s
File '/tmp/pod-sil.mp3' already exists. Overwrite ? [y/N] y
Output #0, mp3, to '/tmp/pod-sil.mp3':
Metadata:
TSSE : Lavf56.40.101
Stream #0:0: Audio: mp3 (libmp3lame), 44100 Hz, stereo, fltp
Metadata:
encoder : Lavc56.60.100 libmp3lame
Stream mapping:
Stream #0:0 -> #0:0 (mp3 (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
[libmp3lame @ 0x21999e0] Trying to remove 1152 samples, but the queue is empty
size= 56253kB time=01:00:00.16 bitrate= 128.0kbits/s
video:0kB audio:56253kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000439%