Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: FFmpeg + FFplay SVN-r18880 (m68k)  (Read 14521 times)

0 Members and 1 Guest are viewing this topic.

Offline 0amigan0

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #30 on: May 23, 2009, 12:33:41 PM »
@Bernd_afa:

I'm with you.
Go on with your work, improving things on 68k Amiga, and don't bother what people like Piru are saying!
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #31 on: May 23, 2009, 12:46:17 PM »
Quote from: 0amigan0;455809
@Bernd_afa:
Go on with your work, improving things on 68k Amiga, and don't bother what people like Piru are saying!

There is absolutely nothing wrong with that. But he should still rename the library.
 

Offline wawrzon

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #32 on: May 23, 2009, 12:56:32 PM »
@ami_stuff: thinking again im not sure mp3 decoding and sdl display fuctions are critical. disabling audio doesnt bring that much speedup suprisingly at least at low quality player. i know, on 060 mp3 decoding is in fact already an expensive task, but anyway. from what was posted on amigans on topic of the new flash port, replacing sdl drawing fuctions with os4 native has not brought a major speedup. so probably it is just decoding that matters most.

@bernd: after all i too think you are right.
 

Offline ami_stuff

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #33 on: May 23, 2009, 01:02:45 PM »
Quote from: wawrzon;455812
@ami_stuff: thinking again im not sure mp3 decoding and sdl display fuctions are critical. disabling audio doesnt bring that much speedup suprisingly at least at low quality player. i know, on 060 mp3 decoding is in fact already an expensive task, but anyway. from what was posted on amigans on topic of the new flash port, replacing sdl drawing fuctions with os4 native has not brought a major speedup. so probably it is just decoding that matters most.


This should be a start when someone want to optimized video player for m68k. MP2/MP3 codecs are used with all of the video files like AVI, MPG and when mpegaduio decoder is slow, you will not get any decent speed even with Cinepak video codec.

FFplay supports a lot of codecs, when you optimize DIvX, it will not speedup MPEG decoding process. Run "FFplay -formats", so you will see how much work it would require to optimize all of this stuff.

Again, SDL code is C only. When you repleace SDL with direct asm-rountines, it will be a lot faster WHEN you use for test uncompressed AVI files.
« Last Edit: May 23, 2009, 01:07:25 PM by ami_stuff »
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #34 on: May 23, 2009, 01:07:55 PM »
Quote from: bernd_afa;455808
do you want faking me ?
Um, probably not. I didn't quite understand that, sorry.
Quote
everybody know when linux run out of virtuel mem, apps crash, because devs are most part lazy and dont check for enough mem.
This is often the case, but yet it does not justify f*cking up libc for the cases where it is not. libc should not bring up some requester when malloc() fails.

The correct way to handle this would be to have a link-library that replaces malloc/realloc/free. This link library would then have the requester code. When building a program that can be expected to crash if malloc fails just add the linklib to the link cmdline in makefile (say -lsafemalloc). Clean, easy, no need to mess up the libc with silly requesters.

Anyone with even decent emount of design experience can see this.

Quote
also the attached crt0.o is named crt0_v61.o.a dev must foirst rename it
Bad design again.

With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.

Quote
You want force that ixemul on 68k is not furtherdevdelop because it is port since long time to MOS.right ?
No. I want you to rename your branch of ixemul. Then you can do whatever you like with the API and functionality, without need to worry about messing things up (you'd only mess your stuff then, not everyone elses).

Quote
burt what rights MOS have, that now that ixemul run on MOS 68k ixemul cant get new features ?
Sorry, I didn't quite get that.

I suppose you're trying to suggest I somehow try to block your ixemul development. That's not the case; I merely want you to rename the library.

Quote
change the source so the buildsystem can create another lib show me too its not enough to only change the name.
Huh, what?

Quote
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 ?
Yes.

Quote
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 ?
Yes.
 

Offline wawrzon

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #35 on: May 23, 2009, 01:12:52 PM »
@ami_stuff: yeah. i could get this damn delfina with a mp3 decoder dsp, i wantde to do it for weeks. but i could throw as well these >100eur into the basket to optimize mpega.library. are you sure it has to be done from the scratch, there are numerous versions on the net. none asm optimized for mp3 decoding?
 

Offline ami_stuff

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #36 on: May 23, 2009, 01:23:19 PM »
Quote from: wawrzon;455815
@ami_stuff: yeah. i could get this damn delfina with a mp3 decoder dsp, i wantde to do it for weeks. but i could throw as well these >100eur into the basket to optimize mpega.library. are you sure it has to be done from the scratch, there are numerous versions on the net. none asm optimized for mp3 decoding?


Yes, mpega.library should be fine for MP3 decoding, but it will not optimize DIvX codec, so as a result you will still have slow playback.

MP3's hardware decoder will not help you as long as FFplay don't support it or there is no mpega.library repleacement which uses your hardware decoder.

But of course first FFplay needs to have mpega.library support :)

When you have AVI file with DIvX video codec and MP3 audio codec, all of these codecs needs to be optimized, not only one, or you will not see any different.
 

Offline bernd_afa

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #37 on: May 23, 2009, 01:54:22 PM »
Quote from: Piru;455814
Um, probably not. I didn't quite understand that, sorry.

The correct way to handle this would be to have a link-library that replaces malloc/realloc/free. This link library would then have the requester code. When building a program that can be expected to crash if malloc fails just add the linklib to the link cmdline in makefile (say -lsafemalloc). Clean, easy, no need to mess up the libc with silly requesters.

Anyone with even decent emount of design experience can see this.
.


i see no reason, that programmer need do additional work.A requester is always 1000* more usefull than a complete amiga OS crash.
but if there is really a reason that it is better that amiga crash than show a error requester that users should free more memory, i can add a envvar that switch it off.no problem

Quote from: Piru;455814

With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.


But MOS ixemul handle this not.there are no diffrent spec files to support programs that run on V48.

when use the V49 MOS libc or cr0.o this programs fail on V48 ixemul because V48 miss features.

when use such a program on OS4, then it crash badly, because OS4 ixemul have number V51.

on ixemul V61 such a program work, because this ixemul support V49 MOS funcs too.

so you see MOS V49 is exact same problem, this should rename.there should be a V48 that is compatible and a ixemul_ng for MOS that offer this new functions.

and when you do that what you want from me on the ixemul code, and it work well, i do same.

But dont be believe that i am so stupid and do extra work others want to do.

So my offer is easy, change MOS ixemul to be clean, name the V49 MOS Version that have new functions to a new name.if then both ixemul work on MOS (i have a cybppc and can test)then i make that too.

You still have no logical arguments wy 68k ixemul should rename, but MOS ixemul V49 not.

if you want discusss more, then we can this together with neutral people here.

Morphos is already known on the GPL Violaters, see that entry and read the comments.

http://developers.slashdot.org/comments.pl?sid=142894&cid=11973934

if they say that the furtherdevelop 68k ixemul should rename and the MOS furtherdevelop ixemul need not not renaim, then i accept it.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #38 on: May 23, 2009, 02:27:42 PM »
Quote from: bernd_afa;455818
i see no reason, that programmer need do additional work.
Adding -lsafemalloc to the link cmd would be a lot of additional work?

Quote
A requester is always 1000* more usefull than a complete amiga OS crash. but if there is really a reason that it is better that amiga crash than show a error requester that users should free more memory, i can add a envvar that switch it off.no problem
The code should not be there at all. If it is there, it should be disabled by default. I've already explained why having such functionality by default is a very bad idea (see the apache example).

Quote
Quote
With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.
But MOS ixemul handle this not.
Irrelevant as MorphOS ixemul or SDK do not generate m68k binaries. See below.

Quote
there are no diffrent spec files to support programs that run on V48.
when use the V49 MOS libc or cr0.o this programs fail on V48 ixemul because V48 miss features.
But ixemul devkit on MorphOS is used to create powerpc binaries not m68k. As such there is no problem.

Quote
when use such a program on OS4, then it crash badly, because OS4 ixemul have number V51.
That is a problem of OS4. Why you chose to repeat it, is a mystery.

Quote
But dont be believe that i am so stupid and do extra work others want to do.
Um, what?

Quote
So my offer is easy, change MOS ixemul to be clean, name the V49 MOS Version that have new functions to a new name.if then both ixemul work on MOS (i have a cybppc and can test)then i make that too.
If you wish you release your renamed library for MorphOS that is just fine! In fact, I'd welcome it. There's no reason why the two couldn't co-exist.

Quote
You still have no logical arguments wy 68k ixemul should rename, but MOS ixemul V49 not.
MorphOS ixemul doesn't allow developers to create 68k binaries that don't run on other ixemul versions.

Quote
Morphos is already known on the GPL Violaters, see that entry and read the comments.
Lets examine the claims in that post in detail:
Quote
ixemul
Did or didn't you get the source code for ixemul when you requested it?
Quote
libnix
Isn't open source that'd require distribution of the sources.
Quote
gcc & binutils
http://www.lysator.liu.se/~lcs/files/gg-cross/

I find it quite insulting that you're speading these lies even further. There are no GPL violations in MorphOS. This sounds almost like the rerun of the "MorphOS is based on stolen AmigaOS source code" -lies. Really lame, and childish. I guess people will default to such tactics when all else fails.

Quote
if they say that the furtherdevelop 68k ixemul should rename and the MOS furtherdevelop ixemul need not not renaim, then i accept it.
Who exactly? All I can see is a anon post in a slashdot thread. The post is full of lies. Hello!? That's as intelligent as pulling a nazi card or something.

[EDIT]

After some deciphering I think you're referring to the gpl-violations.org thread. If you read carefully you learn that the problem was with the wording of the powerup download page. As soon as we found out about the problem (which a) we were never told about b) isn't really a GPL violation [I should also mention that the GPL and LGPL is included on the CD.]), we fixed the download page wording.

This is the only time MorphOS is mentioned on the gpl-violations.org.

Regardless, gpl-violations.org has no authority on this matter at all, so "asking them" is quite useless.

[/EDIT]

Stop that foolishness and rename the fork already. By insisting on this version bump trickery you're only causing harm to all ixemul versions.
« Last Edit: May 23, 2009, 03:05:31 PM by Piru »
 

Offline bernd_afa

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #39 on: May 23, 2009, 03:01:05 PM »
Quote from: Piru;455820

MorphOS ixemul doesn't allow developers to create 68k binaries that don't run on other ixemul versions.


then all is clear.ixemul V61 doesnt allow developers to create programs that need V61 funcs to run on other ixemul Versions.

if in the readme stand need V61 ixemul then its clear and the requester show this.

again, it seem not easy possible to run 2 ixemul.Have you not read the Post ?

if it is only a rename this take 5 minutes, i think you need more than 5 minutes to read and post about that, and it is more clever, when you instead of writing here only spend 3 minutes to rename ixemul and post here the diff.

Whats your roadmap about ixemul.after how many years you think reach V60 with MOS ixemul ?.

Or do you think 68k programmers should always force that new programs with modern features run on MOS too and MOS devs should not write programs to use new features that run on 68k ?

I have also the new function add from MOS, so programs can common written with V49 functions on 68k and MOS.

currenlty you have bring no facts, is it true that MOS give a PPC program a ppc ixemul before a 68k version ?

and a 68k program that want a V61 ixemul but there is only a V49 PPC ixemul open then a 68k ixemul with that number ?

so wy cant V61 68k ixemul not run on MOS, if there is no native lib ?
I use no traps.

then MOS user and you can see, that all work stable and clean and 100% backward compatible.i am sure if V61 run on MOS, then there run more 68k ixemul programs than with V49 ixemul.
 

Offline bernd_afa

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #40 on: May 23, 2009, 03:17:50 PM »
Quote from: ami_stuff

Yes, without SDL it might be faster because less code would be used. Also, SDL is not asm-optimized, only C code.


most speedcritical is in sdl the YUV to RGB conversion and scaler.MOS or OS4 SDL support working cgx or P96 overlay code, so code can merge easy i think.

but if on classic amigas cards are out that support HW overlay Bug free i dont know.

i remember on my cybervision PPC and the phase5 videoplayer that support overlay (forget name) crash randomly.

so i also dont know if overlay can work stable.

sound is slow, because it use 64 bit commands a 68060 dont have.this is used in the DCT code and antialiasing Filter code.
if somebody know a fast DCT code for 68k cpu, then this func can add.i dont like the gcc assembler mess and i like a amiga dspmath.library i can code in amiblitz, that is systemspecific for 68060 winuae or other CPU.


on winuae it call then native ISSE code, for 68060 asm optimized code.

BTW: You forget in your feature list, that ffplay with no filename open a amiga filerequester.

here is the code of the DCT.i think this are the few speedcritical lines but MULH use a 64 bit mul.the antialiasing filter can also work with FPU, maybe thats faster on a 060.

maybe this code can move in a amiga library imdct36 and more programs can use it ?

same with other speedcritical funcs ?

static void imdct36(int *out, int *buf, int *in, int *win)
{
    int i, j, t0, t1, t2, t3, s0, s1, s2, s3;
    int tmp[18], *tmp1, *in1;

    for(i=17;i>=1;i--)
        in += in[i-1];
    for(i=17;i>=3;i-=2)
        in += in[i-2];

    for(j=0;j<2;j++) {
        tmp1 = tmp + j;
        in1 = in + j;
        t2 = in1[2*4] + in1[2*8] - in1[2*2];

        t3 = in1[2*0] + (in1[2*6]>>1);
        t1 = in1[2*0] - in1[2*6];
        tmp1[ 6] = t1 - (t2>>1);
        tmp1[16] = t1 + t2;

        t0 = MULH(2*(in1[2*2] + in1[2*4]),    C2);
        t1 = MULH(   in1[2*4] - in1[2*8] , -2*C8);
        t2 = MULH(2*(in1[2*2] + in1[2*8]),   -C4);

        tmp1[10] = t3 - t0 - t2;
        tmp1[ 2] = t3 + t0 + t1;
        tmp1[14] = t3 + t2 - t1;

        tmp1[ 4] = MULH(2*(in1[2*5] + in1[2*7] - in1[2*1]), -C3);
        t2 = MULH(2*(in1[2*1] + in1[2*5]),    C1);
        t3 = MULH(   in1[2*5] - in1[2*7] , -2*C7);
        t0 = MULH(2*in1[2*3], C3);

        t1 = MULH(2*(in1[2*1] + in1[2*7]),   -C5);

        tmp1[ 0] = t2 + t3 + t0;
        tmp1[12] = t2 + t1 - t0;
        tmp1[ 8] = t3 - t1 - t0;
    }

    i = 0;
    for(j=0;j<4;j++) {
        t0 = tmp;
        t1 = tmp[i + 2];
        s0 = t1 + t0;
        s2 = t1 - t0;

        t2 = tmp[i + 1];
        t3 = tmp[i + 3];
        s1 = MULH(2*(t3 + t2), icos36h[j]);
        s3 = MULL(t3 - t2, icos36[8 - j], FRAC_BITS);

        t0 = s0 + s1;
        t1 = s0 - s1;
        out[(9 + j)*SBLIMIT] =  MULH(t1, win[9 + j]) + buf[9 + j];
        out[(8 - j)*SBLIMIT] =  MULH(t1, win[8 - j]) + buf[8 - j];
        buf[9 + j] = MULH(t0, win[18 + 9 + j]);
        buf[8 - j] = MULH(t0, win[18 + 8 - j]);

        t0 = s2 + s3;
        t1 = s2 - s3;
        out[(9 + 8 - j)*SBLIMIT] =  MULH(t1, win[9 + 8 - j]) + buf[9 + 8 - j];
        out[(        j)*SBLIMIT] =  MULH(t1, win[        j]) + buf[        j];
        buf[9 + 8 - j] = MULH(t0, win[18 + 9 + 8 - j]);
        buf[      + j] = MULH(t0, win[18         + j]);
        i += 4;
    }

    s0 = tmp[16];
    s1 = MULH(2*tmp[17], icos36h[4]);
    t0 = s0 + s1;
    t1 = s0 - s1;
    out[(9 + 4)*SBLIMIT] =  MULH(t1, win[9 + 4]) + buf[9 + 4];
    out[(8 - 4)*SBLIMIT] =  MULH(t1, win[8 - 4]) + buf[8 - 4];
    buf[9 + 4] = MULH(t0, win[18 + 9 + 4]);
    buf[8 - 4] = MULH(t0, win[18 + 8 - 4]);
}
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #41 on: May 23, 2009, 03:21:09 PM »
I see it is pointless to try argue the matter further. You're just unwilling or unable to understand even the basic concepts of good design and good development practices.

Anyone using the new ixemul for development will lose the ability to run the binaries under MorphOS. Instead the programs will just crash and die horribly (there is no way to avoid this now, it is inevitable because of the bernd version mess).

It would be possible to avoid this all, and have all binaries running on different platforms just fine, if only the bernd-ixemul library would be renamed.

It is very unfortunate that the stubborness of one developer has lead to this.

Overall this will lead to death of ixemul as a portability platform. Such incompatible versions will spell total chaos and confusion for both developers and end users.

I won't be bothering you again about this. Have a nice day.
« Last Edit: May 23, 2009, 03:26:44 PM by Piru »
 

Offline wawrzon

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #42 on: May 23, 2009, 03:54:32 PM »
@ bernd:
voodoo supports overlay atl east as far as its used by elbox driver to display dma signal streaming from a tv card in a workbench window. its fully resizable and all. i dont know exactly of p4 but i could test it someow. but since there was also tv-receiver module for p4 once i believe also p4 supports overlay to some extent. i have both graphic cards installed in my both main amiga machines so i can test. i have also some cv64 layin around here, so i could build system to test that too. have been too lazy so far..
 

Offline ChaosLord

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #43 on: May 23, 2009, 04:21:14 PM »
Background:
The version number problem with ixemul has been around since before Bernd came onto the scene.  Probably since before MOS.
There have always been certain programs that required vA of ixemul.library while others demanded vB.  When the new vB version of ixemul was used certain older programs stopped working correctly.  But switching back to vA did not solve everything either.  Some other different programs broke under vA.  Its been a long standing problem.

This same thing has happened with lots of other shared libraries also.  Basically any complex library that gets steady development over time seems to develop this problem eventually.  The more coders that work on the library the more likely it seems to be to occur.



PROBLEM: Libraries are Global.
The filename "ixemul.library" is global.
The code inside ixemul.library is global.

ixemul.library can be considered to be one gigantic global variable.
This is all true for any shared library.

When 2 different people write 2 different programs that expect a particular global variable to behave differently, there will be bugs and crashes.


SOLUTION: Stop using global variables.  Use local variables instead.
Everyone who wants "ixemul" functionality must link in a static .lib (ixemul.lib) into their exe.

That is the only solution that will ever work 100% for everyone.
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 bernd_afa

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #44 on: May 23, 2009, 05:57:32 PM »
Quote from: Piru

Anyone using the new ixemul for development will lose the ability to run the binaries under MorphOS.
Instead the programs will just crash and die horribly (there is no way to avoid this now, it is inevitable because of the bernd version mess).


thats complete wrong, because MOS have only a V49 ixemul, a program that need V61 ixemul bring a requester V61 ixemul need.

then User can try 68k ixemul V61.If thats not work on MOS, thats not my fault.MOS is announce as 68k compatible, and when ixemul V61 not work, then MOS 68k EMU have Bugs until you show me whats wrong in ixemul V61 Code.

and currently you have not show me whats wrong, about the out of mem requester it is also easy possible to change.

Quote from: Piru

Overall this will lead to death of ixemul as a portability platform. Such incompatible versions will spell total chaos and confusion for both developers and end users.


again this is done with your MOS V49.

A MOS developer can choose if he want develop faster and use V49 funcs or develop slower and have 68k compatibilty.

and what do you guess is the choose ?
A developer can also on V61 choose that he want only use V48 V49 funcs so the 68k program run maybe on MOS.again if it not work there is possible that MOS ixemul is incompatible.


working together seem not possible of diffrent platforms on amiga land,
and thats not my fault, i make you many suggestions to solve this problem, but you react in my eyes as a little child without logical reason, wy 68k ixemul should always stay on functionaltiy as V48 and never should get more features as V48.

You also dont want help to get running ixemul V61 on MOS or post the changes need in the buildscript to change the name.
« Last Edit: May 23, 2009, 06:19:59 PM by bernd_afa »