1. 14 Feb, 2018 21 commits
  2. 10 Feb, 2018 19 commits
    • Edward Hervey's avatar
      playbin3: Re-enable buffering message handling · eacb7a77
      Edward Hervey authored
      Buffering messages are only sent for the active group (in case there
      is more than one).
      
      If the inactive group posts buffering messages we keep the last one
      around and will post it once it becomes the playing one.
      eacb7a77
    • François Laignel's avatar
      decodebin3: high cpu usage after eos · ec7d81f6
      François Laignel authored
      After eos, decodebin3 enters a loop sending eos events which causes high cpu usage.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=792693
      ec7d81f6
    • Edward Hervey's avatar
      decodebin3: Handle dual-output of STREAM_START/EOS · 1f792ab8
      Edward Hervey authored
      In order to flush out multiqueue, we send again a STREAM_START and
      then a EOS event.
      
      The problem was that was that we might end up pushing out on the
      output of multiqueue (and therefore decodebin3) a series of:
      * EOS / STREAM_START / EOS
      
      Apart from the uglyness of such output, If decodebin3 is used with
      elements such as concat on their output, they might potentially
      block on that second STREAM_START.
      
      In order to make sure we don't end up in that situation we send
      a custom STREAM_START event when refreshing multiqueue (which we
      drop on the output) and we don't special case EOS events on streams
      on which we already got EOS.
      
      At worst we now end up sending at most two EOS on the output of
      multiqueue (and decodebin3).
      1f792ab8
    • Edward Hervey's avatar
      playbin3: Implement gapless playback · c1e902a0
      Edward Hervey authored
      Similar in vein to the playbin2 architecture except that uridecodebin3
      are prerolled much earlier and all streams of the same type are
      fed through a 'concat' element.
      
      This keeps the philosphy of having all elements connected as soon
      as possible.
      
      The 'about-to-finish' signal is emitted whenever one of the uridecodebin
      is about to finish, allowing the users to set the next uri/suburi.
      
      The notion of a group being active has changed. It now means that the
      uridecodebin3 has been activated, but doesn't mean it is the one
      currently being outputted by the sinks (i.e. curr_group and next_group).
      This is done via detecting GST_MESSAGE_STREAM_START emission by playsink
      and figuring out which group is really playing.
      
      When the current group changes, a new thread is started to deactivate
      the previous one and optionnaly fire 'about-to-finish'.
      c1e902a0
    • Edward Hervey's avatar
      playbin3: Use uridecodebin3 and link/reconfigure immediately · b9e73d05
      Edward Hervey authored
      Apologies for the big commit, but it wasn't really possible to split it
      in anything smaller.
      
      * Switch to uridecodebin3 instead of managing urisourcebin and decodebin3
      ourselves. No major architectural change with this.
      
      * Reconfigure sinks/outputs when needed. This is possible thanks to the
      various streams-related API. Instead of blocking new pads and waiting
      for a (fake) no-more-pads to decide what to connect, we instead reconfigure
      playsink and the combiners to whatever types are currently selected. All of
      this is done in reconfigure_output().
        New pads are immediately connected to (combiners and) sinks, allowing
      immediate negotiation and usage.
      
      * Since elements are always connected, the "cached-duration" feature is gone
      and queries can reach the target elements.
      
      * The auto-plugging related code is currently disabled entirely until
      we get the new proper API.
      
      * Store collections at the GstSourceGroup level and not globally
      
      * And more comments a bit everywhere
      
      NOTE: gapless is still not functional, but this opens the way to be able
      to handle it in a streams-aware fashion (where several uridecodebin3 can
      be active at the same time).
      b9e73d05
    • Edward Hervey's avatar
      urisourcebin: Add 'about-to-finish' signal · ebf138e2
      Edward Hervey authored
      With push-based sources, urisourcebin will emit this signal when
      the stream has been fully consumed.
      
      This signal can be used to know when the source is done providing
      data.
      ebf138e2
    • Edward Hervey's avatar
      playback: New uridecodebin3 element · 08044ab7
      Edward Hervey authored
      In the same vein as old uridecodebin except that it also
      accepts a suburi and uses urisourcebin and decodebin3 internally
      08044ab7
    • Edward Hervey's avatar
      playbin3: Remove wrong 'notify' · 28584006
      Edward Hervey authored
      Those properties doesn't exist on playbin3, don't emit a notify for that
      28584006
    • Edward Hervey's avatar
      playbin3: Remove setting 'subtitle-encoding' on decodebin · 8386ea70
      Edward Hervey authored
      That property doesn't exist
      8386ea70
    • Edward Hervey's avatar
      7b8cfb9e
    • Edward Hervey's avatar
      playbin3: Remove unused define · 4ed0708f
      Edward Hervey authored
      4ed0708f
    • Edward Hervey's avatar
      decodebin3: Use GST_GROUP_ID_INVALID · 9e7401be
      Edward Hervey authored
      9e7401be
    • Edward Hervey's avatar
      decodebin3: Don't forward already-handling SELECT_STREAMS · dd7a1407
      Edward Hervey authored
      Upstream might respond negatively to the event, whereas we actually
      handled it.
      dd7a1407
    • Edward Hervey's avatar
      decodebin3: Add new about-to-finish signal · 401cadfd
      Edward Hervey authored
      401cadfd
    • Edward Hervey's avatar
      decodebin3: Remove unused definition · c136acf2
      Edward Hervey authored
      c136acf2
    • Edward Hervey's avatar
      decodebin3: Don't take the lock when creating a new input · fa710a59
      Edward Hervey authored
      We only need to take the input lock when adding/removing
      inputs from the list.
      fa710a59
    • Edward Hervey's avatar
      playbin3: Remove unused variable · fa9adbe9
      Edward Hervey authored
      The lock is never used
      fa9adbe9
    • Edward Hervey's avatar
      urisourcebin: Remove auto-plugging signals · 1717e33d
      Edward Hervey authored
      They were never used and we need a better system
      1717e33d
    • Edward Hervey's avatar
      urisourcebin: Remove ASYNC behaviour · e5157ca4
      Edward Hervey authored
      It is not needed in the new streams-aware world
      e5157ca4