After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784958 - v4l2transform: implement stable element names
v4l2transform: implement stable element names
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: 1.15.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-14 16:05 UTC by Michael Tretter
Modified: 2018-07-01 19:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-v4l2transform-implement-stable-element-names.patch (1.05 KB, patch)
2017-07-14 16:05 UTC, Michael Tretter
none Details | Review
v4l2transform: Implement stable element name (1.25 KB, patch)
2018-07-01 19:35 UTC, Nicolas Dufresne (ndufresne)
none Details | Review
v4l2transform: Implement stable element name (1.24 KB, patch)
2018-07-01 19:44 UTC, Nicolas Dufresne (ndufresne)
none Details | Review
v4l2transform: Implement stable element name (1.23 KB, patch)
2018-07-01 19:45 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Michael Tretter 2017-07-14 16:05:12 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.
Comment 1 Nicolas Dufresne (ndufresne) 2017-07-14 16:28:56 UTC
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 ?
Comment 2 Nicolas Dufresne (ndufresne) 2018-07-01 19:35:37 UTC
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.
Comment 3 Nicolas Dufresne (ndufresne) 2018-07-01 19:37:09 UTC
Just a refresher of the patch, using v4l2videoconvert, and avoiding to dup/free for no reason (all minor).
Comment 4 Nicolas Dufresne (ndufresne) 2018-07-01 19:39:25 UTC
And still unsure between v4l2convert and v4l2videoconvert, considering v in v4l2 is video ...
Comment 5 Nicolas Dufresne (ndufresne) 2018-07-01 19:44:39 UTC
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.
Comment 6 Nicolas Dufresne (ndufresne) 2018-07-01 19:45:37 UTC
Created attachment 372905 [details] [review]
v4l2transform: Implement stable element name

Ok, decided to go for v4l2convert and giving you back the authorship (oops).
Comment 7 Nicolas Dufresne (ndufresne) 2018-07-01 19:46:03 UTC
Attachment 372905 [details] pushed as 442c377 - v4l2transform: Implement stable element name