1. 06 Feb, 2013 17 commits
  2. 05 Feb, 2013 5 commits
  3. 04 Feb, 2013 2 commits
    • Diego Biurrun's avatar
    • 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
  4. 01 Feb, 2013 9 commits
  5. 31 Jan, 2013 5 commits
    • Diego Biurrun's avatar
      52acd791
    • Diego Biurrun's avatar
    • Diego Biurrun's avatar
      configure: Move newlib libc check before mingw libc check · 29f1fa74
      Diego Biurrun authored
      On Cygwin systems MinGW headers can be present if the corresponding
      packages have been installed. Since the MinGW libc is checked for
      first, this results in newlib getting misdetected as MinGW libc.
      29f1fa74
    • Diego Biurrun's avatar
    • 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
  6. 30 Jan, 2013 2 commits