1. 18 Aug, 2015 6 commits
  2. 16 Aug, 2015 1 commit
  3. 15 Aug, 2015 2 commits
    • Edward Hervey's avatar
      decodebin2: Handle flushing with multiple decode groups · eaf9ca90
      Edward Hervey authored
      When an upstream element wants to flush downstream, we need to take
      all chains/groups into consideration.
      
      To that effect, when a FLUSH_START event is seen, after having it
      sent downstream we mark all those chains/groups as "drained" (as if
      they had seen a EOS event on the endpads).
      
      When a FLUSH_STOP event is received, we check if we need to switch groups.
      This is done by checking if there are next groups. If so, we will switch
      over to the latest next_group. The actual switch will be done when
      that group is blocked.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=606382
      eaf9ca90
    • Edward Hervey's avatar
      decodebin2: Forward event/queries for unlinked groups · 2d3743e3
      Edward Hervey authored
      When upstream events/queries reach sinkpads of unlinked groups (i.e.
      no longer linked to the upstream demuxer), this patch attempts to find
      the linked group and forward it upstream of that group.
      
      This is done by adding upstream event/query probes on new group sinkpads
      and then:
      * Checking if the pad is linked or not (has a peer or not)
      * If there is a peer, just let the event/query follow through normally
      * If there is no peer, we find a pad to which to proxy it and return
        GST_PROBE_HANDLED if it succeeded (allowing the event/query to be properly
        returned to the initial called)
      
      Note that this is definitely not thread-safe for the time being
      
      https://bugzilla.gnome.org/show_bug.cgi?id=606382
      2d3743e3
  4. 05 Aug, 2015 1 commit
  5. 14 Jul, 2015 2 commits
  6. 24 Apr, 2015 1 commit
  7. 09 Apr, 2015 1 commit
  8. 03 Apr, 2015 1 commit
  9. 27 Mar, 2015 1 commit
  10. 24 Mar, 2015 1 commit
  11. 26 Feb, 2015 1 commit
    • Edward Hervey's avatar
      playback: Fix broken GList modification · 7813315a
      Edward Hervey authored
      When we modify a GList (via g_list_delete_link), always reassign the
      new head to the original GList. Otherwise we end up with
      filtered_errors being corrupt (the head might have been the element
      removed)
      7813315a
  12. 24 Feb, 2015 1 commit
  13. 23 Feb, 2015 1 commit
    • Luis de Bethencourt's avatar
      decodebin: move null check · 8703d93b
      Luis de Bethencourt authored
      Check if dbin->decode_chain is NULL before running drain_and_switch_chains()
      because if it is, we shouldn't run that function or it will segfault.
      
      CID #1271074
      8703d93b
  14. 20 Feb, 2015 1 commit
  15. 19 Feb, 2015 3 commits
  16. 20 Jan, 2015 1 commit
  17. 17 Jan, 2015 1 commit
  18. 16 Jan, 2015 2 commits
  19. 14 Jan, 2015 1 commit
  20. 15 Dec, 2014 1 commit
  21. 01 Dec, 2014 1 commit
  22. 26 Nov, 2014 2 commits
    • Thibault Saunier's avatar
      decodebin: Analyze source pad before setting to PAUSED for 'simple demuxers' · 35f6259b
      Thibault Saunier authored
      Before we were setting them to PAUSED and (much) later connecting to
      their source pad caps notify signal.
      
      There was a race where that demuxer was pushing a caps and later a buffer
      on its source pad when we were not even connected to its source pad caps notify
      signal leading to decodebin missing the information and not keeping on
      building the pipeline on CAPS event thus the demuxer was posting an ERROR
      (not linked) message on the bus. This need to be done for 'simple
      demuxers' because those have one ALWAYS source pad, not like usual demuxers
      that have several dynamic source pads.
      
      A "simple demuxer" is a demuxer that has one and only one ALWAYS source
      pad.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740693
      35f6259b
    • Mathieu Duponchelle's avatar
      decodebin2: Take STREAM_LOCK before sending sticky events. · 68edf0eb
      Mathieu Duponchelle authored
      There was a race where:
      
      1) we would put the element to PAUSED
      2) It would get data sent to it from upstream
      3) It would thus send caps
      3) caps_notify_cb would continue autoplugging
      4) caps would flow downstream, the last pad would get exposed
      5) we were still not done sending the sticky events
      
      Taking the stream lock on the new element's sinkpad and only
      releasing it when sticky events have all been sent prevents
      the caps from reaching the source pad of the element before
      we're all set.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740694
      68edf0eb
  23. 26 Oct, 2014 2 commits
  24. 21 Oct, 2014 4 commits
  25. 07 Oct, 2014 1 commit