1. 31 Oct, 2013 1 commit
  2. 15 Oct, 2013 1 commit
  3. 16 Sep, 2013 1 commit
  4. 30 Apr, 2013 1 commit
  5. 19 Apr, 2013 1 commit
  6. 05 Apr, 2013 1 commit
  7. 27 Mar, 2013 1 commit
  8. 26 Mar, 2013 1 commit
  9. 11 Mar, 2013 1 commit
  10. 08 Mar, 2013 3 commits
  11. 06 Mar, 2013 1 commit
  12. 15 Feb, 2013 3 commits
    • 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
    • Anton Khirnov's avatar
      mpegvideo: split ff_draw_horiz_band(). · 1d0feb5d
      Anton Khirnov authored
      Split out dependency on MpegEncContext.
      1d0feb5d
    • Anton Khirnov's avatar
      54974c62
  13. 07 Feb, 2013 1 commit
  14. 04 Feb, 2013 1 commit
    • Anton Khirnov's avatar
      mpegvideo: simplify REBASE_PICTURE · d9df93ef
      Anton Khirnov authored
      Always evaluate to NULL when the source Picture is not located in the
      MpegEncContext.picture array. That will only happen for
      next/last_picture_ptr when updating the thread context during h264 frame
      threaded decoding, where they will point to elements of ref_list. Since
      ref_list is not copied during updating the context and is invalid until
      it is constructed for the current slice, there is no point in doing
      anything complicated with next/last_picture_ptr, as they will get
      updated when the ref_list is filled.
      d9df93ef
  15. 31 Jan, 2013 1 commit
    • Martin Storsjö's avatar
      mpegvideo: Do REBASE_PICTURE with byte pointers · a65f965c
      Martin Storsjö authored
      REBASE_PICTURE (more specifically, this half of it) takes a Picture
      pointer that points into one larger struct, finds the offset of
      that Picture within the struct and finds the corresponding field
      within another instance of a similar struct.
      
      The pointer difference "pic - (Picture*)old_ctx" is a value given
      in sizeof(Picture) units, and when applied back on
      (Picture*)new_ctx gets multiplied back with sizeof(Picture). Many
      compilers seem to optimize out this division/multiplication, but
      not all do.
      
      GCC 4.2 on OS X doesn't seem to remove the division/multiplication,
      therefore the new pointer didn't turn out to point to exactly
      the right place in the new struct since it only had sizeof(Picture)
      granularity (and the Picture is not aligned on a sizeof(Picture)
      boundary within the encompassing struct). This bug has been present
      before 47318953 as well - with H264, pointers to h->ref_list[0][0]
      pointed to 88 bytes before h->ref_list[0][0] after the rebase. After
      shrinking Picture, the difference ended up even larger, making
      writes via such a Picture pointer overwrite other fields at random
      in H264Context, ending up in crashes later.
      
      This fixes H264 multithreaded decoding on OS X with GCC 4.2.
      Signed-off-by: 's avatarMartin Storsjö <martin@martin.st>
      a65f965c
  16. 29 Jan, 2013 1 commit
  17. 23 Jan, 2013 1 commit
  18. 20 Dec, 2012 1 commit
  19. 18 Dec, 2012 1 commit
    • Janne Grunau's avatar
      mpegvideo: allocate scratch buffers after linesize is known · f1d8763a
      Janne Grunau authored
      Since we can't know which stride a custom get_buffer() implementation is
      going to use we have to allocate this scratch buffers after the linesize
      is known. It was pretty safe for 8 bit per pixel pixel formats since we
      always allocated memory for up to 16 bits per pixel. It broke hoever
      with cmdutis.c's alloc_buffer() and high pixel bit depth since it
      allocated larger edges than mpegvideo expected.
      
      Fixes fuzzed sample nasa-8s2.ts_s244342.
      f1d8763a
  20. 13 Dec, 2012 1 commit
  21. 09 Dec, 2012 1 commit
  22. 12 Oct, 2012 1 commit
  23. 08 Oct, 2012 1 commit
  24. 19 Sep, 2012 2 commits
  25. 04 Sep, 2012 3 commits
  26. 24 Aug, 2012 2 commits
  27. 09 Aug, 2012 1 commit
  28. 07 Aug, 2012 1 commit
  29. 04 Jul, 2012 1 commit
  30. 21 Apr, 2012 1 commit
  31. 14 Mar, 2012 1 commit
  32. 01 Mar, 2012 1 commit