1. 18 Jul, 2018 1 commit
    • Edward Hervey's avatar
      ogg: Avoid undefined granule shift · d68164e6
      Edward Hervey authored
      A granule is a 64bit signed integer, shifting by 63 or more is
      undefined and most likely an indication that the stream is
      corrupted or invalid.
      Detected by oss-fuzz
  2. 17 Mar, 2018 1 commit
  3. 01 Feb, 2018 1 commit
  4. 08 Dec, 2017 1 commit
  5. 06 Dec, 2017 1 commit
  6. 15 Nov, 2017 3 commits
  7. 08 Nov, 2017 2 commits
    • Edward Hervey's avatar
      oggdemux: Solidify gst_ogg_demux_loop_push() some more · 895d8847
      Edward Hervey authored
      There were still some races going on where seeking events wouldn't
      be properly intercepted/executed by this thread.
      * Instead of always waiting for the GCond to be emitted, first just
        check if there is an event available
      * Take ownership of the event *while* the lock is taken and not
        after releasing/reacquiring it
      * Finally acquire lock at the very top and release it at the end
        to make it a bit more streamlined
      This removes the remaining issues with seeks not being executed
    • Edward Hervey's avatar
      oggdemux: Don't double-unlock · 9f678bb2
      Edward Hervey authored
      The previous branch will release the lock in the call to
      Only unlock it if we didn't call that function
  8. 07 Nov, 2017 2 commits
    • Edward Hervey's avatar
      oggdemux: Drop data before new segment · c86df789
      Edward Hervey authored
      When calculating duration in push-mode we seek to a certain position
      and discard any data until we get data from that requested position.
      The problem is that basing ourselves solely on offset to determine
      whether we reached the target offset is wrong since the source might
      be fast enough  to send us that target position *before* it processed
      the requested seek.
      This would end up in a situation where:
      * We think we're done with duration estimate
      * We fire a seek back to "0" in the loop thread
      * We resume normal processing
      * ... except that we're still getting data from too far ahead which
        we decide to process.
      * And we start doing totally wrong granule/time/duration calculation
        and pushing wrong data.
      Instead of this confusion, wait until we receive data from the requested
      seek. We do that by using the fact that the seqnum in
      seek_event_drop_til will be non-zero until the SEGMENT corresponding
      to the requested SEEK has been received.
      Bonus: makes startup slightly faster
    • Edward Hervey's avatar
      oggdemux: Wait for push loop to be started · 0a49b93a
      Edward Hervey authored
      Code using the push_loop_thread (using for sending seeks) assumes
      that the thread was properly started, except that this isn't always
      true and the thread might not have completely started.
      Instead wait for the thread to properly start before doing anything
  9. 06 Nov, 2017 1 commit
  10. 05 Nov, 2017 2 commits
  11. 04 Nov, 2017 2 commits
  12. 01 Nov, 2017 5 commits
  13. 31 Oct, 2017 1 commit
  14. 26 Oct, 2017 1 commit
  15. 24 Oct, 2017 2 commits
  16. 20 Oct, 2017 2 commits
  17. 29 May, 2017 1 commit
  18. 26 May, 2017 1 commit
  19. 16 May, 2017 1 commit
  20. 10 Mar, 2017 1 commit
  21. 03 Mar, 2017 3 commits
    • Jan Schmidt's avatar
      oggdemux: Fix reverse playback · 8596ec23
      Jan Schmidt authored
      Fix various issues with reverse playback by clearing tracking
      vars when working in reverse, and where possible using the
      timestamp interpolation code to generate timestamps for
      outgoing buffers. Make sure to mark things as discontinuous
      only when looping backward to a new position and fix seeking
      to the next page when starting.
    • Jan Schmidt's avatar
      oggdemux: Timestamp tracking fixes · fe1f47aa
      Jan Schmidt authored
      In gst_ogg_demux_do_seek() when calculating the
      keyframe time, account for a non-zero start-time
      Handle a discontinuous first packet in
      gst_ogg_demux_setup_first_granule() because that's pretty
      normal after a seek. Also differentiate between a genuinely
      truncated first packet and just bailing out early, by not using
      granule = -1 as an error code.
      Make the debug output logs clearer about which timestamps
      are stream times (PTS) and which are ogg timestamps.
    • Jan Schmidt's avatar
      oggdemux: Don't arbitrarily guess a timestamp of 0 · 342132a7
      Jan Schmidt authored
      When we haven't managed to manufacture a timestamp for
      a packet, don't just guess '0', leave it at none and
      let downstream decide
  22. 09 Dec, 2016 1 commit
  23. 01 Dec, 2016 1 commit
  24. 12 Nov, 2016 1 commit
  25. 05 Oct, 2016 1 commit
  26. 05 Sep, 2016 1 commit