1. 04 Mar, 2011 1 commit
  2. 17 Feb, 2011 1 commit
    • James Zern's avatar
      documentation: minor cosmetics · f42d52e6
      James Zern authored
      - correct spelling
      - remove explicit file name w/\file (unnecessary when contained in the
        same file and prone to desync)
      
      Change-Id: I68a3960ac5ab84d0f2e5c9b2e29799f26dfccf23
      f42d52e6
  3. 10 Nov, 2010 1 commit
    • Fritz Koenig's avatar
      postproc : Re-work posproc calling to allow more flags. · 647df00f
      Fritz Koenig authored
      Debugging in postproc needs more flags to allow for specific
      block types to be turned on or off in the visualizations.
      
      Must be enabled with --enable-postproc-visualizer during
      configuration time.
      
      Change-Id: Ia74f357ddc3ad4fb8082afd3a64f62384e4fcb2d
      647df00f
  4. 28 Oct, 2010 2 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
    • 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
  5. 09 Sep, 2010 1 commit
  6. 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
  7. 04 Jun, 2010 1 commit
  8. 25 May, 2010 1 commit
    • John Koleszar's avatar
      install includes in DIST_DIR/include/vpx, move vpx_codec/ to vpx/ · b7492341
      John Koleszar authored
      This renames the vpx_codec/ directory to vpx/, to allow applications
      to more consistently reference these includes with the vpx/ prefix.
      This allows the includes to be installed in /usr/local/include/vpx
      rather than polluting the system includes directory with an
      excessive number of includes.
      
      Change-Id: I7b0652a20543d93f38f421c60b0bbccde4d61b4f
      b7492341
  9. 18 May, 2010 1 commit