1. 14 Aug, 2015 1 commit
  2. 10 Aug, 2015 2 commits
  3. 06 Jul, 2015 1 commit
  4. 01 Jul, 2015 1 commit
  5. 30 Jun, 2015 1 commit
  6. 12 Jun, 2015 1 commit
  7. 08 May, 2015 1 commit
  8. 06 May, 2015 1 commit
    • Sebastian Dröge's avatar
      videodecoder: Try to be smarter when clipping buffers without duration/framerate to the segment · 21b57412
      Sebastian Dröge authored
      2 second frame duration is rather unlikely... but if we don't clip
      away buffers that far before the segment we can cause the pipeline to
      lockup. This can happen if audio is properly clipped, and thus the
      audio sink does not preroll yet but the video sink prerolls because
      we already outputted a buffer here... and then queues run full.
      
      In the worst case we will clip one buffer too many here now if no
      framerate is given, no buffer duration is given and the actual
      framerate is less than 0.5fps.
      
      Fixes seeking on HLS/DASH streams, when seeking into the middle of
      fragments and having no framerate/buffer duration.
      21b57412
  9. 11 Apr, 2015 1 commit
  10. 09 Apr, 2015 1 commit
  11. 07 Apr, 2015 1 commit
  12. 03 Apr, 2015 1 commit
  13. 07 Mar, 2015 1 commit
  14. 23 Feb, 2015 1 commit
  15. 22 Feb, 2015 2 commits
  16. 19 Feb, 2015 1 commit
  17. 11 Feb, 2015 1 commit
  18. 03 Feb, 2015 1 commit
  19. 22 Dec, 2014 2 commits
    • Sebastian Dröge's avatar
      video{en,de}coder: Call reset() before the start() vfunc · 87d6c265
      Sebastian Dröge authored
      This makes sure that the element is in the same state before start() is called
      the very first time and every future call after the element was used already.
      
      Also it ensure that we always have a clean state before start(), cleaned the
      same way in every case.
      87d6c265
    • Sebastian Dröge's avatar
      video{en,de}coder: Reset the codec after calling the stop() vfunc · 098b42f3
      Sebastian Dröge authored
      The stop() vfunc might mess with some of our fields we have just
      reset, which could cause memory leaks or invalid state taken over
      to later.
      
      Also the stop() vfunc, or anything called until it from another thread,
      might want to be able to use the fields that were just resetted and
      become confused because of that.
      
      In the decoder we already had a workaround for things like this happening,
      this workaround is not needed anymore.
      098b42f3
  20. 17 Dec, 2014 3 commits
  21. 11 Dec, 2014 1 commit
  22. 18 Sep, 2014 1 commit
  23. 15 Sep, 2014 1 commit
  24. 28 Aug, 2014 1 commit
  25. 14 Aug, 2014 1 commit
  26. 11 Aug, 2014 2 commits
    • Jan Alexander Steffens (heftig)'s avatar
    • George Kiagiadakis's avatar
      videodecoder: In reverse playback, flush the output queue after decoding each keyframe chain · a4d97f49
      George Kiagiadakis authored
      This fixes the reverse playback scenario when upstream is not fully
      parsing the stream and does not send every keyframe chain separately
      with the DISCONT flag on the keyframe.
      
      To explain this, let's suppose we have this stream:
       0 1 2 3 4 5 6 7 8
       K     K     K
      
      In most circumstances, the upstream parser will chain in the
      decoder the buffers in the following order:
      
       6 7 8 3 4 5 0 1 2
       D     D     D
      
      In this case, GstVideoDecoder will flush the parse queue every time
      it receives discont (D) and we will eventually get in the output queue:
      
        (flush here) 8 7 6  (flush here) 5 4 3 (flush here) 2 1 0
      
      In case the upstream parser doesn't do this work, though,
      GstVideoDecoder will receive the whole stream at once and will flush
      the parse queue afterwards:
      
       0 1 2 3 4 5 6 7 8
       D
      
      During the flush, it will look backwards for keyframes and will
      decode in this order:
      
       6 7 8 3 4 5 0 1 2
      
      This is the same order that it would receive from upstream if
      upstream was parsing and looking for the keyframes, only that now
      there is no flushing of the output queue in between keyframes,
      which will result in the output queue looking like this:
      
       2 1 0 6 5 3 8 7 6
      
      This will confuse downstream obviously and will play incorrectly.
      This patch forces the decoder to flush the output queue every time
      it picks a new keyframe to decode, so it will end up decoding 6 7 8
      and then flushing before picking 3 for decoding, so the output will
      get 8 7 6 before 6 5 3 and the video will play back correctly.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=734441
      a4d97f49
  27. 21 Jul, 2014 1 commit
  28. 03 Jul, 2014 1 commit
    • Gwenole Beauchesne's avatar
      videodecoder: parse any source data that is still available. · fb44ec96
      Gwenole Beauchesne authored
      Fix gst_video_decoder_parse_available() to really parse any pending
      source data that is still available in the adapter. This is a memory
      optimization to avoid expansion of video packed added to the adapter,
      but also a fix to EOS condition when the subclass parse() function
      ultimately only needed to call into gvd_have_frame() and no additional
      source bytes were consumed, i.e. gvd_add_to_frame() is not called.
      
      This situation can occur when decoding H.264 streams in byte-stream/nal
      mode for instance. A decoder always requires the next NAL unit to be
      parsed so that to determine picture boundaries. When a new picture is
      found, no byte is consumed (i.e. gvd_add_to_frame() is not called)
      but gvd_have_frame() is called (i.e. priv->current_frame is gone).
      
      Also make sure to avoid infinite loops caused by incorrect subclass
      parse() implementations. This can occur when no byte gets consumed
      and no appropriate indication (GST_VIDEO_DECODER_FLOW_NEED_DATA) is
      returned.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=731974Signed-off-by: default avatarGwenole Beauchesne <gwenole.beauchesne@intel.com>
      fb44ec96
  29. 02 Jul, 2014 1 commit
  30. 03 Jun, 2014 1 commit
  31. 27 May, 2014 1 commit
  32. 26 May, 2014 1 commit
  33. 12 May, 2014 1 commit
  34. 08 May, 2014 1 commit