[Bug 750402] tsdemux: pads are removed before new ones are added

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=750402

Edward Hervey <bilboed at bilboed.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bilboed at bilboed.com
         Resolution|---                         |FIXED

--- Comment #11 from Edward Hervey <bilboed at bilboed.com> ---
commit 531117b7df1002f816f2a4e3259fdcdfa470cb72
Author: Edward Hervey <edward at centricular.com>
Date:   Tue Oct 20 17:22:23 2015 +0200

    tsdemux: Push GAP events *after* deactivating old programs

    The order in which program switch must happen is:
    1) drain all data on old pads (but don't push EOS)
    2) add new pads (but don't push any data on them)
    3) Push EOS and remove old pads
    4) Start pushing data on new pads

    There was one caveat in this implementation, which is that when
    we activate a sparse pad (step 2) we would push a GAP event. The problem
    is that, while being an event, it is actually *data*.

    We therefore need to make sure pushing those GAP event is done at the step
    we start pushing data.

    https://bugzilla.gnome.org/show_bug.cgi?id=750402

commit 7336294635d6066c812ca918e799a5ed21f177bb
Author: Edward Hervey <edward at centricular.com>
Date:   Tue Sep 15 18:20:38 2015 +0200

    tsdemux: Make sure old streams are drained before switching

    Before we add any streams, make sure we drain all streams. This ensures
    there's consistency that only "new" data will be pushed on buffers once
    the new pads are added

    https://bugzilla.gnome.org/show_bug.cgi?id=750402

commit 14e6d2d42736a66cd83b08113f4a067943443b11
Author: Edward Hervey <bilboed at bilboed.com>
Date:   Thu Sep 10 14:55:05 2015 +0200

    mpegtsdemux: Allow deactivation of programs to be delayed

    When changing programs, the order of events needs to be the following:
    * add pads from new program
    * send EOS on old pads
    * remove old pads
    * emit 'no-more-pads'

    Previously tsdemux was not doing that, and was first deactivating and
    removing old pads before adding new ones.

    We fix this by allowing subclasses of mpegtsbase to be able to handle
    themselves the deactivation of programs. In this case tsdemux will
    properly deactivate it once it has activated the new program.

    https://bugzilla.gnome.org/show_bug.cgi?id=750402

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.