FFmpeg + FFplay SVN-r18880 (m68k)

[Piru]

if it could be optimized further we could even have a working 68k amiga media player. i do not dare to hope...

I'm afraid you can forget about the optimizations. The code is pretty much as optimal as it can get.



Also, I wonder what is going on with those "ixemul" version numbers... Unlike what some have speculated elsewhere, those bumps weren't my idea. My request was to rename the library, as it clearly no longer is compatible. If you're wondering why I care about the 68k library: 68k ixemul applications also work on MorphOS, but any binary linked with link libraries from the "new ixemul" SDK will not. Just because of the version bump... The correct way to handle this is to rename the new library, especially since library API changes appear to have occurred (why else would there be a bump?).

When I was requested the ixemul source code I wondered what could be the worst case situation resulting from it. I came up with: "Some less clued developer releasing incompatible versions with bumped version." Too bad this has come to pass.

Please Bernd, stop breaking ixemul, rename your branch.

[Piru]

well, yes it was me that supposed that discussions between you and bernd result in this wild version numbers. but as far as ive been able to test the 68k versions of sdl ports do not work on os4 and of course vice versa, unfortunatelly i do not know of mos, since ive got no machine i could run it on.

MorphOS ixemul can run both original 68k and PPC native binaries.

but i dont believe mos has to rely on 68k sdl ports anyway, so how does this break anything on mos?

Any application built for 68k using the new SDK fails to start on MorphOS. Remember: ixemul can also be used for closed source projects, so source code might not be always available.

To correct the situation the library must be renamed, and fast. The longer anyone has the non-renamed ixemul SDK installed, more probable are the broken binaries being generated. Having the library renamed would have several benefits:
1) Developers would be able to build binaries targeted for known shared API (ixemul) which would work on both classic AmigaOS and MorphOS or for the bernd-ixemul. If needed, binaries for both could be provided.
2) Bernd could keep on expirementing on his own "ixemul" fork freely, without upsetting developers involved in the ixemul at every release.
3) If bernd-ixemul actually ends up having some useful changes, then either those can be backported to "original" ixemul (without actually being FORCED TO, as would be the case now), or the bernd-ixemul could be built for the target system. This way both could co-exists easily.

but are you sure that new functions in ixemul break things on mos? did you try and found an example?

The new functionality breaks even with 68k: namely trying to make ixemul amigaos thread safe. This is not possible mainly because of the way unix like signalling works. So the current 68k bernd-ixemuls are broken, especially when anything relying on this "thread-safety" is used, for example SDL. It might seem to work for now, but certain usage patterns will make it die horribly. In general ixemul does not mix with amigaos calls and ixemul should only be used to build non-amigaos code. Bernd is not experienced enough to understand this, it seems.

[Piru]

if you are really concerned about above why dont you talk privately to bernd?

I have tried talking to him. It didn't help, it seems (the library did not get renamed).

im sure he is eager to learn and improve things and would accomodate every constructive advice into his work. since the code seems to be on sf you even could work together to assure keeping mos compatibility in ixemul

MorphOS ixemul will only accompany changes we approve of. So far none of them have. Considering bernd and I disagree on fundamental issues co-operation isn't possible (I doubt he would be willing to revert most of his changes).

[Piru]

I ask you again: Please rename your ixemul library. These version number tricks are NOT helping at all. They're just polluting the name/versionspace needlessly.

As you say, old program will work just fine when using the old library.

When the new features are needed, the new library is used.

What you've done now is to make it impossible to release any ixemul library unless if you bump version to 62. That is just unacceptable.

[Piru]

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.

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.

* 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.

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!?

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

[Piru]

most do no  benchmarks, so they dont notice that.

You're running what kind of benchmark exactly?

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.

Wy do you write its in libc ?

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

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.

[Piru]

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.

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

Unfortunately he doesn't seem to listen to reason.

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).

[Piru]

@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.

[Piru]

do you want faking me ?

Um, probably not. I didn't quite understand that, sorry.

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.

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.

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).

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.

change the source so the buildsystem can create another lib show me too its not enough to only change the name.

Huh, what?

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.

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.

[Piru]

i see no reason, that programmer need do additional work.

Adding -lsafemalloc to the link cmd would be a lot of 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

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).

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.

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.

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.

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

Um, what?

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.

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.

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

Lets examine the claims in that post in detail:

ixemul

Did or didn't you get the source code for ixemul when you requested it?

libnix

Isn't open source that'd require distribution of the sources.

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.

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.

[Piru]

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.