GNOME Bugzilla – Bug 750032
videorate: fails to renegotiate on streams with a variable framerate
Last modified: 2015-05-29 13:42:16 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.
Any chance you could add a unit test for this too? :)
Created attachment 304196 [details] [review] unit test There you go :)
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