[Bug 784958] New: v4l2transform: implement stable element names

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784958

            Bug ID: 784958
           Summary: v4l2transform: implement stable element names
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: m.tretter at pengutronix.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 355615
  --> https://bugzilla.gnome.org/attachment.cgi?id=355615&action=edit
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.