
Recherche avancée
Autres articles (32)
-
Les tâches Cron régulières de la ferme
1er décembre 2010, parLa gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
Le super Cron (gestion_mutu_super_cron)
Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...) -
XMP PHP
13 mai 2011, parDixit Wikipedia, XMP signifie :
Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...) -
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
Sur d’autres sites (4447)
-
Opera Beta with WebM Available
16 juin 2010, par noreply@blogger.com (John Luther)More exciting browser news. Opera has released a Beta build of their desktop browser with WebM playback support. They’ve even made their own WebM demo (about Norway, of course).
-
The Future of the VP8 Bitstream
18 juin 2010, par noreply@blogger.com (John Luther) — vp8Recently we’ve seen software products such as VLC, FFmpeg, Logitech Vid, Flumotion and Tixeo adopting and using WebM and VP8 (the video codec in WebM) in exciting new ways.
In addition to software developers, many hardware vendors have committed to shipping VP8-accelerated products based on our current bitstream in 2011 . Devices that use hardware acceleration for video are a very small percentage of overall web traffic today, but they are a rapidly growing segment of the market and our project must be mindful of these vendors’ needs. Given the longer lead times for changes in chipsets, hardware companies implementing the codec today need to be confident that it will be stable and supported as VP8 content proliferates.
Like every codec, WebM is not immune to change ; the difference in our project is that the improvements are publicly visible, and compatibility and implementation issues can be worked through in an open forum.
So, to maintain codec stability while also allowing for quality and performance improvements in VP8, we have added an experimental branch to the VP8 source tree. The WebM community can use this unstable branch to propose changes to VP8 that will produce the best video codec possible, but without the constraints of a frozen bitstream. At some point in the future, when the experimental branch proves significantly better than the stable branch, we will create a new version of the codec.
Teams dedicated to improving WebM are actively investigating and evaluating new techniques, and are committed to do so for the long term. We encourage the WebM community to keep contributing as well. To learn more about the experimental branch and get involved, see our repository layout page.
Jim Bankoski is Codec Engineering Manager at Google.
-
Monster Battery Power Revisited
28 mai 2010, par Multimedia Mike — Python, Science ProjectsSo I have this new fat netbook battery and I performed an experiment to determine how long it really lasts. In my last post on the matter, it was suggested that I should rely on the information that gnome-power-manager is giving me. However, I have rarely seen GPM report more than about 2 hours of charge ; even on a full battery, it only reports 3h25m when I profiled it as lasting over 5 hours in my typical use. So I started digging to understand how GPM gets its numbers and determine if, perhaps, it’s not getting accurate data from the system.
I started poking around /proc for the data I wanted. You can learn a lot in /proc as long as you know the right question to ask. I had to remember what the power subsystem is called — ACPI — and this led me to /proc/acpi/battery/BAT0/state which has data such as :
present : yes capacity state : ok charging state : charged present rate : unknown remaining capacity : 100 mAh present voltage : 8326 mV
"Remaining capacity" rated in mAh is a little odd ; I would later determine that this should actually be expressed as a percentage (i.e., 100% charge at the time of this reading). Examining the GPM source code, it seems to determine as a function of the current CPU load (queried via /proc/stat) and the battery state queried via a facility called devicekit. I couldn’t immediately find any source code to the latter but I was able to install a utility called ’devkit-power’. Mostly, it appears to rehash data already found in the above /proc file.
Curiously, the file /proc/acpi/battery/BAT0/info, which displays essential information about the battery, reports the design capacity of my battery as only 4400 mAh which is true for the original battery ; the new monster battery is supposed to be 10400 mAh. I can imagine that all of these data points could be conspiring to under-report my remaining battery life.
Science project : Repeat the previous power-related science project but also parse and track the remaining capacity and present voltage fields from the battery state proc file.
Let’s skip straight to the results (which are consistent with my last set of results in terms of longevity) :
So there is definitely something strange going on with the reporting— the 4400 mAh battery reports discharge at a linear rate while the 10400 mAh battery reports precipitous dropoff after 60%.
Another curious item is that my script broke at first when there was 20% power remaining which, as you can imagine, is a really annoying time to discover such a bug. At that point, the "time to empty" reported by devkit-power jumped from 0 seconds to 20 hours (the first state change observed for that field).
Here’s my script, this time elevated from Bash script to Python. It requires xdotool and devkit-power to be installed (both should be available in the package manager for a distro).
PYTHON :-
# !/usr/bin/python
-
-
import commands
-
import random
-
import sys
-
import time
-
-
XDOTOOL = "/usr/bin/xdotool"
-
BATTERY_STATE = "/proc/acpi/battery/BAT0/state"
-
DEVKIT_POWER = "/usr/bin/devkit-power -i /org/freedesktop/DeviceKit/Power/devices/battery_BAT0"
-
-
print "count, unixtime, proc_remaining_capacity, proc_present_voltage, devkit_percentage, devkit_voltage"
-
-
count = 0
-
while 1 :
-
commands.getstatusoutput("%s mousemove %d %d" % (XDOTOOL, random.randrange(0,800), random.randrange(0, 480)))
-
battery_state = open(BATTERY_STATE).read().splitlines()
-
for line in battery_state :
-
if line.startswith("remaining capacity :") :
-
proc_remaining_capacity = int(line.lstrip("remaining capacity : ").rstrip("mAh"))
-
elif line.startswith("present voltage :") :
-
proc_present_voltage = int(line.lstrip("present voltage : ").rstrip("mV"))
-
devkit_state = commands.getoutput(DEVKIT_POWER).splitlines()
-
for line in devkit_state :
-
line = line.strip()
-
if line.startswith("percentage :") :
-
devkit_percentage = int(line.lstrip("percentage :").rstrip(’\%’))
-
elif line.startswith("voltage :") :
-
devkit_voltage = float(line.lstrip("voltage :").rstrip(’V’)) * 1000
-
print "%d, %d, %d, %d, %d, %d" % (count, time.time(), proc_remaining_capacity, proc_present_voltage, devkit_percentage, devkit_voltage)
-
sys.stdout.flush()
-
time.sleep(60)
-
count += 1
-