1. 31 Mar, 2011 1 commit
    • Attila Nagy's avatar
      Runtime detection of available processor cores. · 297b2765
      Attila Nagy authored
      Detect the number of available cores and limit the thread allocation
      accordingly. On decoder side limit the number of threads to the max
      number of token partition.
      
      Core detetction works on Windows and
      Posix platforms, which define _SC_NPROCESSORS_ONLN or _SC_NPROC_ONLN.
      
      Change-Id: I76cbe37c18d3b8035e508b7a1795577674efc078
      297b2765
  2. 11 Mar, 2011 1 commit
  3. 10 Feb, 2011 1 commit
    • John Koleszar's avatar
      Fix relative include paths · 02321de0
      John Koleszar authored
      Allow compiling without adding vp8/{common,encoder,decoder} to the
      include paths.
      
      Change-Id: Ifeb5dac351cdfadcd659736f5158b315a0030b6c
      02321de0
  4. 04 Nov, 2010 1 commit
    • Fritz Koenig's avatar
      postproc : Update visualizations. · 0e7b6061
      Fritz Koenig authored
      Change color reference frame to blend the macro block edge.
      This helps with layering of visualizations.
      
      Add block coloring for intra prediction modes.
      
      Change-Id: Icefe0e189e26719cd6937cebd6727efac0b4d278
      0e7b6061
  5. 28 Oct, 2010 3 commits
    • Timothy B. Terriberry's avatar
      Eliminate more warnings. · 97b766a4
      Timothy B. Terriberry authored
      This eliminates a large set of warnings exposed by the Mozilla build
       system (Use of C++ comments in ISO C90 source, commas at the end of
       enum lists, a couple incomplete initializers, and signed/unsigned
       comparisons).
      It also eliminates many (but not all) of the warnings expose by newer
       GCC versions and _FORTIFY_SOURCE (e.g., calling fread and fwrite
       without checking the return values).
      There are a few spurious warnings left on my system:
      
      ../vp8/encoder/encodemb.c:274:9: warning: 'sz' may be used
       uninitialized in this function
      gcc seems to be unable to figure out that the value shortcut doesn't
       change between the two if blocks that test it here.
      
      ../vp8/encoder/onyx_if.c:5314:5: warning: comparison of unsigned
       expression >= 0 is always true
      ../vp8/encoder/onyx_if.c:5319:5: warning: comparison of unsigned
       expression >= 0 is always true
      This is true, so far as it goes, but it's comparing against an enum,
       and the C standard does not mandate that enums be unsigned, so the
       checks can't be removed.
      
      Change-Id: Iead6cd561a2afaa3d801fd63f1d8d58953da7426
      97b766a4
    • Fritz Koenig's avatar
      postproc: Tweaks to line drawing and blending. · 6fda7668
      Fritz Koenig authored
      Turned down the blending level to make colored blocks obscure
      the video less.
      Not blending the entire block to give distinction to macro
      block edges.
      Added configuration so that macro block blending function can
      be optimized.
      Change to constrain line as to when dx and dy are computed.
      Now draw two lines to form an arrow.
      
      Change-Id: I986784e6abff65ea3e0d1437dfca7d06d44ede71
      6fda7668
    • Timothy B. Terriberry's avatar
      Eliminate more warnings. · c4d7e5e6
      Timothy B. Terriberry authored
      This eliminates a large set of warnings exposed by the Mozilla build
       system (Use of C++ comments in ISO C90 source, commas at the end of
       enum lists, a couple incomplete initializers, and signed/unsigned
       comparisons).
      It also eliminates many (but not all) of the warnings expose by newer
       GCC versions and _FORTIFY_SOURCE (e.g., calling fread and fwrite
       without checking the return values).
      There are a few spurious warnings left on my system:
      
      ../vp8/encoder/encodemb.c:274:9: warning: 'sz' may be used
       uninitialized in this function
      gcc seems to be unable to figure out that the value shortcut doesn't
       change between the two if blocks that test it here.
      
      ../vp8/encoder/onyx_if.c:5314:5: warning: comparison of unsigned
       expression >= 0 is always true
      ../vp8/encoder/onyx_if.c:5319:5: warning: comparison of unsigned
       expression >= 0 is always true
      This is true, so far as it goes, but it's comparing against an enum, and the C
       standard does not mandate that enums be unsigned, so the checks can't be
       removed.
      
      Change-Id: Iaf689ae3e3d0ddc5ade00faa474debe73b8d3395
      c4d7e5e6
  6. 27 Oct, 2010 1 commit
    • Fritz Koenig's avatar
      postproc: Tweaks to line drawing and blending. · a097e189
      Fritz Koenig authored
      Turned down the blending level to make colored blocks obscure
      the video less.
      Not blending the entire block to give distinction to macro
      block edges.
      Added configuration so that macro block blending function can
      be optimized.
      Change to constrain line as to when dx and dy are computed.
      Now draw two lines to form an arrow.
      
      Change-Id: Id3ef0fdeeab2949a6664b2c63e2a3e1a89503f6c
      a097e189
  7. 26 Oct, 2010 1 commit
    • John Koleszar's avatar
      make vp8_recon16x16mb{,y} RTCD functions · d6c67f02
      John Koleszar authored
      ARM NEON has a platform specific version of vp8_recon16x16mb, though
      it's just a stub to extract the various parameters from the
      MACROBLOCKD struct and pass them to vp8_recon16x16mb_neon(). Using
      that function's prototype directly will be a better long term solution,
      but it's quite an invasive change.
      
      Change-Id: I04273149e2ade34749e2d09e7edb0c396e1dd620
      d6c67f02
  8. 25 Oct, 2010 1 commit
    • Timothy B. Terriberry's avatar
      Add runtime CPU detection support for ARM. · b71962fd
      Timothy B. Terriberry authored
      The primary goal is to allow a binary to be built which supports
       NEON, but can fall back to non-NEON routines, since some Android
       devices do not have NEON, even if they are otherwise ARMv7 (e.g.,
       Tegra).
      The configure-generated flags HAVE_ARMV7, etc., are used to decide
       which versions of each function to build, and when
       CONFIG_RUNTIME_CPU_DETECT is enabled, the correct version is chosen
       at run time.
      In order for this to work, the CFLAGS must be set to something
       appropriate (e.g., without -mfpu=neon for ARMv7, and with
       appropriate -march and -mcpu for even earlier configurations), or
       the native C code will not be able to run.
      The ASFLAGS must remain set for the most advanced instruction set
       required at build time, since the ARM assembler will refuse to emit
       them otherwise.
      I have not attempted to make any changes to configure to do this
       automatically.
      Doing so will probably require the addition of new configure options.
      
      Many of the hooks for RTCD on ARM were already there, but a lot of
       the code had bit-rotted, and a good deal of the ARM-specific code
       is not integrated into the RTCD structs at all.
      I did not try to resolve the latter, merely to add the minimal amount
       of protection around them to allow RTCD to work.
      Those functions that were called based on an ifdef at the calling
       site were expanded to check the RTCD flags at that site, but they
       should be added to an RTCD struct somewhere in the future.
      The functions invoked with global function pointers still are, but
       these should be moved into an RTCD struct for thread safety (I
       believe every platform currently supported has atomic pointer
       stores, but this is not guaranteed).
      
      The encoder's boolhuff functions did not even have _c and armv7
       suffixes, and the correct version was resolved at link time.
      The token packing functions did have appropriate suffixes, but the
       version was selected with a define, with no associated RTCD struct.
      However, for both of these, the only armv7 instruction they actually
       used was rbit, and this was completely superfluous, so I reworked
       them to avoid it.
      The only non-ARMv4 instruction remaining in them is clz, which is
       ARMv5 (not even ARMv5TE is required).
      Considering that there are no ARM-specific configs which are not at
       least ARMv5TE, I did not try to detect these at runtime, and simply
       enable them for ARMv5 and above.
      
      Finally, the NEON register saving code was completely non-reentrant,
       since it saved the registers to a global, static variable.
      I moved the storage for this onto the stack.
      A single binary built with this code was tested on an ARM11 (ARMv6)
       and a Cortex A8 (ARMv7 w/NEON), for both the encoder and decoder,
       and produced identical output, while using the correct accelerated
       functions on each.
      I did not test on any earlier processors.
      
      Change-Id: I45cbd63a614f4554c3b325c45d46c0806f009eaa
      b71962fd
  9. 09 Sep, 2010 1 commit
  10. 02 Sep, 2010 1 commit
    • James Zern's avatar
      encoder: remove postproc dependency · 76640f85
      James Zern authored
      Remove the dependency on postproc.c for the encoder in general, the only
      unchecked need for it is when CONFIG_PSNR is enabled. All other cases
      are already wrapped in CONFIG_POSTPROC. In the CONFIG_PSNR case the file
      will still be included.
      
      Additionally, when VP8_SET_POSTPROC is used with the encoder when post
      processing has been disabled an error will be returned.
      
      This addresses issue #153.
      
      Change-Id: Ia6dfe20167f7077734a6058cbd1d794550346089
      76640f85
  11. 23 Jul, 2010 1 commit
    • Jeff Muizelaar's avatar
      Combine idct and reconstruction steps · b2fa74ac
      Jeff Muizelaar authored
      This moves the prediction step before the idct and combines the idct and
      reconstruction steps into a single step. Combining them seems to give an
      overall decoder performance improvement of about 1%.
      
      Change-Id: I90d8b167ec70d79c7ba2ee484106a78b3d16e318
      b2fa74ac
  12. 18 Jun, 2010 1 commit
    • John Koleszar's avatar
      cosmetics: trim trailing whitespace · 94c52e4d
      John Koleszar authored
      When the license headers were updated, they accidentally contained
      trailing whitespace, so unfortunately we have to touch all the files
      again.
      
      Change-Id: I236c05fade06589e417179c0444cb39b09e4200d
      94c52e4d
  13. 04 Jun, 2010 1 commit
  14. 18 May, 2010 1 commit