Welcome, Guest. Please login or register.

Author Topic: FFmpeg + FFplay SVN-r18880 (m68k)  (Read 18326 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #14 on: May 22, 2009, 06:45:16 PM »
Quote from: bernd_afa;455668
with the new library they work much better.the first was increase of buffer size.gcc compile faster and many programs start faster.
You're adding large default buffers just to get good performance with specific programs?

If a program needs larger buffers it can set them via setvbuf call.

Making the libc level buffer excessively large is a bad idea. If you need general faster I/O, add cache to device level (dynamicache for example). That will give you much better results, without eating precious system memory for every single filehandle.

Quote
and when there come later speedup on some funcs old programs are too faster.maybe a new mem allocator
Good luck with that. The ixemul memory system is quite fast in fact. But even if you add a new memory system it will still be bound by the memory system of the OS itself, so the correct place to fix it is at the OS level.

Quote
* because most Linux programs do not check if enough memory is here and to avoid them crash badly after a failed malloc
  a check is add if memory cant allocate.
  then a requester come that show how many mem need, and the user can free memory on other programs
  and can then click on try again.
This should not be in libc, or at least it should be off by default.

Quote
also i know when there are more programs use code, then Bugs find better.i for example always test a little new ixemul lib with OWB 68k.if that make problems, i see fast i have add a bug.
Huh, OWB uses ixemul? That's just horrible. Please tell me ain't so!?

Quote
this is one of the importants of software developing.the more programs or users execute functions and the faster can tell it is rock solid.
Have you heard of unit testing?

Please rename the library. You're ruining ixemul for everyone with this mess.

- MorphOS ixemul.library missing features: Irrelevant. Those only affect MorphOS, not ixemul overall.
- Regarding OS4 ixemul.library version foul up: Two wrongs don't make one good.
- Your version fuckups ruin it for EVERYONE else. Please rename the library
« Last Edit: May 22, 2009, 06:50:00 PM by Piru »
 

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #15 on: May 22, 2009, 07:00:39 PM »
Quote from: Piru;455670
You're adding large default buffers just to get good performance with specific programs?



I use the default buffer size other systems have.clib2 use 8192 bytes, so i use that too.

i know from very program on my real classic, that 1024 bytes of buffer is too small.aztec c use default 4096 bytes.this also cause some speedloss.8192 used on clib2 is a good value.

most do no  benchmarks, so they dont notice that.

Quote from: Piru

Good luck with that. The ixemul memory system is quite fast in fact. But even if you add a new memory system it will still be bound by the memory system of the OS itself, so the correct place to fix it is at the OS level.


sure but old ixemul have own mem system.when i have tlsf in amiga os, then i must change ixemul that it support stright amiga os alloc

and that is need on both versions.

Quote from: Piru

This should not be in libc, or at least it should be off by default.


Wy do you write its in libc ?

its of course in malloc func.look the source
and if malloc return 0 then the requester come.
and this feature is testet and confirm its lots better than crash whole system because Linux programs assume unlimitet memory, because of virtualmem  and selden check for enough mem.  

Quote from: Piru

Huh, OWB uses ixemul? That's just horrible. Please tell me ain't so!?


thats the Version Jörg Strohmayr do, 1.4 work stable.
the OWB 1.2 use SDL and is 2-3 * faster than 1.4.

that 1.2 is faster with SDL is also confirm from more User.but 1.2 is unstable but thats because SDL 1.2.6 used for OWB was too old and buggy and slow
« Last Edit: May 22, 2009, 07:03:24 PM by bernd_afa »
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #16 on: May 22, 2009, 07:23:24 PM »
Quote from: bernd_afa;455673
most do no  benchmarks, so they dont notice that.

You're running what kind of benchmark exactly?

Quote
sure but old ixemul have own mem system.when i have tlsf in amiga os, then i must change ixemul that it support stright amiga os alloc

and that is need on both versions.

No, it's not. ixemul allocator is fast enough as it is. Changing it to use OS allocator (even when TLSF) directly doesn't give enough performance boost to justify such a change.

Quote
Wy do you write its in libc ?

Because it is. malloc is provided by the C library, which ixemul is.

Quote
and if malloc return 0 then the requester come.
and this feature is testet and confirm its lots better than crash whole system because Linux programs assume unlimitet memory, because of virtualmem  and selden check for enough mem.

And how can you tell that the application is not testing for the result? This is moving the application level functionality to the libc. This is not a good design: malloc is supposed to either return memory or quietly return 0. Adding requesters requiring user interaction is a bad idea. What if your program does handle the low memory situation, and could continue just fine even if the allocation fails, but now is stuck in some requester requiring user input? The program cannot continue. Imagine running for example apache that runs out of memory. Instead of recovering, the web server will now be stuck waiting for user input.

Please, don't break ixemul anymore. Please rename your library.
 

Offline Methuselas

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2205
    • Show only replies by Methuselas
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #17 on: May 22, 2009, 07:47:39 PM »
Quote from: DJBase;455569
Nice but I doubt it will make much fun even on 68060.



*laughs*


Imagine running it on an 030, which is what most people have! :lol:
\'Using no way as way. Having no limitation as limitation.\' - Bruce Lee

\'No, sorry. I don\'t get my tits out. They\'re not actually real, you know? Just two halves of a grapefruit...\' - Miki Berenyi

\'Evil will always triumph because good is dumb.\' - Dark Helmet :roflmao:

\'And for future reference, it might be polite to ask someone if you can  quote them in your signature, rather than just citing them to make a  sales pitch.\' - Karlos. :rtf
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show only replies by ami_stuff
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #18 on: May 22, 2009, 08:01:51 PM »
Quote from: Methuselas;455681
*laughs*


Imagine running it on an 030, which is what most people have! :lol:


Sure, imagine running it on 68000. :hammer:

Good luck with DivX on your 030 even with asm-optimized MooVId.
 

Offline buzz

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 612
    • Show only replies by buzz
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #19 on: May 22, 2009, 08:38:57 PM »
If he renames it, then surely old applications will not work with it (And some of the changes he has mentioned would benefit some older applications)

Isn't he free to call it what he likes. Those that don't want to use it, can use the older library.
« Last Edit: May 22, 2009, 08:42:52 PM by buzz »
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #20 on: May 22, 2009, 09:34:23 PM »
Quote from: buzz;455687
If he renames it, then surely old applications will not work with it

The old applications will continue to use the old ixemul.library and work adequately, as before.

Quote
Isn't he free to call it what he likes.

Unfortunately he doesn't seem to listen to reason.

Quote
Those that don't want to use it, can use the older library.

The problem is, as it is now the decision is not left to the user. If the developer makes the mistake of installing the latest bernd-ixemul he will automagically create binaries that are only able to work with bernd-ware (even if none of the bernd-ixemul features would be needed!). Regardless what the user does he can only use bernd-ixemul. This is the very heart of the problem.

The library should be renamed. Then there would be no issues from the version conflicts. As it is now the situation is very damaging for the future of ixemul (both non-bernd and bernd).
 

Offline ChaosLord

  • Hero Member
  • *****
  • Join Date: Nov 2003
  • Posts: 2608
    • Show only replies by ChaosLord
    • http://totalchaoseng.dbv.pl/news.php
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #21 on: May 22, 2009, 11:04:06 PM »
Quote from: Piru;455693
The old applications will continue to use the old ixemul.library and work adequately, as before.

There is no such thing as an old ixemul.library that works adequately.

Every ixemul I ever tested was a hopelessly bug-ridden hack.

I found all that out the hard way. :(

Recently people have been insisting at me that it has become safe to once again start using ixemul software if I will only use Bernd's new bugfixed version.  But today I see that Piru has exposed at least 1 bug in Berndemul.

I even created my own ixesux.library to try to "go around" the problems of ixemul and that did fix one set of problems but other problems persisted if someone used ixemul and ixesux at the same time they magically conflicted with each other.  There is some heavily illegal code in there somewhere.  That is why I said above it is "hopeless".  Nobody is ever going to spend the needed 200 hours of work to fix all the bugs in ixemul.

So I simply refuse to use ixemul software.

The above message was a friendly informational message.
Warning: if anyone flames me for this message I will cease & desist from trying to help out with the Grand Ixemul Problem.

Wanna try a wonderfull strategy game with lots of handdrawn anims,
Magic Spells and Monsters, Incredible playability and lastability,
English speech, etc. Total Chaos AGA
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show only replies by ami_stuff
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #22 on: May 23, 2009, 01:04:44 AM »
Quote from: wawrzon;455575
GREAT JOBBBB!!!! i just tried it on my a4k 060, its faster than megacz's port of mplayer. the test porky.mov is played back insync with audio on!. i tried also a couple of other more complex avis up to 640x480. up till now if they were playable then only with warpos enchanced players. now with low_quality_mp3 and -lowres and skipframe it is possible to view them even if with distorted sound and frameskip. if it could be optimized further we could even have a working 68k amiga media player. i do not dare to hope...
it seems to be quite stable too!! no hits whatsoever, responsive while execution!


@wawrzon:

Do you have 060@50MHz or maybe overclocked?

I think that I can try to optimize mpegaudio decoder to run faster on the 68060 CPU, but to test if it really work faster I would need someone with a real 68060 CPU + installed OxyPatcher.

The problem is that 68060 CPU don't have "muls" instruction and this instruction SHOULD be used a lot with mpegaudio decoder. Right now this instruction is NOT USED, because I compiled ffmpeg for 68060 CPU, so GCC "emulates" "muls" instruction with longer code supported by 68060 CPU. I think it may be possible that 68060 + OxyPatcher would be faster compared to GCC's "emulated" code.

On the WinUAE mpegaduio decoder compiled for 68040 (with "muls" instruction) needs only 29 sec. to decode 5 min. MP3 file. 68060 build needs for the same task 1:25 min., so you can see how slow GCC code is.

x86, PPC and ARM CPUs have belowe functions asm-optimized:

#ifndef MULL
#   define MULL(a,b,s) (((int64_t)(a) * (int64_t)(b)) >> (s))
#endif

#ifndef MULH
//gcc 3.4 creates an incredibly bloated mess out of this
//#    define MULH(a,b) (((int64_t)(a) * (int64_t)(b))>>32)

static av_always_inline int MULH(int a, int b){
    return ((int64_t)(a) * (int64_t)(b))>>32;
}
#endif

#ifndef MUL64
#   define MUL64(a,b) ((int64_t)(a) * (int64_t)(b))
#endif

#ifndef MAC64
#   define MAC64(d, a, b) ((d) += MUL64(a, b))
#endif

#ifndef MLS64
#   define MLS64(d, a, b) ((d) -= MUL64(a, b))
#endif

/* signed 16x16 -> 32 multiply add accumulate */
#ifndef MAC16
#   define MAC16(rt, ra, rb) rt += (ra) * (rb)
#endif

/* signed 16x16 -> 32 multiply */
#ifndef MUL16
#   define MUL16(ra, rb) ((ra) * (rb))
#endif

#ifndef MLS16
#   define MLS16(rt, ra, rb) ((rt) -= (ra) * (rb))
#endif

Someone optimized for me two of the functions for 68020-68040 CPUs:

static inline av_const int64_t MAC64(int64_t d, int a, int b)
{
    union { int64_t x; int hl[2]; } x = { d };
    int h, l;
    __asm__ ("muls.l %5, %2:%3   \n\t"
             "add.l  %3, %1      \n\t"
             "addx.l %2, %0      \n\t"
             : "+dm"(x.hl[0]), "+dm"(x.hl[1]),
               "=d"(h), "=&d"(l)
             : "3"(a), "dmi"(b));
    return x.x;
}
#define MAC64(d, a, b) ((d) = MAC64(d, a, b))

static inline av_const int64_t MLS64(int64_t d, int a, int b)
{
    union { int64_t x; int hl[2]; } x = { d };
    int h, l;
    __asm__ ("muls.l %5, %2:%3   \n\t"
             "sub.l  %3, %1      \n\t"
             "subx.l %2, %0      \n\t"
             : "+dm"(x.hl[0]), "+dm"(x.hl[1]),
               "=d"(h), "=&d"(l)
             : "3"(a), "dmi"(b));
    return x.x;
}
#define MLS64(d, a, b) ((d) = MLS64(d, a, b))

but I need 68060 versions. The rest of the C functions should also be asm-optimized for 68060.
« Last Edit: May 23, 2009, 01:34:28 AM by ami_stuff »
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show only replies by ami_stuff
 

Offline wawrzon

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #24 on: May 23, 2009, 02:37:29 AM »
@ami_stuff: no. it is not overclocked. as far as understand oxypatcher just like cyberpatcher patches non optimized exes on the fly. so you want someone to run your current exe on a regular 060/50 with oxypatcher on? unfortunatelly i do not recall to have this soft but i havnt examined the software boxes i got lately with my last purchuase. i see softwarehut has this too, maybe i could get it if need be.
 

Offline Tumbleweed

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #25 on: May 23, 2009, 10:19:29 AM »
Quote from: DJBase;455569
Nice but I doubt it will make much fun even on 68060.


This rocks! I installed it last night and ran it this morning and its really good. I encoded a Futurama episode on my PC, using PocketDVD_Studio using the lowest settings for Video and Audio. Video 61kbs 15 fps; Audio AM raio quality 24kbps Mono and set the resolution to 160x128. I then burned the file to a DVD and transferred to my A4000D. Fired it up in FFPlay and hey presto its runnning fine - video at least; (my audio circuit is flakey due to leaky caps).

A4000D Specs as follows:

A4000D Kick v45.57 Workbench v45.3 BB1, BB2
CSMK11 060 128MB Ram
Z3 Fastlane 48MB
CV3D with scan doubler
Deneb 2.0
80GB IDE HD
A3000T, Cybervision64, CSMKII 060; A3000D, PicassoII, Z3 Fastlane; A2000D, 040, PicassoII; A4000D, A1200, Blizzard 030 MKIV  (not working - next project)
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show only replies by ami_stuff
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #26 on: May 23, 2009, 11:38:42 AM »
Quote from: Tumbleweed;455789
This rocks! I installed it last night and ran it this morning and its really good. I encoded a Futurama episode on my PC, using PocketDVD_Studio using the lowest settings for Video and Audio. Video 61kbs 15 fps; Audio AM raio quality 24kbps Mono and set the resolution to 160x128. I then burned the file to a DVD and transferred to my A4000D. Fired it up in FFPlay and hey presto its runnning fine - video at least; (my audio circuit is flakey due to leaky caps).

A4000D Specs as follows:

A4000D Kick v45.57 Workbench v45.3 BB1, BB2
CSMK11 060 128MB Ram
Z3 Fastlane 48MB
CV3D with scan doubler
Deneb 2.0
80GB IDE HD


If you really need to re-compress your episodes, next time try to use Cinepak.

The only  problem is that the code is not optimized at all, but no one will do it for free just to read that it is still not fast enough to watch your episodes on your 20 years old hardware. At least you can slideshow videos with the recent codecs. On WinUAE there is no problem with speed :)
« Last Edit: May 23, 2009, 11:49:41 AM by ami_stuff »
 

Offline wawrzon

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #27 on: May 23, 2009, 12:08:18 PM »
how about replacing sdl parts of code, it displays via sdl i take it? maybe we should create a bounty to optimize it for the last century hw? :P no, im serious..
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show only replies by ami_stuff
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #28 on: May 23, 2009, 12:12:10 PM »
Quote from: wawrzon;455805
how about replacing sdl parts of code, it displays via sdl i take it? maybe we should create a bounty to optimize it for the last century hw? :P no, im serious..


Yes, without SDL it might be faster because less code would be used. Also, SDL is not asm-optimized, only C code. FFmpeg's MP3 decoder should be repleaced with optimized mpega.library, but no one will do it.
 

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #29 from previous page: May 23, 2009, 12:22:28 PM »
Quote from: Piru

And how can you tell that the application is not testing for the result? This


do you want faking me ?
everybody know when linux run out of virtuel mem, apps crash, because devs are most part lazy and dont check for enough mem.

If somebody know this not, please lower ram and deactivate swap space and use linux try ffplay or other player progs show some images etc.

Quote from: piru

The problem is, as it is now the decision is not left to the user. If the developer makes the mistake of installing the latest bernd-ixemul he will automagically create binaries that are only able to work with bernd-ware


ok it seem you think i am stupid, but now it seem you think all developers are stupid and dont know that the dev files must copy by hand to lib dir.

If a developer not copy crt0.o from V61 and not use libc.a from V61 and use instead the old versions from V49 or V48 all should work on MOS.if it not work on MOS, then its a Bug in MOS ixemul.

also the attached crt0.o is named crt0_v61.o.a dev must foirst rename it

what you want is this.

You want force that ixemul on 68k is not furtherdevdelop because it is port since long time to MOS.right ?

burt what rights MOS have, that now that ixemul run on MOS 68k ixemul cant get new features ?

That you write here so much wrong text, instead  change the source so the buildsystem can create another lib show me too its not enough to only change the name.

as you know ixemul is a BSD kernel running on AOS.Can you 100% sure that all work well, if a program use ixemul V48 and 1 program ixemul_ng at same time ?

then there run unnecessary 2 Unix kernels, that need additional  signalling , shedulling mem etc.
Can you be sure, that it not slowdown system, when there now 2 ixemultaskswitchers are installed ?

Quote from: chaoslord

But today I see that Piru has exposed at least 1 bug in Berndemul.


what bug you mean have V61 ?
i read Piru post, they are very long but i see no Bug

Quote from: chaoslord

I even created my own ixesux.library to try to "go around" the problems of ixemul and that did fix one set of problems but other problems persisted if someone used ixemul and ixesux at the same time they magically conflicted with each other. There is some heavily illegal code in there somewhere.


so and here are the Facts, what i think, just a rename is not enough.
« Last Edit: May 23, 2009, 12:35:53 PM by bernd_afa »