[Bug 726104] Proposal for a v4l2scale element

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=726104
  GStreamer | gst-plugins-good | 1.2.3

--- Comment #3 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-03-11 17:17:05 UTC ---
Review of attachment 271520:
 --> (https://bugzilla.gnome.org/review?bug=726104&attachment=271520)

Ok, on my side, what I've been working on is a more generalized. This
implementation only has support for 1 scaler. Also, many platform have
multi-purpose transformation. I'll keep that here as a reference, but I'd
prefer having a transform framework from which we would correctly detect
devices based on a supported list, and flag the feature (like transform,
scaling, colorbalance, etc) that are supported.

::: sys/v4l2/gstv4l2scale.c
@@ +205,3 @@
+    }
+    i++;
+  } while (v4l2object->videodev == NULL && i < MAX_VIDEO_DEVICES);

MAX being 10, on my HW the scaler is found at 10, 12, 14 and 16. I want a
generalized way to probe HW, and remove the overhead (something that works too
even if dev are renamed, so udev should be the way), since atm each new class
do a full probing again and gain.

@@ +536,3 @@
+
+  LOG_CAPS (v4l2scale, incaps);
+  LOG_CAPS (v4l2scale, outcaps);

Any reason to have customer logging ?

@@ +539,3 @@
+
+  sinkObj = v4l2scale->v4l2sinkobject;
+  srcObj = v4l2scale->v4l2srcobject;

Coding style is sink_obj, not camel.

@@ +589,3 @@
+
+static gboolean
+gst_v4l2scale_decide_allocation (GstBaseTransform * trans, GstQuery * query)

These need to be generalized, see propose_allocation.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.