1. 03 Jul, 2012 10 commits
    • Diego Biurrun's avatar
      misc typo and wording fixes · 09f21198
      Diego Biurrun authored
      09f21198
    • Reinhard Tartler's avatar
      attributes: add av_noreturn · 22662ca5
      Reinhard Tartler authored
      Also use it in the declaration of the various exit_program
      implementations in avtools.
      
      inspired by a clang-scan report.
      22662ca5
    • Reinhard Tartler's avatar
      attributes: drop pointless define guards · a1641e95
      Reinhard Tartler authored
      the av_-prefixed attributes must not be defined outside of this file
      a1641e95
    • Mans Rullgard's avatar
      configure: do not disable av_always_inline with --enable-small · 06eb4f08
      Mans Rullgard authored
      Currently, --enable-small turns av_always_inline into plain inline,
      which is more or less ignored by the compiler.  While the intent of
      this is probably to reduce code size by avoiding some inlining, it
      has more far-reaching effects.
      
      We use av_always_inline in two situations:
      
      1. The body of a function is smaller than the call overhead.
         Instances of these are abundant in libavutil, the bswap.h
         functions being good examples.
      
      2. The function is a template relying on constant propagation
         through inlined calls for sane code generation.  These are
         often found in motion compensation code.
      
      Both of these types of functions should be inlined even if targeting
      small code size.
      
      Although GCC has heuristics for detecting the first of these types,
      it is not always reliable, especially when the function uses inline
      assembler, which is often the reason for having those functions in
      the first place, so making it explicit is generally a good idea.
      
      The size increase from inlining template-type functions is usually
      much smaller than it seems due to different branches being mutually
      exclusive between the different invocations.  The dead branches can,
      however, only be removed after inlining and constant propagation have
      been performed, which means the initial cost estimate for inlining
      these is much higher than is actually the case, resulting in GCC
      often making bad choices if left to its own devices.
      
      Furthermore, the GCC inliner limits how much it allows a function to
      grow due to automatic inlining of calls, and this appears to not take
      call overhead into account.  When nested inlining is used, the limit
      may be hit before the innermost level is reached.  In some cases, this
      has prevented inlining of type 1 functions as defined above, resulting
      in significant performance loss.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      06eb4f08
    • Luca Barbato's avatar
      flvdec: initial stream switch support · 09a445ce
      Luca Barbato authored
      Codec change midstream gets mapped to a separate stream.
      09a445ce
    • Luca Barbato's avatar
      avplay: fix write on freed memory for rawvideo · 906f9dce
      Luca Barbato authored
      Do not assume avpacket and the decoded frames are independent.
      
      To be absolutely sure and not sprinkle av_free_packet around the code
      the call had been placed before getting the frame and on the error path.
      906f9dce
    • Ronald S. Bultje's avatar
      33895451
    • Mans Rullgard's avatar
      x86: lavfi: fix gradfun/yadif build with mmx/sse disabled · fb93e61e
      Mans Rullgard authored
      These functions are defined conditionally so any uses need to have
      preprocessor guards.
      Signed-off-by: 's avatarMans Rullgard <mans@mansr.com>
      fb93e61e
    • Ronald S. Bultje's avatar
      snow: remove the runs[] VLA. · cbd9b2f9
      Ronald S. Bultje authored
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      cbd9b2f9
    • Martin Storsjö's avatar
      snow: Check mallocs at init · 4d8516fd
      Martin Storsjö authored
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      4d8516fd
  2. 02 Jul, 2012 14 commits
  3. 01 Jul, 2012 12 commits
  4. 30 Jun, 2012 4 commits