Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day, 1 hr ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 20 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 5 hrs ago - more...
|
2011-12-07
, 03:42
|
|
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.
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.
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: | ||
anders_gud, antezz, ayos!, don_falcone, drucula, Estel, freemangordon, fw190, gregoranderson, Hurrian, ivgalvez, Joseph9560, jurop88, knobby, maacruz, Maj3stic, Mara, mauron85, Netweaver, nkirk, OVK, pali, panjgoori, pepitoe, Raimu, Santhan, SSLMM, strange1712, szopin, tecs, wumpwoast, zeljkobo12 | ||
|
|
2011-12-07
, 11:12
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#683
|
Originally Posted by felipec
Thanks, will keep that in mind.
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.
libbridge is still needed (even if we remove gst-openmax) as dsp-recover and several libraries use it. And stock one works like a charm with latest kernel-power so there is no need for rebuild or new version anymore.
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).
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).
dspipp is used in n900 camera-ui AFAIK.
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).
BTW I wouldn't say "There's really not much of a difference from upstream" for a patchset consisting of about 600 patches.
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 9 Users Say Thank You to freemangordon For This Useful Post: | ||
|
|
2011-12-07
, 11:42
|
|
Posts: 26 |
Thanked: 4 times |
Joined on Oct 2011
|
#684
|
Originally Posted by freemangordon
Thanks, will keep that in mind.
Which are great news all of us were expectng for a long time.
Well , latest official n900 firmware is PR1.3.1. On the other hand there is no point to use anything else but maemo5 gst-dsp branch with stock n900 DSP binaries as it is working and stable.
Actually both me and pali sent a mail to you (using the address from http://code.google.com/p/gst-dsp/ ), but you didn't answer. Neither I received a reply to my questions/comments on Harmattan bugtracker. Anyway I could assume it was some bad communication issue.
libbridge is still needed (even if we remove gst-openmax) as dsp-recover and several libraries use it. And stock one works like a charm with latest kernel-power so there is no need for rebuild or new version anymore.
I did not enable bridgedriver auto-recovery feature for kernel-power. dsp-recover (along with cexec.out) don't seem to cause any issues while auto-recovery feature is not tested, maybe I will enable it when all other stuff is working properly. For now my focus is on core functionality (i.e. HD playback/recording)
We need new camera-ui as stock one offers selection only for low res videos. And there is no way to fine-tune gstreamer elements properties using /etc/gdigicam/gdigicam-camerabin.conf. For example default queue of v4l2camsrc consists of 4 buffers, which is one of the reasons why videos recorded using stock camera-ui stutter. The other is lack of priority management. No way to set up bitrate/framerate, etc.
dspipp is used in n900 camera-ui AFAIK.
In case you missed it, bridgedriver in kernel we are using (kernel-power>=49) is backported from Harmattan. And I have modified it in such a way that it supports both old and new set of ioctl codes, so it does/should not matter which DSP_API will be used while building.
BTW I wouldn't say "There's really not much of a difference from upstream" for a patchset consisting of about 600 patches.
For which you have my (and I am sure everyone else using it) thousand thanks.
Well, what gst-omapfb lacks is xvideo support. Without such support there is not much use of it on a consumer device. And there is no way to display high-res videos on TV using gst-omapfb, as DSS scaler is not capable to down-sample to tvout resolutions above 1024/720 or so AIUI. While xvimagesink is capable (if using powervr instead of framebuffer driver)
Thanks for uploading harmattan patches to gitorious. And thanks again for wonderful work you've done with gst-dsp. I hope there won't be issues I wouldn't be able to resolve by myself, but if such arose my questions will be sent to the correct destination.
Freemangordon, i seend you 2 PM but i think i never get a answer... so i let you here the question...
Is there any way to get higher bitrates? quality still sucks, also in HD because bitrate still too low...
If you can manage to get working 15mbps at 800x480 ( or similar ) the quality will be better than HD at 10mbps.
Anyway, thanks for the hard work, and please, tell me if is there any way to increase the bitrate.
Keep up the good work
Last edited by |ErosizeD|; 2011-12-07 at 11:44.
|
|
2011-12-07
, 11:58
|
|
Posts: 65 |
Thanked: 143 times |
Joined on Dec 2009
@ Helsinki
|
#685
|
Originally Posted by freemangordon
Yes, there is, including years of development for bugfixes, much improved performance for video recording, and a working dspipp to improve image captures. Plus, it's also working and stable, as we use something very similar on the N9.
Well , latest official n900 firmware is PR1.3.1. On the other hand there is no point to use anything else but maemo5 gst-dsp branch with stock n900 DSP binaries as it is working and stable.
Originally Posted by freemangordon
I receive many mails, and I put them on my to-do list. I was probably on vacation at the time. Fortunately there's a mailing list, so people who use it might receive answers from other people involved with gst-dsp, I'm not the only one.
Actually both me and pali sent a mail to you (using the address from http://code.google.com/p/gst-dsp/ ), but you didn't answer. Neither I received a reply to my questions/comments on Harmattan bugtracker. Anyway I could assume it was some bad communication issue.
Originally Posted by freemangordon
I am not aware of any other library that uses libbridge, and you shouldn't be using dsp-recover, but the kernel side recovery.
libbridge is still needed (even if we remove gst-openmax) as dsp-recover and several libraries use it. And stock one works like a charm with latest kernel-power so there is no need for rebuild or new version anymore.
Originally Posted by freemangordon
Nope, it's not.
dspipp is used in n900 camera-ui AFAIK.
Originally Posted by freemangordon
Yes, that's what I figured, but there's no point in doing that. Anyway, you should be using the latest upstream tidspbridge preferably, as the one in Harmattan is quite outdated.
In case you missed it, bridgedriver in kernel we are using (kernel-power>=49) is backported from Harmattan. And I have modified it in such a way that it supports both old and new set of ioctl codes, so it does/should not matter which DSP_API will be used while building.
Originally Posted by freemangordon
git log --oneline master..maemo6-patches | wc -l
BTW I wouldn't say "There's really not much of a difference from upstream" for a patchset consisting of about 600 patches.
65
Originally Posted by freemangordon
If all you want is to render videos to full-screen (which is what most people want anyway), gst-omapfb is fine. Plus, the reason it's so efficient is that omapfb has contiguous memory, which means the map/unmap operations done by gst-dsp on every buffer are basically free. If you use user-space allocated memory, which is wuat xvimagesink would do, then a lot of CPU and memory bandwidth will be wasted finding the pages, and flushing the cache for each single buffer. The bigger the buffers, the worst the overhead.
Well, what gst-omapfb lacks is xvideo support. Without such support there is not much use of it on a consumer device. And there is no way to display high-res videos on TV using gst-omapfb, as DSS scaler is not capable to down-sample to tvout resolutions above 1024/720 or so AIUI. While xvimagesink is capable (if using powervr instead of framebuffer driver)
Anyway, some people have added X support to gst-omapfb, and it is used on consumer devices. See OpenEmbedded patches.
Originally Posted by freemangordon
No problem, that had to be done sooner or later. I will try to follow this thread, but using the gst-dsp mailing list and CC'ing me is always best.
Thanks for uploading harmattan patches to gitorious. And thanks again for wonderful work you've done with gst-dsp. I hope there won't be issues I wouldn't be able to resolve by myself, but if such arose my questions will be sent to the correct destination.
Now, off to make latest linux kernel vanilla to work properly on N900
| The Following 21 Users Say Thank You to felipec For This Useful Post: | ||
ahmadamaj, don_falcone, Estel, freemangordon, fw190, g0r, Hurrian, Joseph9560, JSTAR, jurop88, knobby, maacruz, Netweaver, nkirk, OVK, Raimu, Santhan, SSLMM, strange1712, szopin, udaychaitanya16 | ||
|
|
2011-12-07
, 12:38
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#686
|
Originally Posted by |ErosizeD|
Yes, there is, but camera-ui lack interface for that. Will try to implement it when video-calling works. Or you can ask on camera-ui thread, maybe nicolai could do it.
Freemangordon, i seend you 2 PM but i think i never get a answer... so i let you here the question...
Is there any way to get higher bitrates? quality still sucks, also in HD because bitrate still too low...
If you can manage to get working 15mbps at 800x480 ( or similar ) the quality will be better than HD at 10mbps.
Anyway, thanks for the hard work, and please, tell me if is there any way to increase the bitrate.
Keep up the good work
| The Following 4 Users Say Thank You to freemangordon For This Useful Post: | ||
|
|
2011-12-07
, 13:14
|
|
Posts: 3,074 |
Thanked: 12,960 times |
Joined on Mar 2010
@ Sofia,Bulgaria
|
#687
|
A little status update - video-calling works with gstreamer-dsp build in FREMANTLE scratchbox. Will upload .deb file soon.
| The Following 18 Users Say Thank You to freemangordon For This Useful Post: | ||
don_falcone, Estel, fw190, g0r, Hurrian, Joseph9560, JSTAR, knobby, maacruz, moepda, nkirk, OVK, patlak, Santhan, SSLMM, strange1712, visN900, zeljkobo12 | ||
|
|
2011-12-07
, 13:52
|
|
Posts: 440 |
Thanked: 160 times |
Joined on Aug 2010
@ Las Vegas, NV
|
#688
|
Originally Posted by freemangordon
Do you happen to mean cellular network video call?
A little status update - video-calling works with gstreamer-dsp build in FREMANTLE scratchbox. Will upload .deb file soon.
 |
|
2011-12-07
, 15:23
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#689
|
There is no difference between call made using WiFi or 3G, given sufficient bandwidth. After all, they're based on network.
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
| The Following User Says Thank You to Estel For This Useful Post: | ||
 |
|
2011-12-07
, 17:19
|
|
Posts: 584 |
Thanked: 700 times |
Joined on Jan 2010
|
#690
|
this is OT but importat as I see it:
While reading news from felpec I started to wonder if we could atract some more developers to N900 from various places?
While reading news from felpec I started to wonder if we could atract some more developers to N900 from various places?
__________________
per ardua ad astra
per ardua ad astra
| The Following User Says Thank You to fw190 For This Useful Post: | ||
 |
| Tags |
| balls, gpl violation, hackjobs, lgpl violation, nokia, upgrade..., video player |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 01:52.
Your logic is correct *except* part about "no one received the code, so they can change their mind about current version". From legit point of view, binary distributed with copyright stating it's LGPL is LGPL'ed already and public received that file. It's just Nokia failing to finalize distributing required part of it (code).
Still, I agree that "enforcing" (L)GPL against copyright holder is hard, to say at least (not to mention quite funny/ironically, actually). I'm also thinking that we need just more patience, and repeating same arguments again and again by Pali and freemangordon in bug report. Considering, how certman code short novel (cause saga doesn't fit there) ended, I'm sure they will eventually release it in line with license file.
/Estel
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!