Recherche avancée

Sur d’autres sites (3914)

• Memcached protocol support

  15 novembre 2013, par Mikko Koppanen — Imagick

  For the past few days I’ve been adding Memcached binary protocol support to PECL memcached extension. The protocol handler provides a high-level abstraction for acting as a memcached server. There are quite a few things still missing and only binary protocol is supported at the moment, but the code seems to work reasonably well in small-scale testing.

  I am not sure whether this is useful for anyone, but at least it allows things such as quick prototyping of network servers, exposing sqlite database over memcached protocol etc.

  The code is quite simple and implementing a simple server responding to get and set would look roughly like the following :

  php

  < view plain text >

  1. < ?php
  2. // Create new server instance
  3. $server = new MemcachedServer() ;
  4.  
  5. // Create a simple storage class
  6. class Storage {
  7.   private $values = array () ;
  8.   
  9.   public function set ($key, $value, $expiration) {
  10.     $this->values [$key] = array (’value’ => $value,
  11.                    ’expires’ => time () + $expiration) ;
  12.   }
  13.  
  14.   public function get ($key) {
  15.     if (isset ($this->values [$key])) {
  16.       if ($this->values [$key] [’expires’] < time ()) {
  17.         unset ($this->values [$key]) ;
  18.         return null ;
  19.       }
  20.       return $this->values [$key] [’value’] ;
  21.     }
  22.     else
  23.       return null ;
  24.   }
  25. }
  26.  
  27. $storage = new Storage () ;
  28.  
  29. // Set callback for get command
  30. $server->on (Memcached: :ON_GET,
  31.        function ($client_id, $key, &$value, &$flags, &$cas) use ($storage) {
  32.          echo "Getting key=[$key]" . PHP_EOL ;
  33.          if (($value = $storage->get ($key))  != null)
  34.            return Memcached: :RESPONSE_SUCCESS ;
  35.  
  36.          return Memcached: :RESPONSE_KEY_ENOENT ;
  37.        }) ;
  38.  
  39. // Set callback for set command
  40. $server->on (Memcached: :ON_SET,
  41.        function ($client_id, $key, $value, $flags, $expiration, $cas, &$result_cas) use ($storage) {
  42.          echo "Setting key=[$key] value=[$value]" . PHP_EOL ;
  43.          $storage->set ($key, $value, $expiration) ;
  44.          return Memcached: :RESPONSE_SUCCESS ;
  45.        }) ;
  46.  
  47. // Run the server on localhost, port 3434. Will block
  48. $server->run ("127.0.0.1:3434") ;
  49.  ?>

  And the client that communicates with the server :

  php

  < view plain text >

  1. < ?php
  2.  
  3. $cache = new Memcached() ;
  4. $cache->setOption(Memcached: :OPT_BINARY_PROTOCOL, true) ;
  5. $cache->setOption(Memcached: :OPT_COMPRESSION, false) ;
  6. $cache->addServer(’localhost’, 3434) ;
  7.  
  8. $cache->set (’set_key1’, ’This is the first key’, 10) ;
  9. var_dump ($cache->get (’set_key1’)) ;
  10.  
  11. $cache->set (’set_key2’, ’This is the second key’, 2) ;
  12. var_dump ($cache->get (’set_key2’)) ;
  13.  ?>

  The code is still work in progress but it’s available in github : https://github.com/mkoppanen/php-memcached/tree/feature-server. Note that you need to compile libmemcached with –enable-libmemcachedprotocol and the PECL memcached extension with –enable-memcached-protocol.

• Building FFmpeg for android to run command line args

  11 septembre 2012, par Zargoon

  I am trying to build the FFmpeg library to use in my android app with the NDK. The reason for this is because I am using the native video capture feature in android because I really don't want to write my own video recorder. However, the native video capture only allows for either high-quality encoding, or low quality encoding. I want something in between, and I believe that the solution is to use the FFmpeg library to re-encode the high quality video to be lighter.

  So far I have been able to build the FFmpeg library according to this guide : http://www.roman10.net/how-to-build-ffmpeg-for-android/ and which a few tweaks I have been able to get it to work.

  However, everything that I've found seems to be about writing your own encoder, which seems like overkill to me. All that I really want to do is send a string in command line format to the main() function of FFmpeg and re-encode my video. However, I can't seem to figure out how I build FFmpeg to give me access to the main method. I found this post : Compile ffmpeg.c and call its main() via JNI which links to a project doing what I want more of less, but for the life of me I cannot figure out what is going on. It also seems like he is compiling more than I want, and I would really like to keep my application as light weight as possible.

  Some additional direction would be extremely helpful. Thank you.

• The First Problem

  19 janvier 2011, par Multimedia Mike — HTML5

  A few years ago, The Linux Hater made the following poignant observation regarding Linux driver support :

  Drivers are only just the beginning... But for some reason y’all like to focus on the drivers. You know why lusers do that ? Because it just happens to be the problem that people notice first.

  And so it is with the HTML5 video codec debate, re-invigorated in the past week by Google’s announcement of dropping native H.264 support in their own HTML5 video tag implementation. As I read up on the fiery debate, I kept wondering why people are so obsessed with this issue. Then I remembered the Linux Hater’s post and realized that the video codec issue is simply the first problem that most people notice regarding HTML5 video.

  I appreciate that the video codec debate has prompted Niedermayer to post on his blog once more. Otherwise, I’m just munching popcorn on the sidelines, amused and mildly relieved that the various factions are vociferously attacking each other rather than that little project I help with at work.

  Getting back to the "first problem" aspect— there’s so much emphasis on the video codec ; I wonder why no one ever, ever mentions word one about an audio codec. AAC is typically the codec that pairs with H.264 in the MPEG stack. Dark Shikari once mentioned that "AAC’s licensing terms are exponentially more onerous than H.264′s. If Google didn’t want to use H.264, they would sure as hell not want to use AAC." Most people are probably using "H.264" to refer to the entire MPEG/H.264/AAC stack, even if they probably don’t understand what all of those pieces mean.

  Anyway, The Linux Hater’s driver piece continues :

  Once y’all have drivers, the fight will move to the next layer up. And like I said, it’s a lot harder at that layer.

  A few months ago, when I wanted to post the WebM output of my new VP8 encoder and thought it would be a nice touch to deliver it via a video tag, I ignored the video codec problem (just encoded a VP8/WebM file) only to immediately discover a problem at a different layer— specifically, embedding a file using a video tag triggers a full file download when the page is loaded, which is unacceptable from end user and web hosting perspectives. This is a known issue but doesn’t get as much attention, I guess because there are bigger problems to solve first (c.f. video codec issue).

  For other issues, check out the YouTube blog’s HTML5 post or Hulu’s post that also commented on HTML5. Issues such as video streaming flexibility, content protection, fullscreen video, webcam/microphone input, and numerous others are rarely mentioned in the debates. Only "video codec" is of paramount importance.

  But I’m lending too much weight to the cacophony of a largely uninformed internet debate. Realistically, I know there are many talented engineers down in the trenches working to solve at least some of these problems. To tie this in with the Linux driver example, I’m consistently stunned these days regarding how simple it is to get Linux working on a new computer— most commodity consumer hardware really does just work right out of the box. Maybe one day, we’ll wake up and find that HTML5 video has advanced to the point that it solves all of the relevant problems to make it the simple and obvious choice for delivering web video in nearly all situations.

  It won’t be this year.