![]() |
Fremantle GStreamer
Hi all,
I'm willing to test GStreamer applications on Fremantle hardware. It would really help multimedia developers if someone could provide GStreamer Editor for Fremantle, to help figure out how to build correct pipelines. |
Re: Fremantle GStreamer
Ok, basic gstreamer pipeline from camera to screen:
v4l2src device=/dev/video0 ! autovideosink For high resolution (back) camera, it is /dev/video0 and for the front web camera, it is /dev/video1. The output needs to be massaged, so that the aspect ratio is correct, etc. |
Re: Fremantle GStreamer
Can you change the self.player line to the one below and try again. Post the output here.
Code:
self.player = gst.parse_launch ('v4l2src device=/dev/video0 ! video/x-raw-yuv,width=320,height=240,framerate=(fraction)15/1 ! autovideosink') |
Re: Fremantle GStreamer
Just trying that pipeline from the command line (gst-launch), I start getting "cannot negotiate format" as soon as I start adding the width, height, or framerate values...
How do you check what the device's capabilities are? There's got to be a way to query the device for acceptable parameters... |
Re: Fremantle GStreamer
Use the following generic string instead. It should either work or dump out an error message with some width/height info.
Code:
self.player = gst.parse_launch ('v4l2src device=/dev/video0 ! autovideosink') |
Re: Fremantle GStreamer
Yes, that very simple pipeline works. It displays the back camera's view in a square window in the middle of the screen (above your two buttons). I'd post a screenshot, but it appears that the screenshot utility doesn't capture the picture, just a black square where the picture is.
There was no output on the command line. |
Re: Fremantle GStreamer
Just a note for future reference, since it is in a completely different thread; daperl's original camera script can be found here.
|
Re: python / gstreamer / camera / xvimagesink issues
Ok, so the output of the large camera is 640 x 492 encoded as YUYV.
|
Re: python / gstreamer / camera / xvimagesink issues
Actually although that gives you good Y data, the U and V data are probably arranged a little differently in the data stream (as for each of these you get two images side by side).
More testing... |
Re: Fremantle GStreamer
The script you pointed to doesn't really do anything. The following really, really bad hack will actually take a picture and create a .png file on an n800. As is, it won't work on an n900, but the changes should be obvious.
Also, the file creation is really, really slow; about 25 seconds. It's strictly just a hard-coded, proof-of-concept that a picture can be taken on a tablet with just using PyGTK and GStreamer. Obviously, plenty of room for improvement. Code:
#! /usr/bin/env python |
Re: Fremantle GStreamer
Quote:
|
Re: Fremantle GStreamer
Run this script and post the output. It won't save a picture, it should just give me information about the captured buffer. Then I'll post back an n900 save solution while I work on a more general one. This is fun; I haven't flipped bits in a long while.
Code:
#! /usr/bin/env python |
Re: Fremantle GStreamer
1 Attachment(s)
I've cut file creation down to under
numpy could be just what the doctor ordered. |
Re: Fremantle GStreamer
I f you want to go beyond http://wiki.maemo.org/Documentation/...mera_API_Usage then I recommend you to ask to maemo-developers where some of our Multimedia developers are following.
|
Re: Fremantle GStreamer
1 Attachment(s)
Code:
/* Initialize the the Gstreamer pipeline. Below is a diagram I quickly tried modifying things so that the image queue path doesn't run until a snapshot is requested, but I haven't had luck there yet. So, even though a file isn't created until the button's clicked, the Image queue and the Image filter are processing every frame. On my n800, that's 640x480 @ 15 fps. For the n900, that would be more like 2592x1944 @ 25 fps. According to the specs, the supplied video recorder does 848x480 @ 25 fps with unknown sound quality. Pretty good, and I'm guessing the supplied camera app doesn't use the above pipeline. But if it does, which I doubt, there seems to be room for improvement. The problem here is that you really only want to be pushing the decimated view finder pixels until it's picture time, so I really just want some hardware decimated camera buffer. Instead, with a pipeline like this, I'm using the CPU to decimate the feed. Currently, I'm using a view window of 320x240. From the n900 demos, it looks like they're using close to the whole 800x480. And since I haven't figured out how to no-op the Image queue until photo request, I have two unnecessary loads. My next two steps are to see if I can change the Camera src capabilities on-the-fly, and also see if I can dynamically link and unlink the Image branch from the tee when taking a picture. The first might need a pipeline start-and-stop, but the second might just need a simple switch that I haven't found yet. But most importantly, are the camera and video apps open source? :) |
Re: python / gstreamer / camera / xvimagesink issues
1 Attachment(s)
Attached is a hard-coded, proof-of-concept that works on my n800. Look at it closely 'cause you'll probably have to change a few things to get it working on the n900. Including, but not limited to, anything that says:
Code:
if self.machine == 'armv6l': More info about what I've been doing can be found here. |
Re: python / gstreamer / camera / xvimagesink issues
I tried several Vala Gstreamer samples from http://live.gnome.org/Vala/GStreamerSample -- the last one is working well with N900 when v4l2camsrc is used instead of videotestsrc.
While this is not a Python, you can easily see how to use gstreamer correctly and I can confirm that this approach works well on the device with both cameras (front and rear). |
Re: python / gstreamer / camera / xvimagesink issues
Just a note, guys. The original post (from the thread that this post was originally in before sjgadsby unceremoniously dumped everything in the right thread) is talking about Diablo and the tablets, not Fremantle and the N900...
I know that's where everyone's head is these days, but read closely... :) |
Re: python / gstreamer / camera / xvimagesink issues
Quote:
|
Re: python / gstreamer / camera / xvimagesink issues
I wish I had looked at the original post's timestamp :)
|
Re: python / gstreamer / camera / xvimagesink issues
Quote:
|
Re: python / gstreamer / camera / xvimagesink issues
It's lardman's fault. He should have posted on my thread not this ancient, crusty thread.
And sorry, daperl, I haven't tested your scripts yet. My brain was refusing to go into "work" mode all weekend. It just wanted to sit around on the couch and drink beer. :( |
Re: python / gstreamer / camera / xvimagesink issues
Sorry, I thought this was the thread you were talking about!
|
Re: python / gstreamer / camera / xvimagesink issues
Quote:
Quote:
|
Re: python / gstreamer / camera / xvimagesink issues
Quote:
|
Re: Fremantle GStreamer
So while we're at it, what are the thoughts on camera focusing?
There are v4l2 hooks there in ad5820.c iirc, and it looks like the camerabin component (or photography interface) can use them. However as I'm currently writing in Python, that's not so great. There is the v4l2camsrc, which looks like it's linked to the above, but I'm not sure I can do anything with it (as it just appears as a source afaict). Otherwise I'm considering talking to the ad5820 directly using ioctls, but then I need to work out how to pull in the isp_af functionality, or implement my own (which would be interesting, but ultimately a waste of time). So, anyone have any bright ideas? |
Re: Fremantle GStreamer
lardman: this is output from Fremantle VLC that you might find useful:
Code:
opening device '/dev/video0' |
Re: Fremantle GStreamer
Good, at least the focus components are available through v4l2 on the device. No auto focus there, but just altering it would be good as a starting point.
|
Re: Fremantle GStreamer
Hmm, using v4l2camsrc, I get a frame which is 61440 in size.
Now that is 640 x 480 x 2 But the camera is not supposed to return that frame size, and also it seems an odd encoding, either you get a one-to-one YUV, or the U and V data are a 1/4 the size of the Y data, so I'd expect the total frame to be 640 x 480 x 1.5. Though I guess there are other encodings available (and this seems to be the same one I saw before). Perhaps it's just the fact it's morning ;) Indeed just morning. As the encoding is UYVY (or something like that), for every 2 Y pixels we have a total of 4*8 byes = 32bytes. 32/2 = 16bytes total per pixel -> the frame is twice the size of the resolution. Doh! |
Re: Fremantle GStreamer
What does the line, "device codec BA10 (Bayer10 (GrR/BGb)) not supported" mean I wonder? What's Bayer10 (GrR/BGb)?
|
Re: Fremantle GStreamer
Bayer10 is RAW sensor data format. Most camera sensors allow export of data in either already pre-processed format (some form of YUV) or in raw, usually unprocessed output of sensor.
As sensor typically has number of color filters, they need to be placed in certain order and quantities to allow capture of light similar to what our eye does. Bryce E. Bayer from Eastman Kodak developed specific arrangement pattern where 50% of green and 25% of red and blue are used. This pattern became quite popular and thus output format from any sensor that uses this arrangement is called Bayer pattern. Bayer 10 means 10-bit values for Green Red Blue Green output from the sensor. "not supported" here means that V4L2 driver for this particular sensor does not allow to access to RAW output from Bayer filter of the sensor. Perhaps, the RAW output is possible to get by other ways, but V4L2 driver implementation simply does not give you such output. |
Re: Fremantle GStreamer
Note to self: Just create jpeg's.
I just switched from creating 'png' files to creating 'jpeg' files and creation time is now two blinks of an eye. And that's with quality set to 100%. |
Re: Fremantle GStreamer
This seems to be good news to me: GDigicam at maemo.gitorious.org
|
Re: Fremantle GStreamer
5 Attachment(s)
Do you not have a Fremantle dev environment? If yes, why?
I've attached the non-doc/dbg debs if you wanted to try it out. |
Re: Fremantle GStreamer
I just meant it is good news to see fresh source code in this area being posted and developed in real time.
EDIT: The examples and tests look interesting, though... |
All times are GMT. The time now is 13:00. |
vBulletin® Version 3.8.8