Re: N800 Video playback
On 4/30/07, Siarhei Siamashka [EMAIL PROTECTED] wrote: On Friday 27 April 2007 04:43, Daniel Stone wrote: [...] Daniel, Siarhei, Eero: I always find your mails to provide great deal of tech information about N800. However we do not have a central place with these information, it would be great if you guys setup a wiki page with tech details about drivers, optimizations and weakness of current implementations so others could base work on. I see that Eero has a how to at: http://maemo.org/platform/docs/howtos/howto_performance_test_process.html Other docs, describing best fetch size, which instructions that usually are cheap are bad implemented/slow on omap2420, etc... Tools would be great. I see Oprofile kernel was suggested to Siarhei, so it would be great to have it for download on this wiki page as well. Thank you all for your great work! Keep it coming :-) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]: On Monday 30 April 2007 17:49, Daniel Stone wrote: It's completely safe to upgrade from a deb if it's not broken. If you set up a standard Maemo build environment and run apt-get source xorg-server and apt-get build-dep xorg-server, it should work just fine, in theory. I don't have any tips, per se. Once I get it all integrated it'll be in git, but for now, the only public source is the packages. OK, thanks. It may take some time though. I'm still using old scratchbox with mistral SDK here (did not have enough free time to upgrade yet). Until I clean up my scratchbox mess, I can only provide some patch without testing, if anybody courageous can try to build it :) Given that I fear not the perils of building a X server with nonstandard options[1], I shall be more than happy to conduct such adventurous acts :) And unless Mr. Kulve has objections, the results could be installed from a repository as well. [1] http://syslog.movial.fi/archives/47-Shadows-for-everyone-well,-not-really.html -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote: 2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]: OK, thanks. It may take some time though. I'm still using old scratchbox with mistral SDK here (did not have enough free time to upgrade yet). Until I clean up my scratchbox mess, I can only provide some patch without testing, if anybody courageous can try to build it :) Given that I fear not the perils of building a X server with nonstandard options[1], I shall be more than happy to conduct such adventurous acts :) And unless Mr. Kulve has objections, the results could be installed from a repository as well. [1] http://syslog.movial.fi/archives/47-Shadows-for-everyone-well,-not-really.html OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. In the worst case only video playback may be broked. But if everything works as expected, video output performance should become a lot better. Video output performance can be tested by mplayer using -benchmark option, 'VO:' stat shows how much time was used for video output, 'VC:' stat shows how much time was used for video decoding. Built-in video player also should become faster. I don't know if this improvement can be 'scientifically' benchmarked, but it should drop less frames on high resolution video playback. If any of you can build xserver package with this patch, please put it for download somewhere or send directly to me. Thanks. diff -u -r -N xorg-server-1.1.99.3/hw/kdrive/omap/Makefile.am xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/Makefile.am --- xorg-server-1.1.99.3/hw/kdrive/omap/Makefile.am 2007-03-05 16:17:32.0 +0200 +++ xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/Makefile.am 2007-05-01 15:04:43.0 +0300 @@ -1,5 +1,5 @@ if XV -XV_SRCS = omap_video.c +XV_SRCS = omap_video.c omap_colorconv.S omap_colorconv.h endif if DEBUG @@ -34,4 +34,4 @@ $(TSLIB_FLAG) \ $(DYNSYMS) -EXTRA_DIST = omap_video.c +EXTRA_DIST = omap_video.c omap_colorconv.S omap_colorconv.h diff -u -r -N xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.h xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.h --- xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.h 1970-01-01 03:00:00.0 +0300 +++ xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.h 2007-05-01 15:06:13.0 +0300 @@ -0,0 +1,45 @@ +/* + * Copyright © 2007 Siarhei Siamashka + * + * Permission to use, copy, modify, distribute and sell this software and its + * documentation for any purpose is hereby granted without fee, provided that + * the above copyright notice appear in all copies and that both that + * copyright notice and this permission notice appear in supporting + * documentation, and that the names of the authors and/or copyright holders + * not be used in advertising or publicity pertaining to distribution of the + * software without specific, written prior permission. The authors and + * copyright holders make no representations about the suitability of this + * software for any purpose. It is provided as is without any express + * or implied warranty. + * + * THE AUTHORS AND COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO + * THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND + * FITNESS, IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR + * ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER + * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF + * CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + * + * Author: Siarhei Siamashka [EMAIL PROTECTED] + */ + +/* + * ARMv6 assembly optimized color format conversion functions + * (planar YV12 to some custom YUV420 format used by graphics chip in Nokia N800) + */ + +#ifndef _OMAP_COLORCONV_H_ +#define _OMAP_COLORCONV_H_ + +#include stdint.h + +/** + * Convert a line of pixels from YV12 to YUV420 color format + * @param dst - destination buffer for YUV420 pixel data, it should be at least 16-bit aligned + * @param src_y - pointer to Y plane, it should be 16-bit aligned + * @param src_c - pointer to chroma plane (U for even lines, V for odd lines) + * @param w - number of pixels to convert (should be multiple of 4) + */ +void yv12_to_yuv420_line_armv6(uint16_t *dst, const uint16_t *src_y, const uint8_t *src_c, int w); + +#endif diff -u -r -N xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.S xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.S --- xorg-server-1.1.99.3/hw/kdrive/omap/omap_colorconv.S 1970-01-01 03:00:00.0 +0300 +++ xorg-server-1.1.99.3.yuv420patch/hw/kdrive/omap/omap_colorconv.S 2007-05-01 15:06:36.0 +0300 @@ -0,0 +1,244 @@ +/* + * Copyright © 2007 Siarhei
Re: N800 Video playback
2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]: On Tuesday 01 May 2007 13:36, Kalle Vahlman wrote: 2007/5/1, Siarhei Siamashka [EMAIL PROTECTED]: OK, thanks. It may take some time though. I'm still using old scratchbox with mistral SDK here (did not have enough free time to upgrade yet). Until I clean up my scratchbox mess, I can only provide some patch without testing, if anybody courageous can try to build it :) Given that I fear not the perils of building a X server with nonstandard options[1], I shall be more than happy to conduct such adventurous acts :) And unless Mr. Kulve has objections, the results could be installed from a repository as well. [1] http://syslog.movial.fi/archives/47-Shadows-for-everyone-well,-not-really.html OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. Applied and build without problems for me. For testing, I fabricated some video with gstreamer: gst-launch-0.10 videotestsrc num-buffers=300 \ ! video/x-raw-yuv, width=640, height=480 \ ! ffenc_mpeg4 ! avimux \ ! filesink location=640x480.avi which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some reason 320x240 and 352x288 refused to play with: X11 error: BadValue (integer parameter out of range for operation) MPlayer interrupted by signal 6 in module: flip_page while gstreamer did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died in the same way. My mplayer is compiled from the svn trunk of the garage project, with some additional cflags I use (so maybe those were the problem...). Anyway, then I shut down af-base-apps and matchbox (to avoid scaling the video) and ran mplayer -benchmark file. In the worst case only video playback may be broked. But if everything works as expected, video output performance should become a lot better. Video output performance can be tested by mplayer using -benchmark option, 'VO:' stat shows how much time was used for video output, 'VC:' stat shows how much time was used for video decoding. There's something fishy in the decoding or something as the color bars in the test video were broken (yellow and cyan to be precise), but that seemed to be the case in a vanilla image too so nothing to do with this patch. I could not see any other glitches in the output. But on to the results: VIDEO: [DX50] 640x480 24bpp 30.000 fps 1597.6 kbps (195.0 kbyte/s) Original: V: 10.0 300/300 44% 74% 0.0% 0 0 0% BENCHMARKs: VC: 4.387s VO: 7.436s A: 0.000s Sys: 0.482s = 12.305s BENCHMARK%: VC: 35.6503% VO: 60.4311% A: 0.% Sys: 3.9185% = 100.% Patched: V: 10.0 300/300 42% 72% 0.0% 0 0 0% BENCHMARKs: VC: 4.213s VO: 7.265s A: 0.000s Sys: 0.381s = 11.859s BENCHMARK%: VC: 35.5296% VO: 61.2604% A: 0.% Sys: 3.2100% = 100.% --- VIDEO: [DX50] 800x480 24bpp 30.000 fps 1976.5 kbps (241.3 kbyte/s) Original: V: 10.0 300/300 54% 114% 0.0% 0 0 0% BENCHMARKs: VC: 5.466s VO: 11.456s A: 0.000s Sys: 0.366s = 17.287s BENCHMARK%: VC: 31.6179% VO: 66.2677% A: 0.% Sys: 2.1144% = 100.% Patched: V: 10.0 300/300 53% 70% 0.0% 0 0 0% BENCHMARKs: VC: 5.346s VO: 7.043s A: 0.000s Sys: 0.449s = 12.838s BENCHMARK%: VC: 41.6414% VO: 54.8602% A: 0.% Sys: 3.4984% = 100.% There is a clear drop in amount of time used to output the videos for 800x480 (the numbers were stable trough multiple runs). So I gather from the 10s benchmark time that we didn't get to real time yet, but close to it? And of course this is just video, audio decoding should be considered for real video playback performance measurement. If any of you can build xserver package with this patch, please put it for download somewhere or send directly to me. I put the deb up at: http://iki.fi/zuh/xserver-xomap_1.1.99.3-0.zuh2_armel.deb until I get it to the repository. This version also has the composite extension enabled, but AFAIK it does not depend on the libs or change server behaviour if composite is not specifically used. The server *should* be compiled with '-mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp -O2', but as I had troubles with the SBOX_EXTRA_COMPILER_ARGS env var being honored some time ago I'm not guaranteeing it at the moment ;) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
2007/5/1, Kalle Vahlman [EMAIL PROTECTED]: The server *should* be compiled with '-mcpu=arm1136j-s -mfpu=vfp -mfloat-abi=softfp -O2', but as I had troubles with the SBOX_EXTRA_COMPILER_ARGS env var being honored some time ago I'm not guaranteeing it at the moment ;) Actually seems that I had added the env var to the rules file so it *is* built with those options. I can produce a build without them if need be (it does affect performance in my experience, so if one wants to see the impact of that patch on a more normal version...). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Localhost unavailable when wi-fi offline or not connected
Hi, I have a Wiki running on my N800 using the usual configuration (for many applications) of a TCP/IP server running on the local host address (127.0.0.1) and an TCP/IP client on the same device. (In this case an HTTP web server and the Opera browser.) While trying to test this on an aeroplane at the weekend -- with Wi-Fi offline, of course -- the browser would not connect to the server. I've since experimented further and find a similar (or the same) problem occurs online if no Wi-Fi connection is active. This is a showstopper for my application as it means I cannot easily view my data unless online and connected -- is there a fix/workaround? Thanks -- mfc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Next steps in the future of our beloved Nokia 770
Am Montag, 30. April 2007 21:55 schrieb Frantisek Dufka: How we can reflect this with maemo SDK and repository structure? Looks like there are such things as subarchitecture and flavors in Debian. http://www.debian.org/releases/stable/powerpc/ch02s01.html.en Good point, Frantisek. I found it quite frustrating when I found out the maemo-mapper (bora version) illegal instruction was because it used some arm11 features and was not running for that reason on my n770. A debian like repository structure would help here a lot. Thanks, Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: OK, here is this untested a patch for xserver to add ARMv6 optimized YUV420 color format conversion. Theoretically it should compile (I did not try to build xserver myself though) and work. If it refuses to compile, fixing the patch should be not too difficult. Applied and build without problems for me. Thanks a lot for building the package and putting it for download, everything seems to be fine, but more details will follow below. For testing, I fabricated some video with gstreamer: which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some reason 320x240 and 352x288 refused to play with: X11 error: BadValue (integer parameter out of range for operation) MPlayer interrupted by signal 6 in module: flip_page while gstreamer did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died in the same way. This X11 error on video playback start and also sometimes on switching fullscreen/windowed mode is a known problem [1] reported in this mailing list. If MPlayer dies on start, usually trying to start it again succeeds. So these 320x240 and 352x288 videos could be played as well if you were a bit more persistent :) As Daniel replied in one of the followup messages, it is most likely some race condition. The question is which code is a suspect. Is it MPlayer Xv video output code that has been around for ages and worked fine on different systems or relatively new Xv extension code from N800 xserver? In addition, a previous revision of N800 firmware had a serious bug [2] related to video playback. It should be noted, that MPlayer needed only about 1 minute to freeze on the initial N800 firmware. So the problem could be identified much more easily if MPlayer was included in the standard set of tests done by Nokia QA staff before each new IT OS release. Surely, Nokia is only interested in a properly working xvimagesink for the software included in IT OS by default. But testing with more client applications can improve overall xserver quality. With all that said, I don't know if MPlayer Xv code is bugfree, it wasn't me who developed it. My mplayer is compiled from the svn trunk of the garage project, with some additional cflags I use (so maybe those were the problem...). Do you have a set of cflags settings which work better than the default set? Can you share this information? There's something fishy in the decoding or something as the color bars in the test video were broken (yellow and cyan to be precise), but that seemed to be the case in a vanilla image too so nothing to do with this patch. I could not see any other glitches in the output. But on to the results: VIDEO: [DX50] 640x480 24bpp 30.000 fps 1597.6 kbps (195.0 kbyte/s) [snip] VIDEO: [DX50] 800x480 24bpp 30.000 fps 1976.5 kbps (241.3 kbyte/s) [snip] There is a clear drop in amount of time used to output the videos for 800x480 (the numbers were stable trough multiple runs). So I gather from the 10s benchmark time that we didn't get to real time yet, but close to it? And of course this is just video, audio decoding should be considered for real video playback performance measurement. These videos are way too heavy for N800 to decode and play in realtime. We may expect playback for videos up to 640x480 resolution with 1000kbps bitrate and 24fps. This is probably current realistic limit which can be achieved. Some minor variations to these parameters are possible (for example we can get 30fps, but should also reduce resolution or bitrate, etc.). If you want a guaranteed video playback with divx/xvid/mpeg4 codecs, you should restrict to 512x384 resolution or lower and keep bitrate reasonable. The results for these 'insane' videos you have posted are somewhat weird, a complete statistics would require also a number of frames dropped, otherwise we don't know how much work was done by the player. Probably missing audio track resulted in MPlayer not being able to provide a proper report. Don't know. Also it is strange that you did not see any improvement at all for 640x480 video, are you sure you really tested it with the patched xserver? Anyway, the new xserver package works really good. If we do some tests with the standard Nokia_N800.avi video clip, we get the following results with the patched xserver: # mplayer -benchmark -quiet -noaspect Nokia_N800.avi BENCHMARKs: VC: 29,764s VO: 7,666s A: 0,468s Sys: 64,635s = 102,534s BENCHMARK%: VC: 29,0287% VO: 7,4767% A: 0,4565% Sys: 63,0381% = 100,% BENCHMARKn: disp: 2504 (24,42 fps) drop: 0 (0%) total: 2504 (24,42 fps) # mplayer -benchmark -quiet -noaspect -dr -nomenu Nokia_N800.avi BENCHMARKs: VC: 30,266s VO: 5,490s A: 0,467s Sys: 66,286s = 102,509s BENCHMARK%: VC: 29,5255% VO: 5,3554% A: 0,4560% Sys: 64,6631% = 100,% BENCHMARKn: disp: 2501 (24,40 fps) drop: 0 (0%) total: 2501 (24,40 fps) Results with unpatched xserver and some more
Re: qemu gentoo based cd
Hello It has been an while but I did not give up yet! Here is the first version of the qemu image http://box.mmapps.net/~keesj/qemu_maemo_gentoo/ It supports both the 2.2 sdk and 3.1. I hope it will help ease the development of 770 and n800 supporting apps. greetings On 4/7/07, Kees Jongenburger [EMAIL PROTECTED] wrote: On 3/31/07, Kees Jongenburger [EMAIL PROTECTED] wrote: Hi I am creating a gentoo based qemu image for maemo development I want to support at least version SDK 2.1 and 3.1 of the maemo sdk. The rationale is quite simple I want it for the MUD project so we can build binaries Hello I have now setup a demo of a web based qemu based maemo sdk (2.2 and 3.1) on http://mud.mmapps.net/ I guess that the idea is to provide a build environment for mud packages where people can test if the package can build in a clear environment. I did not give it much testing yet, But I think it works :) Next steps would be to setup kernel targets.This distro was created with scripts and uses a cow file system to keep the original image intact so feel free to poke around but don't expect speed (I have a broken wireless network) greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
Frantisek Dufka wrote: [sbox-SDK_ARMEL: ~/x/xorg-server-1.1.99.3] patch -p1 ../xomap_yuv420patch.diff patching file hw/kdrive/omap/Makefile.am Hunk #1 FAILED at 1. Hunk #2 FAILED at 34. 2 out of 2 hunks FAILED -- saving rejects to file hw/kdrive/omap/Makefile.am.rej patching file hw/kdrive/omap/omap_colorconv.h patching file hw/kdrive/omap/omap_colorconv.S patching file hw/kdrive/omap/omap_video.c Hunk #1 FAILED at 39. Hunk #2 FAILED at 468. Hunk #3 FAILED at 491. 3 out of 3 hunks FAILED -- saving rejects to file hw/kdrive/omap/omap_video.c.rej Sorry, my fault, mystery solved. Saved attachement in Thunderbird in Windows XP, then moved to Ubuntu inside VMware. The problem was caused by DOS CR+LF line endings, patch doesn't like it. Recoded to unix linefeeds and now it applies cleanly. I'm using Windows a lot, it is strange this never happened to me yet. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On 4/30/07, Daniel Stone [EMAIL PROTECTED] wrote: There are two important optimizations in this code: 1. Cache prefetch with PLD instruction (added in '_armv5' version) which boosts performance to 70 megapixels per second. Inner loop is unrolled to process 32 pixels per iteration (cache line size is 32 bytes on ARM, so such unrolling is convenient). This is the most important improvement. You can try using __builtin_prefetch() from C code to do the same optimization. Ah, sounds useful. From what Dan Amelang's been saying on xorg@, gcc should coalesce four 32-bit reads into one 128-bit read, but this sounds promising as well. To expand on this: I was referring to fact that gcc is pretty smart about using ldmia/stdmia instructions to cluster sequential reads/writes. I see that Siarhei is already using this technique in his assembler code, so nothing new here. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On 5/1/07, Daniel Amelang [EMAIL PROTECTED] wrote: about using ldmia/stdmia instructions to cluster sequential that was supposed to be ldmia/sdmia, sorry. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 Video playback
On 5/1/07, Daniel Amelang [EMAIL PROTECTED] wrote: On 5/1/07, Daniel Amelang [EMAIL PROTECTED] wrote: about using ldmia/stdmia instructions to cluster sequential that was supposed to be ldmia/sdmia, sorry. Gah, ldmia/stmia, final answer. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Standard widget spacing and padding?
On Mon, 2007-04-23 at 16:39 +0300, ext Murray Cumming wrote: Did you discover anything? Sorry to bug you, but I still feel sure that some document exists somewhere. Let's move this to Documenting widget spacing requirements https://maemo.org/bugzilla/show_bug.cgi?id=1280 Murray, please CC yourself there. Thanks. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
