Skip to content
Snippets Groups Projects
  1. Sep 18, 2017
  2. Sep 16, 2017
  3. Sep 08, 2017
  4. Sep 07, 2017
  5. Aug 25, 2017
  6. Aug 17, 2017
  7. Aug 16, 2017
  8. Aug 15, 2017
  9. Aug 14, 2017
  10. Aug 11, 2017
  11. Aug 08, 2017
  12. Jul 25, 2017
  13. Jul 17, 2017
  14. Jul 16, 2017
  15. Jul 14, 2017
  16. Jul 13, 2017
    • Edward Hervey's avatar
      adaptivedemux: Workaround for live seek ranges when advancing · 2f01c7e5
      Edward Hervey authored and Edward Hervey's avatar Edward Hervey committed
      This is a workaround for a regression introduced by
      f4190a49
       ( adaptivedemux: Check live seeking range more often )
      
      The goal of the previous commit was to be able to cope with non-1.0
      rates on live streams which have a "seeking window" (i.e. the server
      keeps around quite a bit of the live stream so you can seek back into
      it).
      
      Without that commit, two different kind of issues would happen:
      * When doing reverse playback, you would never check whether you
        are outside of the seekable region. And would then continuously
        try to download fragments that are no longer present.
      * When doing fast forward, you would end up requesting fragments
        which are not present yet.
      
      In order to determine whether one was *really* outside of the seekable
      window, we check whether the current stream position is still
      within the seekable region.
      
      The *problem* though with that commit is that it assumes that subclasses
      will return continuously updated seeking ranges (i.e. dependent on the
      current time), which is *NOT* the case.
      
      For example:
      * dashdemux does use the current UTC to determine the seekable region
      * hlsdemux uses the values from the last updated manifest
      
      Therefore if one downloads fragments faster than realtime, for HLS
      we would end up at the end of the last manifest seekable range, and
      the previous commit would consider the stream as being ended... which
      is not the case.
      
      In the long run, we need to figure out a way to cope with non-1.0
      rates on live streams for all types of stream (including HLS).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783075
      2f01c7e5
    • Thiago Sousa Santos's avatar
      adaptivedemux: small refactor to avoid repeated code · 4fc49a28
      Thiago Sousa Santos authored and Edward Hervey's avatar Edward Hervey committed
      Move segment event update to a function
      
      https://bugzilla.gnome.org/show_bug.cgi?id=773159
      4fc49a28
    • Edward Hervey's avatar
      adaptivedemux: Handle prepared streams on seeks · b80b11cc
      Edward Hervey authored and Edward Hervey's avatar Edward Hervey committed
      This is a race that was exposed by the {hls|dash}.scrub_forward_seeking
      validate test.
      
      The "race" is that a subclass might want to change format, causing
      a new stream to be created (but not exposed/switched yet) and put on the
      prepared_streams list. That stream will have values (including pending
      segment) from the pre-seek state.
      
      Before the stream is exposed/switched, a new seek comes in and the stream
      values get updated ... but the ones that will be changed don't get updated
      causing them to push out wrong segments once they are exposed.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=773159
      b80b11cc
    • Sebastian Dröge's avatar
    • Sebastian Dröge's avatar
      mxfdemux: Initialize index table entries completely in all cases · 9f9ff5e4
      Sebastian Dröge authored
      When seeking backwards into a previously unseen location, we wouldn't
      fully initialize them and playback would fail later.
      9f9ff5e4
Loading