View Single Post
Posts: 65 | Thanked: 143 times | Joined on Dec 2009 @ Helsinki
#682
Whoa, that was a long thread to read.

All right guys, first of all most developers don't visit forums. If you want to get something done, use the proper channels:

http://code.google.com/p/gst-dsp/

There's an issue tracker, but most importantly, a mailing list where people send questions, and provide patches.

Secondly, I started the gst-dsp project on my own free time, that's why I have the copyright, but I also worked on it paid by Nokia, and other people did it as well, that's why Nokia has the copyright too.

+Estel Is wrong about the LGPL, +maacruz is right. I'm not a lawyer, but I believe if you go to the legal channels, they would contact the copy right holders (me), and ask if Nokia had licensed the software properly, and if they did (I have them permission), that would be the end of it.

Fortunately, this is just a misunderstanding. gst-dsp is LGPL, and Nokia never intended to use any other license.

Thirdly, the upstream version of gst-dsp is very similar to the Harmattan one, and it can be easily used for the Nokia N900, with the official PR1.2 software, and DSP binaries (or at least it worked perfectly fine the last time I tried). In fact, I recommend using the latest version, as there have been a tremendous amount of bugfixes.

+freemangordon

gst-dsp doesn't use libbridge, I don't know why it kept popping up in this thread.
wish you luck with Felipe, so far I don't find him cooperative.
You have not exchanged a single message with me. That's not very collaborative from your side.

Anyway, a few tips. dsp-recover should not be used if you use a driver that has the recovery function enabled (I thought official PR1.2 software already had it disabled). cexec.out is not needed at all (used by dsp-recover I guess, or an old version of it).

As for these URLs:
https://qa9recEP:Pat2UGuP@downloads....+0m6_armel.deb

I don't think you are supposed to make those public, the are intended for personal use after you have agreed with the EULA.

Also, you don't need a new camera-ui, there's a file in /etc/gdigicam/gdigicam-camerabin.conf that you can modify to specify the element for video encoding that you want to use. Also note there's a field for imagepp that you can enable by using dspipp that should give better image quality. This has been enabled even in the latest upstream gst-dsp, and I made sure it worked with the N900 PR1.2 official DSP binaries, no need for the Harmattan ones (although they work too).

To build the latest upstream gst-dsp, you have to use 'make DSP_API=0 SN_API=0' IIRC, and everything should work fine.

Finally, I have pushed the maemo6-patches branch to gitorious, so you should be able to see the code. There's really not much of a difference from upstream, as I have tried to make the diff as small as possible.

For N900 bridge driver you should build with DSP_API=0, for N9 and so on should be DSP_API=1, and for latest upstream driver should be DSP_API=2 (the default).

gst-dsp is an open project and many people have been able to use it on a variety of boards:
http://mypaclog.blogspot.com/2011/06...-board-xm.html

Oh, and also, the video renderers used on the N900 are not very well optimized, specially for video recording. For absolutely the best performance you might want to take a look at gst-omapfb, which is public and open. When both gst-dsp and gst-omapfb are used, the collaboration between the drivers on the kernel side is very nice, so you get excellent performance. The drawback is that you might need to tweak gst-omapfb to disable the overlay properly on the N900.

Great work guys, but remember the gst-dsp mailing list, and there's also maemo-devel. I recommend sending a mail to both, and CC me if you have any questions.

Cheers.
 

The Following 32 Users Say Thank You to felipec For This Useful Post: