Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #44 from previous page: 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 »
 

Offline koaftder

  • Hero Member
  • *****
  • Join Date: Apr 2004
  • Posts: 2116
    • Show only replies by koaftder
    • http://koft.net
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #45 on: May 23, 2009, 07:36:02 PM »
This thread blows my mind. I don't know how somebody could accumulate enough skill and experience to develop stuff like this and come to the conclusion that modifying the standard behavior of malloc is a good idea. Mind blowing.
« Last Edit: May 23, 2009, 07:36:38 PM by koaftder »
 

Offline dcr8520

  • Full Member
  • ***
  • Join Date: Mar 2002
  • Posts: 107
    • Show only replies by dcr8520
    • http://Amiga.SourceForge.net
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #46 on: May 23, 2009, 11:11:57 PM »
Quote from: bernd_afa;455857

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


apache was a very good example.. and using a global environment variable to disable your "hack" (requester) is not good either for other programs which may need it.. The best should be to create a "blacklist" (or "whitelist") where to add programs which should or not use that extra check over malloc(), IMHO.

That said, IIRC all that regarding "strange versions bumps" started due the broken V49 version for m68k. Well, what about REMOVING from Amiga.sf ixemul V49, 50, and 61, AND THEN change your ixemul 61.1 to version eg 49.30 (i think last MOS version is ixemul 49.26) ?? Can't this be ok for both parts?.. (if this cause certain m68k programs to crash under MOS/OS4, don't worry, we should interpret it as a MOS/OS4 fault, the same way other programs already crashes under OS4 by the V51 version used there(?))
 

Offline Crumb

  • Hero Member
  • *****
  • Join Date: Mar 2002
  • Posts: 1786
  • Country: 00
    • Show only replies by Crumb
    • http://cuaz.sourceforge.net
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #47 on: May 23, 2009, 11:42:57 PM »
Quote from: bernd_afa;455824
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.

Classic Amigas have overlay with various cards:

CV3D, PicassoIV, Prometheus/Mediator/G-rex+3dfx Voodoo... IMHO it's a good idea supporting it

@Diego

Jumping back to version 49.30 sounds better. The main problem here is IMHO that there's no cooperation between OS4/MOS/OS3 developers and they don't work together to bring new ixemul versions... I would prefer something using SDI headers, like sourceforge MCC classes, that compiled in the three OSes. And global variables are not a good idea. Perhaps it could be changed to create some kind of ixemul.resource in memory with all that global variable stuff. Then the code could be changed to use the same name as the library, e.g. newixemul.library and newixemul.resource.

I think that Bernd could simply add some "experimental version warning" for developers and that he should keep separated the malloc stuff. The idea of adding a simple flag when compiling like -lsafemalloc proposed by Piru is quite reasonable.

BTW, is libnix updated to latest MorphOS versions? I usually avoid using ixemul...

I really appreciate the efforts Bernd does in the 68k front but Piru knowledge of AmigaOS inner working is impressive and his advice should be followed.

I would prefer there was some cooperation between OS4/OS3/MOS devs. It doesn't make much sense that there are 3 people reinventing the wheel with incompatible versions of the same library...

As ChaosLord as suggested, couldn't new v61 ixemul be statically linked? that way we would fix the problem temporarily until the 3 teams cooperate.

Good job with the ffmpeg port for 68k... does it convert FLV to Cinepak? that could make possible to use Tubexx with AmigaOS3 and use common avi/mov players like Moovid to play the files with weak cpus.

BTW, 680x0 cpus usually decode mp3 faster using integers.
« Last Edit: May 23, 2009, 11:50:05 PM by Crumb »
The only spanish amiga news web page/club: Club de Usuarios de Amiga de Zaragoza (CUAZ)
 

Offline dcr8520

  • Full Member
  • ***
  • Join Date: Mar 2002
  • Posts: 107
    • Show only replies by dcr8520
    • http://Amiga.SourceForge.net
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #48 on: May 24, 2009, 12:52:43 AM »
They don't really need to "work together" to bring new ixemul versions... there we had V48 for ages and a new V49 was made for MOS bringing new API functions, then that lib gets backported to OS3.. if new functions are added later to that os3/68k version, the MOS's ixemul-maintainer should implement such new api functions to create THE compatibility, and so on for each platform.

How the library itself works internally on each platform does not "really" matter.. while it works ok (without causing conflicts between systems), of course. For example, for the ixemul >= 50 Bernd had to get the vfork/signals stuff from the V48, because the one re-implemented for V49-MOS didn't worked ok under OS3/m68k.. but thats ok after all, the new ixemuls are (should be) compatible with the <= V49 branch, regardless how it works internally.

and about SDI headers, thats ixemul.. not a simple OOP "program" ;) i doubt it can be done by using macros, i think everything would need to be ifdef'ed to compile ok around systems.
 

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #49 on: May 24, 2009, 09:52:14 AM »
Quote from: koaftder;455869
This thread blows my mind. I don't know how somebody could accumulate enough skill and experience to develop stuff like this and come to the conclusion that modifying the standard behavior of malloc is a good idea. Mind blowing.


on a harddrive this behaviour is standard, there come message disk full, and a user can free some memory and try again.Is this not usefull ?.Or is it better to change as in memalloc case, to crash the system, if not enough hardisk space is here, or end the program, or force a developer to check if there is always enough diskspace free ?

i have now download apache and search for malloc

the first entry i find was in support.ab.c

""""
ssl_info = malloc(128);
                apr_snprintf(ssl_info, 128, "%s,%s,%d,%d",
                             SSL_CIPHER_get_version(ci),
                             SSL_CIPHER_get_name(ci),
                             pk_bits, sk_bits);
""""

here you see no check for enough mem, result is crash, with overwrite of execbase.i can make ixemul more stable when i do a check in snprintf that it do nothing when 0 pointer, so all programs work better, annother reason again 2 Versions.

""""
if ((cleanenv = (char **) calloc(AP_ENVBUF, sizeof(char *))) == NULL) {
        log_err("failed to malloc memory for environment\n");
        exit(120);
    }
""""

here if the memalloc fail the program is end (exit(120)) do that and a user cant free some memory so the program contiue to work

there are other places that do mem alloc check in apache, but i think all result in that case that apache end.but the requester in ixemul allow a user to free some mem and he can then click on try again and apache do not end and continue to work.


A black and white list is too much work for this feature, but there are only contra about that feature here read only pro from me, i deactivate it as default, and if a user want be more sure that his system not crash, he can activate that.

Quote from: Crumb

Jumping back to version 49.30 sounds better. The main problem here is IMHO that there's no cooperation between OS4/MOS/OS3 developers and they don't work together to bring new ixemul versions...
[/ QUOTE]

this too not work.OS4 have their lib number as V51.1 but this support not OS4 functions.

Also when you say, we should stay at a same level, then look on programs that are out.

every dev side do additional work, to support only their features.

for example read here about the itf8_decode function only in MOS 2.0
http://utilitybase.com/

for this few lines, netsurf is not easy portable and need MOS 2.0.o think with codepage.library utf comvert is too possible, maybe it need not char by char call and is faster, i dont know.

My experience is, that new MOS or OS4 functions are mostly small functions, and devs do their best to make their programs not easy portable.

.see netsurf or OWB or other opensource programs that are portet opensource.Yam /simple mail have much more complex GUI as OWB or netsurf and there is a sourcetree possible without changes.

but when look on netsurf, i see  1,3 megabyte OS4 only code and 960 kb MOS MUI only sourcecode.

I really ask how it is possible to write so much diffrent code only for diffrent GUI that is far not so large as YAM or simplemail.

Is reaction really worth to do this big extra work ?

in the linux world there is tolerance for each system.but not an amiga OS.the comercial aspect, that every commercial AOS need enough user to support further development, introduce the red versus blue war i think and some strange comments to other systems that enhance AOS features too.

Again it is not easy to change the ixemul name only and programs can work together.

if it is easy, then i think Piru have done this and post the diffs here.I have suggest him this at beginnung to do, but he write instead long in my eyes unlogical and senseless Posts with wrong Facts, i must correct, so i need write too much.

Quote

As ChaosLord as suggested, couldn't new v61 ixemul be statically linked? that way we would fix the problem temporarily until the 3 teams cooperate.


i prefer that with 68k SDL, but sdl is also a static lib, so it is easy.

but for ixemul this also is too much work in compare the advantage you get, i really dont know what problem it have.

ixemul V61 programs dont crash MOS, situation is same as a MUI4 program run not on MUI3.
« Last Edit: May 24, 2009, 10:27:40 AM by bernd_afa »
 

Offline arnljot

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #50 on: May 24, 2009, 10:22:24 AM »
@bernd

I think the problem here is one of perspective. This discussion is a wasps nest, but I'll still try to venture an opinion here.

Perhaps it is so that you persive ixemul as an application, it seems so to me as you persive the code from a users perspective.

This is not a bad thing, but we also try to think architecture. One thing we then should think of is separation of concerns.

Ixemul is a common module, component aka library. It has an API with a defined behaviour. Even if this behaviour is bad, or allows clients (applications) to behave badly, it should not be ixemuls concern.

It gets messy. Even though the intentions of changeing the behaviour is good, the concequences might be very messy.

The Apache example is a good example because it's not a user program. It's a webserver which won't have a user infront of a desktop at all times. It will for exaple run headless (no monitor/screen attatched) on a computer, and when it crashes will be autorestarted by a script or other admin tools. It's up to the admin to setup and configure such a system. If a library then start dioing GUI requesters, the admin gets unexpected behaviour, and the server cannot recover by its self. There are many readily made scripts for apache and other server tools which does this, they don't know or have any way of muting such a requester.

My preference both as a user and potential developer for amiga would be a separate patch to ixemul, which could intercept "return 0" from malloc and treat the incident based on blacklists and whitelists. A good separation of concerns, and ixemul behaves according to it's API contract.

I really applaude you bernd for your efforts for 68k amiga, and it's rare that programmers are good enough to see their programs from an end users perspective. This is a good trait of yours.

I understand your reluctance to change your code. It apparently works. But it's obviously creating some problems for others.

It does seem like the critisism you've received is a case of the pot calling the kettle black, and both sides here needs to take a breather and think a bit about how they address the other part. Both sides have not used a respectfull tone at all times, however it's apparent that you've tried to excercise restraint :-)

A problem here is obvious that language is a barrier, you are talking past eachother. Now just stop for a moment, and try to see if there is a middle ground.

All of this isn't only addressed to you bernd. Hence the kettle and pot comment as the malloc issue just seem to be one of the many issues beihg discussed here (version number, name and expanded functionality).
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #51 on: May 24, 2009, 11:11:35 AM »
Quote from: arnljot;455935
@bernd

The Apache example is a good example because it's not a user program. It's a webserver which won't have a user infront of a desktop at all times. It will for exaple run headless (no monitor/screen attatched) on a computer, and when it crashes will be autorestarted by a script or other admin tools. It's up to the admin to setup and configure such a system. If a library then start dioing GUI requesters, the admin gets unexpected behaviour, and the server cannot recover by its self. There are many readily made scripts for apache and other server tools which does this, they don't know or have any way of muting such a requester.



ok, i add a env var, a blacklist is too much work.adding this usefull requester cost me 20 minutes and help a lot.thats a good effort in time to usability.but for coding several hours on such a feature i have no patience because many other i want do that i need more important, maybe something other do that perfect with black and whitelist ?

you are right, i think more as a user, because i want use amiga OS Software and not only coding for fun.i know lots of programs that theoretic, selten used functions can easy use and the everday functions are hard to reach.

I like a feature that give in 99,9% of real world usage a advantage or easier to use.if this is in 0,1% give more work, then overall the time save is a better result.

i think in praxis it more happen get 6 rights in lottery than on amiga os a apache run out of mem ;-)

i think when somebody set up a webserver that run standalone he look that he can not run out of mem carefull on amiga and look that at least 5 megabytes of mem stay free.

And he mus also be carefull that the harddrives are not run out of diskspace.

and when he have appache running and start another program, that need more mem, he have access on his computer, the requester come and he can close the other program or free some mem.
« Last Edit: May 24, 2009, 11:15:54 AM by bernd_afa »
 

Offline dcr8520

  • Full Member
  • ***
  • Join Date: Mar 2002
  • Posts: 107
    • Show only replies by dcr8520
    • http://Amiga.SourceForge.net
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #52 on: May 24, 2009, 11:40:13 AM »
Quote from: bernd_afa;455934

A black and white list is too much work for this feature


This isn't much work at all, imho. i can write such code myself if you want.

Quote from: bernd_afa;455934

Quote from: Crumb

Jumping back to version 49.30 sounds better.


this too not work.OS4 have their lib number as V51.1 but this support not OS4 functions.


Please, forget about the existence of ixemul for OS4, and then tell us, what do you think now?

(You DON't need to worry about if a ixemul program crash under OS4, it is just not your problem)

Quote from: bernd_afa;455934

netsurf is not easy portable and need MOS 2.0.


Wasn't NetSurf first made for another platform not related to Amiga at all? how it could require some MOS specific stuff?.. (if some implementation indeed requires mos, then just skip it, you know what i mean ;) )


Quote from: bernd_afa;455934

Again it is not easy to change the ixemul name only and programs can work together.


Well, in those last posts we didn't mention to rename the lib, i just suggested to set the version back to 49.x considering it should be ok to both parts (you Bernd, and Piru).

Quote from: bernd_afa;455934

ixemul V61 programs dont crash MOS.


I really wonder why you worry too much regarding if 68k programs could crash under MOS/OS4, seeing you don't said good things about those OSs at all.
 

Offline dcr8520

  • Full Member
  • ***
  • Join Date: Mar 2002
  • Posts: 107
    • Show only replies by dcr8520
    • http://Amiga.SourceForge.net
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #53 on: May 24, 2009, 11:46:31 AM »
Quote from: arnljot;455935

treat the incident based on blacklists and whitelists.


Yeah... you had a very good idea there.. :D ;)
 

Offline arnljot

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #54 on: May 24, 2009, 12:41:28 PM »
@dcr8520

Yes, indeed ;-)
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline arnljot

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #55 on: May 24, 2009, 02:43:37 PM »
Quote from: bernd_afa;455943
ok, i add a env var, a blacklist is too much work.adding this usefull requester cost me 20 minutes and help a lot.thats a good effort in time to usability.but for coding several hours on such a feature i have no patience because many other i want do that i need more important, maybe something other do that perfect with black and whitelist ?


Great :-)

How about letting dcr8520 or someone else write a tool that patches (using wht/blck list) malloc functionality, or at least have the default operation to be no requester?

If this compromise can be agreed upon, maybe there is hope for the rest? :-)

What other functionality has been disputed?
A posting a day keeps the sanity away...
http://www.arnljot.com
 

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #56 on: May 24, 2009, 03:12:29 PM »
Quote from: dcr8520;455957

Well, in those last posts we didn't mention to rename the lib, i just suggested to set the version back to 49.x considering it should be ok to both parts (you Bernd, and Piru).



Yes, i can do that

Quote from: dcr8520;455957


Please, forget about the existence of ixemul for OS4, and then tell us, what do you think now?


the Facts are this.

68k have a unix emul lib that want MOS devs port to use ixemul Software on MOS.

but during time, ixemul miss more and more features (C99) so they need add.

But when there is somebody that enhance this ixemul library on the Home platform, Piru didnt like that.

now we find out, that it is from MOS dev side not suppport to create 68k progs that use V49 functions on MOS.

i think thats nearly the same as when i add a requester in ixemul 68k V61 libc.new ixemul progs cant use on MOS.

then i can name the ixemul libnum as V51.

should i do that, is then Piru happy ?

thats exact the same situation, because V49 funcs on MOS can only run on PPC.68k they want not support.

MOS have a 68k emulator and can exute 68k progs.

so to follow the MOS side rule, i must add a requester this code cant run on MOS.

Is this now better ?

But i think its better to get new features on MOS too running and increase the feature of all ixemul

If you add blacklist whitelist code is nice.
i think best is only a blacklist, here can add the few programs as apache, that can restart on crash.

What do you think about this ?
 

Offline bernd_afa

  • Sr. Member
  • ****
  • Join Date: Nov 2005
  • Posts: 479
    • Show only replies by bernd_afa
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #57 on: May 24, 2009, 03:54:49 PM »
Quote from: dcr8520;455980

Wasn't NetSurf first made for another platform not related to Amiga at all? how it could require some MOS specific stuff?.. (if some implementation indeed requires mos, then just skip it, you know what i mean  )


the OS4 and MOS side add own code, look on source, OS4 side add a amiga folder with 1,2 megabyte source, and MOS side add a mui folder with 900 kb size.but this folder contain 400 kb of OWB source.

So it look like coding on MOS the same features, there is not so much code typing need

the dir render that contain the browser engine use too 900 kb
another folder css contain 730 kb

so on the source contents can say netsurf is amiga browser, because many is code for amiga specific ;-)

there is a folder for beos, this use 568kb of code.
I like OS that can with less typing reach features, maybe i should change to Beos ;-)
« Last Edit: May 24, 2009, 04:10:59 PM by bernd_afa »
 

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 #58 on: May 24, 2009, 03:57:42 PM »
Quote from: Crumb;455892
Good job with the ffmpeg port for 68k...

Thanks.

Quote
does it convert FLV to Cinepak? that could make possible to use Tubexx with AmigaOS3 and use common avi/mov players like Moovid to play the files with weak cpus.

No, FFmpeg have only Cinepak's decoder and as I can see most of the encoders seems to be very CPU-intensive. Of couse raw can be used, but probably output files would be too big. :(
« Last Edit: May 24, 2009, 04:02:34 PM by ami_stuff »
 

Offline Matt_H

Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #59 on: May 24, 2009, 05:20:55 PM »
If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with them, even if they don't use v61 features and that's why running those programs under MorphOS will result in crashes. It's my understanding that with most libraries, compatibility with old versions can be maintained by not using new features, but that doesn't seem to be how ixemul is evolving. Someone who wants to write a 68k program that is compatible with MorphOS will have to use the old includes.

While I still agree that v61 ixemul should be renamed, someone mentioned the idea of unifying development across the Amiga architectures, as with the NList, Texteditor, and codesets projects. I think that's a good compromise, and would like to read other comments on its feasibility.