FFmpeg + FFplay SVN-r18880 (m68k)

[ami_stuff]

FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video.   FFmpeg can also convert from any sample rate to any other, and resize video on the fly with a high quality polyphase filter.

1. convert avi video file to mpg with audio bitrate 128kb & video bitrate
1024kb:

ffmpeg -i test.avi -acodec mp2 -ab 128kb -vcodec mpeg1video -b 1024kb test.mpg

2. convert wmv video file to avi (divx) with audio bitrate 256kb and video
bitrate 1024kb:

ffmpeg -i test.wmv -acodec libmp3lame -ab 256kb -vcodec msmpeg4v2 -b 1024kb test.avi

3. convert jpeg2000 image file to bmp:

ffmpeg -i test.jp2 test.bmp

4. convert wma audio file to flac:

ffmpeg -i test.wma test.flac

You will also find FFplay video player in the archive.

FFplay requires ixemul.library v61. You can download it from here:

http://amiga.sourceforge.net/?showpackage=ixemul.library

Two versions of FFplay are included:

FFplay - compiled with High-Quality MP3 decoder
FFplay_MP3LQ - compiled with Lower-Quality MP3 decoder

To reduce CPU usage, you can set AHI unit 3 to "Paula: DMA 8 bit stereo".

IMPORTANT: When you want to use FFplay with WinUAE, you must copy
"env/ahi_minbufflen" file to "ENV:" and "ENVARC:".


While playing:
q, ESC       quit
f, ENTER     toggle full screen
p, SPACE    pause
a               cycle audio channel
v               cycle video channel
t               cycle subtitle channel
w              show audio waves
s               skip frame
x               save screenshot
left/right     seek backward/forward 15 seconds
down/up     seek backward/forward 1 minute
LMB click    seek to percentage in file corresponding to fraction of width
RMB click    hide/show mouse pointer


If your Amiga is too slow to play videos, you can try some tricks:

1. disable audio:

FFplay -an file.avi

2. skip B-frames:

FFplay -skipframe 16

3. play lowres version of the video:
(be careful with this option, because it can crash your system
when used with some codecs - this is not Amiga-related bug)

FFplay -lowres 1 file.avi

or

FFplay -lowres 2 file.avi

4. play video in grayscale:

FFplay -gray file.avi

5. hardcore version

FFplay -an -fast -gray -quiet -skipframe 16 -lowres 2 file.avi


Thanks to Bernd Roesch for his bugfixed/improved ixemul and SDL libraries.


Amiga 68k port by Piotr Bandurski


Download link:

http://aminet.net/gfx/conv/ffmpeg-svnr18880-m68k.lha

[djbase]

Nice but I doubt it will make much fun even on 68060.

[TNovosel]

Thanks for this great proggy!!!!!

[wawrzon]

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!

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

[wawrzon]

@piru: if im not mistaken this port still seems to use sdl for display. but even if its not optimizable still its quite impressive on pure 68k

edit: well, yes it was me that supposed that discussions between you and bernd result in this wild version numbers. edit: sorry, bullshit on my side. yes, renaming the lib might be a good solution and wouldnt harm anyone. but are you sure that new functions in ixemul break things on mos? did you try and found an example?

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

[wawrzon]

bernd may be less experienced than you and a stubborn person, but if he wasnt we would miss one of the few remaining programmers that still move things on 68k forward. if you are really concerned about above why dont you talk privately to bernd? 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.

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

[unusedunused]

@Piru

I have write here and send you a PM because you give no answer in the last ffmpeg news.I can not find a link, maybe somebody can post it here ?

here i explain more, that i think about it and i am near sure i make a 100% compatible solution and i explain how it work.but you do not asnwer or have some arguments wy it not work.

everything is possible and ixemul can also work with amiga tasks.

BTW; I make zune working together with MUI.and if i can get MUI4 sources i want make it too working together with MUI3, because for my matter of taste MUI4 is too incompatible to MUI3.

maybe you know not much about me, i like to have perfect compatible solutions, and no feature loss and unlimitet feature enhance , and i like the fastest and cheapest CPU ;-)

A also offer you, that you change the lib.I have no time for that, there is lots more needed to do.

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

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.

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.

what is your problem, wy should ixemul 68k not get new functionality  ?.

Have somebody cry when OS4 the ixemul without working vfork and other problems number it as V51.1 instead of rename it ?

have somebody cry when MOS number his ixemul to V49 and miss features or break compatibility without reason, or add the 60 features, because the change userdate structure order, or dont implement ixtrace ?

As i told V61 is full compatible.You can see this also when you look on source.

So there is more reason to rename MOS or OS4 ixemul lib.But i never told that ixmeul for MOS and OS4 should rename.

I for example make zune seperate of MUI, the same i do with MUI4 if i have sources, because zune and MUI4 are less compatible to MUI3.

But ixemul V61 is much more compatible as MUI4 and MUI3, so wy i should rename lib ?
 
when you see the new features, most of them can need on old programs too.so wy i should implement this twice ?

I accept that a library get progress,  and i see that on MOS in last years not much progress done.no C99 funcs add.missing features are not add.(no ixtrace)

I think zapek was the guy who mainly work and implement over 60 Unix functions to enhance MOS ixemul(what is enhance in OS4 i dont know).I think he make the buildscripts and make it possible to build this lib also on 68k with amogaos option in buildscript.

But zapek give up MOS long time ago and release ixemul and some other sources.
And there is since year not much necessary enhance  i see.

so if MOS or OS4 ixemul never reach V61 then there is no problem possible.MOS have since years V49 OS4 since years V51, so its easy to speculate that MOS or OS4 ixemul maybe never reach V60.

I think ixemul with his ixtrace and profile features very good to develop fast programs and find where the slowdown is

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.

But sdl programs use no unix signalling.SDL have own signalling and thread functions that are based on amiga os.look on SDL source and sdl program.

same when use pthread.this too use own signalling

ffplay is very complex in threading, there run 5 SDL treads together, so if something is really wrong, crashes and enforcer hits can see very soon.and if somebody know that ffplay play sound and no video, this is a known problem on all systems.

[ami_stuff]

The only problem I see here is that ixemul.lib v61 is not 100% compatible to MorphOS's version, but of course software compiled for ixemul.lib v48 (m68k) will run without problems with ixemul.lib v61.

Why it's not compatible anymore? Because there are new fuctions added to ixemul.lib v61.

Bernd bumped ixemul's version so high to preven ixemul+SDL mixed binaries to run on the MorphOS, because these binaries would only crash the system.
I don't know if it is OK or NOT to mix ixemul & SDL code, but I can tell that FFplay works OK, the same about some other programs which didn't work before.

Normal binaries which don't use SDL code and new ixemul's functions can run without problems on the MorphOS, but here is a version's check problem (v61 vs v49). Bernd may remove version check, but as a result programs linked with libSDL will crash on the MorphOS without any warning.

It's not a easy situation, because m68k users don't need any new library. There is only need for improved ixemul.lib which will work better with already ported software (for example, Bernd's ixemul.lib will not crash the system when there is not enough memory).

My solution is to have 2 lib (lib/lib_61) dirs, so I use lib_61 only when I need ixemul+libSDL compatibility or any new ixemul's functions implemented by Bernd.

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

[Matt_H]

From a user perspective, I completely agree with Piru.

The v61 naming convention is confusing. I kept thinking it was a typo for v51. If it's not 100% API compatible across all systems, it should be forked. One might conceivably install v61 on a MorphOS system because of its higher version number and end up breaking things.

Down the line, what happens when other programs or system components start using the v61 numbering convention? Version numbering is a good way to lock out use within architectures (like v34 and v36 on 68K), but now that we have multiple architectures evolving independently, using version number lockouts between architectures lays the framework for serious problems in the future.

Besides, shouldn't a name change be as simple as a find-and-replace operation in the source code?

[unusedunused]

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

with the new library they work much better.the first was increase of buffer size.gcc compile faster and many programs start faster.

and when there come later speedup on some funcs old programs are too faster.maybe a new mem allocator

see also ixemul V61 featurelist.

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


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.

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.

If it's not 100% API compatible across all systems, it should be forked.

thats not my fault.ixemul is create on 68k

ixemul is port to MOS.MOS add in V49 functions that V48 ixemul dont have and MOS V49 miss some functions and is not 100% compatible.i have add all funcs MOS V49 have so i do all right.when i add additional features then it is clean to increase libnum to V50.

But see here the readme.morphos

Remaining issues:

"""""
- traps are not handled yet.
- ix_panic() does not work properly (varargs conversion needed).
- 'man' crashes here. I've not investigated why yet.
- programs that rely on low-level internal ixemul structs won't work.
The only one I know doing that is 'gdb'. Recompiling it with some minor
changes should take care of the problem.
- ixtrace is not yet supported.
- neither is profiling.
- not compatible with the powerup bridge currently. That may or may
not change.
- DTYPE_MEM is broken, disabled for now.
""""

ixemul is port to OS4.it have number V51.1.But it contain not the features MOS V49 ixemul have.

also OS4 version miss more features as vfork, than MOS V49 have.

here is readme of OS4 Version, and there is since several years no update

""""
You can use this AmigaOS4 port of ixemul.library to run most m68k ixemul
software on AmigaOS4, but it's not a complete port, especially for PPC
native software some functions are not implemented (actually the most
important ones, you can only build simple PPC native programs for which
you wouldn't need ixemul ...), and even for running m68k ixemul software
it's not complete: It has no automatic stack enlargment, if the stack is
too small it will crash the application with a "trap".
"""""

if there really need a lib rename, then i think it is the ixemul of MOS and OS4 and not ixemul 68k.

because they break compatibility much more, thats a Fact.

and if they want emulate 68k then they need upgrade their lib, or less programs run, but dont force 68k side to stop further developing on ixemul.

i dont understand wy on MOS or OS4 the 68k ixemul V61 not work.it use ne special 68k code and no traps.

if somebody want help then 68k ixemul can use and then the incompatible native libs are not need.
 
sure i know there are some guys that want that 68k make no feature progress and stay retro and new features should only MOS or OS4 have.

[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