[Bug 739289] Stepping with Video-only Files not respecting step amount

[GStreamer (GNOME Bugzilla)]

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

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit b9a4a2a95276d28aaa0e105d834e6f10d6e49d6f
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Mon Jun 13 18:33:27 2016 +0200

    basesink: Update start time when losing state only if we were in PLAYING

    If we were in PAUSED, the current clock time and base time don't have much
to
    do with the running time anymore as the clock might have advanced while we
    were PAUSED. The system clock does that for example, audio clocks often
don't.

    Updating the start time in PAUSED will cause a) the wrong position to be
    reported, b) step events to step not just the requested amount but the
amount
    of time we spent in PAUSED. The start time should only ever be updated when
    going from PLAYING to PAUSED to remember the current running time (to be
able
    to compensate later when going to PLAYING for the clock time advancing
while
    PAUSED), not when we are already in PAUSED.

    Based on a patch by Kishore Arepalli <kishore.arepalli at gmail.com>

    The updating of the start time when the state is lost was added in commit
    ba943a82c0bbfd17c9ee9f5068d44c9d9274fd13 to fix the position reporting when
    the state is lost. This still works correctly after this change.

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

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