1. 03 Feb, 2014 1 commit
  2. 28 Dec, 2013 1 commit
  3. 09 Dec, 2013 1 commit
  4. 31 Oct, 2013 1 commit
  5. 15 Oct, 2013 2 commits
  6. 28 Sep, 2013 1 commit
  7. 21 Jul, 2013 1 commit
  8. 24 May, 2013 1 commit
  9. 19 Apr, 2013 1 commit
  10. 21 Mar, 2013 10 commits
  11. 08 Mar, 2013 1 commit
  12. 07 Mar, 2013 1 commit
  13. 03 Mar, 2013 1 commit
  14. 23 Feb, 2013 1 commit
  15. 20 Feb, 2013 1 commit
  16. 19 Feb, 2013 3 commits
  17. 18 Feb, 2013 2 commits
    • Ronald S. Bultje's avatar
      h264/svq3: stop using draw_edges. · 51513b98
      Ronald S. Bultje authored
      Instead, only extend edges on-demand when the motion vector actually
      crosses the visible decoded area using ff_emulated_edge_mc(). This
      changes decoding time for cathedral from 8.722sec to 8.706sec, i.e.
      0.2% faster overall. More generally (VP8 uses this also), low-motion
      content gets significant speed improvements, whereas high-motion content
      tends to decode in approximately the same time.
      Signed-off-by: 's avatarMichael Niedermayer <michaelni@gmx.at>
      51513b98
    • Ronald S. Bultje's avatar
      h264: don't store intra pcm samples in h->mb. · c63f9fb3
      Ronald S. Bultje authored
      Instead, keep them in the bitstream buffer until we read them verbatim,
      this saves a memcpy() and a subsequent clearing of the target buffer.
      decode_cabac+decode_mb for a sample file (CAPM3_Sony_D.jsv) goes from
      6121.4 to 6095.5 cycles, i.e. 26 cycles faster.
      Signed-off-by: 's avatarMichael Niedermayer <michaelni@gmx.at>
      c63f9fb3
  18. 15 Feb, 2013 1 commit
    • Anton Khirnov's avatar
      h264: deMpegEncContextize · 2c541554
      Anton Khirnov authored
      Most of the changes are just trivial are just trivial replacements of
      fields from MpegEncContext with equivalent fields in H264Context.
      Everything in h264* other than h264.c are those trivial changes.
      
      The nontrivial parts are:
      1) extracting a simplified version of the frame management code from
         mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
         its own more complex system already and those were set only to appease
         the mpegvideo parts.
      2) some tables that need to be allocated/freed in appropriate places.
      3) hwaccels -- mostly trivial replacements.
         for dxva, the draw_horiz_band() call is moved from
         ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
         because it's now different for h264 and MpegEncContext-based
         decoders.
      4) svq3 -- it does not use h264 complex reference system, so I just
         added some very simplistic frame management instead and dropped the
         use of ff_h264_frame_start(). Because of this I also had to move some
         initialization code to svq3.
      
      Additional fixes for chroma format and bit depth changes by
      Janne Grunau <janne-libav@jannau.net>
      Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
      2c541554
  19. 06 Feb, 2013 2 commits
  20. 24 Jan, 2013 1 commit
  21. 23 Jan, 2013 1 commit
  22. 18 Jan, 2013 1 commit
    • Anton Khirnov's avatar
      h264: avoid pointless copying of ref lists · 940b8b58
      Anton Khirnov authored
      ref_list is constructed from other fields per slice when needed, so do
      not copy it for both frame and slice threading.
      default_ref_list is constructed per frame and still needs to be copied
      to per-slice contexts for slice threading, but a copy is not needed for
      frame threading.
      940b8b58
  23. 15 Jan, 2013 1 commit
    • Ronald S. Bultje's avatar
      h264: don't clobber mmco opcode tables for non-first slice headers. · f6badba1
      Ronald S. Bultje authored
      Clobbering these tables will temporarily clobber the template used
      as a basis for other threads to start decoding from. If the other
      decoding thread updates from the template right at that moment,
      subsequent threads will get invalid (or, usually, none at all) mmco
      tables. This leads to invalid reference lists and subsequent decode
      failures.
      
      Therefore, instead, decode the mmco tables only for the first slice in
      a field or frame. For other slices, decode the bits and ensure they
      are identical to the mmco tables in the first slice, but don't ever
      clobber the context state. This prevents other threads from using a
      clobbered/invalid template as starting point for decoding, and thus
      fixes decoding in these cases.
      
      This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
      frame-multithreading enabled.
      Signed-off-by: 's avatarMichael Niedermayer <michaelni@gmx.at>
      f6badba1
  24. 14 Jan, 2013 2 commits
    • Anton Khirnov's avatar
      h264: fix ff_generate_sliding_window_mmcos() prototype. · ea382767
      Anton Khirnov authored
      It's been returning an error value since
      bad446e2
      
      Also check for the errors it returns.
      ea382767
    • Ronald S. Bultje's avatar
      h264: don't clobber mmco opcode tables for non-first slice headers. · bad446e2
      Ronald S. Bultje authored
      Clobbering these tables will temporarily clobber the template used
      as a basis for other threads to start decoding from. If the other
      decoding thread updates from the template right at that moment,
      subsequent threads will get invalid (or, usually, none at all) mmco
      tables. This leads to invalid reference lists and subsequent decode
      failures.
      
      Therefore, instead, decode the mmco tables only for the first slice in
      a field or frame. For other slices, decode the bits and ensure they
      are identical to the mmco tables in the first slice, but don't ever
      clobber the context state. This prevents other threads from using a
      clobbered/invalid template as starting point for decoding, and thus
      fixes decoding in these cases.
      
      This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
      frame-multithreading enabled.
      Signed-off-by: 's avatarLuca Barbato <lu_zero@gentoo.org>
      bad446e2
  25. 19 Dec, 2012 1 commit