Format enumeration in Gstreamer expects drivers to implement VIDIOC_ENUM_FMT and if not, it calls
VIDIOC_TRY_FMT on a set of "emulated formats" which could be unsupported resulting in failure of
the format negotiation stage [1]
We add UYVY to the set of formats making the mt9v113 sensor in this camera board and other sensors
that don't support the emulated formats work out-of-the box without needing a caps filter element
[1] http://lists.freedesktop.org/archives/gstreamer-devel/2011-July/032425.html
Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
I must be missing something, but what has negotation failure to do with adding a new format? I would expect adding new formats not to have any effect if negotiation fails.
Anyway, could you add a 'upstream-status' tag to the patch as described in http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations ?
Format enumeration in Gstreamer expects drivers to implement VIDIOC_ENUM_FMT and if not, it calls
VIDIOC_TRY_FMT on a set of "emulated formats" which could be unsupported resulting in failure of
the format negotiation stage [1]
We add UYVY to the set of formats making the mt9v113 sensor in this camera board and other sensors
that don't support the emulated formats work out-of-the box without needing a caps filter element
[1] Gstreamer v4l2src could not negotiate format
Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com>
---
...-UYVY-color-format-to-the-list-of-enumera.patch | 43 ++++++++++++++++++++
recipes/gstreamer/gst-plugins-good_0.10.28.bb | 4 +-
2 files changed, 46 insertions(+), 1 deletions(-)
create mode 100644 recipes/gstreamer/gst-plugins-good/0001-v4l2src-Add-UYVY-color-format-to-the-list-of-enumera.patch
diff --git a/recipes/gstreamer/gst-plugins-good/0001-v4l2src-Add-UYVY-color-format-to-the-list-of-enumera.patch b/recipes/gstreamer/gst-plugins-good/0001-v4l2src-Add-UYVY-color-format-to-the-list-of-enumera.patch
new file mode 100644
index 0000000..88a0125
--- /dev/null
+++ b/recipes/gstreamer/gst-plugins-good/0001-v4l2src-Add-UYVY-color-format-to-the-list-of-enumera.patch
@@ -0,0 +1,43 @@
+From d5a1f365bfd4420912735709bcb8004d3ad7226c Mon Sep 17 00:00:00 2001
+From: Joel A Fernandes <agnel.joel@gmail.com>
+Date: Fri, 29 Jul 2011 17:23:43 -0500
+Subject: [PATCH] v4l2src: Add UYVY color format to the list of enumerations
+
+OMAP3 ISP returns -EINVAL for VIDIOC_ENUM_FMT ioctl on video node. Due to this, format negotiation fails. This adds UYVY format to the list of enumerations.
I must be missing something, but what has negotation failure to do with adding a new format? I would expect adding new formats not to have any effect if negotiation fails.
The way it works is:
Enumerate formats -> Negotiate formats between source and sink pads
and set the format
Enumerate formats doesn't return UYVY (The driver is supposed to
return this but ENUM_FMT ioctl is not implemented in ISP like I was
saying). Due to this, the negotiate function is either unable to find
a matching format on the sink pad (if you used a UYVY caps filter
element) or fails to set the format if you used a more general
element.
Anyway, could you add a 'upstream-status' tag to the patch as described in http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations ?
This patch is more like a harmless hack which works around a
limitation of the driver. It is unlikely that it will be accepted by
upstream or if it should even be submitted as an RFC. Considering
this, would it be ok if I prepended "HACK!" to the title? I noticed
this in your 1GHz patches
Thanks,
Joel
Joel A Fernandes wrote:
+From d5a1f365bfd4420912735709bcb8004d3ad7226c Mon Sep 17 00:00:00 2001
+From: Joel A Fernandes<agnel.joel@gmail.com>
+Date: Fri, 29 Jul 2011 17:23:43 -0500
+Subject: [PATCH] v4l2src: Add UYVY color format to the list of enumerations
+
+OMAP3 ISP returns -EINVAL for VIDIOC_ENUM_FMT ioctl on video node. Due to this, format negotiation fails. This adds UYVY format to the list of enumerations.
I must be missing something, but what has negotation failure to do with adding a new format? I would expect adding new formats not to have any effect if negotiation fails.
The way it works is:
Enumerate formats -> Negotiate formats between source and sink pads
and set the format
Enumerate formats doesn't return UYVY (The driver is supposed to
return this but ENUM_FMT ioctl is not implemented in ISP like I was
saying). Due to this, the negotiate function is either unable to find
a matching format on the sink pad (if you used a UYVY caps filter
element) or fails to set the format if you used a more general
element.
and why not make ENUM_FMT ioctl return what is needed??? Instead
of "hacking" the gst driver?
Joel A Fernandes wrote:
Hi Vladimir,
and why not make ENUM_FMT ioctl return what is needed??? Instead
of "hacking" the gst driver?
That'll be a hack as well:
Re: [PATCH] omap3isp: implement ENUM_FMT
Oh well, so in the end V4L2 is not the right API to capture video
on OMAP....
On anything it seems, since it's a hack to add a mandatory IOCTL...