On Sunday 12 October 2008, GNUtoo@no-log.org wrote:

...

Hi,

On Wednesday 08 October 2008 01:01, GNUtoo@no-log.org wrote:

...

hello, I wanted to cross-compile mplayer from svn but it failed...that's because the pld instruction is not supported by my platform(armv4): More precisely the pld instruction was introduced in armv5tE variants( but is not present on armv5texp)

[...]

...

I bet the patch won't be accepted as-is because it has a performance cost on the platform where the pld instruction is supported because the pld instruction preloads things...

Then just use #ifdef HAVE_ARMV5TE #endif /* HAVE_ARMV5TE */ closure around this instruction.

Best regards, Andrew

thanks a lot...here's the updated patch...it took a long time because I don't have much time theses days

Hmm, ifdefs around every instruction look extremely ugly. In addition, they have exactly the same effect as just removing all PLD instructions even for ARM cores that support cache prefetch (HAVE_ARMV5TE is never defined when compiling this assembly file). Have you tried looking into configure script from ffmpeg and 'libavcodec/armv4l/dsputil_arm_s.S' to see how this can be done better?

I tested it and it compiles and runs(youtube works)

Youtube videos have nothing to do with libmpeg2. If you want to test your changes, you need to get some mpeg1 or mpeg2 sample files (or convert some videos to mpeg1/mpeg2 with mencoder). By the way, libmpeg2 may be slower than ffmpeg so you might want to benchmark ffmpeg vs. libmpeg2 on your device. If libmpeg2 is slower there, just compiling mplayer without libmpeg2 support is a good idea. Also I wonder about your target device. Is it more or less common hardware or just some kind of exotic development board? I'm asking because this armv4 unfriendly code has been used in mplayer for ages and nobody cared until now. It makes me think that the number of mplayer users having armv4 hardware is close to zero. This fact of course does not encourage working on any armv4 fixes or improvements. But if armv4 is still alive, I would be glad to work on improving it a bit, or at least fixing all the known issues. And patches are surely welcome. -- Best regards, Siarhei Siamashka

My device is the openmoko freerunner GTA02.

Won't you run into severe performance issues on that platform? The 920T series is not quite lightning fast, so you'd probably need at least hardware colorspace transformation and scaling support to display anything larger than thumbnail size. Is there any progress on that side? From what I've read, the Neo's graphics accelerator (Smedia Glamo 3362) is as tightly NDA'd as its GSM chip. On the other hand, implementing full hardware video acceleration (the Glamo can do MPEG4), would be awesome. vaapi has still a long way to go, it seems. But I don't want to criticise your effort, improving compatibility is always a good thing.

On Tuesday 14 October 2008, GNUtoo@no-log.org wrote:

...

On the other hand, implementing full hardware video acceleration (the Glamo can do MPEG4), would be awesome. vaapi has still a long way to go, it seems.

we have hardware acceleration for videos with a patched mplayer bug: *it's ugly(i don't mean the code...i mean the colours)

Regarding the colors, this must be some bug probably, too bad if it is in some closed source component. Regarding "patched mplayer bug", is it the one with PLD instruction or there is something else to fix?

*it uses framebuffer and not X see http://unadventure.wordpress.com/2008/06/08/accelerating-in-my-pocket/

and yes it's slow...

From what I can see, it shows sthe numbers that are not impressive at all, maybe even just decoding MPEG4 video on the ARM core could be faster. One of the comments there mentions that you have Xv supported there with Xglamo, so this is a good thing for video playback (unless implementation sucks and it has a heavy overhead itself).

and between lastest trunk and the 1.0rc2-r7 the lastest trunk seems a lot slower on youtube(i'll test with mpeg2)

Do you mean the latest trunk of that Glamo thing? Or trunk in MPlayer SVN? If there are some noticeable performance regressions in MPlayer, you can try to search for the revision where it got introduced and report it. As libavcodec is an svn:externals, this makes everything a bit more complicated, but you can still get some older SVN snapshots using date: 'svn up -r {SOMEDATE}'. It might be easier to do performance regressions investigation with FFmpeg itself. -- Best regards, Siarhei Siamashka

On Monday 13 October 2008, Gregor Riepl wrote:

...

My device is the openmoko freerunner GTA02.

Won't you run into severe performance issues on that platform? The 920T series is not quite lightning fast, so you'd probably need at least hardware colorspace transformation and scaling support to display anything larger than thumbnail size.

Just FYI, video decoding capabilities limit for Nokia 770 with 926ejs core running at 252MHz is currently something like this video: http://samples.mplayerhq.hu/benchmark/testsuite1/matrixbench_normdivx_vbrmp3... There are some frames dropped in heavy action scenes, but overall it is watchable. Video is decoded on ARM core, audio is offloaded to DSP and has almost zero overhead, there is hardware YUV support, but scaling is performed in software. Now regarding this freerunner GTA02, it is armv4, but cpu frequency is much higher and it can probably compensate missing armv5te edsp instructions. Smaller instructions cache (16K vs. 32K) is a bit worrying, so it might affect performance and compilation with -O2 or -Os instead of -O3 might be preferable. There was also a discussion about video decoding performance on Sharp Zaurus (PXA270 416MHz, xscale) and it is supposedly quite horrible according to: http://thread.gmane.org/gmane.linux.distributions.angstrom.user/1583/focus=1... They suspected that Sharp Zaurus has very bad memory bandwidth performance and it kills everything. I also tried to take part in that discussion as I was very curious what exactly could be wrong (Sharp Zaurus seems to be a similar or better hardware than Nokia 770 as it also has armv5te instructions support and even iwmmxt, has hardware YUV but also no arbitrary hardware scaling). But they did not seem to be very motivated to even try benchmarking anything or accept any help :)

Is there any progress on that side? From what I've read, the Neo's graphics accelerator (Smedia Glamo 3362) is as tightly NDA'd as its GSM chip. On the other hand, implementing full hardware video acceleration (the Glamo can do MPEG4), would be awesome. vaapi has still a long way to go, it seems.

But I don't want to criticise your effort, improving compatibility is always a good thing.

I think it is not only compatibility, but there is also some quite visible practical use. For example, flash video was also mentioned and it should play just fine on this hardware. -- Best regards, Siarhei Siamashka

Also I wonder about your target device. Is it more or less common hardware or just some kind of exotic development board? I'm asking because this armv4 unfriendly code has been used in mplayer for ages and nobody cared until now. It makes me think that the number of mplayer users having armv4 hardware is close to zero. This fact of course does not encourage working on any armv4 fixes or improvements.

But if armv4 is still alive, I would be glad to work on improving it a bit, or at least fixing all the known issues. And patches are surely welcome. My device is the openmoko freerunner GTA02.(http://en.wikipedia.org/wiki/Neo_FreeRunner , http://wiki.openmoko.org/wiki/Main_Page) It's the totally(but the firmwares) free/open phone... I don't know the exact number of users(mabe a lot more than other devices...) but it has an active community(and some of the openembedded well known devellopers works for openmoko such as zecke,Michael Lauer(mickeyl) and even Harald Welte(I don't think that he's in the openembedded community ) worked for the openmoko company http://en.wikipedia.org/wiki/Harald_Welte#Openmoko and works for it again: http://laforge.gnumonks.org/weblog/2008/10/07/#20081007-uboot)

Also I wonder about your target device. Is it more or less common hardware or just some kind of exotic development board? I'm asking because this armv4 unfriendly code has been used in mplayer for ages and nobody cared until now. It makes me think that the number of mplayer users having armv4 hardware is close to zero. This fact of course does not encourage working on any armv4 fixes or improvements.

But if armv4 is still alive, I would be glad to work on improving it a bit, or at least fixing all the known issues. And patches are surely welcome. My device is the openmoko freerunner GTA02.(http://en.wikipedia.org/wiki/Neo_FreeRunner , http://wiki.openmoko.org/wiki/Main_Page) It's the totally(but the firmwares) free/open phone... I don't know the exact number of users(mabe a lot more than other devices...) but it has an active community(and some of the openembedded well known devellopers works for openmoko such as zecke,Michael Lauer(mickeyl) and even Harald Welte(I don't think that he's in the openembedded community ) worked for the openmoko company http://en.wikipedia.org/wiki/Harald_Welte#Openmoko and works for it again: http://laforge.gnumonks.org/weblog/2008/10/07/#20081007-uboot)

On Thu, Nov 06, 2008 at 11:59:53PM +0100, GNUtoo@no-log.org wrote:

...

on Sunday 12 October 2008, GNUtoo@no-log.org wrote:

Hmm, ifdefs around every instruction look extremely ugly. In addition, they have exactly the same effect as just removing all PLD instructions even for ARM cores that support cache prefetch (HAVE_ARMV5TE is never defined when compiling this assembly file). I looked at the configure file of mplayer trunk and there is the following inside: if arm ; then echocheck "ARM pld instruction" cat > $TMPC << EOF int main(void) { __asm__ volatile ("pld [r0]"); return 0; } EOF pld=no cc_check && pld=yes echores "$pld" so if I add the following to the beginning of the assembly file would it work? #ifndef HAVE_PLD .macro pld reg .endm #endif More precisely is the checks in the configure script enough or should I also add that in the configure script: enabled armv4l && check_asm pld '"pld [r0]"'

What we have is enough. It accomplishes exactly what you need. Diego

...

On Thu, Nov 06, 2008 at 11:59:53PM +0100, GNUtoo@no-log.org wrote:

...

...

on Sunday 12 October 2008, GNUtoo@no-log.org wrote:

Hmm, ifdefs around every instruction look extremely ugly. In addition, they have exactly the same effect as just removing all PLD instructions even for ARM cores that support cache prefetch (HAVE_ARMV5TE is never defined when compiling this assembly file). I looked at the configure file of mplayer trunk and there is the following inside: if arm ; then echocheck "ARM pld instruction" cat > $TMPC << EOF int main(void) { __asm__ volatile ("pld [r0]"); return 0; } EOF pld=no cc_check && pld=yes echores "$pld" so if I add the following to the beginning of the assembly file would it work? #ifndef HAVE_PLD .macro pld reg .endm #endif More precisely is the checks in the configure script enough or should I also add that in the configure script: enabled armv4l && check_asm pld '"pld [r0]"'

What we have is enough. It accomplishes exactly what you need.

Diego Thanks a lot!!! I attached the patch for applying the following code to the libmpeg2/motion_comp_arm_s.S: #ifndef HAVE_PLD .macro pld reg .endm #endif_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng I was forgetting to tell the test setup: on my computer: mencoder matrixbench_normdivx_vbrmp3.avi -oac none -ovc lavc -lavcopts vcodec=mpeg2video -of mpeg -o matrix_openmoko.mpeg2 on the device: DISPLAY=:0 mplayer -ao null -vo xv -fs -vf framestep=2 -vc mpeg12 /media/mmcblk0p2/matrix_openmoko.mpeg2 it's slow...but the colours are ok

Am Wed, 8 Oct 2008 10:46:02 +0300 schrieb "Siarhei Siamashka" <siarhei.siamashka@gmail.com>:

Regarding audio decoders, you need to avoid any of them using floating point math, the most obvious example is mp3lib which is used as a default mp3 decoder in mplayer. A good choice of fixed point audio decoders is libmad for mp3

Just a note on that: libmpg123, the active spawn of what once led to mp3lib, can be compiled to use fixed point math for the actual decoding. In the current development version (http://mpg123.org/snapshot), this also works with the internal resampling (what can save CPU cycles). I don't have a performance comparisong of libmad and libmpg123 on ARM on hand, but there are people who seem to use libmpg123 happily on such devices (i.e. Nintendo DS or Sony PSP, also lately someone with a ColdFire thingy without FPU). Well, I'm just poking a bit on the replace-mp3lib-by-libmpg123 issue. I know it would be best settled by me doing a patch, but perhaps this is an opportunity to offload this work to someone who wants efficient mpeg audio decoding with a decoder that's still maintained on ARM;-) (On the other hand, I still need to include the recent AMD64 SSE code from mp3lib... once that is in libmpg123, we got a full replacement/enhancement). Alrigthy then, Thomas.