Page 69 of 141 « First 596768 69 707179 Last »
Reply
Thread Tools
Estel's Avatar
Estel is offline Estel
2011-12-07 , 01:35
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#681
@maacruz

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!
 
felipec is offline felipec
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.
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:
freemangordon is offline freemangordon
2011-12-07 , 11:12
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#683
Originally Posted by felipec View Post
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.
Thanks, will keep that in mind.

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.
Which are great news all of us were expectng for a long time.

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.
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.

+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.
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.

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).
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)

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).
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.

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).
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.

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
For which you have my (and I am sure everyone else using it) thousand thanks.

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.
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)

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.
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.
 

The Following 9 Users Say Thank You to freemangordon For This Useful Post:
|ErosizeD| is offline |ErosizeD|
2011-12-07 , 11:42
Posts: 26 | Thanked: 4 times | Joined on Oct 2011
#684
Originally Posted by freemangordon View Post
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.
 
felipec is offline felipec
2011-12-07 , 11:58
Posts: 65 | Thanked: 143 times | Joined on Dec 2009 @ Helsinki
#685
Originally Posted by freemangordon View Post
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.
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.

Originally Posted by freemangordon View Post
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.
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.

Originally Posted by freemangordon View Post
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 am not aware of any other library that uses libbridge, and you shouldn't be using dsp-recover, but the kernel side recovery.

Originally Posted by freemangordon View Post
dspipp is used in n900 camera-ui AFAIK.
Nope, it's not.

Originally Posted by freemangordon View Post
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.
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.

Originally Posted by freemangordon View Post
BTW I wouldn't say "There's really not much of a difference from upstream" for a patchset consisting of about 600 patches.
git log --oneline master..maemo6-patches | wc -l
65

Originally Posted by freemangordon View Post
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)
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.

Anyway, some people have added X support to gst-omapfb, and it is used on consumer devices. See OpenEmbedded patches.

Originally Posted by freemangordon View Post
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.
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.

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:
freemangordon is offline freemangordon
2011-12-07 , 12:38
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#686
Originally Posted by |ErosizeD| View Post
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
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.
 

The Following 4 Users Say Thank You to freemangordon For This Useful Post:
freemangordon is offline freemangordon
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:
Joseph9560 is offline Joseph9560
2011-12-07 , 13:52
Posts: 440 | Thanked: 160 times | Joined on Aug 2010 @ Las Vegas, NV
#688
Originally Posted by freemangordon View Post
A little status update - video-calling works with gstreamer-dsp build in FREMANTLE scratchbox. Will upload .deb file soon.
Do you happen to mean cellular network video call?
 
Estel's Avatar
Estel is offline Estel
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!
 

The Following User Says Thank You to Estel For This Useful Post:
fw190's Avatar
fw190 is offline fw190
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?
__________________
per ardua ad astra
 

The Following User Says Thank You to fw190 For This Useful Post:
Reply
Page 69 of 141 « First 596768 69 707179 Last »

Tags
balls, gpl violation, hackjobs, lgpl violation, nokia, upgrade..., video player

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 23:03.

Contact Us - Home - Archive - Top