Recherche avancée

Sur d’autres sites (12275)

• 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.

• Trolls in trouble

  6 juin 2013, par Mans — Law and liberty

  Life as a patent troll is hopefully set to get more difficult. In a memo describing patent trolls as a “drain on the American economy,” the White House this week outlined a number of steps it is taking to stem this evil tide. Chiming in, the Chief Judge of the Court of Appeals for the Federal Circuit (where patent cases are heard) in a New York Times op-ed laments the toll patent trolling is taking on the industry, and urges judges to use powers already at their disposal to make the practice less attractive. However, while certainly a step in the right direction, these measures all fail to address the more fundamental properties of the patent system allowing trolls to exist in the first place.

  System and method for patent trolling

  Most patent trolling operations comprise the same basic elements :

  1. One or more patents with broad claims.
  2. The patents of (1) acquired by an otherwise non-practising entity (troll).
  3. The entity of (2) filing numerous lawsuits alleging infringement of the patents of (1).
  4. The lawsuits of (3) targeting end users or retailers.
  5. The lawsuits of (3) listing as plaintiffs difficult to trace shell companies.

  The recent legislative actions all take aim at the latter entries in this list. In so doing, they will no doubt cripple the trolls, but the trolls will remain alive, ready to resume their wicked ways once a new loophole is found in the system.

  To kill a patent troll

  As Judge Rader and his co-authors point out in the New York Times, “the problem stems largely from the fact that, [...] trolls have an important strategic advantage over their adversaries : they don’t make anything.” This is the heart of the troll, and this is where the blow should be struck. Our weapon shall be the mightiest judicial sword of all, the Constitution.

  The United States Constitution contains (in Article I, Section 8) the foundation for the patent system (emphasis mine) :

  The Congress shall have Power [...] To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.

  Patent trolls are typically not inventors. They are merely hoarders of other people’s discarded inventions, and that allowing others to reap the benefits of an inventor’s work would somehow promote progress should be a tough argument. Indeed, it is the dissociation between investment and reward which has allowed the patent trolls to rise and prosper.

  In light of the above, the solution to the troll menace is actually strikingly simple : make patents non-transferable.

  Having the inventor retain the rights to his or her inventions (works for hire still being recognised), would render the establishment of non-practising entities, which most trolls are, virtually impossible. The original purpose of patents, to protect the investment of inventors, would remain unaffected, if not strengthened, by such a change.

  Links

  • Taking on Patent Trolls to Protect American Innovation
  • Fact Sheet : White House Task Force on High-Tech Patent Issues
  • Make Patent Trolls Pay in Court
  • Constitution of the United States

• ffmpeg app using node occasionally crashes as file doesn't appear to be read correctly

  31 mai 2022, par Zabs

  I have an simple Node application that allows me to pass an AWS S3 URL link to a file (in this case video files). It uses the FFMPEG library to read the video file and return data like codecs, duration, bitrate etc..

  


  The script is called from PHP script which in turn send the data to the Node endpoint and passes the Amazon S3 URL to node. Sometimes for no obvious reasons the video file fails to return the expected values regarding container, codec, duration etc... and just returns '0'. But when I try the exact same file/request again it returns this data correctly e.g container:mp4

  


  I'm not sure but I think the script somehow needs the createWriteStream to be closed but I cannot be sure, the problem is the issue I have found doesn't happen all the time but sporadically so its hard to get to the issue when its difficult to replicate it.

  


  Any ideas ?

  


  router.post('/', async function(req, res) {
  const fileURL = new URL(req.body.file);
  var path = fileURL.pathname;
  path = 'tmp/'+path.substring(1);    // removes the initial / from the path

  let file = fs.createWriteStream(path);  // create the file locally
  const request = https.get(fileURL, function(response) {
    response.pipe(file);
  });
  
  // after file has saved
  file.on('finish', function () {
    var process = new ffmpeg(path);
    process.then(function (video) {
      let metadata = formatMetadata(video.metadata);

      res.send ({
        status: '200',
        data: metadata,
        errors: errors,
        response: 'success'
      });

    }, function (err) {
      console.warn('Error: ' + err);

      res.send ({
        status: '400',
        data: 'Something went wrong processing this video',
        response: 'fail',
      });
    });
  });

  file.on('error', function (err) {
    console.warn(err);
  });

});

function formatMetadata(metadata) {
  const data = {
    'video' : metadata.video,
    'audio' : metadata.audio,
    'duration' : metadata.duration
  };
  return data;
}


  


  // Expected output

  


  {"data":{"video":{"container":"mov","bitrate":400,"stream":0,"codec":"h264","resolution":{"w":1280,"h":720},"resolutionSquare":{"w":1280,"h":720},"aspect":{"x":16,"y":9,"string":"16:9","value":1.7777777777777777},"rotate":0,"fps":25,"pixelString":"1:1","pixel":1},"audio":{"codec":"aac","bitrate":"127","sample_rate":44100,"stream":0,"channels":{"raw":"stereo","value":2}},"duration":{"raw":"00:00:25.68","seconds":25}}


  


  // Actual output

  


  {"data":{"video":{"container":"","bitrate":0,"stream":0,"codec":"","resolution":{"w":0,"h":0},"resolutionSquare":{"w":0,"h":null},"aspect":{},"rotate":0,"fps":0,"pixelString":"","pixel":0},"audio":{"codec":"","bitrate":"","sample_rate":0,"stream":0,"channels":{"raw":"","value":""}},"duration":{"raw":"","seconds":0}}


  


  Note - this happens sporadically