Created attachment 363343 [details] [review]
concat: Handle single-pad use-cases

When EOS reaches concat, it will switch to the next candidate as its
activate pad.

The problem arises when there is only one sinkpad, the "active" pad
becomes NULL. This results in concat becoming unusable after it receives
a *single* EOS on its single sinkpad.

If we detect there is a single sinkpad and there is no current active pad:
* If we are waiting (from selected sink event/buffer), become the current
  active pad.
* If there is a seek request, send it upstream. We don't switch the
  active_sinkpad property at that point in time, since the seek could
  fail. If the seek succeeds, the following SEGMENT (or STREAM_START)
  will cause the pad_wait() to elect that pad as the new active one.
* Flush events get forwarded

Review of attachment 363343 [details] [review]:

I think this makes sense, re-reading some of my code, I notice that I simply remove the concat and create a new one if it reached that state. Being able to flush or seek it seems rather useful.

::: plugins/elements/gstconcat.c
@@ +398,3 @@
+    if (self->current_sinkpad == NULL && g_list_length (self->sinkpads) == 1) {
+      GST_LOG_OBJECT (spad, "Sole pad waiting, switching");
+      /* If we are the only sinkpad, take active pad ownership */

Maybe "If there is only one sinkpad, ..."

Comment on attachment 363343 [details] [review]
concat: Handle single-pad use-cases

commit f03443f90c6d5d143861f5e75990d06b700a5895 (HEAD -> master, origin/master, origin/HEAD)
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Fri Nov 10 14:10:31 2017 +0100

    concat: Handle single-pad use-cases
    
    When EOS reaches concat, it will switch to the next candidate as its
    activate pad.
    
    The problem arises when there is only one sinkpad, the "active" pad
    becomes NULL. This results in concat becoming unusable after it receives
    a *single* EOS on its single sinkpad.
    
    If we detect there is a single sinkpad and there is no current active pad:
    * If we are waiting (from selected sink event/buffer), become the current
      active pad.
    * If there is a seek request, send it upstream. We don't switch the
      active_sinkpad property at that point in time, since the seek could
      fail. If the seek succeeds, the following SEGMENT (or STREAM_START)
      will cause the pad_wait() to elect that pad as the new active one.
    * Flush events get forwarded
    
    https://bugzilla.gnome.org/show_bug.cgi?id=790167

This should've been closed, right?