
Recherche avancée
Médias (91)
-
Les Miserables
9 décembre 2019, par
Mis à jour : Décembre 2019
Langue : français
Type : Textuel
-
VideoHandle
8 novembre 2019, par
Mis à jour : Novembre 2019
Langue : français
Type : Video
-
Somos millones 1
21 juillet 2014, par
Mis à jour : Juin 2015
Langue : français
Type : Video
-
Un test - mauritanie
3 avril 2014, par
Mis à jour : Avril 2014
Langue : français
Type : Textuel
-
Pourquoi Obama lit il mes mails ?
4 février 2014, par
Mis à jour : Février 2014
Langue : français
-
IMG 0222
6 octobre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Image
Autres articles (89)
-
Des sites réalisés avec MediaSPIP
2 mai 2011, parCette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page. -
MediaSPIP Player : problèmes potentiels
22 février 2011, parLe lecteur ne fonctionne pas sur Internet Explorer
Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...) -
Participer à sa documentation
10 avril 2011La documentation est un des travaux les plus importants et les plus contraignants lors de la réalisation d’un outil technique.
Tout apport extérieur à ce sujet est primordial : la critique de l’existant ; la participation à la rédaction d’articles orientés : utilisateur (administrateur de MediaSPIP ou simplement producteur de contenu) ; développeur ; la création de screencasts d’explication ; la traduction de la documentation dans une nouvelle langue ;
Pour ce faire, vous pouvez vous inscrire sur (...)
Sur d’autres sites (12200)
-
FFMPEG command line not using GPU when compressing MP4 file
13 avril 2022, par StealthRTHey all I have been working on a good command line string to use for my movies that I would like to trim the size down to at least half the current size.


My handbrake information regaurding my GPU and computer system is this :


HandBrake 1.5.1 (2022011000)
OS: Microsoft Windows NT 10.0.19043.0
CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz (12 Cores, 24 Threads)
Ram: 40940 MB, 
GPU Information:
 Microsoft Remote Display Adapter - 10.0.19041.662
 NVIDIA Tesla K10 - 30.0.14.7141
 NVIDIA Tesla K10 - 30.0.14.7141
 Microsoft Basic Display Adapter - 10.0.19041.868



When I originally made a command line, I was just using it to copy the file over to where it needed to go with the following :




ffmpeg -y -hide_banner -threads 8 -hwaccel cuda -hwaccel_device 1
-hwaccel_output_format cuda -v verbose -i "c :\testingvids\AEON FLUX 2005.mp4" -c:v h264_cuvid -gpu:v 1 -preset slow -c copy "c :\testingvids\AEON FLUX 2005 nvidia.mp4"




This produced a 828x processing speed :




But for taking that same file and compressing it I seem to only get a 8x speed ?




So that is quite a difference there. Am I using the correct syntax for it to only use my GPU to convert/compress the mp4 with the h264 nvenc ?


-
FFMPEG mosaic/side-by-side-compositing from simultaneous DirectShow input devices
9 juin 2013, par timlukinsThis is what I'm trying to do :
ffmpeg.exe -y \
-f dshow -i video="Microsoft LifeCam Cinema" \
-f dshow -i video="Microsoft LifeCam VX-2000" \
-filter_complex "[0:v]pad=iw*2:ih:0[left];[left][1:v]overlay=W/2.0[fileout]" \
-map "[fileout]" -vcodec libx264 -f flv out.flvBasically, I have 2 webcams and I would like to combine them into a single video file in which the frames are 2x1 in size with the frame from one camera in the left and the other on the right.
In other words, what might be termed "mosaic-ing" or "side-by-side compositing". This is not concatenation - i.e. one file after the other (so not using the concat filter).
I've gleamed that this use of
-filter_complex
to pad and then position the frames appears the prescribed way. Indeed, when I test this with files like so :ffmpeg.exe -y -i test1.flv -i test2.flv -filter_complex "[0:v]pad=iw*2:ih:0[left];[left][1:v]overlay=W/2.0[fileout]" -map "[fileout]" -vcodec libx264 -f flv testout.flv
It works fine !
With the "live" version however, both cameras seem to start (their lights come on) but the capture stalls.
(Suspiciously like there is some DirectShow deadlock on the separate input device threads...)
And so, I wonder is there some way to overcome this and force the two input stream's data to merge ?
I have also tried the extended format of the dshow filter option like so as well :
-f dshow -i video="Microsoft LifeCam Cinema":video="Microsoft LifeCam VX-2000"
But only one camera is then selected (I suspect this option is really only to enable separate video and audio streams to be combined).
I've also tried explicitly setting each input device to have the exact same frame size and rate with
-f dshow -video_size 640x480 -framerate 30
. No joy though. It still stalls once the camera is listed.Here is the tail end of the output (with
-v debug
on) :Finished splitting the commandline.
Parsing a group of options: global .
Applying option y (overwrite output files) with argument 1.
Applying option v (set libav* logging level) with argument debug.
Applying option filter_complex (create a complex filtergraph) with argument [0:v]pad=iw*2:ih:0[left];[left][1:v]overlay=W/2.0[fileout].
Successfully parsed a group of options.
Parsing a group of options: input file video=Microsoft LifeCam Cinema.
Applying option f (force format) with argument dshow.
Successfully parsed a group of options.
Opening an input file: video=Microsoft LifeCam Cinema.
[dshow @ 00000000016e79a0] All info found
[dshow @ 00000000016e79a0] Estimating duration from bitrate, this may be inaccurate
Input #0, dshow, from 'video=Microsoft LifeCam Cinema':
Duration: N/A, start: 1130406.072000, bitrate: N/A
Stream #0:0, 1, 1/10000000: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 640x480, 333333/10000000, 30 tbr, 10000k tbn, 30 tbc
Successfully opened the file.
Parsing a group of options: input file video=Microsoft LifeCam VX-2000.
Applying option f (force format) with argument dshow.
Successfully parsed a group of options.
Opening an input file: video=Microsoft LifeCam VX-2000.
[dshow @ 00000000016e79a0] real-time buffer 101% full! frame dropped!EDIT Further details trying to fix within the code...*
I've always understood from past Windows DirectShow work that multiple calls to CoInitialize() on the same thread is bad. See here. Perhaps I've misunderstood how FFMPEG is multi-threaded (i.e. if each input device is on it's own thread) but I thought to just try regulating the call with a guard variable (a
static int com_init = 0;
- this should probably be mutex-ed...).e.g. in libavdevice/dshow.c method
dshow_read_header
889 if (com_init==0)
890 CoInitialize(0);
891 com_init++And similar for dshow_read_close
170 com_init--;
171 if (com_init==0)
172 CoUninitialize()Sadly, this doesn't work. The first camera starts but the second doesn't and the error is :
[dshow @ 0000000000301760] Could not set video options
video=Microsoft LifeCam VX-2000: Input/output error(Worth a shot. Looks like each input device is indeed on the same thread...)
-
Announcing Long Term Support in Piwik 2 – The analytics platform for your mission critical projects
11 janvier 2016, par Matthieu Aubry — About, DevelopmentWe are proud to announce our Long Term Support (LTS) for Piwik 2.X !
Why Long Term Support (LTS) ?
Part of our mission is to ready Piwik for the enterprise — and ready the enterprise for Piwik. Our fast release cycle and our ability to quickly innovate has served us well for the past seven years and has lead Piwik to being one of the most popular open source projects, used by over one million websites worldwide. But Piwik’s success today has also shown us that this fast release cycle is not suited for all users and customers. Like most large open source projects (such as Ubuntu, Firefox, Debian, Symfony, Node.js, etc.) at Piwik we now also offer a Long Term Support release which gives users the confidence that Piwik can be used for mission critical projects for months to come.
What does LTS mean for Piwik ?
For the duration of the LTS period, Piwik 2.X will continue to receive the following fixes :
- Critical bugs causing data loss or data corruption.
- Major and Critical security issues.
Our goal is to offer you a Piwik LTS release that you can trust for all your mission critical projects.
How long will Piwik 2.X be supported ?
Piwik 2.X will be supported for at least 12 months after the initial release of Piwik 3.0.0.
Piwik 3.0.0 is expected to be released in the second half of 2016.
This means that Piwik 2.X will be supported at least until the second half of 2017.Which Piwik version is LTS ?
The latest Piwik 2.16.X release is our Long Term Support version.
How do I benefit from the LTS version ?
To get the full benefits of Piwik LTS, please make sure you are using the latest LTS version. First, update to the latest Piwik 2.X version, then Configure Piwik to use the LTS release channel and then update to the latest LTS version.
How do I configure Piwik to use the LTS version ?
By default, Piwik will not use the LTS version. When you use the one-click update your Piwik instance will be updated to the very latest release : when Piwik 3.0.0 will be released, the one click update will update your instance to 3.0.0. It is however possible to configure your Piwik so that you will stay on Piwik 2.X and keep using the LTS Long Term Support version :
- Login Piwik as the Super User,
- Go to Settings > General > Update settings,
- Under “Release channel” click “Latest stable 2.X Long Term Support version”, and click “Save”.
How do I get professional Piwik Support ?
If you need professional support for your Piwik service get in touch with the Piwik PRO experts.
For other questions, feedback or discussion, feel free to join our forums and comment on this LTS forum post.
We wish you all a fantastic year 2016 !