[Bug 750032] videorate: fails to renegotiate on streams with a variable framerate

[GStreamer (GNOME Bugzilla)]

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

George Kiagiadakis <george.kiagiadakis at collabora.com> changed:

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

--- Comment #3 from George Kiagiadakis <george.kiagiadakis at collabora.com> ---
commit c84f911cee427ea8e1759cccfa99950c1e0988d3
Author: George Kiagiadakis <george.kiagiadakis at collabora.com>
Date:   Thu May 28 12:51:35 2015 +0200

    videorate: update the caps framerate only in the GST_PAD_SINK
transform_caps direction

    When a stream has a variable framerate, videorate calculates it and
    forces it on the output caps. However, the code in _transform_caps()
    currently also does that if the transform is going in the opposite
    direction (GST_PAD_SRC), so during a renegotiation it tries to force
    upstream to use the calculated framerate and it fails.

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

commit a998d380bd817ccd28f764ba57e4903c9b1efee4
Author: George Kiagiadakis <george.kiagiadakis at collabora.com>
Date:   Thu May 28 19:49:31 2015 +0200

    tests: add test for videorate caps renegotiation after a framerate has been
calculated and added to caps

    The original 0/1 framerate must still be allowed to be configured
    on the upstream side of videorate, otherwise future caps renegotiation
    is going to fail.

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

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