
Recherche avancée
Médias (1)
-
Richard Stallman et le logiciel libre
19 octobre 2011, par
Mis à jour : Mai 2013
Langue : français
Type : Texte
Autres articles (55)
-
Librairies et logiciels spécifiques aux médias
10 décembre 2010, parPour un fonctionnement correct et optimal, plusieurs choses sont à prendre en considération.
Il est important, après avoir installé apache2, mysql et php5, d’installer d’autres logiciels nécessaires dont les installations sont décrites dans les liens afférants. Un ensemble de librairies multimedias (x264, libtheora, libvpx) utilisées pour l’encodage et le décodage des vidéos et sons afin de supporter le plus grand nombre de fichiers possibles. Cf. : ce tutoriel ; FFMpeg avec le maximum de décodeurs et (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
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 (...)
Sur d’autres sites (9767)
-
MP3 (MPEG I) chunk decoder for Python
3 juillet 2022, par ClementI've been searching for a few days and trying many different libraries including PyDub, python_mp3_decoder (segmentation faults), pymad, but have had basically no luck in finding a library for Python that would allow me to decode a MP3 Stream (from a internet radio ; icecast) on the fly and treat it like microphone input (e.g. PyAudio stream).



I am trying to get a stream of decoded audio to use with PyAudio for an acoustic fingerprinting project. The other catch is I cannot use PyMedia which has been suggest here on stackoverflow before since it is not supported on the Mac, nor has it been updated in more than 12 years.



Any input on how I could decode a MP3 Stream in real time in python would be much appreciated ! Thanks !


-
Add lensfun filter
13 juillet 2018, par Stephen SeoAdd lensfun filter
Lensfun is a library that applies lens correction to an image using a
database of cameras/lenses (you provide the camera and lens models, and
it uses the corresponding database entry's parameters to apply lens
correction). It is licensed under LGPL3.The lensfun filter utilizes the lensfun library to apply lens
correction to videos as well as images.This filter was created out of necessity since I wanted to apply lens
correction to a video and the lenscorrection filter did not work for me.While this filter requires little info from the user to apply lens
correction, the flaw is that lensfun is intended to be used on indvidual
images. When used on a video, the parameters such as focal length is
constant, so lens correction may fail on videos where the camera's focal
length changes (zooming in or out via zoom lens). To use this filter
correctly on videos where such parameters change, timeline editing may
be used since this filter supports it.Note that valgrind shows a small memory leak which is not from this
filter but from the lensfun library (memory is allocated when loading
the lensfun database but it somehow isn't deallocated even during
cleanup ; it is briefly created in the init function of the filter, and
destroyed before the init function returns). This may have been fixed by
the latest commit in the lensfun repository ; the current latest release
of lensfun is almost 3 years ago.Bi-Linear interpolation is used by default as lanczos interpolation
shows more artifacts in the corrected image in my tests.The lanczos interpolation is derived from lenstool's implementation of
lanczos interpolation. Lenstool is an app within the lensfun repository
which is licensed under GPL3.v2 of this patch fixes license notice in libavfilter/vf_lensfun.c
v3 of this patch fixes code style and dependency to gplv3 (thanks to
Paul B Mahol for pointing out the mentioned issues).v4 of this patch fixes more code style issues that were missed in
v3.v5 of this patch adds line breaks to some of the documentation in
doc/filters.texi (thanks to Gyan Doshi for pointing out the issue).v6 of this patch fixes more problems (thanks to Moritz Barsnick for
pointing them out).v7 of this patch fixes use of sqrt() (changed to sqrtf() ; thanks to
Moritz Barsnick for pointing this out). Also should be rebased off of
latest master branch commits at this point.Signed-off-by : Stephen Seo <seo.disparate@gmail.com>
-
Handling high volume traffic and traffic peaks with Matomo just got easier
16 avril 2018, par Matomo Core TeamWhen you use the self-hosted version of Matomo on-premise instead of the Matomo cloud-hosted solution, you may experience some traffic peaks on your Matomo server when the traffic volume on your websites increases. For example, every day at a certain time you might receive two or three times the amount of traffic that usually visits your website. This can have many negative impacts, including :
- Slow loading time for your JavaScript tracker (piwik.js) which in turn may slow down your website giving your users a poor experience. Also you may see less page views in Matomo because by the time the tracker is loaded on your website, the user has already moved on to another page.
- Some tracking requests might be simply ignored at some point because your server might not be able to handle any tracking requests anymore which results in many untracked visits and page views.
- You may need additional servers only to handle traffic peaks which results in increased server costs, maintenance work and maintenance costs.
The solution
Handling traffic peaks has been possible with Matomo for years using the Queued Tracking plugin. When this feature is enabled, tracking requests are put into a queue instead of being processed immediately. Then when a job is running separately it takes the requests out of the queue and processes them. This brings various benefits.
Faster tracking
It improves the tracking speed on your server by a factor of 5 to 15. So for example, instead of a tracking request taking 50ms, it takes only 5ms. This means your server will be able to handle a lot more concurrent requests compared to the traditional tracking and is likely to survive traffics peaks much more likely without any trouble at all.
Faster processing
When a request is queued, the request still needs to be processed eventually. Because the Queued Tracking solution can take multiple tracking requests out of the queue at once and process them in one go, the processing speed increases massively as well. This is because by default each tracking request has to bootstrap Matomo and do a lot of things again and again which takes quite a bit of time (you’d be surprised). Instead, many things can now be cached and don’t have to be done multiple times. As a result, your server can process tracking requests much faster and needs less resources overall which in turn reduces cost and trouble.
Queued Tracking is now easier to set up
In the background, Queued Tracking has been using Redis, an in-memory database. While Redis is very fast, it’s not simple to setup and maintain it. Especially when it comes to making Redis “highly available” and when you need to scale your Redis. Also, your servers will need a lot more memory for Redis as all queued tracking requests are stored in memory.
One click setup
We have now added support for a MySQL database so you can activate Queued Tracking with a simple click. What used to take hours or maybe even weeks to set up and a lot of maintenance, can now be cut down to seconds. Queued Tracking will then simply reuse the database that you have been using all along for storing all your visits. A side benefit is that your server won’t need more memory and all queued tracking requests even survive a server reboot.
Both Redis and MySQL are now supported in Queued Tracking. If you do have experience with managing Redis, we still recommend using this solution as it’s likely a bit faster. However, in most cases the MySQL solution should work just as well.
Further improvements
We have made various other improvements for Queued Tracking that increases the performance and you can now be notified when the number of queued tracking requests reaches a certain threshold. View the changelog for a list of all changes.
Learn more
We have been setting up Queued Tracking multiple times when it comes to high volume traffic or dealing with peaks and are amazed by the results. Often, we can even reduce the overall amount of needed servers.
If this sounds like something that could be beneficial to you, we recommend you have a look at the Queued Tracking page and also check out the FAQ. You might be also interested in learning how to configure Matomo for speed.
Need help with setting up, maintaining, or scaling Matomo ? Get in touch now.
The post Handling high volume traffic and traffic peaks with Matomo just got easier appeared first on Analytics Platform - Matomo.