[Bug 726104] Proposal for a v4l2scale element
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue Mar 11 09:53:43 PDT 2014
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.
More information about the gstreamer-bugs
mailing list