Skip to content
Snippets Groups Projects
  1. Mar 25, 2023
  2. Mar 23, 2023
  3. Mar 21, 2023
  4. Mar 16, 2023
  5. Mar 13, 2023
  6. Mar 07, 2023
  7. Mar 06, 2023
  8. Mar 03, 2023
  9. Mar 01, 2023
  10. Feb 28, 2023
  11. Feb 27, 2023
  12. Feb 26, 2023
    • Martin Storsjö's avatar
      Fix building with MSVC after recent commit · ef0fb0b6
      Martin Storsjö authored
      98b0c96d added an include of
      src/ref.h in src/fg_apply_tmpl.c. That template source file is
      included in tests/checkasm/filmgrain.c.
      
      src/ref.h includes <stdatomic.h>. Including this file requires
      declaring a dependency on stdatomic_dependencies in meson, which
      provides the fallback implementation of stdatomic.h when building
      with MSVC.
      ef0fb0b6
  13. Feb 25, 2023
  14. Feb 23, 2023
  15. Feb 14, 2023
  16. Feb 13, 2023
  17. Feb 10, 2023
    • Victorien Le Couviour--Tuffet's avatar
      drain: Properly fix a desync between next and first · 9b4b2448
      Victorien Le Couviour--Tuffet authored
      The code in dav1d_drain_picture could result in a desync between
      c->task_thread.first (oldest submitted frame) and c->frame_thread.next (first
      frame to retrieve and/or next submit location).
      As we loop through drain, we always increment next, but first only if the
      frame has data. If the frame is visible we return. The problem arises when
      encountering (an) invisible frame(s), and the next entries haven't been fed
      yet, we then keep on looping increasing next but not first, as these have no
      data.
      
      We should always return when we encountered data (visible or
      invisible decoded frame): for visible, the code already returns, for
      invisible, we can store a boolean indicating we drained at least one frame,
      whenever we reach an empty entry after that, we return (all subsequent
      entries are guaranteed to be empty anyway), not incrementing next nor first.
      This will have the effect to insert the next frame at the first free spot
      (which is much better than the weird skips it's doing now).
      
      So basically, c->frame_thread.next could skip some (empty) entries.
      Now it's contiguous.
      
      Fixes #416.
      9b4b2448
  18. Feb 09, 2023
    • Victorien Le Couviour--Tuffet's avatar
      Revert "Fix mismatch between first and next in drain" · 3f19ece6
      Victorien Le Couviour--Tuffet authored
      This reverts commit a51b6ce4.
      
      We can't increment first when no data is there, otherwise we might do it
      while the first frame was not yet decoded, messing up ordering: imagine
      having a framedelay of 8, and a file with 7 frames. We feed 7 frames over 8
      slots, now next points to [7] (empty entry), and we start draining cause EOF.
      We do need next to be incremented to reach the first frame ([0]), so it can
      be outputted, and only then first too.
      
      Fixes #418.
      3f19ece6
  19. Feb 03, 2023
Loading