Recherche avancée

Sur d’autres sites (4790)

• Monster Battery Power Revisited

  28 mai 2010, par Multimedia Mike — Python, Science Projects

  So 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).
  

  PLAIN TEXT

  PYTHON :

  1. # !/usr/bin/python
  2.  
  3. import commands
  4. import random
  5. import sys
  6. import time
  7.  
  8. XDOTOOL = "/usr/bin/xdotool"
  9. BATTERY_STATE = "/proc/acpi/battery/BAT0/state"
  10. DEVKIT_POWER = "/usr/bin/devkit-power -i /org/freedesktop/DeviceKit/Power/devices/battery_BAT0"
  11.  
  12. print "count, unixtime, proc_remaining_capacity, proc_present_voltage, devkit_percentage, devkit_voltage"
  13.  
  14. count = 0
  15. while 1 :
  16.   commands.getstatusoutput("%s mousemove %d %d" % (XDOTOOL, random.randrange(0,800), random.randrange(0, 480)))
  17.   battery_state = open(BATTERY_STATE).read().splitlines()
  18.   for line in battery_state :
  19.     if line.startswith("remaining capacity :") :
  20.       proc_remaining_capacity = int(line.lstrip("remaining capacity : ").rstrip("mAh"))
  21.     elif line.startswith("present voltage :") :
  22.       proc_present_voltage = int(line.lstrip("present voltage : ").rstrip("mV"))
  23.   devkit_state = commands.getoutput(DEVKIT_POWER).splitlines()
  24.   for line in devkit_state :
  25.     line = line.strip()
  26.     if line.startswith("percentage :") :
  27.       devkit_percentage = int(line.lstrip("percentage :").rstrip(’\%’))
  28.     elif line.startswith("voltage :") :
  29.       devkit_voltage = float(line.lstrip("voltage :").rstrip(’V’)) * 1000
  30.   print "%d, %d, %d, %d, %d, %d" % (count, time.time(), proc_remaining_capacity, proc_present_voltage, devkit_percentage, devkit_voltage)
  31.   sys.stdout.flush()
  32.   time.sleep(60)
  33.   count += 1

• a lot of GREEN Color at YUV420p —> RGB in OpenGL 2.0 Shader on iOS

  25 octobre 2012, par 이형근

  I want to make a movie player for iOS using ffmpeg and OpenGL ES 2.0
  but I have some problem. Output RGB image has a lot of GREEN color.
  This is code and images

  • 480x320 width & height :
  • 512x512 Texture width & height

  I got a YUV420p row data from ffmpeg AVFrame.

      for (int i = 0, nDataLen = 0; i < 3; i++) {
  
          int nShift = (i == 0) ? 0 : 1;
  
          uint8_t *pYUVData = (uint8_t *)_frame->data[i];
  
          for (int j = 0; j < (mHeight >> nShift); j++) {
  
              memcpy(&pData->pOutBuffer[nDataLen], pYUVData, (mWidth >> nShift));
  
              pYUVData += _frame->linesize[i];
  
              nDataLen += (mWidth >> nShift);
  
          }
  
      }

  and prepare texture for Y, U & V channel.

  //: U Texture
  
      if (sampler1Texture) glDeleteTextures(1, &sampler1Texture);
  
  
  
      glActiveTexture(GL_TEXTURE1);
  
      glGenTextures(1, &sampler1Texture);
  
      glBindTexture(GL_TEXTURE_2D, sampler1Texture);
  
  
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  
      // This is necessary for non-power-of-two textures
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
  
      glEnable(GL_TEXTURE_2D);
  
  
  
      glTexImage2D(GL_TEXTURE_2D, 
  
                   0, 
  
                   GL_LUMINANCE, 
  
                   texW / 2, 
  
                   texH / 2, 
  
                   0, 
  
                   GL_LUMINANCE, 
  
                   GL_UNSIGNED_BYTE,
  
                   NULL);
  
  
  
      //: V Texture
  
      if (sampler2Texture) glDeleteTextures(1, &sampler2Texture);
  
  
  
      glActiveTexture(GL_TEXTURE2);
  
      glGenTextures(1, &sampler2Texture);
  
      glBindTexture(GL_TEXTURE_2D, sampler2Texture);
  
  
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  
      // This is necessary for non-power-of-two textures
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
  
      glEnable(GL_TEXTURE_2D);
  
  
  
      glTexImage2D(GL_TEXTURE_2D, 
  
                   0, 
  
                   GL_LUMINANCE, 
  
                   texW / 2, 
  
                   texH / 2, 
  
                   0, 
  
                   GL_LUMINANCE,
  
                   GL_UNSIGNED_BYTE,
  
                   NULL);
  
  
  
      //: Y Texture
  
      if (sampler0Texture) glDeleteTextures(1, &sampler0Texture);
  
  
  
      glActiveTexture(GL_TEXTURE0);
  
      glGenTextures(1, &sampler0Texture);
  
      glBindTexture(GL_TEXTURE_2D, sampler0Texture);
  
  
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  
      // This is necessary for non-power-of-two textures
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
  
      glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
  
      glEnable(GL_TEXTURE_2D);
  
  
  
      glTexImage2D(GL_TEXTURE_2D, 
  
                   0, 
  
                   GL_LUMINANCE, 
  
                   texW, 
  
                   texH, 
  
                   0, 
  
                   GL_LUMINANCE,
  
                   GL_UNSIGNED_BYTE, 
  
                   NULL);

  Rendering part is below.

  int _idxU = mFrameW * mFrameH;
  
  int _idxV = _idxU + (_idxU / 4);
  
  
  
  // U data
  
  glActiveTexture(GL_TEXTURE1);
  
  glBindTexture(GL_TEXTURE_2D, sampler1Texture);
  
  glUniform1i(sampler1Uniform, 1);
  
  
  
  glTexSubImage2D(
  
                  GL_TEXTURE_2D, 
  
                  0, 
  
                  0, 
  
                  0, 
  
                  mFrameW / 2,            // source width
  
                  mFrameH / 2,            // source height
  
                  GL_LUMINANCE,
  
                  GL_UNSIGNED_BYTE, 
  
                  &_frameData[_idxU]);
  
  
  
  // V data
  
  glActiveTexture(GL_TEXTURE2);
  
  glBindTexture(GL_TEXTURE_2D, sampler2Texture);
  
  glUniform1i(sampler2Texture, 2);
  
  
  
  glTexSubImage2D(
  
                  GL_TEXTURE_2D, 
  
                  0, 
  
                  0, 
  
                  0, 
  
                  mFrameW / 2,            // source width
  
                  mFrameH / 2,            // source height
  
                  GL_LUMINANCE,
  
                  GL_UNSIGNED_BYTE,
  
                  &_frameData[_idxV]);
  
  
  
  // Y data
  
  glActiveTexture(GL_TEXTURE0);
  
  glBindTexture(GL_TEXTURE_2D, sampler0Texture);
  
  glUniform1i(sampler0Uniform, 0);
  
  
  
  glTexSubImage2D(
  
                  GL_TEXTURE_2D, 
  
                  0, 
  
                  0, 
  
                  0, 
  
                  mFrameW,            // source width
  
                  mFrameH,            // source height
  
                  GL_LUMINANCE,
  
                  GL_UNSIGNED_BYTE,
  
                  _frameData);

  Vertex Shader & Fragment Shader is below.

  attribute vec4 Position;
  
  attribute vec2 TexCoordIn;
  
  
  
  varying vec2 TexCoordOut;
  
  varying vec2 TexCoordOut_UV;
  
  
  
  uniform mat4 Projection;
  
  uniform mat4 Modelview;
  
  
  
  void main()
  
  {
  
      gl_Position = Projection * Modelview * Position;
  
      TexCoordOut = TexCoordIn;
  
  }
  
  
  
  
  
  
  
  uniform sampler2D sampler0; // Y Texture Sampler
  
  uniform sampler2D sampler1; // U Texture Sampler
  
  uniform sampler2D sampler2; // V Texture Sampler
  
  
  
  varying highp vec2 TexCoordOut;
  
  
  
  void main()
  
  {
  
      highp float y = texture2D(sampler0, TexCoordOut).r;
  
      highp float u = texture2D(sampler2, TexCoordOut).r - 0.5;
  
      highp float v = texture2D(sampler1, TexCoordOut).r - 0.5;
  
  
  
      //y = 0.0;
  
      //u = 0.0;
  
      //v = 0.0;
  
  
  
      highp float r = y + 1.13983 * v;
  
      highp float g = y - 0.39465 * u - 0.58060 * v;
  
      highp float b = y + 2.03211 * u;
  
  
  
      gl_FragColor = vec4(r, g, b, 1.0);
  
  }

  Y Texture (Grayscale) is correct but U & V has a lot of Green Color.
  So final RGB image (Y+U+V) has a lot of GREEN Color.
  What's the problem ?

  Please help.
  thanks.

• Power-Up your Piwik installation with Custom Reports

  13 novembre 2017, par InnoCraft — Plugins

  Would you like to create a report in Piwik with just the data you want and nothing else ? Would you like to be free to decide the shape of it ? Are you struggling with the Piwik database and wish you could have an easy interface to create the report you want ? Are you tired of exporting your data in a spreadsheet ? Since last October, there’s a solution and it’s called Custom Reports.

  With custom reports you will :

  1. get a user-friendly interface to create the report you wish
  2. see all the possible combinations to create the report you desire
  3. reveal new data combinations which were not directly available in Piwik

  User friendly interface

  The time when you created your reports from MySQL database is over. Now with custom reports you can create the report you want and get the data you need in just a few seconds.
  Custom reports are part of the main user interface. You can access them in just one click :

  

  As you can see from above the interface is straightforward, just indicate the name of your report and start to select the dimensions and metrics you would like to see.

  See all the possible combinations to create the report you desire

  As a user the big question has always been, how much data does Piwik collect and where can I find a list of all those data points ? Here you have the solution. Piwik is gathering in custom reports all the possible combinations so you can select only the data you want :

  

  Creating such a report is going to take you no more than a minute. As with any reports within Piwik, you can easily get information regarding the specific data you are using by hovering your mouse on the question mark next to each dimension and metric :

  

  Make new combinations which were not directly available in Piwik

  By default, not all combinations are possible within the Piwik user interface. Now thanks to Custom Reports, you can easily design the report you want. Here is for example a report crossing page titles and page url :

  

  You can then identify if there are any duplicate titles within your content and see the associated URL in a single report.

  You could also identify easily what are your most viewed entry page from Google :

  

  Custom reports can also be used with segments and filters in order to get even more specific data.
  Here we have an example of a custom report designed to take into consideration only the visits coming from Wikipedia :

  

  What is the next step ?

  As you understood it, Piwik custom reports is the must-have plugin in order to take your Piwik to the next level. Why wait ? Piwik custom reports are available through the marketplace.

  Get Custom Reports

  If you are not sure yet, you can always give it a try within our Piwik Cloud infrastructure.