Recherche avancée

Sur d’autres sites (18180)

• Patent skullduggery : Tandberg rips off x264 algorithm

  25 novembre 2010, par Dark Shikari — patents, ripoffs, x264

  Update : Tandberg claims they came up with the algorithm independently : to be fair, I can actually believe this to some extent, as I think the algorithm is way too obvious to be patented. Of course, they also claim that the algorithm isn’t actually identical, since they don’t want to lose their patent application.

  I still don’t trust them, but it’s possible it’s merely bad research (and thus being unaware of prior art) as opposed to anything malicious. Furthermore, word from within their office suggests they’re quite possibly being honest : supposedly the development team does not read x264 code at all. So this might just all be very bad luck.

  Regardless, the patent is still complete tripe, and should never have been filed.
  

  Most importantly, stop harassing the guy whose name is on the patent (Lars) : he’s just a programmer, not the management or lawyers responsible for filing the patent. This is stupid and unnecessary. I’ve removed the original post because of this ; it can be found here for those who want to read it.

  Appendix : the details of the patent :

  I figure I’ll go over the exact correspondence between the patent and my code here.

  1. A method for calculating run and level representations of quantized transform coefficients representing pixel values included in a block of a video picture, the method comprising :

  Translation : It’s a run-level coder.

  packing, at a video processing apparatus, each quantized transform coefficients in a value interval [Max, Min] by setting all quantized transform coefficients greater than Max equal to Max, and all quantized transform coefficients less than Min equal to Min

  The quantized coefficients are clipped to a certain valid range to allow them to be packed into bytes (they start as 16-bit values).

  reordering, at the video processing apparatus, the quantized transform ID coefficients according to a predefined order depending on respective positions in the block resulting in an array C of reordered quantized transform coefficients

  This is the zigzag pattern used in H.264 (and most formats) for reordering DCT coefficients. In x264, this is done before the run-level coder ste.

  masking, at the video processing apparatus, C by generating an array M containing ones in positions corresponding to positions of C having non-zero values, and zeros in positions corresponding to positions of C having zero values

  This is creating a bitmask based on the coefficient values, the pmovmskb step.

  is generating, at the video processing apparatus, for each position containing a one in M, a run and a level representation by setting the level value equal to an occurring value in a corresponding position of C ; and setting, at the video processing apparatus, for each position containing a one in M₅ the run value equal to the number of proceeding positions relative to a current position in M since a previous occurrence of one in M.

  This is the process of creating run/level values from the bitmask.

  Now into the detailed claims :

  2. The method according to Claim 1, wherein the masking further includes, creating an array C from C where positions corresponding to positions of nonzero values in C are filled with ones, and positions corresponding to positions of zero values in C are filled with zeros, and creating M from C by extracting the most significant bit from values in respective position of C and inserting the bits in corresponding positions in M.

  They’re extracting the most significant bit of the values to create a bitmask. This is exactly what the pmovmskb in my algorithm does.

  3. The method according to Claim 2, wherein the creating of the array C is executed by a C++ function PCMPGTB, and the creating of M from C is executed by a C++ function PMOVMSKB.

  And here they use pcmpgtb (they call it a C++ function for some reason, but it’s a SSE instruction) to do the clipping of the input values. This is exactly the same method I used in decimate_score. They also use pmovmskb as mentioned.

  4. The method according to Claim 1 , wherein the generating of the run and level representation further includes determining positions containing non-zero values in C by corresponding positions containing ones in M.

  5. The method according to Claim 4, wherein the determining of positions containing non-zero values in C is executed by a C++ function BSF.

  Here they iterate over the bitmask of transform coefficients using a “BSF” function to find runs, which is exactly what I did. Of course, BSF isn’t a function, it’s an x86 instruction.

  6. The method according to Claim 1 , wherein Max is 256 and Min is 0.

  This is almost surely a typo or mistake of some sort. They mean the Max should be 255, not 256 : 256 doesn’t fit in a uint8_t.

  7. The method according to Claim 1 , wherein the predefined order follows a zigzag path of transform coefficient positions in the block starting in an upper left corner heading towards a lower right corner.

  This is a description of the typical DCT zigzag pattern (like in H.264, MPEG-2, Theora, etc).

  Everything after this part is just repeating itself with the phrase “an apparatus” added in order to make the USPTO listen to them.

• Révision 22264 : Suite de r22206 quant à l’exemple fourni par Georges Kandalaft.

  24 juin 2015, par esj -

  D’abord le message r22206 a été tronqué par un chevron non neutralisé ; il voulait dire :

  Dans le squelette ci-dessous le "**" après #SESSION n’est pas seulement
  destiné à produire un code PHP plus efficace (il ne sécurise pas car ce
  n’est pas nécessaire quand on ne s’intéresse qu’au résultat booléen),
  mais aussi parce que le "interdire_script" introduit sinon transcode
  le chevron dans le "< ?php" de la balise dynamique #URL_LOGOUT,
  ce qui la neutralise.

  C’est en fait un bug qui a toujours existé. Le rôle de "interdire_scripts"
  est de nettoyer la valeur d’une balise qui peut être alimentée de l’extérieur.
  Cette fonction doit s’appliquer sur cette valeur seulement,
  et non sur le résultat de son traitement par les filtres qu’on lui applique,
  qui eux peuvent introduire des scripts à bon escient. C’est en particulier
  le cas des balises dynamiques comme URL_LOGOUT qui introduit un "< ?php"
  neutralisé à tort par le compilateur jusqu’à aujourd’hui.

  On permute donc l’insertion de "interdire_scripts" dans le code avec l’insertion des filtres. Dans le squelette ci-dessous, il n’est donc plus nécessaire de placer la double étoile pour obtenir un code compilé correct (mais il reste intéressant dans le faire par souci d’efficacité).

  <span class="CodeRay">[(#SESSION**{nom}|?{
  
  <span class="tag">&lt;:bienvenue:></span> <span class="tag"><strong></strong></span>#SESSION{nom}<span class="tag"></span>    
  
  <span class="tag">span> <span class="tag">/></span><span class="tag">span> <span class="attribute-name">href</span>=<span class="string"><span class="delimiter">'</span><span class="content">#URL_LOGOUT</span><span class="delimiter">'</span></span><span class="tag">></span><span class="tag">&lt;:logout:></span><span class="tag"></span>
  
  ,
  
  <span class="tag"><p></p></span><span class="tag"><small></small></span><span class="tag">span> <span class="attribute-name">alt</span>=<span class="string"><span class="delimiter">"</span><span class="content">&lt;:zonep:</span></span><span class="error">></span>" src='#CHEMIN{encrypted.png}' /<span class="error">></span> <span class="tag">&lt;:acces:></span> <span class="tag">span> <span class="attribute-name">href</span>=<span class="string"><span class="delimiter">"</span><span class="content">#URL_PAGE{login,url=#SELF}</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag">&lt;:ident:></span><span class="tag"></span>
  
  <span class="tag"></span><span class="tag"></span>
  
  })]
  
  </span></span></span></span></span>

• How to get your Piwik plugin translated in many languages ?

  8 septembre 2015, par Stefan Giehl — Community, Development, Plugins

  About a year ago we introduced the Piwik Marketplace to make it easy for developers to share their plugins with all Piwik users.

  As Piwik is currently available in 54 languages we would love to have as many plugins as possible available in at least a few of those languages.

  Currently most plugins on the Marketplace are only available in English and sometimes some other languages. To improve this situation, we offer plugin developers the possibility to use the power of our translators community to get their plugins translated.

  Some plugin developers are already using this service and some very popular plugins like BotTracker or CustomOptOut have already been translated in more than 10 languages !

  Getting translations for your plugin

  As long as you are developing an open source plugin hosted on Github, you may get in touch with us (translations@piwik.org) in order to get your plugin translated by the Piwik translators community.

  You will need an account on Transifex.com. If you use Transifex with a social login, please ensure to set a password in your account settings. This will be required for fetching new translations into your plugin repository.

  Importing your plugin’s strings in the translation platform

  While doing the initial setup for your plugin, we will import your english translation file (en.json) in your Github plugin repository and we will configure an auto-update for this file. Source strings on Transifex will automatically synchronise with your plugin repository. When you change any string in your en.json translation file, the updated English strings will automatically be imported in Transifex.

  How to fetch your plugins translations into your repository

  As soon as we have set up your plugin within our Piwik project on Transifex and there are new translations available, you will be able to update your plugin translations using the Piwik console. You will need a locally installed Piwik with development mode enabled, and your plugin installed. To update the translations go to the Piwik directory on your development box and execute the following command :

  ./console translations:update -u {YourTransifexUserName} -p {YourTransifexPassword} -P {YourPluginName}

  We are looking forward to seeing your Piwik plugins available in more languages ! For more information, check out our Translations plugin developer guide.

  Happy hacking,