1. 13 Feb, 2019 1 commit
  2. 08 Feb, 2019 1 commit
    • James Almer's avatar
      Simplify dav1d_thread_picture_alloc() · 515f5af5
      James Almer authored
      It's called from a single function in the entire codebase, so no point
      passing so many individual arguments to it when almost all of them are
      derived from a single struct.
  3. 28 Jan, 2019 1 commit
  4. 11 Jan, 2019 1 commit
  5. 20 Dec, 2018 1 commit
    • Henrik Gramner's avatar
      Perform stack realignment in every API entry point · ee8856ff
      Henrik Gramner authored
      Unlikely to cause problems in practice, but technically required since the
      compiler is free to use aligned AVX stores to zero local stack-allocated
      variables (when using the appropriate compiler flags) for example.
  6. 25 Nov, 2018 1 commit
    • Ronald S. Bultje's avatar
      Rewrite flushing logic · 3f410fd9
      Ronald S. Bultje authored
      The old flushing logic would simply leave frame threads (and tile
      threads) running without caring how much latency that might impose
      in the post-seek time-to-first-frame. This commit adds a 'flush'
      state that will abort all running frame/tile threads from decoding
      their current frame, as well as dispose of all frames in the output
      Then, we use dav1d_flush() in dav1d_close() to abort running threads
      on exit, instead of signaling their respective dependents to prevent
      deadlocks. The advantage of this approach is that we don't signal on
      objects we don't have ownership over, and thus this should prevent
      race conditions where the owning thread could dispose of the object
      just as we're signaling it, which I believe is what causes #193.
  7. 22 Nov, 2018 1 commit
  8. 20 Nov, 2018 1 commit
  9. 19 Nov, 2018 1 commit
    • Niklas Haas's avatar
      film_grain: implement film grain synthesis · cfa986fe
      Niklas Haas authored
      This is using a slightly adapted version of my GPU-based algorithm. The
      major difference to the algorithm suggested by the spec (and implemented
      in libaom) is that instead of using a line buffer to hold the previous
      row's film grain blocks, we compute each row/block fully independently.
      This opens up the door to exploit parallelism in the future, since we
      don't have any left->right or top->down dependency except for the PRNG
      state. (Which we could pre-compute for a massively parallel / GPU
      That being said, it's probably somewhat slower than using a line buffer
      for the serial / single CPU case, although most likely not by much
      (since the areas with the most redundant work get progressively smaller,
      down to a single 2x2 square for the worst case).
  10. 16 Nov, 2018 1 commit
  11. 07 Nov, 2018 1 commit
  12. 06 Nov, 2018 1 commit
  13. 19 Oct, 2018 1 commit
  14. 28 Sep, 2018 1 commit
  15. 22 Sep, 2018 2 commits