Recherche avancée

Sur d’autres sites (9183)

• Piwik Mobile est maintenant disponible !

  18 août 2010, par SteveG — Développement

  Après quelques mois de développement, l’équipe Piwik est fière de vous présenter le client mobile.

  Piwik Mobile est déjà disponible pour les markets des différents téléphones avec IOS (comme iPhone, iPod et iPad) ou Android (1.6 ou supérieure).

  Piwik Mobile dans les markets :
  Android : http://www.androidpit.com/en/android/market/apps/app/org.piwik.mobile/Piwik-Mobile-Beta
  iOS : http://itunes.apple.com/us/app/piwikmobile/id385536442?mt=8

  

  Piwik Mobile a été développé en utilisant Titanium et fournit aujourd’hui les principaux graphiques et rapports. Comme Piwik Mobile est toujours en développement et ce n’est que la première version, tous les rapports ne sont pas disponibles. L’application utilise la traduction inclue dans Piwik. Ainsi, il est disponible dans toutes les langues supportées par Piwik.

  D’autres améliorations suivront. Il n’est pas possible pour nous de tester l’application sur tous les téléphones, il peut y avoir des problèmes avec certains d’entre eux. Si vous trouvez des erreurs dans l’application ou si vous avez des suggestions pour l’améliorer, n’hésitez pas à nous contacter par courriel à mobileatpiwik.org ou créer un ticket.

  Piwik Mobile a été développé par Thomas et Stefan, qui ont rejoins l’équipe Piwik avec l’idée du client mobile. Ils vont superviser et maintenir les développements en tant que meneurs de ce projet.

  Un grand merci à Mayflower, une société de développement Web Allemande, qui a sponsorisé les heures de travail des développeurs Thomas et Stefan.

  

• More Weird VP8 Encodings

  10 décembre 2010, par Multimedia Mike — VP8

  When I announced that I had transitioned my VP8 encoder’s status from "toy" to "working", Jim L. lamented the loss of humorous posts about oddly encoded images output from my encoder. Not so ! There are still plenty of features that I have yet to implement, each of which carries the possibility of bizarre images.

  For example, I dusted off my work-in-progress intra 4x4 encoding, fixed a few of the more obvious bugs, and told the encoder to encode the first block in 4x4 mode and the rest in the usual, working, debugged 16x16 mode. The results of the first pass surprised me :

  
  
  

  The reason this surprised me was that I intuitively expected one of 2 outcomes :

  • Perfect image right away since everything is correct (very unlikely but not outside the realm of possibility)
  • Total garbage with, at most, the first macroblock looking somewhat legible ; this would be due to having some of the first macroblock correct but completely desynchronizing the bitstream for the purpose of decoding the rest of the coefficients.

  I absolutely did not expect the first macroblock to look messed up but for the rest of the picture to look fine. For fun, I reversed the logic and encoded the first block as 16x16 and the rest with the experimental 4x4 mode :

  
  
  

  If you examine carefully, you will see that the color planes are correct (though faint). There just isn’t much going on in the luma plane. This made sense when I noticed the encoder was encoding a blank (undefined, actually) set of luma coefficients for 4x4 mode macroblocks due to a bug. This helps to rationalize the first image as well— the first macroblock was encoding nonsense for the first macroblock which messed up the macroblocks which immediately surrounded it. Eventually, macroblock decoding got back on track when the prediction modes weren’t relying on the errantly decoded macroblocks.

  After I fixed that bug, I let the 4x4 mode rip through the whole image. That’s when I got what I am terming the "dark and gritty reboot of Big Buck Bunny" :

  
  
  

  Fortunately, this also turned out to be traceable to a pretty obvious code bug.

  One day, this VP8 encoder might do the right thing while implementing all of the algorithm’s features. In the meantime, it’s at least entertaining to watch it make mistakes.

• RoR ffmpeg installed by brew

  26 octobre 2012, par Thomas Kobber Panum

  I'm developing a Ruby on Rails application that needs ffmpeg, to do some processing of the files I have.

  However, when trying to use ffmpeg, I get this error

  Failed encoding. Errors: no output file created. Full output: dyld: Library not loaded: /usr/local/lib/libogg.0.dylib
  
  Referenced from: /usr/local/bin/ffmpeg
  
  Reason: Incompatible library version: ffmpeg requires version 9.0.0 or later, but libogg.0.dylib provides version 6.0.0

  It's a basically a CarrierWave project, which can be seen here : http://www.freezzo.com/2010/12/23/create-ffmpeg-processor-for-carrierwave-in-rails-3/