GNOME Bugzilla – Bug 619844
[basetransform] transform_caps can ignore pass-through
Last modified: 2011-06-15 17:28:29 UTC
Due to the way basetransform calls transform_caps it is possible that passthrough caps aren't used. To reproduce, the following launch line can be used: gst-launch videotestsrc ! video/x-raw-yuv,format=\(4\)YV12\;video/x-raw-yuv,format=\(4\)I420 ! ffmpegcolorspace ! video/x-raw-yuv,format=\(4\)YV12\;video/x-raw-yuv,format=\(4\)I420 ! ffmpegcolorspace ! video/x-raw-yuv,format=\(4\)YV12 ! xvimagesink -v This should show the pipeline switching from YV12 to I420, even though everywhere (but in template caps), YV12 is the preferred format. Here's what happens: Suppose we have a caps with two structures A B. The transform_caps function T will then transform them into a new caps A T(A) B T(B) If the peer then accepts caps from T(A) and B, it will not use the passthrough caps from B but the caps from T(A). And there's nothing an element can do about it. A suggestion is to add a flag to basetranform to say "pass the whole caps to the transform func instead of structure-by-structure". This would solve this issue and also the performance issues from bug 619806
Sounds good to me.
it might be better to create a new virtual method for transforming whole caps, else you'll break all existing transform plugins that don't know about that flag. Otherwise I'm totally for it :)
Another possibility is to have an allow_passthrough flag in basetransform, and if set, will transform the caps via "otherpad->peer->getcaps() + transform_caps(otherpad->peer->getcaps())".
*** Bug 623532 has been marked as a duplicate of this bug. ***
Created attachment 177390 [details] [review] Implement allow_passthrough This implements my last comment. It sort of works. In the videotestsrc ! ffmpegcolorspace ! ximagesink problem, it causes ffmpegcolorspace sinkpad to have a better order in the caps returned from getcaps(). However, the intersection with videotestsrc caps still gives YUY2 as the first. To really solve these sorts of issues, we should add a priority value to structures for 0.11. Don't like the idea of carrying around more stuff in caps, though.
Any comments on my patch? If it seems like a good route to take, I'll fix it up and add API.
A unit test somewhere (could be core or -base) would be nice too.
IMHO this looks more like a workaround for a deeper problem with how negotiation works... and reminds me of all the problems I currently see with the renegotiate/reconfigure event in basetransform. I don't have a solution though, other than adding priorities to caps structures, but that's something I'd like to prevent :)
This works as expected now in 0.10. In 0.11 negotiation is improved by adding filter caps to the getcaps functions and transform_caps. In 0.11 basetransform's transform_caps will soon get complete caps instead of getting them structure-by-structure. In 0.10 this is probably fixed by one (or the combination) of these commits: commit e8688b62b2d0536509c3b35bb962fa4dfe0de7d4 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu May 5 17:54:56 2011 +0200 basetransform: When trying to fixate the sink suggestion prefer its structure order commit f56c6e12255b37d75b1eb949e434fa8e3bb33f51 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed May 4 11:29:15 2011 +0200 basetransform: In getcaps() prefer the caps order and caps of downstream if possible commit b4bed6e09ee04d59e962dd4e9107769470d70153 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Tue May 3 17:26:53 2011 +0200 basetransform: Prefer caps order given by the subclass of the template caps order