1. 11 Sep, 2014 4 commits
  2. 09 Sep, 2014 1 commit
  3. 02 Sep, 2014 3 commits
  4. 01 Sep, 2014 1 commit
  5. 28 Aug, 2014 2 commits
  6. 25 Aug, 2014 1 commit
  7. 18 Aug, 2014 3 commits
  8. 16 Aug, 2014 1 commit
  9. 15 Aug, 2014 2 commits
  10. 13 Aug, 2014 5 commits
  11. 12 Aug, 2014 1 commit
  12. 10 Aug, 2014 1 commit
  13. 04 Aug, 2014 1 commit
  14. 01 Aug, 2014 3 commits
  15. 28 Jul, 2014 4 commits
  16. 26 Jul, 2014 5 commits
    • Martin Storsjö's avatar
      omxil: Retry getting an output buffer while waiting for a free input buffer · 1285807f
      Martin Storsjö authored
      
      
      As soon as either the input packet has been written, or an output
      buffer is available, we return from the function, allowing passing
      the output frames down the pipeline as soon as possible. (For
      direct rendering, a new output buffer only become available for
      the codec to use once the picture is rendered or discarded.)
      
      This fixes playback with IOMX direct rendering on Nexus S, which
      only uses 2 output buffers in this mode (min_undequeued = 1,
      nBufferCountMin = 1), and probably also for other devices with
      a small number of output buffers.
      
      (On the Nexus S, the number of output buffers can't be increased,
      since this leads to blinking.)
      
      This is similar to how available input/output buffers are checked
      in the MediaCodec plugin.
      
      This still isn't completely foolproof with respect to the case when
      an input packet needs to be split up over multiple input buffers
      though, but it wasn't completely correct previously either.
      
      Also make sure we don't return from the function without consuming
      the input packet or returning an output frame, which earlier would
      lead to a skipped input packet and leaked memory. (This could
      previously happen on reconfiguration, or on timeout while waiting for
      an input buffer.)
      
      Finally, make sure we don't block indefinitely in case the playback
      is paused (causing the decoder to block while waiting for a free
      output buffer). The same solution as in the android mediacodec
      decoder is used here.
      Signed-off-by: Martin Storsjö's avatarMartin Storsjö <martin@martin.st>
      1285807f
    • Thomas Guillem's avatar
      iomx-dr: split IOMXHWBuffer_Setup function · ef230f41
      Thomas Guillem authored
      
      
      In HwBuffer, split Setup into Setup, GetMinUndequeued and SetBufferCount since
      we want to control the buffer count logic from omxil.c.
      
      Some OMX components (like OMX.TI.*.Decoder) may have nBufferCountActual that is
      greater than nBufferCountMin + min_undequeued. In that case we decreased the
      number of buffer wanted by the component and had an undefined behavior.
      
      In order to fix it, we need to increase nBufferCountActual value from the
      component only when it's smaller than nBufferCountMin + min_undequeued.
      Signed-off-by: Martin Storsjö's avatarMartin Storsjö <martin@martin.st>
      ef230f41
    • Thomas Guillem's avatar
      iomx-dr: don't always lock buffers from dequeue · f9182874
      Thomas Guillem authored
      
      
      According to OMXCodec.cpp, we shouldn't call lockBuffer when we first allocate
      all buffers, since we may cancel some of them (the min_undequeued ones).
      
      We should call lockBuffer only before giving a buffer to OMX.
      Signed-off-by: Martin Storsjö's avatarMartin Storsjö <martin@martin.st>
      f9182874
    • Thomas Guillem's avatar
      e69072b9
    • Thomas Guillem's avatar
      7c937db6
  17. 25 Jul, 2014 1 commit
  18. 24 Jul, 2014 1 commit