Thread: [HOWTO]Watch 720p videos on n900 [09.12.2011 VIDEOCALL WORKS]
View Single Post
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: