After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 750032 - videorate: fails to renegotiate on streams with a variable framerate
videorate: fails to renegotiate on streams with a variable framerate
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-28 13:00 UTC by George Kiagiadakis
Modified: 2015-05-29 13:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that solves the issue (1.25 KB, patch)
2015-05-28 13:00 UTC, George Kiagiadakis
committed Details | Review
unit test (2.01 KB, patch)
2015-05-28 17:57 UTC, George Kiagiadakis
committed Details | Review

Description George Kiagiadakis 2015-05-28 13:00:31 UTC
Created attachment 304155 [details] [review]
Patch that solves the issue

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.

The attached patch solves this issue.
Comment 1 Tim-Philipp Müller 2015-05-28 13:23:27 UTC
Any chance you could add a unit test for this too? :)
Comment 2 George Kiagiadakis 2015-05-28 17:57:18 UTC
Created attachment 304196 [details] [review]
unit test

There you go :)
Comment 3 George Kiagiadakis 2015-05-29 13:07:40 UTC
commit c84f911cee427ea8e1759cccfa99950c1e0988d3
Author: George Kiagiadakis <george.kiagiadakis@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@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