
Recherche avancée
Médias (1)
-
Rennes Emotion Map 2010-11
19 octobre 2011, par
Mis à jour : Juillet 2013
Langue : français
Type : Texte
Autres articles (61)
-
HTML5 audio and video support
13 avril 2011, parMediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
For older browsers the Flowplayer flash fallback is used.
MediaSPIP allows for media playback on major mobile platforms with the above (...) -
Support audio et vidéo HTML5
10 avril 2011MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...) -
List of compatible distributions
26 avril 2011, parThe table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)
Sur d’autres sites (8375)
-
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 ?


-
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 ? -
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.