
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (71)
-
Use, discuss, criticize
13 avril 2011, parTalk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
A discussion list is available for all exchanges between users. -
MediaSPIP Player : les contrôles
26 mai 2010, parLes contrôles à la souris du lecteur
En plus des actions au click sur les boutons visibles de l’interface du lecteur, il est également possible d’effectuer d’autres actions grâce à la souris : Click : en cliquant sur la vidéo ou sur le logo du son, celui ci se mettra en lecture ou en pause en fonction de son état actuel ; Molette (roulement) : en plaçant la souris sur l’espace utilisé par le média (hover), la molette de la souris n’exerce plus l’effet habituel de scroll de la page, mais diminue ou (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Pour avoir une installation fonctionnelle, 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 (...)
Sur d’autres sites (10054)
-
lavc/opusdsp : simplify R-V V postfilter
16 décembre 2023, par Rémi Denis-Courmontlavc/opusdsp : simplify R-V V postfilter
This skips the round-trip to scalar register for the sliding 'x'
coefficients, improving performance by about 5%. The trick here is that
the vector slide-up instruction preserves elements in destination vector
until the slide offset.The switch from vfslide1up.vf to vslideup.vi also allows the elimination
of data dependencies on consecutive slides. Since the specifications
recommend sticking to power of two offsets, we could slide as follows :vslideup.vi v8, v0, 2
vslideup.vi v4, v0, 1
vslideup.vi v12, v8, 1
vslideup.vi v16, v8, 2However in the device under test, this seems to make performance slightly
worse, so this is left for (in)validation with future better hardware. -
Converting a H.264-Stream with node.js using fluent-ffmpeg
10 novembre 2014, par Andreas LacknerI want to convert a H.264 stream (provided by a foscam via RTSP) into a ogg-stream (via HTTP) using node.js and ffmpeg.
So far I tried it with VLC, wich works fine. But VLC needs too much CPU power.I’ve tried the following :
var ffmpeg = require('fluent-ffmpeg');
var http = require('http');
http.createServer(function (req, res) {
var command = ffmpeg();
command.input('rtsp://user:password@foscam.example.com:88/videoMain');
command.inputFormat('rtsp');
command.videoCodec('libtheora');
command.audioCodec('libvorbis');
command.toFormat('ogg');
console.log('New Request');
res.writeHead('200', {
'Content-Type' : 'video/ogg',
'Connection' : 'keep-alive',
"Accept-Ranges" : "bytes"
});
command.on('error', function(err, stdout, stderr) {
console.log("error:"+err);
console.log('ffmpeg stdout: ' + stdout);
console.log('ffmpeg stderr: ' + stderr);
});
command.output(res);
}).listen(8080, 'localhost');If I try to open the stream with VLC, I don’t get any response.
Does anybody know what’s wrong ? -
Thread count option in FFmpeg for FASTEST conversion to h264 ?
9 février, par S BI need to maximize speed while converting videos using FFmpeg to h264



- 

- Any input format of source videos
- User's machine can have any number of cores
- Power and memory consumption are non-issues









Of course, there are a whole bunch of options that can be tweaked but this question is particularly about choosing the best
-thread <count></count>
option. I am trying to find an ideal thread count as a function of


- 

- no. of cores
- input video format
- h264-friendly values maybe ?
- anything else missed above ?











I am aware the default
-thread 0
follows one-thread-per-core approach which is supposed to be optimal. But I am not sure if this is time or space-optimized. Also, on certain testcases, I've seen more threads (say 4 threads on my dual core test machine) finishes quicker than the default.


Any other direction, say configure options w.r.t. threads, worth pursuing ?