1. 21 Mar, 2017 1 commit
  2. 07 Jun, 2016 2 commits
  3. 29 Apr, 2016 1 commit
  4. 21 Apr, 2016 1 commit
  5. 29 Jan, 2016 1 commit
  6. 22 Dec, 2015 1 commit
  7. 04 Nov, 2015 1 commit
  8. 10 Aug, 2015 1 commit
  9. 08 Jul, 2015 1 commit
    • Thiago Santos's avatar
      qtdemux: rename upstream_newsegment to upstream_format_is_time · 6ee4b31c
      Thiago Santos authored
      upstream_newsegment isn't really clear on what it means, it is set
      to TRUE when the upstream element sends a segment in TIME format, so
      rename it to be more clear about it.
      
      It is important to know this because it means that upstream has
      a notion of time and qtdemux is likely being driven by an upstream
      element that is reading from a higher level abstraction than a file,
      such as a DASH, MSS or DLNA element.
      6ee4b31c
  10. 12 Feb, 2015 1 commit
  11. 28 Jan, 2015 1 commit
  12. 10 Dec, 2014 1 commit
  13. 30 Nov, 2014 2 commits
  14. 26 May, 2014 1 commit
  15. 15 Jan, 2014 2 commits
    • Thiago Santos's avatar
      qtdemux: remove elst_offset variables · 52fc0783
      Thiago Santos authored
      They are not used anymore
      52fc0783
    • Thiago Santos's avatar
      qtdemux: do not ignore empty segments · 90a55652
      Thiago Santos authored
      Make sure empty segments are used and pushed with a gap event
      to represent its data (or lack of it)
      
      Each QtSegment is mapped into a GstSegment with the corresponding
      media range. For empty QtSegments a gap event is pushed instead
      of GstBuffers and it advances to the next QtSegment.
      
      To make this work with seeks, need to keep track of the starting
      'base' to make sure it remains consistently increasing when
      pushing new segment events.
      For example: if a seek makes qtdemux start from 5s, the first
      segment will have a base=0. When the next segment is activated,
      its base time will be QtSegment.time - qtdemux.segment_base so
      that it doesn't include the first 5s that weren't played and
      shouldn't be accounted on the running time
      
      This purposedly will remove the fix made for
      https://bugzilla.gnome.org/show_bug.cgi?id=700264, at this
      point it was decided to respect the gaps, even if they cause
      a delay on playback, because that's the way the file was crafted.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=345830
      90a55652
  16. 27 Dec, 2013 1 commit
    • Thiago Santos's avatar
      qtdemux: improve mss_mode/fragmented special handling · c1cd2f81
      Thiago Santos authored
      Make it clear what should be handled purely by mss mode:
      1) Expose the streams on the first moof as there are no moov atoms
      2) Properly cleanup streams on flushes
      
      Add a note about the meaning of upstream_newsegment and mss_mode
      for future reference.
      
      Make all other special fragment handling shared for both dash
      and mss streams.
      c1cd2f81
  17. 04 Dec, 2013 1 commit
    • Thiago Santos's avatar
      qtdemux: improve fragment-start tracking · 1fd094d9
      Thiago Santos authored
      Some buffers can have multiple moov atoms inside and the strategy
      of using the gst_adapter_prev_pts timestamp to get the base timestamp
      for the media of the fragment would fail as it would reuse the same
      base timestamp for all moofs in the buffer instead of accumulating
      the durations for all of them.
      
      Heres a better explanation of the issue:
      qtdemux receives a buffer where PTS(buf) = X
      buf -> moofA | moofB | moofC
      
      The problem was that PTS(buf) was used as the base timestamp for
      all 3 moofs, causing all buffers to be X based. In this case we want
      only moofA to be X based as it is what the PTS on buf means, and the
      other moofB and moofC just use the accumulated timestamp from the
      previous moofs durations.
      
      To solve this, this patch uses gst_adapter_prev_pts distance
      result, this allows qtdemux to calculate if it should use the
      resulting pts or just accumulate the samples as it can identify
      if the moofs belong to the same upstream buffer or not.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=719783
      1fd094d9
  18. 29 Nov, 2013 1 commit
  19. 07 Nov, 2013 1 commit
    • Thiago Santos's avatar
      qtdemux: When using a buffered mdat, store all received data for later use · 0e78ffc9
      Thiago Santos authored
      In push mode, when qtdemux can't use a seek to skip the mdat buffer it has
      to buffer it for later use.
      
      The issue is that after parsing the next moov/moof, there might be some
      trailing bytes from the next atom in the file. This data was being discarded
      along with the already parsed moov/moof and playback would fail to continue
      after the contents of this moov/moof are played.
      
      This is particularly bad on fragmented files that have the mdat before the
      corresponding moof. So you'd get:
      
      mdat|moof|mdat|moof ...
      
      When a moof was received, it usually came with some extra bytes that would
      belong to the next mdat (because upstream doesn't care about atoms alignment).
      So those bytes were being discarded and playback would fail.
      
      This patch makes qtdemux store those extra bytes to reuse them later after the
      mdat is emptied.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710623
      0e78ffc9
  20. 10 Sep, 2013 1 commit
  21. 22 Jul, 2013 1 commit
  22. 15 Jul, 2013 1 commit
  23. 12 Jul, 2013 1 commit
  24. 07 May, 2013 3 commits
    • Thiago Santos's avatar
      qtdemux: some code cleanup for mss handling code · 4d073bee
      Thiago Santos authored
      * Explicitly init variables for fragmented formats at init
      * Do not use GstClockTime type if the variable isn't a timestamp
      * Fix a style/readability issue at an if block
      * Group 2 mss mode conditional blocks together to improve readability
      
      Conflicts:
      	gst/isomp4/qtdemux.c
      4d073bee
    • Louis-Francis Ratté-Boulianne's avatar
      qtdemux: Remove old pads when exposing streams and other general fixes. · d499b461
      Louis-Francis Ratté-Boulianne authored
      Conflicts:
      	gst/isomp4/qtdemux.c
      d499b461
    • Thiago Santos's avatar
      qtdemux: handle mss streams · a3c19eee
      Thiago Santos authored
      smoothstreaming streams should be handled as a special kind of
      fragmented isomedia. In MSS the fragments will not contain a
      'moov' atom with the media descriptions, this has to be extracted
      from the caps.
      
      Additionally, there should be another demuxer upstream that is likely
      going to be the one to answer/act on queries and events, so qtdemux has
      to forward those upstream.
      a3c19eee
  25. 04 Nov, 2012 1 commit
  26. 12 Oct, 2012 1 commit
  27. 27 Sep, 2012 1 commit
  28. 30 Dec, 2011 1 commit
  29. 30 Aug, 2011 1 commit
  30. 29 Jun, 2011 1 commit
  31. 16 May, 2011 1 commit
  32. 30 Apr, 2011 1 commit
  33. 12 Apr, 2011 1 commit
  34. 03 Dec, 2010 2 commits