[Bug 797130] decklink: sometimes displays a flashed frame of a previously played sequence

[GStreamer (GNOME Bugzilla)]

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

Matthew Waters (ystreet00) <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.15.1

--- Comment #7 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
commit 946cbbccc15f707857a550065fa7ba0028e4d627
Author: Matthew Waters <matthew at centricular.com>
Date:   Wed Sep 12 05:29:09 2018 -0500

    decklink: wait for stop with a timeout

    Decklink sometimes does not notify us through the callback that it has
    stopped scheduled playback either because it was uncleanly shutdown
    without an explicit stop or for unknown other reasons.

    Wait on the cond for a short amount of time before checking if scheduled
    playback has stopped without notification.

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

commit bf849e9a69442f7a6f9d4f0a1ef30d5a8009f689
Author: Matthew Waters <matthew at centricular.com>
Date:   Sun Jul 8 09:54:04 2018 -0500

    decklink: start scheduled playback in paused

    This is part of a much larger goal to always keep the frames we schedule to
    decklink be always increasing.  This also allows us to avoid using both the
    sync and async frame display functions which aren't recomended to be used
    together.

    If the output timestatmsp is not always increasing decklink seems to hold
    onto the latest frame and may cause a flash in the output if the played
    sequence has a framerate less than the video output.

    Scenario is play for N seconds, pause, flushing seek to some other
position,
    play again.  Each of the play sequences would normally start at 0 with
    the decklink time.  As a result, the latest frame from the previous
sequence
    is kept alive waiting for it's timestamp to pass before either dropping
    (if a subsequent frame in the new sequence overrides it) or displayed
    causing the out of place frame to be displayed.

    This is also supported by the debug logs from the decklink video sink
    element where a ScheduledFrameCompleted() callback would not occur for
    the frame until the above had happened.

    It was timing related as to whether the frame was displayed based
    on the decklink refresh cycle (which seems to be 16ms here),
    when the frame was scheduled by the sink and the difference between
    the 'time since vblank' of the two play requests (and thus start times
    of scheduled playback).

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

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