GNOME Bugzilla – Bug 784958
v4l2transform: implement stable element names
Last modified: 2018-07-01 19:46:44 UTC
Created attachment 355615 [details] [review] 0001-v4l2transform-implement-stable-element-names.patch Similar to the stable names for the v4l2 video decoder and v4l2 video encoder elements, it would be nice to have stable names for the v4l2 video convert elements as well. They are also affected by changing node names between reboots and, as they are not yet usable with autoplugging, pipelines have to explicitly refer to the elements which makes the situation much worse. As first draft, we could just drop the node from the first element name, which would at least guarantee that, if we have at least one v4l2 device available, a pipeline will try to use it. This should lead to more stable pipelines. However, this is based on the assumption that the first v4l2 device always implements all functionality that the used pipeline expects, which is not necessarily true. Hopefully, a SoC will only have one v4l2 convert, which will always be available as v4l2convert and, at least in these cases, the name will be independent of the node. I considered the following ideas for the naming as well, but none of them were really convincing: - Add the provided functionality in the name, i.e, v4l2convert, v4l2deinterlace, v4l2scale, v4l2colorscale..., which allows to select elements that provide the expected features. However, I don't want to split conversions into multiple steps if the hardware can do it at once and I even didn't find a way to get that information from the v4l2 device during the registration. - Add the v4l2 driver name in the element's name, because then we can be sure that the element provides the functionality that we are expecting. However, then the pipeline would be coupled with the used hardware and cannot be reused across different platforms, which isn't a good solution either. I'm not really sure to do it right, so any comments or ideas are very welcome.
For this use case, I always had the impression that the kernel lacks classification flags. As an example, v4l2transform simply does not work for deinterlacer at the moment. It should work for color converter and/or scaler, but might have strange results with blitters that can color convert (specially if the input is not opaque). In this list, the blitter is really a thing that exist (IMX6 and Exynos) but that we can't differentiate from the rest and where fixes name can cause much more trouble then good. I think we need some time to figure-out what to do in the long term. Meanwhile, I'll give you patch a try, maybe we can find a way to enumerate all the "converters" before assigning names, and run some heuristic to pick the best videoconvert/videoscale replacement ?
Created attachment 372903 [details] [review] v4l2transform: Implement stable element name The first converter to be found will now gain the same v4l2videoconvert. Other converters will be named after the m2m dev node end point they are attached to.
Just a refresher of the patch, using v4l2videoconvert, and avoiding to dup/free for no reason (all minor).
And still unsure between v4l2convert and v4l2videoconvert, considering v in v4l2 is video ...
Created attachment 372904 [details] [review] v4l2transform: Implement stable element name The first converter to be found will now gain the same v4l2videoconvert. Other converters will be named after the m2m dev node end point they are attached to.
Created attachment 372905 [details] [review] v4l2transform: Implement stable element name Ok, decided to go for v4l2convert and giving you back the authorship (oops).
Attachment 372905 [details] pushed as 442c377 - v4l2transform: Implement stable element name