GNOME Bugzilla – Bug 754076
videoconvert: overlay negotiation fails
Last modified: 2018-11-03 11:40:43 UTC
Created attachment 309955 [details] [review] videoconvert: properly transform caps containing added features With the following pipeline overlay negotiation fails between textoverlay and the sink: gst-launch-1.0 videotestsrc ! video/x-raw,format=YUV9 ! textoverlay text=YEAH font-desc="Arial 60" ! videoconvert ! glimagesink The caps filter forces videoconvert in non-passthrough mode. The transform_meta and filter_meta callbacks in videoconvert do let the overlay composition meta pass, but the caps transformation function (that remove the video format info) does not account for it. This means the caps with SystemMemory and other caps features will be ignored. The attached patch fixes this issue. Note that there are probably other elements with the same issue. videoscale for example, but in this case it's more complicated because we also need to scale the overlay composition.
Review of attachment 309955 [details] [review]: (Small note, I believe I wrote this patch ;-P) My concern with this PoC is that the caps negotiation becomes much wider the what we actually support. I have the impression that there should be some conditions base on being pass-through or not. For meta:VideoCompositionOverlay it totally make sense to me. For meta:VideoCrop also, but for some other meta (which might not exist yet) will it still make sense ? And if not, how will we make it negotiation properly ?
Sorry I didn't credit you, feel free to repost the patch with you as the author.
(In reply to Nicolas Dufresne (stormer) from comment #1) > Review of attachment 309955 [details] [review] [review]: > > (Small note, I believe I wrote this patch ;-P) My concern with this PoC is > that the caps negotiation becomes much wider the what we actually support. > I have the impression that there should be some conditions base on being > pass-through or not. > > For meta:VideoCompositionOverlay it totally make sense to me. For > meta:VideoCrop also, but for some other meta (which might not exist yet) > will it still make sense ? And if not, how will we make it negotiation > properly ? You can query the tags of a specific meta, and use that to decide if you can pass it through or not.
Ok, as it never bee done before, please correct me, but for each feature that would mean: Split the string on the column ":", take the first part and get the GstMetaInfo. From there, you can check if that meta has tag. Seems like a pretty heavy thing to do, but possible.
I don't know what else we could do here :) It doesn't seem ideal
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/216.