Recherche avancée

Sur d’autres sites (4365)

• Things I Have Learned About Emscripten

  1er septembre 2015, par Multimedia Mike — Cirrus Retro

  3 years ago, I released my Game Music Appreciation project, a website with a ludicrously uninspired title which allowed users a relatively frictionless method to experience a range of specialized music files related to old video games. However, the site required use of a special Chrome plugin. Ever since that initial release, my #1 most requested feature has been for a pure JavaScript version of the music player.

  “Impossible !” I exclaimed. “There’s no way JS could ever run fast enough to run these CPU emulators and audio synthesizers in real time, and allow for the visualization that I demand !” Well, I’m pleased to report that I have proved me wrong. I recently quietly launched a new site with what I hope is a catchier title, meant to evoke a cloud-based retro-music-as-a-service product : Cirrus Retro. Right now, it’s basically the same as the old site, but without the wonky Chrome-specific technology.

  Along the way, I’ve learned a few things about using Emscripten that I thought might be useful to share with other people who wish to embark on a similar journey. This is geared more towards someone who has a stronger low-level background (such as C/C++) vs. high-level (like JavaScript).

  General Goals
  Do you want to cross-compile an entire desktop application, one that relies on an extensive GUI toolkit ? That might be difficult (though I believe there is a path for porting qt code directly with Emscripten). Your better wager might be to abstract out the core logic and processes of the program and then create a new web UI to access them.

  Do you want to compile a game that basically just paints stuff to a 2D canvas ? You’re in luck ! Emscripten has a porting path for SDL. Make a version of your C/C++ software that targets SDL (generally not a tall order) and then compile that with Emscripten.

  Do you just want to cross-compile some functionality that lives in a library ? That’s what I’ve done with the Cirrus Retro project. For this, plan to compile the library into a JS file that exports some public functions that other, higher-level, native JS (i.e., JS written by a human and not a computer) will invoke.

  Memory Levels
  When porting C/C++ software to JavaScript using Emscripten, you have to think on 2 different levels. Or perhaps you need to force JavaScript into a low level C lens, especially if you want to write native JS code that will interact with Emscripten-compiled code. This often means somehow allocating chunks of memory via JS and passing them to the Emscripten-compiled functions. And you wouldn’t believe the type of gymnastics you need to execute to get native JS and Emscripten-compiled JS to cooperate.
  

  “Emscripten : Pointers and Pointers” is the best (and, really, ONLY) explanation I could find for understanding the basic mechanics of this process, at least when I started this journey. However, there’s a mistake in the explanation that left me confused for a little while, and I’m at a loss to contact the author (doesn’t anyone post a simple email address anymore ?).

  Per the best of my understanding, Emscripten allocates a large JS array and calls that the memory space that the compiled C/C++ code is allowed to operate in. A pointer in C/C++ code will just be an index into that mighty array. Really, that’s not too far off from how a low-level program process is supposed to view memory– as a flat array.

  Eventually, I just learned to cargo-cult my way through the memory allocation process. Here’s the JS code for allocating an Emscripten-compatible byte buffer, taken from my test harness (more on that later) :

  var musicBuffer = fs.readFileSync(testSpec[’filename’]) ;
  var musicBufferBytes = new Uint8Array(musicBuffer) ;
  var bytesMalloc = player._malloc(musicBufferBytes.length) ;
  var bytes = new Uint8Array(player.HEAPU8.buffer, bytesMalloc, musicBufferBytes.length) ;
  bytes.set(new Uint8Array(musicBufferBytes.buffer)) ;
  

  So, read the array of bytes from some input source, create a Uint8Array from the bytes, use the Emscripten _malloc() function to allocate enough bytes from the Emscripten memory array for the input bytes, then create a new array… then copy the bytes…

  You know what ? It’s late and I can’t remember how it works exactly, but it does. It has been a few months since I touched that code (been fighting with front-end website tech since then). You write that memory allocation code enough times and it begins to make sense, and then you hope you don’t have to write it too many more times.

  Multithreading
  You can’t port multithreaded code to JS via Emscripten. JavaScript has no notion of threads ! If you don’t understand the computer science behind this limitation, a more thorough explanation is beyond the scope of this post. But trust me, I’ve thought about it a lot. In fact, the official Emscripten literature states that you should be able to port most any C/C++ code as long as 1) none of the code is proprietary (i.e., all the raw source is available) ; and 2) there are no threads.

  Yes, I read about the experimental pthreads support added to Emscripten recently. Don’t get too excited ; that won’t be ready and widespread for a long time to come as it relies on a new browser API. In the meantime, figure out how to make your multithreaded C/C++ code run in a single thread if you want it to run in a browser.

  Printing Facility
  Eventually, getting software to work boils down to debugging, and the most primitive tool in many a programmer’s toolbox is the humble print statement. A print statement allows you to inspect a piece of a program’s state at key junctures. Eventually, when you try to cross-compile C/C++ code to JS using Emscripten, something is not going to work correctly in the generated JS “object code” and you need to understand what. You’ll be pleading for a method of just inspecting one variable deep in the original C/C++ code.

  I came up with this simple printf-workalike called emprintf() :

  #ifndef EMPRINTF_H
  #define EMPRINTF_H
  #include <stdio .h>
  
  #include <stdarg .h>
  
  #include <emscripten .h>
  #define MAX_MSG_LEN 1000
  /* NOTE : Don’t pass format strings that contain single quote (’) or newline
  
  * characters. */
  
  static void emprintf(const char *format, ...)
  
  
  
      char msg[MAX_MSG_LEN] ;
  
      char consoleMsg[MAX_MSG_LEN + 16] ;
  
      va_list args ;
  
      /* create the string */
  
      va_start(args, format) ;
  
      vsnprintf(msg, MAX_MSG_LEN, format, args) ;
  
      va_end(args) ;
      /* wrap the string in a console.log(’’) statement */
  
      snprintf(consoleMsg, MAX_MSG_LEN + 16, "console.log(’%s’)", msg) ;
      /* send the final string to the JavaScript console */
  
      emscripten_run_script(consoleMsg) ;
  
  
  #endif  /* EMPRINTF_H */
  

  Put it in a file called “emprint.h”. Include it into any C/C++ file where you need debugging visibility, use emprintf() as a replacement for printf() and the output will magically show up on the browser’s JavaScript debug console. Heed the comments and don’t put any single quotes or newlines in strings, and keep it under 1000 characters. I didn’t say it was perfect, but it has helped me a lot in my Emscripten adventures.

  Optimization Levels
  Remember to turn on optimization when compiling. I have empirically found that optimizing for size (-Os) leads to the best performance all around, in addition to having the smallest size. Just be sure to specify some optimization level. If you don’t, the default is -O0 which offers horrible performance when running in JS.

  Static Compression For HTTP Delivery
  JavaScript code compresses pretty efficiently, even after it has been optimized for size using -Os. I routinely see compression ratios between 3.5:1 and 5:1 using gzip.

  Web servers in this day and age are supposed to be smart enough to detect when a requesting web browser can accept gzip-compressed data and do the compression on the fly. They’re even supposed to be smart enough to cache compressed output so the same content is not recompressed for each request. I would have to set up a series of tests to establish whether either of the foregoing assertions are correct and I can’t be bothered. Instead, I took it into my own hands. The trick is to pre-compress the JS files and then instruct the webserver to serve these files with a ‘Content-Type’ of ‘application/javascript’ and a ‘Content-Encoding’ of ‘gzip’.

  1. Compress your large Emscripten-build JS files with ‘gzip’ : ‘gzip compiled-code.js’
  2. Rename them from extension .js.gz to .jsgz
  3. Tell the webserver to deliver .jsgz files with the correct Content-Type and Content-Encoding headers

  To do that last step with Apache, specify these lines :

  AddType application/javascript jsgz
  AddEncoding gzip jsgz
  

  They belong in either a directory’s .htaccess file or in the sitewide configuration (/etc/apache2/mods-available/mime.conf works on my setup).

  Build System and Build Time Optimization
  Oh goodie, build systems ! I had a very specific manner in which I wanted to build my JS modules using Emscripten. Can I possibly coerce any of the many popular build systems to do this ? It has been a few months since I worked on this problem specifically but I seem to recall that the build systems I tried to used would freak out at the prospect of compiling stuff to a final binary target of .js.

  I had high hopes for Bazel, which Google released while I was developing Cirrus Retro. Surely, this is software that has been battle-tested in the harshest conditions of one of the most prominent software-developing companies in the world, needing to take into account the most bizarre corner cases and still build efficiently and correctly every time. And I have little doubt that it fulfills the order. Similarly, I’m confident that Google also has a team of no fewer than 100 or so people dedicated to developing and supporting the project within the organization. When you only have, at best, 1-2 hours per night to work on projects like this, you prefer not to fight with such cutting edge technology and after losing 2 or 3 nights trying to make a go of Bazel, I eventually put it aside.

  I also tried to use Autotools. It failed horribly for me, mostly for my own carelessness and lack of early-project source control.

  After that, it was strictly vanilla makefiles with no real dependency management. But you know what helps in these cases ? ccache ! Or at least, it would if it didn’t fail with Emscripten.

  Quick tip : ccache has trouble with LLVM unless you set the CCACHE_CPP2 environment variable (e.g. : “export CCACHE_CPP2=1”). I don’t remember the specifics, but it magically fixes things. Then, the lazy build process becomes “make clean && make”.

  Testing
  If you have never used Node.js, testing Emscripten-compiled JS code might be a good opportunity to start. I was able to use Node.js to great effect for testing the individually-compiled music player modules, wiring up a series of invocations using Python for a broader test suite (wouldn’t want to go too deep down the JS rabbit hole, after all).

  Be advised that Node.js doesn’t enjoy the same kind of JIT optimizations that the browser engines leverage. Thus, in the case of time critical code like, say, an audio synthesis library, the code might not run in real time. But as long as it produces the correct bitwise waveform, that’s good enough for continuous integration.

  Also, if you have largely been a low-level programmer for your whole career and are generally unfamiliar with the world of single-threaded, event-driven, callback-oriented programming, you might be in for a bit of a shock. When I wanted to learn how to read the contents of a file in Node.js, this is the first tutorial I found on the matter. I thought the code presented was a parody of bad coding style :

  var fs = require("fs") ;
  var fileName = "foo.txt" ;
  fs.exists(fileName, function(exists) 
  
    if (exists) 
  
      fs.stat(fileName, function(error, stats) 
  
        fs.open(fileName, "r", function(error, fd) 
  
          var buffer = new Buffer(stats.size) ;
  
          fs.read(fd, buffer, 0, buffer.length, null, function(error, bytesRead, buffer) 
  
            var data = buffer.toString("utf8", 0, buffer.length) ;
  
            console.log(data) ;
  
            fs.close(fd) ;
  
          ) ;
  
        ) ;
  
      ) ;
  
    ) ;
  

  Apparently, this kind of thing doesn’t raise an eyebrow in the JS world.

  Now, I understand and respect the JS programming model. But this was seriously frustrating when I first encountered it because a simple script like the one I was trying to write just has an ordered list of tasks to complete. When it asks for bytes from a file, it really has nothing better to do than to wait for the answer.

  Thankfully, it turns out that Node’s fs module includes synchronous versions of the various file access functions. So it’s all good.

  Conclusion
  I’m sure I missed or underexplained some things. But if other brave souls are interested in dipping their toes in the waters of Emscripten, I hope these tips will come in handy.

  The post Things I Have Learned About Emscripten first appeared on Breaking Eggs And Making Omelettes.

• Things I Have Learned About Emscripten

  1er septembre 2015, par Multimedia Mike — Cirrus Retro

  3 years ago, I released my Game Music Appreciation project, a website with a ludicrously uninspired title which allowed users a relatively frictionless method to experience a range of specialized music files related to old video games. However, the site required use of a special Chrome plugin. Ever since that initial release, my #1 most requested feature has been for a pure JavaScript version of the music player.

  “Impossible !” I exclaimed. “There’s no way JS could ever run fast enough to run these CPU emulators and audio synthesizers in real time, and allow for the visualization that I demand !” Well, I’m pleased to report that I have proved me wrong. I recently quietly launched a new site with what I hope is a catchier title, meant to evoke a cloud-based retro-music-as-a-service product : Cirrus Retro. Right now, it’s basically the same as the old site, but without the wonky Chrome-specific technology.

  Along the way, I’ve learned a few things about using Emscripten that I thought might be useful to share with other people who wish to embark on a similar journey. This is geared more towards someone who has a stronger low-level background (such as C/C++) vs. high-level (like JavaScript).

  General Goals
  Do you want to cross-compile an entire desktop application, one that relies on an extensive GUI toolkit ? That might be difficult (though I believe there is a path for porting qt code directly with Emscripten). Your better wager might be to abstract out the core logic and processes of the program and then create a new web UI to access them.

  Do you want to compile a game that basically just paints stuff to a 2D canvas ? You’re in luck ! Emscripten has a porting path for SDL. Make a version of your C/C++ software that targets SDL (generally not a tall order) and then compile that with Emscripten.

  Do you just want to cross-compile some functionality that lives in a library ? That’s what I’ve done with the Cirrus Retro project. For this, plan to compile the library into a JS file that exports some public functions that other, higher-level, native JS (i.e., JS written by a human and not a computer) will invoke.

  Memory Levels
  When porting C/C++ software to JavaScript using Emscripten, you have to think on 2 different levels. Or perhaps you need to force JavaScript into a low level C lens, especially if you want to write native JS code that will interact with Emscripten-compiled code. This often means somehow allocating chunks of memory via JS and passing them to the Emscripten-compiled functions. And you wouldn’t believe the type of gymnastics you need to execute to get native JS and Emscripten-compiled JS to cooperate.
  

  “Emscripten : Pointers and Pointers” is the best (and, really, ONLY) explanation I could find for understanding the basic mechanics of this process, at least when I started this journey. However, there’s a mistake in the explanation that left me confused for a little while, and I’m at a loss to contact the author (doesn’t anyone post a simple email address anymore ?).

  Per the best of my understanding, Emscripten allocates a large JS array and calls that the memory space that the compiled C/C++ code is allowed to operate in. A pointer in C/C++ code will just be an index into that mighty array. Really, that’s not too far off from how a low-level program process is supposed to view memory– as a flat array.

  Eventually, I just learned to cargo-cult my way through the memory allocation process. Here’s the JS code for allocating an Emscripten-compatible byte buffer, taken from my test harness (more on that later) :

  var musicBuffer = fs.readFileSync(testSpec[’filename’]) ;
  var musicBufferBytes = new Uint8Array(musicBuffer) ;
  var bytesMalloc = player._malloc(musicBufferBytes.length) ;
  var bytes = new Uint8Array(player.HEAPU8.buffer, bytesMalloc, musicBufferBytes.length) ;
  bytes.set(new Uint8Array(musicBufferBytes.buffer)) ;
  

  So, read the array of bytes from some input source, create a Uint8Array from the bytes, use the Emscripten _malloc() function to allocate enough bytes from the Emscripten memory array for the input bytes, then create a new array… then copy the bytes…

  You know what ? It’s late and I can’t remember how it works exactly, but it does. It has been a few months since I touched that code (been fighting with front-end website tech since then). You write that memory allocation code enough times and it begins to make sense, and then you hope you don’t have to write it too many more times.

  Multithreading
  You can’t port multithreaded code to JS via Emscripten. JavaScript has no notion of threads ! If you don’t understand the computer science behind this limitation, a more thorough explanation is beyond the scope of this post. But trust me, I’ve thought about it a lot. In fact, the official Emscripten literature states that you should be able to port most any C/C++ code as long as 1) none of the code is proprietary (i.e., all the raw source is available) ; and 2) there are no threads.

  Yes, I read about the experimental pthreads support added to Emscripten recently. Don’t get too excited ; that won’t be ready and widespread for a long time to come as it relies on a new browser API. In the meantime, figure out how to make your multithreaded C/C++ code run in a single thread if you want it to run in a browser.

  Printing Facility
  Eventually, getting software to work boils down to debugging, and the most primitive tool in many a programmer’s toolbox is the humble print statement. A print statement allows you to inspect a piece of a program’s state at key junctures. Eventually, when you try to cross-compile C/C++ code to JS using Emscripten, something is not going to work correctly in the generated JS “object code” and you need to understand what. You’ll be pleading for a method of just inspecting one variable deep in the original C/C++ code.

  I came up with this simple printf-workalike called emprintf() :

  #ifndef EMPRINTF_H
  #define EMPRINTF_H
  #include <stdio .h>
  
  #include <stdarg .h>
  
  #include <emscripten .h>
  #define MAX_MSG_LEN 1000
  /* NOTE : Don’t pass format strings that contain single quote (’) or newline
  
  * characters. */
  
  static void emprintf(const char *format, ...)
  
  
  
      char msg[MAX_MSG_LEN] ;
  
      char consoleMsg[MAX_MSG_LEN + 16] ;
  
      va_list args ;
  
      /* create the string */
  
      va_start(args, format) ;
  
      vsnprintf(msg, MAX_MSG_LEN, format, args) ;
  
      va_end(args) ;
      /* wrap the string in a console.log(’’) statement */
  
      snprintf(consoleMsg, MAX_MSG_LEN + 16, "console.log(’%s’)", msg) ;
      /* send the final string to the JavaScript console */
  
      emscripten_run_script(consoleMsg) ;
  
  
  #endif  /* EMPRINTF_H */
  

  Put it in a file called “emprint.h”. Include it into any C/C++ file where you need debugging visibility, use emprintf() as a replacement for printf() and the output will magically show up on the browser’s JavaScript debug console. Heed the comments and don’t put any single quotes or newlines in strings, and keep it under 1000 characters. I didn’t say it was perfect, but it has helped me a lot in my Emscripten adventures.

  Optimization Levels
  Remember to turn on optimization when compiling. I have empirically found that optimizing for size (-Os) leads to the best performance all around, in addition to having the smallest size. Just be sure to specify some optimization level. If you don’t, the default is -O0 which offers horrible performance when running in JS.

  Static Compression For HTTP Delivery
  JavaScript code compresses pretty efficiently, even after it has been optimized for size using -Os. I routinely see compression ratios between 3.5:1 and 5:1 using gzip.

  Web servers in this day and age are supposed to be smart enough to detect when a requesting web browser can accept gzip-compressed data and do the compression on the fly. They’re even supposed to be smart enough to cache compressed output so the same content is not recompressed for each request. I would have to set up a series of tests to establish whether either of the foregoing assertions are correct and I can’t be bothered. Instead, I took it into my own hands. The trick is to pre-compress the JS files and then instruct the webserver to serve these files with a ‘Content-Type’ of ‘application/javascript’ and a ‘Content-Encoding’ of ‘gzip’.

  1. Compress your large Emscripten-build JS files with ‘gzip’ : ‘gzip compiled-code.js’
  2. Rename them from extension .js.gz to .jsgz
  3. Tell the webserver to deliver .jsgz files with the correct Content-Type and Content-Encoding headers

  To do that last step with Apache, specify these lines :

  AddType application/javascript jsgz
  AddEncoding gzip jsgz
  

  They belong in either a directory’s .htaccess file or in the sitewide configuration (/etc/apache2/mods-available/mime.conf works on my setup).

  Build System and Build Time Optimization
  Oh goodie, build systems ! I had a very specific manner in which I wanted to build my JS modules using Emscripten. Can I possibly coerce any of the many popular build systems to do this ? It has been a few months since I worked on this problem specifically but I seem to recall that the build systems I tried to used would freak out at the prospect of compiling stuff to a final binary target of .js.

  I had high hopes for Bazel, which Google released while I was developing Cirrus Retro. Surely, this is software that has been battle-tested in the harshest conditions of one of the most prominent software-developing companies in the world, needing to take into account the most bizarre corner cases and still build efficiently and correctly every time. And I have little doubt that it fulfills the order. Similarly, I’m confident that Google also has a team of no fewer than 100 or so people dedicated to developing and supporting the project within the organization. When you only have, at best, 1-2 hours per night to work on projects like this, you prefer not to fight with such cutting edge technology and after losing 2 or 3 nights trying to make a go of Bazel, I eventually put it aside.

  I also tried to use Autotools. It failed horribly for me, mostly for my own carelessness and lack of early-project source control.

  After that, it was strictly vanilla makefiles with no real dependency management. But you know what helps in these cases ? ccache ! Or at least, it would if it didn’t fail with Emscripten.

  Quick tip : ccache has trouble with LLVM unless you set the CCACHE_CPP2 environment variable (e.g. : “export CCACHE_CPP2=1”). I don’t remember the specifics, but it magically fixes things. Then, the lazy build process becomes “make clean && make”.

  Testing
  If you have never used Node.js, testing Emscripten-compiled JS code might be a good opportunity to start. I was able to use Node.js to great effect for testing the individually-compiled music player modules, wiring up a series of invocations using Python for a broader test suite (wouldn’t want to go too deep down the JS rabbit hole, after all).

  Be advised that Node.js doesn’t enjoy the same kind of JIT optimizations that the browser engines leverage. Thus, in the case of time critical code like, say, an audio synthesis library, the code might not run in real time. But as long as it produces the correct bitwise waveform, that’s good enough for continuous integration.

  Also, if you have largely been a low-level programmer for your whole career and are generally unfamiliar with the world of single-threaded, event-driven, callback-oriented programming, you might be in for a bit of a shock. When I wanted to learn how to read the contents of a file in Node.js, this is the first tutorial I found on the matter. I thought the code presented was a parody of bad coding style :

  var fs = require("fs") ;
  var fileName = "foo.txt" ;
  fs.exists(fileName, function(exists) 
  
    if (exists) 
  
      fs.stat(fileName, function(error, stats) 
  
        fs.open(fileName, "r", function(error, fd) 
  
          var buffer = new Buffer(stats.size) ;
  
          fs.read(fd, buffer, 0, buffer.length, null, function(error, bytesRead, buffer) 
  
            var data = buffer.toString("utf8", 0, buffer.length) ;
  
            console.log(data) ;
  
            fs.close(fd) ;
  
          ) ;
  
        ) ;
  
      ) ;
  
    ) ;
  

  Apparently, this kind of thing doesn’t raise an eyebrow in the JS world.

  Now, I understand and respect the JS programming model. But this was seriously frustrating when I first encountered it because a simple script like the one I was trying to write just has an ordered list of tasks to complete. When it asks for bytes from a file, it really has nothing better to do than to wait for the answer.

  Thankfully, it turns out that Node’s fs module includes synchronous versions of the various file access functions. So it’s all good.

  Conclusion
  I’m sure I missed or underexplained some things. But if other brave souls are interested in dipping their toes in the waters of Emscripten, I hope these tips will come in handy.

• Revision a49d80bfc8 : Squash commits from master to playground Moving RD-opt related code from vp9_en

  26 juin 2014, par Yue Chen

  Changed Paths :
   Modify /build/make/gen_msvs_proj.sh

  
   Modify /build/make/gen_msvs_vcxproj.sh

  
   Modify /build/make/iosbuild.sh

  
   Modify /examples/vp9_spatial_svc_encoder.c

  
   Modify /test/decode_test_driver.cc

  
   Modify /test/decode_test_driver.h

  
   Add /test/invalid_file_test.cc

  
   Modify /test/svc_test.cc

  
   Modify /test/test-data.sha1

  
   Modify /test/test.mk

  
   Modify /test/test_vectors.cc

  
   Add /test/user_priv_test.cc

  
   Add /third_party/libmkv/EbmlIDs.h

  
   Add /third_party/libmkv/EbmlWriter.c

  
   Add /third_party/libmkv/EbmlWriter.h

  
   Modify /vp8/common/rtcd_defs.pl

  
   Modify /vp8/encoder/x86/quantize_sse2.c

  
   Delete /vp8/encoder/x86/quantize_sse4.asm

  
   Add /vp8/encoder/x86/quantize_sse4.c

  
   Modify /vp8/vp8cx.mk

  
   Modify /vp9/common/arm/neon/vp9_convolve_neon.c

  
   Modify /vp9/common/arm/neon/vp9_loopfilter_16_neon.c

  
   Modify /vp9/common/vp9_alloccommon.c

  
   Modify /vp9/common/vp9_alloccommon.h

  
   Modify /vp9/common/vp9_convolve.c

  
   Modify /vp9/common/vp9_mvref_common.c

  
   Modify /vp9/common/vp9_mvref_common.h

  
   Modify /vp9/common/vp9_quant_common.c

  
   Modify /vp9/common/vp9_quant_common.h

  
   Modify /vp9/common/vp9_scale.h

  
   Modify /vp9/decoder/vp9_decodeframe.c

  
   Modify /vp9/decoder/vp9_decoder.c

  
   Modify /vp9/decoder/vp9_dthread.h

  
   Modify /vp9/decoder/vp9_read_bit_buffer.c

  
   Modify /vp9/encoder/vp9_bitstream.c

  
   Modify /vp9/encoder/vp9_block.h

  
   Modify /vp9/encoder/vp9_denoiser.c

  
   Modify /vp9/encoder/vp9_denoiser.h

  
   Modify /vp9/encoder/vp9_encodeframe.c

  
   Modify /vp9/encoder/vp9_encoder.c

  
   Modify /vp9/encoder/vp9_encoder.h

  
   Modify /vp9/encoder/vp9_firstpass.c

  
   Modify /vp9/encoder/vp9_firstpass.h

  
   Modify /vp9/encoder/vp9_lookahead.c

  
   Modify /vp9/encoder/vp9_lookahead.h

  
   Modify /vp9/encoder/vp9_pickmode.c

  
   Modify /vp9/encoder/vp9_pickmode.h

  
   Modify /vp9/encoder/vp9_ratectrl.c

  
   Modify /vp9/encoder/vp9_ratectrl.h

  
   Modify /vp9/encoder/vp9_rdopt.c

  
   Modify /vp9/encoder/vp9_rdopt.h

  
   Modify /vp9/encoder/vp9_speed_features.c

  
   Modify /vp9/encoder/vp9_speed_features.h

  
   Modify /vp9/encoder/vp9_svc_layercontext.c

  
   Modify /vp9/encoder/vp9_svc_layercontext.h

  
   Modify /vp9/vp9_cx_iface.c

  
   Modify /vp9/vp9_dx_iface.c

  
   Modify /vp9/vp9cx.mk

  
   Modify /vpx/src/svc_encodeframe.c

  
   Modify /vpx/svc_context.h

  
  
  Squash commits from master to playground

  Moving RD-opt related code from vp9_encoder.h to vp9_rdopt.h.

  Squashed-Change-Id : I8fab776c8801e19d3f5027ed55a6aa69eee951de

  gen_msvs_proj : fix in tree configure under cygwin

  strip trailing ’/’ from paths, this is later converted to ’\’ which
  causes execution errors for obj_int_extract/yasm. vs10+ wasn’t affected
  by this issue, but make the same change for consistency.

  gen_msvs_proj :
  + add missing ’"’ to obj_int_extract call
  unlike gen_msvs_vcproj, the block is duplicated
  missed in : 1e3d9b9 build/msvs : fix builds in source dirs with spaces

  Squashed-Change-Id : I76208e6cdc66dc5a0a7ffa8aa1edbefe31e4b130

  Improve vp9_rb_bytes_read

  Squashed-Change-Id : I69eba120eb3d8ec43b5552451c8a9bd009390795

  Removing decode_one_iter() function.

  When superframe index is available we completely rely on it and use frame
  size values from the index.

  Squashed-Change-Id : I0011d08b223303a8b912c2bcc8a02b74d0426ee0

  iosbuild.sh : Add vpx_config.h and vpx_version.h to VPX.framework.

   Rename build_targets to build_framework
   Add functions for creating the vpx_config shim and obtaining
  preproc symbols.

  Squashed-Change-Id : Ieca6938b9779077eefa26bf4cfee64286d1840b0

  Implemented vp9_denoiser_alloc,free()

  Squashed-Change-Id : I79eba79f7c52eec19ef2356278597e06620d5e27

  Update running avg for VP9 denoiser

  Squashed-Change-Id : I9577d648542064052795bf5770428fbd5c276b7b

  Changed buf_2ds in vp9 denoiser to YV12 buffers

  Changed alloc, free, and running average code as necessary.

  Squashed-Change-Id : Ifc4d9ccca462164214019963b3768a457791b9c1

  sse4 regular quantize

  Squashed-Change-Id : Ibd95df0adf9cc9143006ee9032b4cb2ebfd5dd1b

  Modify non-rd intra mode checking

  Speed 6 uses small tx size, namely 8x8. max_intra_bsize needs to
  be modified accordingly to ensure valid intra mode checking.
  Borg test on RTC set showed an overall PSNR gain of 0.335% in speed
   6.

  This also changes speed -5 encoding by allowing DC_PRED checking
  for block32x32. Borg test on RTC set showed a slight PSNR gain of
  0.145%, and no noticeable speed change.

  Squashed-Change-Id : I1502978d8fbe265b3bb235db0f9c35ba0703cd45

  Implemented COPY_BLOCK case for vp9 denoiser

  Squashed-Change-Id : Ie89ad1e3aebbd474e1a0db69c1961b4d1ddcd33e

  Improved vp9 denoiser running avg update.

  Squashed-Change-Id : Ie0aa41fb7957755544321897b3bb2dd92f392027

  Separate rate-distortion modeling for DC and AC coefficients

  This is the first step to rework the rate-distortion modeling used
  in rtc coding mode. The overall goal is to make the modeling
  customized for the statistics encountered in the rtc coding.

  This commit makes encoder to perform rate-distortion modeling for
  DC and AC coefficients separately. No speed changes observed.
  The coding performance for pedestrian_area_1080p is largely
  improved :

  speed -5, from 79558 b/f, 37.871 dB -> 79598 b/f, 38.600 dB
  speed -6, from 79515 b/f, 37.822 dB -> 79544 b/f, 38.130 dB

  Overall performance for rtc set at speed -6 is improved by 0.67%.

  Squashed-Change-Id : I9153444567e5f75ccdcaac043c2365992c005c0c

  Add superframe support for frame parallel decoding.

  A superframe is a bunch of frames that bundled as one frame. It is mostly
  used to combine one or more non-displayable frames and one displayable frame.

  For frame parallel decoding, libvpx decoder will only support decoding one
  normal frame or a super frame with superframe index.

  If an application pass a superframe without superframe index or a chunk
  of displayable frames without superframe index to libvpx decoder, libvpx
  will not decode it in frame parallel mode. But libvpx decoder still could
  decode it in serial mode.

  Squashed-Change-Id : I04c9f2c828373d64e880a8c7bcade5307015ce35

  Fixes in VP9 alloc, free, and COPY_FRAME case

  Squashed-Change-Id : I1216f17e2206ef521fe219b6d72d8e41d1ba1147

  Remove labels from quantize

  Use break instead of goto for early exit. Unbreaks Visual Studio
  builds.

  Squashed-Change-Id : I96dee43a3c82145d4abe0d6a99af6e6e1a3991b5

  Added CFLAG for outputting vp9 denoised signal

  Squashed-Change-Id : Iab9b4e11cad927f3282e486c203564e1a658f377

  Allow key frame more flexibility in mode search

  This commit allows the key frame to search through more prediction
  modes and more flexible block sizes. No speed change observed. The
  coding performance for rtc set is improved by 1.7% for speed -5 and
  3.0% for speed -6.

  Squashed-Change-Id : Ifd1bc28558017851b210b4004f2d80838938bcc5

  VP9 denoiser bugfixes

  s/stdint.h/vpx\/vpx_int.h

  Added missing ’break ;’s

  Also included other minor changes, mostly cosmetic.

  Squashed-Change-Id : I852bba3e85e794f1d4af854c45c16a23a787e6a3

  Don’t return value for void functions

  Clears "warning : ’return’ with a value, in function returning void"

  Squashed-Change-Id : I93972610d67e243ec772a1021d2fdfcfc689c8c2

  Include type defines

  Clears error : unknown type name ’uint8_t’

  Squashed-Change-Id : I9b6eff66a5c69bc24aeaeb5ade29255a164ef0e2

  Validate error checking code in decoder.

  This patch adds a mechanism for insuring error checking on invalid files
  by creating a unit test that runs the decoder and tests that the error
  code matches what’s expected on each frame in the decoder.

  Disabled for now as this unit test will segfault with existing code.

  Squashed-Change-Id : I896f9686d9ebcbf027426933adfbea7b8c5d956e

  Introduce FrameWorker for decoding.

  When decoding in serial mode, there will be only
  one FrameWorker doing decoding. When decoding in
  parallel mode, there will be several FrameWorkers
  doing decoding in parallel.

  Squashed-Change-Id : If53fc5c49c7a0bf5e773f1ce7008b8a62fdae257

  Add back libmkv ebml writer files.

  Another project in ChromeOS is using these files. To make libvpx
  rolls simpler, add these files back unitl the other project removes
  the dependency.

  crbug.com/387246 tracking bug to remove dependency.

  Squashed-Change-Id : If9c197081c845c4a4e5c5488d4e0190380bcb1e4

  Added Test vector that tests more show existing frames.

  Squashed-Change-Id : I0ddd7dd55313ee62d231ed4b9040e08c3761b3fe

  fix peek_si to enable 1 byte show existing frames.

  The test for this is in test vector code ( show existing frames will
  fail ). I can’t check it in disabled as I’m changing the generic
  test code to do this :

  https://gerrit.chromium.org/gerrit/#/c/70569/

  Squashed-Change-Id : I5ab324f0cb7df06316a949af0f7fc089f4a3d466

  Fix bug in error handling that causes segfault

  See : https://code.google.com/p/chromium/issues/detail?id=362697

  The code properly catches an invalid stream but seg faults instead of
  returning an error due to a buffer not having been initialized. This
  code fixes that.

  Squashed-Change-Id : I695595e742cb08807e1dfb2f00bc097b3eae3a9b

  Revert 3 patches from Hangyu to get Chrome to build :

  Avoids failures :
  MSE_ClearKey/EncryptedMediaTest.Playback_VP9Video_WebM/0
  MSE_ClearKey_Prefixed/EncryptedMediaTest.Playback_VP9Video_WebM/0
  MSE_ExternalClearKey_Prefixed/EncryptedMediaTest.Playback_VP9Video_WebM/0
  MSE_ExternalClearKey/EncryptedMediaTest.Playback_VP9Video_WebM/0
  MSE_ExternalClearKeyDecryptOnly/EncryptedMediaTest.Playback_VP9Video_WebM/0
  MSE_ExternalClearKeyDecryptOnly_Prefixed/EncryptedMediaTest.Playback_VP9Video_We
  bM/0
  SRC_ExternalClearKey/EncryptedMediaTest.Playback_VP9Video_WebM/0
  SRC_ExternalClearKey_Prefixed/EncryptedMediaTest.Playback_VP9Video_WebM/0
  SRC_ClearKey_Prefixed/EncryptedMediaTest.Playback_VP9Video_WebM/0

  Patches are
  This reverts commit 9bc040859b0ca6869d31bc0efa223e8684eef37a
  This reverts commit 6f5aba069a2c7ffb293ddce70219a9ab4a037441
  This reverts commit 9bc040859b0ca6869d31bc0efa223e8684eef37a

  I1f250441 Revert "Refactor the vp9_get_frame code for frame parallel."
  Ibfdddce5 Revert "Delay decreasing reference count in frame-parallel
  decoding."
  I00ce6771 Revert "Introduce FrameWorker for decoding."

  Need better testing in libvpx for these commits

  Squashed-Change-Id : Ifa1f279b0cabf4b47c051ec26018f9301c1e130e

  error check vp9 superframe parsing

  This patch insures that the last byte of a chunk that contains a
  valid superframe marker byte, actually has a proper superframe index.
  If not it returns an error.

  As part of doing that the file : vp90-2-15-fuzz-flicker.webm now fails
  to decode properly and moves to the invalid file test from the test
  vector suite.

  Squashed-Change-Id : I5f1da7eb37282ec0c6394df5c73251a2df9c1744

  Remove unused vp9_init_quant_tables function

  This function is not effectively used, hence removed.

  Squashed-Change-Id : I2e8e48fa07c7518931690f3b04bae920cb360e49

  Actually skip blocks in skip segments in non-rd encoder.

  Copy split from macroblock to pick mode context so it doesn’t get lost.

  Squashed-Change-Id : Ie37aa12558dbe65c4f8076cf808250fffb7f27a8

  Add Check for Peek Stream validity to decoder test.

  Squashed-Change-Id : I9b745670a9f842582c47e6001dc77480b31fb6a1

  Allocate buffers based on correct chroma format

  The encoder currently allocates frame buffers before
  it establishes what the chroma sub-sampling factor is,
  always allocating based on the 4:4:4 format.

  This patch detects the chroma format as early as
  possible allowing the encoder to allocate buffers of
  the correct size.

  Future patches will change the encoder to allocate
  frame buffers on demand to further reduce the memory
  profile of the encoder and rationalize the buffer
  management in the encoder and decoder.

  Squashed-Change-Id : Ifd41dd96e67d0011719ba40fada0bae74f3a0d57

  Fork vp9_rd_pick_inter_mode_sb_seg_skip

  Squashed-Change-Id : I549868725b789f0f4f89828005a65972c20df888

  Switch active map implementation to segment based.

  Squashed-Change-Id : Ibb841a1fa4d08d164cf5461246ec290f582b1f80

  Experiment for mid group second arf.

  This patch implements a mechanism for inserting a second
  arf at the mid position of arf groups.

  It is currently disabled by default using the flag multi_arf_enabled.

  Results are currently down somewhat in initial testing if
  multi-arf is enabled. Most of the loss is attributable to the
  fact that code to preserve the previous golden frame
  (in the arf buffer) in cases where we are coding an overlay
  frame, is currently disabled in the multi-arf case.

  Squashed-Change-Id : I1d777318ca09f147db2e8c86d7315fe86168c865

  Clean out old CONFIG_MULTIPLE_ARF code.

  Remove the old experimental multi arf code that was under
  the flag CONFIG_MULTIPLE_ARF.

  Squashed-Change-Id : Ib24865abc11691d6ac8cb0434ada1da674368a61

  Fix some bugs in multi-arf

  Fix some bugs relating to the use of buffers
  in the overlay frames.

  Fix bug where a mid sequence overlay was
  propagating large partition and transform sizes into
  the subsequent frame because of :-
  sf->last_partitioning_redo_frequency > 1 and
  sf->tx_size_search_method == USE_LARGESTALL

  Squashed-Change-Id : Ibf9ef39a5a5150f8cbdd2c9275abb0316c67873a

  Further dual arf changes : multi_arf_allowed.

  Add multi_arf_allowed flag.
  Re-initialize buffer indices every kf.
  Add some const indicators.

  Squashed-Change-Id : If86c39153517c427182691d2d4d4b7e90594be71

  Fixed VP9 denoiser COPY_BLOCK case

  Now copies the src to the correct location in the running average buffer.

  Squashed-Change-Id : I9c83c96dc7a97f42c8df16ab4a9f18b733181f34

  Fix test on maximum downscaling limits

  There is a normative scaling range of (x1/2, x16)
  for VP9. This patch fixes the maximum downscaling
  tests that are applied in the convolve function.

  The code used a maximum downscaling limit of x1/5
  for historic reasons related to the scalable
  coding work. Since the downsampling in this
  application is non-normative it will revert to
  using a separate non-normative scaler.

  Squashed-Change-Id : Ide80ed712cee82fe5cb3c55076ac428295a6019f

  Add unit test to test user_priv parameter.

  Squashed-Change-Id : I6ba6171e43e0a43331ee0a7b698590b143979c44

  vp9 : check tile column count

  the max is 6. there are assumptions throughout the decode regarding
  this ; fixes a crash with a fuzzed bitstream

  $ zzuf -s 5861 -r 0.01:0.05 -b 6- \
  < vp90-2-00-quantizer-00.webm.ivf \
  | dd of=invalid-vp90-2-00-quantizer-00.webm.ivf.s5861_r01-05_b6-.ivf \
  bs=1 count=81883

  Squashed-Change-Id : I6af41bb34252e88bc156a4c27c80d505d45f5642

  Adjust arf Q limits with multi-arf.

  Adjust enforced minimum arf Q deltas for non primary arfs
  in the middle of an arf/gf group.

  Squashed-Change-Id : Ie8034ffb3ac00f887d74ae1586d4cac91d6cace2

  Dual ARF changes : Buffer index selection.

  Add indirection to the section of buffer indices.
  This is to help simplify things in the future if we
  have other codec features that switch indices.

  Limit the max GF interval for static sections to fit
  the gf_group structures.

  Squashed-Change-Id : I38310daaf23fd906004c0e8ee3e99e15570f84cb

  Reuse inter prediction result in real-time speed 6

  In real-time speed 6, no partition search is done. The inter
  prediction results got from picking mode can be reused in the
  following encoding process. A speed feature reuse_inter_pred_sby
  is added to only enable the resue in speed 6.

  This patch doesn’t change encoding result. RTC set tests showed
  that the encoding speed gain is 2% - 5%.

  Squashed-Change-Id : I3884780f64ef95dd8be10562926542528713b92c

  Add vp9_ prefix to mv_pred and setup_pred_block functions

  Make these two functions accessible by both RD and non-RD coding
  modes.

  Squashed-Change-Id : Iecb39dbf3d65436286ea3c7ffaa9920d0b3aff85

  Replace cpi->common with preset variable cm

  This commit replaces a few use cases of cpi->common with preset
  variable cm, to avoid unnecessary pointer fetch in the non-RD
  coding mode.

  Squashed-Change-Id : I4038f1c1a47373b8fd7bc5d69af61346103702f6

  [spatial svc]Implement lag in frames for spatial svc

  Squashed-Change-Id : I930dced169c9d53f8044d2754a04332138347409

  [spatial svc]Don’t skip motion search in first pass encoding

  Squashed-Change-Id : Ia6bcdaf5a5b80e68176f60d8d00e9b5cf3f9bfe3

  decode_test_driver : fix type size warning

  like vpx_codec_decode(), vpx_codec_peek_stream_info() takes an unsigned
  int, not size_t, parameter for buffer size

  Squashed-Change-Id : I4ce0e1fbbde461c2e1b8fcbaac3cd203ed707460

  decode_test_driver : check HasFailure() in RunLoop

  avoids unnecessary errors due to e.g., read (Next()) failures

  Squashed-Change-Id : I70b1d09766456f1c55367d98299b5abd7afff842

  Allow lossless breakout in non-rd mode decision.

  This is very helpful for large moving windows in screencasts.

  Squashed-Change-Id : I91b5f9acb133281ee85ccd8f843e6bae5cadefca

  Revert "Revert 3 patches from Hangyu to get Chrome to build :"

  This patch reverts the previous revert from Jim and also add a
  variable user_priv in the FrameWorker to save the user_priv
  passed from the application. In the decoder_get_frame function,
  the user_priv will be binded with the img. This change is needed
  or it will fail the unit test added here :
  https://gerrit.chromium.org/gerrit/#/c/70610/

  This reverts commit 9be46e4565f553460a1bbbf58d9f99067d3242ce.

  Squashed-Change-Id : I376d9a12ee196faffdf3c792b59e6137c56132c1

  test.mk : remove renamed file

  vp90-2-15-fuzz-flicker.webm was renamed in :
  c3db2d8 error check vp9 superframe parsing

  Squashed-Change-Id : I229dd6ca4c662802c457beea0f7b4128153a65dc

  vp9cx.mk : move avx c files outside of x86inc block

  same reasoning as :
  9f3a0db vp9_rtcd : correct avx2 references

  these are all intrinsics, so don’t depend on x86inc.asm

  Squashed-Change-Id : I915beaef318a28f64bfa5469e5efe90e4af5b827

  Dual arf : Name changes.

  Cosmetic patch only in response to comments on
  previous patches suggesting a couple of name changes
  for consistency and clarity.

  Squashed-Change-Id : Ida3a359b0d5755345660d304a7697a3a3686b2a3

  Make non-RD intra mode search txfm size dependent

  This commit fixes the potential issue in the non-RD mode decision
  flow that only checks part of the block to estimate the cost. It
  was due to the use of fixed transform size, in replacing the
  largest transform block size. This commit enables per transform
  block cost estimation of the intra prediction mode in the non-RD
  mode decision.

  Squashed-Change-Id : I14ff92065e193e3e731c2bbf7ec89db676f1e132

  Fix quality regression for multi arf off case.

  Bug introduced during multiple iterations on : I3831*

  gf_group->arf_update_idx[] cannot currently be used
  to select the arf buffer index if buffer flipping on overlays
  is enabled (still currently the case when multi arf OFF).

  Squashed-Change-Id : I4ce9ea08f1dd03ac3ad8b3e27375a91ee1d964dc

  Enable real-time version reference motion vector search

  This commit enables a fast reference motion vector search scheme.
  It checks the nearest top and left neighboring blocks to decide the
  most probable predicted motion vector. If it finds the two have
  the same motion vectors, it then skip finding exterior range for
  the second most probable motion vector, and correspondingly skips
  the check for NEARMV.

  The runtime of speed -5 goes down
  pedestrian at 1080p 29377 ms -> 27783 ms
  vidyo at 720p 11830 ms -> 10990 ms
  i.e., 6%-8% speed-up.

  For rtc set, the compression performance
  goes down by about -1.3% for both speed -5 and -6.

  Squashed-Change-Id : I2a7794fa99734f739f8b30519ad4dfd511ab91a5

  Add const mark to const values in non-RD coding mode

  Squashed-Change-Id : I65209fd1e06fc06833f6647cb028b414391a7017

  Change-Id : Ic0be67ac9ef48f64a8878a0b8f1b336f136bceac