1. 28 Nov, 2015 2 commits
  2. 27 Nov, 2015 2 commits
  3. 26 Nov, 2015 1 commit
  4. 19 Nov, 2015 5 commits
  5. 11 Nov, 2015 1 commit
    • Thomas Guillem's avatar
      decoder: don't flush if already flushed · 69c4ec60
      Thomas Guillem authored
      This commit fixes the following assert in the DecoderThread function:
      "assert( vlc_fifo_IsEmpty( p_owner->p_fifo) );"
      Indeed, if input_DecoderFlush is called again (just after), p_owner->flushed
      will be true and the input won't wait for the DecoderThread. As a consequence,
      the input will send blocks while the DecoderThread is flushing, hence the
      Signed-off-by: Rémi Denis-Courmont's avatarRémi Denis-Courmont <remi@remlab.net>
  6. 09 Nov, 2015 1 commit
  7. 07 Nov, 2015 4 commits
  8. 06 Nov, 2015 1 commit
  9. 05 Nov, 2015 1 commit
    • Rémi Denis-Courmont's avatar
      decoder: remove incorrect assertion · d0efd591
      Rémi Denis-Courmont authored
      The decoder can be paused by the decoder owner while the decoder thread
      is decoding. We still need to queue the last decoded picture(s) to the
      (not yet paused) video output.
  10. 02 Nov, 2015 1 commit
  11. 01 Nov, 2015 3 commits
    • Rémi Denis-Courmont's avatar
      decoder: reduce owner lock scope for aout (fixes #10422) · 6ae2905e
      Rémi Denis-Courmont authored
      The decoder thread no longer needs the lock to use the aout, only to
      modify the aout pointer.
    • Rémi Denis-Courmont's avatar
      decoder: handle pause within the decoder thread · 5b2de769
      Rémi Denis-Courmont authored
      This removes the last direct (ab)use of the audio output object from
      the input thread, and the penultimate one of the video output object.
      This solves some race conditions whereby the output pause state was
      enabled by the input thread, while the decoder thread had decoded data
      blocks to queue for playing. Decoded blocks should never get queued
      during pause.
    • Rémi Denis-Courmont's avatar
      decoder: reorder thread loop · 986bea5b
      Rémi Denis-Courmont authored
      There are no real functional changes here. At the first iteration,
      wait_acknowledge is no longer signaled upfront. Because the thread made
      no observable changes by that point, the signal had no effects anyway.
  12. 27 Sep, 2015 2 commits
  13. 16 Sep, 2015 1 commit
  14. 09 Sep, 2015 5 commits
  15. 03 Sep, 2015 1 commit
  16. 23 Aug, 2015 1 commit
  17. 08 Jul, 2015 1 commit
    • Rémi Denis-Courmont's avatar
      Inline all remaining calls to vlc_cleanup_run() · 901fa0d6
      Rémi Denis-Courmont authored
      The code size saving in vlc_cleanup_run() is marginal and premature
      optimization. In practice, vlc_cleanup_run() makes the source code
      harder to follow/read, confuses static analyzers and generates false
      positive clobber warnings (on some OSes due to long jumps).
      It did exercise some of the cleanup code paths though.
  18. 04 Jul, 2015 3 commits
  19. 08 Jun, 2015 1 commit
  20. 03 May, 2015 1 commit
  21. 24 Apr, 2015 2 commits
    • Rémi Denis-Courmont's avatar
      decoder: remove bogus buffering signal · 2e6b61f8
      Rémi Denis-Courmont authored
      Allocating a picture does not mean much w.r.t. buffering. The decoder
      may just have started.
    • Rémi Denis-Courmont's avatar
      decoder: remove vout_FixLeaks() · e56293ea
      Rémi Denis-Courmont authored
      This function was intended to work around a certain class of bugs
      inside video decoders whereby the a reference picture was never
      dereferenced, i.e. missing decoder_UnlinkPicture() call.
      There are however some situations where this hack would release a
      still referenced picture:
      - If the video output or decoder has a high latency or if a video
        filter holds pictures (deinterlace), there may be zero free pictures
        even though the total number of pictures is sufficient overall.
        In that case, waiting for a picture buffer to be released normally
        is the right and safe approach.
      - If the byte stream is invalid or corrupt such that the number of
        required pictures (DPB size) is underestimated, dropping frames is
        acceptable. Frames would be corrupt anyway due to missing references.
        (This case could be better worked around by allocating extra
         pictures on-the-fly, though this would require memory copying in the
         video output.)
      - Even if the decoder indeed leaks pictures, the oldest referenced
        picture is not necessarily among those leaked.
      If the picture was not truly leaked, vout_FixLeaks() would cause an
      extraneous picture release. This should lead to an assertion failure in
      picture_Release(). Without assertions, it would lead to undefined
      behaviour, especially invalid pointer use in case of hardware surfaces.
      In any case, picture leaks are still recovered when resetting the video
      output with vout_Reset(), after the decoder is destroyed. That might
      turn out to be a problem too though.