Hi Alexander,
Thanks for the update ;)
On 02/05/2013 11:50 PM, Alexander Nestorov wrote:
Hi Sylwester :)
I have been working wth 2 guys from Collabora (company behind
GStreamer/Farstream) and there has been
some progress.
We saw that if I run gst-launch v4l2src ! dfbvideosink (without any
caps) then gstreamer won't show anything at all.
But as soon as I force caps, like v4l2src !
video/x-raw-rgb,width=XXX,height=YYY,bpp=16 ! dfbvideosink everything
starts working.
Same way, if I launch my Farstream app without any parameters, it
crashes. But if I specify bpp and depth then
it starts working.
I don't want to confuse you so I'll copy exactly what one of the guys said:
[23:02]<alexandernst_> KaKaRoTo: I have another question regarding
the CMOS and the caps "hack"
[23:03]<alexandernst_> we're setting bpp and depth because the driver
isn't returning: a) anything at all b) invalid values c) ???
[23:06]<KaKaRoTo> alexandernst_, because the driver is reporting big
endian for 16 bits, and it could easily be a gstreamer issue not
supporting big endian 16bits rgb.. or the driver is reporting the
endianness wrong...
[23:06]<KaKaRoTo> alexandernst_, the other reason is because the
driver isn't giving us the capabilities of the CMOS, so we don't knowh
Yes, the driver doesn't implement VIDIOC_ENUM_FRAMESIZES ioctl at
/dev/video? device node. These parameters are supposed to be retrieved
by a driver-specific plugin at the libv4l [1] (it still don't exists
yet..) library. And applications (e.g. v4l2src) should use v4l2_* calls
from this library, rather than plain ioctl(). Until the plugin for the
s3c-camif driver (or a generic Media Controller plugin) is added to
libv4l there is no way v4l2src can query the list of supported resolutions
by the CMOS sensor. Well, it could be hacked in the driver, but I don't
want to do that. I could send you a patch for your own use if you wish,
and if I find some time to write it. ;)
which resolutions it supports, so we're forced to manually setting it,
otherwise it tries to do 2048x4096 and it doesn't work..
This looks suspicious, let me check it...
Hmm, no, its GStreamer that forces the s3c-camif driver to use its maximum
supported resolution at /dev/video?.
root@mini2440:~ v4l2-ctl -d /dev/video0 --all
Driver Info (not using libv4l2):
Driver name : s3c-camif
Card type : s3c-camif
Bus info : platform:s3c2440-camif.0
Driver version: 3.8.0
Capabilities : 0x84000001
Video Capture
Streaming
Device Capabilities
Device Caps : 0x04000001
Video Capture
Streaming
Format Video Capture:
Width/Height : 1280/1024
Pixel Format : '422P'
Field : None
Bytes per Line: 1280
Size Image : 614400
Colorspace : JPEG (JFIF/ITU601)
Selection: compose, Left 0, Top 0, Width 1280, Height 1024
Selection: compose_default, Left 0, Top 0, Width 1280, Height 1024
Selection: compose_bounds, Left 0, Top 0, Width 1280, Height 1024
Video input : 0 (OV9650: ok)
Priority: 2
The default resolution is 1280/1024.
The problem is that there is not enough memory in your system to allocate
all 2048x4096 buffers (it's 16 MB each, 2 bytes per pixel for 422P format).
The driver doesn't enforce any policy on memory allocation, i.e. there is
no limit in the driver. I could add some module parameter for that if
required. But in general it's the v4l2 memory allocator that should return
an allocation error and it should be propagated up to v4l2 videobuf2 layer
and to GStreamer (e.g. through VIDIOC_REQBUFS ioctl).
IIRC there were some issues in the videobuf2 about reporting memory
allocation errors back to user space. Not sure if this is already fixed.
I'll investigate it and will let you know.
I have enabled debug in videobuf2 and got something like below, which
looks like something unexpected:
root@mini2440:~ echo 100 > /sys/module/videobuf2_core/parameters/debug
root@mini2440:~ gst-launch -v v4l2src device=/dev/video0 queue-size=2
! video/x-raw-yuv,format='(fourcc)'YV12 ! ffmpegcolorspace ! fbdevsink
root@mini2440:~ dmesg -c
[ 1907.110000] s3c-camif s3c2440-camif: dma_alloc_coherent of size
12582912 failed
[ 1907.115000] vb2: Failed allocating memory for buffer 1
The error is ignored here, it should all fail at this point.
[ 1907.120000] vb2: Buffer 0, plane 0 offset 0x00000000
[ 1907.125000] vb2: Allocated 1 buffers, 1 plane(s) each
[ 1907.220000] vb2: Buffer 0, plane 0 successfully mapped
[ 1907.225000] vb2: qbuf of buffer 0 succeeded
[ 1907.230000] vb2: Streamon successful
[23:07]<KaKaRoTo> which is also why it freezes (doesn't output
buffers) instead of giving an error when you try to set that
resolution
I made a bug report here, and there are 2 REs which might be really
helpful: https://bugzilla.gnome.org/show_bug.cgi?id=693175
On the other hand, I haven't noticed till now because I compile with
-j9, but I get this when I compile the kernel:
CC drivers/media/platform/s3c-camif/camif-capture.o
drivers/media/platform/s3c-camif/camif-capture.c: In function
's3c_camif_subdev_set_fmt':
drivers/media/platform/s3c-camif/camif-capture.c:1281:25: warning:
array subscript is below array bounds
Maybe that is somehow related to the bug I'm having?
This looks like a real bug, but I doubt it is much related to your
issues as above. Thanks for reporting it. I will prepare a patch for
this for v3.9-rc.
And please note that you should set resolution and frame rate
with e.g. media-ctl tool for optimal results. The libv4l plugin
would let us to do these things from the GStreamer level.
Let me answer your previous e-mail, but can do it only tomorrow...
Need more sleeeeping... ;)
--
Regards,
Sylwester
[1] http://git.linuxtv.org/v4l-utils.git
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
