Re: Best encoder for streaming video?
From Tue, 26 Aug 2008 16:27:24 -0600 Merrick Fonnesbeck [EMAIL PROTECTED] wrote: before sending it out. The video appears on the other side very choppy and pixelated, and I am wondering if I am using the right encoder or whether there is a better encoder that would compress my video better to give me a cleaner video? Video encoding is a *very* CPU-intensive task (even a Core Duo 2 CPU is not able to encode in realtime with every encoding algorithm). So you have to find a balance between: - Frame size (look how small is the video window in the SIP phone). - Bitrate vs CPU load (if you don't need a very low bitrate, you may send the uncompressed stream or as a series of jpeg frames) - Quality vs bitstream, The lower is your target bitstream, the lower will be the resulting video quality, that's obvious. You will have to experiment with available codecs to find a optimal combination for your case. -- Andrew signature.asc Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo Bug Jar #20
A Quick Look at maemo Bugzilla (https://bugs.maemo.org/). 2008-08-25 through 2008-08-31 As of 2008-09-01 maemo Bugzilla contains 2636 (+15 this week) items, including 1066 open issues (+4 this week): * 688 open bugs (+1 this week) * 16 critical/blocker (+2 this week) * 18 easyfix (-2 this week) * 144 moreinfo (+2 this week) * 25 crash (-1 this week) * 20 patch (no change this week) * 11 reopened (+1 this week) * 267 unconfirmed (-4 this week) * 378 open enhancements (+3 this week) * 12 easyfix (no change this week) * 7 moreinfo (no change this week) * 7 patch (no change this week) * 3 reopened (-3 this week) * 92 unconfirmed (-2 this week) ==--- New Items ---== 10 new bugs were opened: ( https://bugs.maemo.org/buglist.cgi?bug_id=3632,3637,3639,3640,3641,3642,3649,3650,3652,3653 ) * [3632] Text selection lost in terminal when gains focus/resizes * [3637] Application crash on theme changing for the case of using stock buttons * [3639] Attachments of Forwarded email from Modest not displayed * [3640] Finger keyboard not shown after pressing center dpad key * [3641] Modest resident process gets stuck * [3642] rendering artifacts on zoomed pages after using scrollbar * [3649] Software Update Wizard does not work pressing the swap key, but the home key is ok * [3650] Focus is lost in some multiline text entries pressing Up and Down keys * [3652] DTMF doesn't work after SIP call is initiated * [3653] files may remain in /tmp preventing browserd to start Of these, 2 were critical/blockers: ( https://bugs.maemo.org/buglist.cgi?bug_id=3637,3653 ) * [3637] Application crash on theme changing for the case of using stock buttons * [3653] files may remain in /tmp preventing browserd to start 5 new enhancements were opened: ( https://bugs.maemo.org/buglist.cgi?bug_id=3635,3638,3643,3646,3654 ) * [3635] open source alarm framework * [3638] gpsdriver should allow a less frequent wakeup rate to save power * [3643] Colour coding of software list based on source repository * [3646] hildon-fm doesn't build with Gtk+ 2.13 * [3654] Application menu is of fixed size and unusable with screen rotation ==--- Top Tens ---== Ten biggest open bugs by number of votes: ( https://bugs.maemo.org/buglist.cgi?bug_id=2878,2723,3306,375,2784,2564,1771,2640,2850,3357 ) 1. (12%) [2878] Very poor satellite acquisition with internal GPS 2. (4%) [2723] Pushing key once causes multiple repeats 3. (4%) [3306] DUMMY connections not visible in Select connection dialog 4. (3%) [375] minimum backlight level is too bright at night 5. (3%) [2784] Screen taps or presses go to random locations, randomly (+1 this week) 6. (3%) [2564] No consistency on scrolling/scrollbars in bundled OS2008 applications (+1 this week) 7. (2%) [1771] Bluetooth transfer speeds not really meeting Bluetooth 2.0 specs (+1 this week) 8. (2%) [2640] Can no longer pair bluetooth keyboard after upgrade to OS 2008 with restore (+1 this week) 9. (2%) [2850] On screen keyboard dooesn't always realise that bluetooth keyboard has been connected or disconnected (+1 this week) 10. (2%) [3357] Modest lingers in memory using 100% CPU (new this week) Ten biggest open enhancements by number of votes: ( https://bugs.maemo.org/buglist.cgi?bug_id=176,2639,667,1695,303,1046,368,1017,1129,417 ) 1. (11%) [176] Support for OGG Vorbis / Theora missing 2. (6%) [2639] Home View needs to have an option to lock widgets into place 3. (5%) [667] A2DP and AVRCP Bluetooth profile wanted 4. (4%) [1695] Provide open link in background 5. (3%) [303] Clock should allow configurable 12h/24h display 6. (3%) [1046] RFE: Power Management Profiles (AC/Battery, Timed, Environment and screen saver) 7. (3%) [368] USB mode selection on control panel 8. (3%) [1017] need 802.1X/PEAPv0/MS-CHAPv2 and/or 802.1X/EAP-TTLS/MS-CHAPv2 9. (3%) [1129] Media player doesn't save the timeposition on close 10. (2%) [417] WEP with 802.1x EAP PEAP not supported (new this week) Ten biggest open bugs by importance: ( https://bugs.maemo.org/buglist.cgi?bug_id=3026,1842,3357,3398,3190,3566,2878,3378,3546,2004 ) 1. [3026] USB state hangs at b_idle on n810(won't allow mode change from sysfs) 2. [1842] Constant metalayer-crawler crashes CPU usage with some VMA file(s) 3. [3357] Modest lingers in memory using 100% CPU 4. [3398] Missing G_BEGIN_DECLS and G_END_DECLS in libhildon-1 5. [3190] Show Connection to one or more account lost when re-invite 6. [3566] nokia-repositories package overwrites user settings and disables maemo.org Extras 7. [2878] Very poor satellite acquisition with internal GPS 8. [3378] Connection dialog presents only previous connections and doesn't scan 9. [3546] Resurrect avahi in maemo-extras 10. [2004] Missing VCard response crashes IM app Ten biggest open enhancements by importance: ( https://bugs.maemo.org/buglist.cgi?bug_id=151,166,167,176,217,230,236,247,259,262 ) 1. [151] Should be able to select home view
SDL, pixel format and little endian issue
Hi, I have a SDL application where I have to replace color of specified pixels. So, I have a color in RGB representation and convert it to the pixel color using that approach: Uint32 PixelSrc = (0 PF-Rshift) | (128 PF-Gshift) | (192 PF-Bshift); But as result I get color 0x10c0 instead of 0x0080C0. Why it's happens? Does SDL pixel format take into account byte order? Moreover, I found following values for Xshift for little endian: const int rshift = 0, gshift = 8, bshift = 16, ashift = 24; Using them I can get correct pixel color: Uini32 PixelDest = (0 rshift) | (128 gshift) | (192 bshift); But the byte order is different. I get 0xc08000 but it should be 0x0080c0. Any idea what I do wrongly? TIA -- Cheers, Michael ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, pixel format and little endian issue
Michael Stepanov wrote: Hi, I have a SDL application where I have to replace color of specified pixels. So, I have a color in RGB representation and convert it to the pixel color using that approach: Uint32 PixelSrc = (0 PF-Rshift) | (128 PF-Gshift) | (192 PF-Bshift); But as result I get color 0x10c0 instead of 0x0080C0. Why it's happens? You did not mention pixel format, if you use device native 16 bit format (RGB565?) you cannot use values like 128 or 192 since it will overflow 5 or 6 bits. Also you should do proper masking. Moreover, I found following values for Xshift for little endian: const int rshift = 0, gshift = 8, bshift = 16, ashift = 24; Uini32 PixelDest = (0 rshift) | (128 gshift) | (192 bshift); But the byte order is different. I get 0xc08000 but it should be 0x0080c0. 00c08000 seems fine to me for 00 | 0x808 |0xC016. I think you should add a bit more of your example code and also tell us what you want to do (and maybe even why). Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, pixel format and little endian issue
On Mon, Sep 1, 2008 at 4:16 PM, Frantisek Dufka [EMAIL PROTECTED] wrote: Michael Stepanov wrote: Hi, I have a SDL application where I have to replace color of specified pixels. So, I have a color in RGB representation and convert it to the pixel color using that approach: Uint32 PixelSrc = (0 PF-Rshift) | (128 PF-Gshift) | (192 PF-Bshift); But as result I get color 0x10c0 instead of 0x0080C0. Why it's happens? You did not mention pixel format, if you use device native 16 bit format (RGB565?) you cannot use values like 128 or 192 since it will overflow 5 or 6 bits. Also you should do proper masking. Moreover, I found following values for Xshift for little endian: const int rshift = 0, gshift = 8, bshift = 16, ashift = 24; Uini32 PixelDest = (0 rshift) | (128 gshift) | (192 bshift); But the byte order is different. I get 0xc08000 but it should be 0x0080c0. 00c08000 seems fine to me for 00 | 0x808 |0xC016. I think you should add a bit more of your example code and also tell us what you want to do (and maybe even why). Ok, there is an SDL application which was ported from x86 to Nokia. The issue with color is following. The application finds some icons on the picture (they are all pink - 255, 102, 255) and replace them by proper color - yellow, red, gray etc. The replacement colors are 32bit but Nokia uses 16bit as you already mentioned. So, I found the way how to compare pink color with actual color of specified pixel: SDL_GetRGB((Uint32)Pixel, m_pScreenImage-format, red, green, blue); where Pixel is retrieved from the surface in the loop. But now I have to fill pink pixel by specified color. And as I understand I should convert that color from 32bit to 16bit? How can I do it? Maybe that's why Xshift works wrongly because I try to use 32bit color definition with 16bit surface? Frantisek -- Cheers, Michael ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
seeking help for starting browser application in a minimized fashion
Hi maemo community members, I managed to get my N810 to autostart the browser whenever it boots up, by modifying /etc/osso-af-init/real-af-base-apps Now, is it possible to launch it in the background? That is, the browser will be loading, but its icon is always showing minimized in the task navigator. I typed browser --help but didn't find any command line options that can do what I described above. I would appreciate any experience sharing from the community in this matter. Thanks! Alex Leung. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SDL, pixel format and little endian issue
Just fixed issue with wrong color of pixels by creating 16bit pixel instead of 32bit: Uint16 PlutoPixelDest = ((ReplacementColor.R() PF-Rloss) PF-Rshift) + ((ReplacementColor.G() PF-Gloss) PF-Gshift) + ((ReplacementColor.B() PF-Bloss) PF-Bshift); where ReplacementColor is structure with 32bit RGB. On Mon, Sep 1, 2008 at 4:27 PM, Michael Stepanov [EMAIL PROTECTED]wrote: On Mon, Sep 1, 2008 at 4:16 PM, Frantisek Dufka [EMAIL PROTECTED] wrote: Michael Stepanov wrote: Hi, I have a SDL application where I have to replace color of specified pixels. So, I have a color in RGB representation and convert it to the pixel color using that approach: Uint32 PixelSrc = (0 PF-Rshift) | (128 PF-Gshift) | (192 PF-Bshift); But as result I get color 0x10c0 instead of 0x0080C0. Why it's happens? You did not mention pixel format, if you use device native 16 bit format (RGB565?) you cannot use values like 128 or 192 since it will overflow 5 or 6 bits. Also you should do proper masking. Moreover, I found following values for Xshift for little endian: const int rshift = 0, gshift = 8, bshift = 16, ashift = 24; Uini32 PixelDest = (0 rshift) | (128 gshift) | (192 bshift); But the byte order is different. I get 0xc08000 but it should be 0x0080c0. 00c08000 seems fine to me for 00 | 0x808 |0xC016. I think you should add a bit more of your example code and also tell us what you want to do (and maybe even why). Ok, there is an SDL application which was ported from x86 to Nokia. The issue with color is following. The application finds some icons on the picture (they are all pink - 255, 102, 255) and replace them by proper color - yellow, red, gray etc. The replacement colors are 32bit but Nokia uses 16bit as you already mentioned. So, I found the way how to compare pink color with actual color of specified pixel: SDL_GetRGB((Uint32)Pixel, m_pScreenImage-format, red, green, blue); where Pixel is retrieved from the surface in the loop. But now I have to fill pink pixel by specified color. And as I understand I should convert that color from 32bit to 16bit? How can I do it? Maybe that's why Xshift works wrongly because I try to use 32bit color definition with 16bit surface? Frantisek -- Cheers, Michael -- Cheers, Michael ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
