GNOME Bugzilla – Bug 609046
basetransform now ignores suggestions from capsfilter
Last modified: 2010-03-16 23:44:15 UTC
Commit 743cde4b requires a valid size for a suggestion to be used in pad alloc. so if I have a pipeline like "v4l2src ! capsfilter ! ...", I can't control the camera's resolution by just changing the caps in the capsfilter anymore (since basetransform will ignore it since it doesn't contain a size). So this is a regression. That said, I'm not sure that reverting that patch is a smart idea. We should just drop the pretense that pad allocation is the right place to do upstream caps renegotiation and instead add a "renegotiate" upstream event, but I guess that's post-release work.
I don't know how it could have ever worked before because the allocation would have failed with an assertion if no size was set anyway. Did it really work before? But yes, we definitely need to separate buffer allocation and upstream negotiation in some way :)
Ok, Olivier said that it had worked before. Anybody has ideas how it could've worked?
I'm also not quite sure how this would have worked before, since as far as I know v4l2src (or basesrc) doesn't do pad_alloc_buffer. I guess we need to write a test case to find out :-)
I presume all the dynamic tess in gst-plugins-good/tests/icles/ still work? (videocrop/videobox tests) (can't test right now because I don't have xvimagesink here)
...and even then basetransform couldn't do anything useful in pad_alloc_buffer() because it doesn't know how the large the buffers should be that should be allocated. Very mysterious :)
Well, capsfilter calls gst_base_transform_suggest(), so it must have worked at some point.. Maybe I'm just wrong and it never worked.
Some more context - please correct me if I'm wrong Olivier: - the v4l2 source Olivier is using is Nokia's version which apparently does do gst_pad_alloc_buffer() - the filter caps set would be fixed and complete caps I think we should be able to replicate this with videotestsrc ! capsfilter ! ximagesink ?
Right now, even if that patch was reverted, the capsfilter code would still only work if complete fixed caps are specified, because they are suggested as-is. So in the short term, I don't mind doing nothing for this release.
Ok, thanks for the update. However, you seemed to claim that something used to work at some point that doesn't work any longer, so I'd still be interested to know what that was, and when it used to work where. FWIW, there'll be another core/base release at the end of February.
My understanding was that you could influence the state of a running pipeline by changing a capsfilter, but maybe I am wrong.
Created attachment 156264 [details] [review] basetransform: Suggest even if the size is 0 Capsfilter caps suggestions are being ignored because it sets size suggestion to 0. This checking to basetransform was added because of a temporary fix for bug #576234, but it caused bug #609046. This fix has the same objective of the temporary fix, but doesn't cause #609046. Fixes #609046
Pushed this fix. If it still fails for you Olivier, please reopen. Module: gstreamer Branch: master Commit: a6a3c129d11e81e932b5e4ce2b42f1294d135e3c URL: http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=a6a3c129d11e81e932b5e4ce2b42f1294d135e3c Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Tue Mar 16 10:32:12 2010 -0300 basetransform: Accept non-fixed caps suggestions When doing pad_allocs, use non-fixed caps suggestions and try to fixate them before using. This makes possible to have suggested buffer size with 0 in basetransform just to signal upstream a renegotiation is needed Fixes #576234 Fixes #609046