1. 16 Aug, 2012 7 commits
  2. 15 Aug, 2012 7 commits
  3. 14 Aug, 2012 13 commits
  4. 13 Aug, 2012 13 commits
    • Martin Storsjö's avatar
      0af85d57
    • Boris Maksalov's avatar
      proresenc: use the edge emulation buffer · cee03436
      Boris Maksalov authored
      
      
      Prevents reading past the end of frame buffer.
      Signed-off-by: default avatarLuca Barbato <lu_zero@gentoo.org>
      cee03436
    • Luca Barbato's avatar
      rtmp: handle bytes read reports · fb96c1c5
      Luca Barbato authored
      0x03 (bytes read report) is a known type and should be safely ignored
      beside in debug situations.
      fb96c1c5
    • Diego Biurrun's avatar
    • Mans Rullgard's avatar
      Use log2(x) instead of log(x) / log(2) · d752509b
      Mans Rullgard authored
      
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      d752509b
    • Mans Rullgard's avatar
      x86: swscale: fix fragile memory accesses · 90540c2d
      Mans Rullgard authored
      
      
      To access data at multiple fixed offsets from a base address, this
      code uses a single "m" operand and code of the form "32%0", relying on
      the memory operand instantiation having no displacement, giving a final
      result of the form "32(%rax)".  If the compiler uses a register and
      displacement, e.g. "64(%rax)", the end result becomes "3264(%rax)",
      which obviously does not work.
      
      Replacing the "m" operands with "r" operands allows safe addition of a
      displacement.  In theory, multiple memory operands could use a shared
      base register with different index registers, "(%rax,%rbx)", potentially
      making more efficient use of registers.  In the cases at hand, no such
      sharing is possible since the addresses involved are entirely unrelated.
      
      After this change, the code somewhat rudely accesses memory without
      using a corresponding memory operand, which in some cases can lead to
      unwanted "optimisations" of surrounding code.  However, the original
      code also accesses memory not covered by a memory operand, so this is
      not adding any defect not already present.  It is also hightly unlikely
      that any such optimisations could be performed here since the memory
      locations in questions are not accessed elsewhere in the same functions.
      
      This fixes crashes with suncc.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      90540c2d
    • Mans Rullgard's avatar
      x86: swscale: remove disabled code · 10b83cb6
      Mans Rullgard authored
      
      
      This code has been disabled since 2003.  Nobody will ever look at
      it again.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      10b83cb6
    • Mans Rullgard's avatar
      x86: yadif: fix asm with suncc · 480178a2
      Mans Rullgard authored
      
      
      Under some circumstances, suncc will use a single register for the
      address of all memory operands, inserting lea instructions loading
      the correct address prior to each memory operand being used in the
      code. In the yadif code, the branch in the asm block bypasses such
      an lea instruction, causing an incorrect address to be used in the
      following load.
      
      This patch replaces the tmpX arrays with a single array and uses a
      register operand to hold its address. Although this prevents using
      offsets from the stack pointer to access these locations, the code
      still builds as 32-bit PIC even with old compilers.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      480178a2
    • Mans Rullgard's avatar
      x86: cabac: allow building with suncc · 8ec0204e
      Mans Rullgard authored
      
      
      This fixes two issues preventing suncc from building this code.
      
      The undocumented 'a' operand modifier, causing gcc to omit a $ in
      front of immediate operands (as required in addresses), is not
      supported by suncc.  Luckily, the also undocumented 'c' modifer
      has the same effect and is supported.
      
      On some asm statements with a large number of operands, suncc for no
      obvious reason fails to correctly substitute some of the operands.
      Fortunately, some of the operands in these statements are plain
      numbers which can be inserted directly into the code block instead
      of passed as operands.
      
      With these changes, the code builds correctly with both gcc and
      suncc.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      8ec0204e
    • Mans Rullgard's avatar
      x86: mlpdsp: avoid taking address of void · c8252e80
      Mans Rullgard authored
      
      
      This code contains a C array of addresses of labels defined in
      inline asm.  To do this, the names must be declared as external
      in C.  The declared type does not matter since only the address is
      used, and for some reason, the author of the code used the 'void'
      type despite taking the address of a void expression being invalid.
      
      Changing the type to char, a reasonable choice since the alignment
      of the code labels cannot be known or guaranteed, eliminates gcc
      warnings and allows building with suncc.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      c8252e80
    • Mans Rullgard's avatar
      ARM: intmath: use native-size return types for clipping functions · 87fa05a0
      Mans Rullgard authored
      
      
      This avoids having the compiler redundantly mask the values to
      the smaller size.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      87fa05a0
    • Mans Rullgard's avatar
      g723.1: do not pass large structs by value · 69665bd6
      Mans Rullgard authored
      
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      69665bd6
    • Mans Rullgard's avatar
      g723.1: do not bounce intermediate values via memory · 138914dc
      Mans Rullgard authored
      
      
      Although a reasonable compiler will probably optimise out the
      actual store and load, this operation still implies a truncation
      to 16 bits which the compiler will probably not realise is not
      necessary here.
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      138914dc