Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: x303 on April 22, 2009, 04:21:21 AM
-
FFmpeg SVN-r18602 (18.04.2009)
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.
Thanks to Bernd Roesch and his improved ixemul includes, it was possible to compile the latest version of FFmpeg for Amiga 68k. There is no FFplay video player in the archive, because it is still not stable enough to be released.
Examples:
1. convert avi 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 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 jpeg 2000 image file to bmp:
ffmpeg -i test.jp2 test.bmp
4. convert wma audio file to flac:
ffmpeg -i test.wma test.flac
Amiga 68k port by Piotr Bandurski
-
Download from Aminet (http://aminet.net/package/gfx/conv/ffmpeg-svnr180602-m68k)
-
Cool :-D
What does this give you over the MPEG.library included with 3.9...eg more speed?
-
@NovaCoder
FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video.
As I recall 3.9 did nothing like this.
-
Is this new version faster or slower than the old version?
Sometimes new versions are dramatically slower than old versions and when that happens I don't want them.
Long live Amiga.
-
>What does this give you over the MPEG.library >included with 3.9...eg more speed?
ffmpeg is a video API lib.with that you can write Videoediting, recording, playback Software.i hope some day i can make out of winuaevidrec in amiblitz fast a full easy to use Video Editing and playback software.
My idea first is to have in a player the most used cut functions, seek to next scene cut automatic, set start marker with i key, now can move to end of scene and press del to remove the unneeded.there should also undo here.also it is possible to save this file.
The ffmpeg Version from Piotr is great, it also contain all codecs that are possible, no codec is deactivate because it do not compile.
----------------------------------------
seem last problem before ffplay release is, what should SDL do, if a screen of 3000*2000 is ask in setvideomode.for example when ffplay should show a 3000*2000 Pixel image
on cygwin this do not work.on 68k in window mode picture is scale down, to fit on existing screen, ffplay set on windowmode the SDL_RESIZEABLE Flag and sdl can safe change with and high.
but in fullscreen there is not SDL_RESIZEABLE set in ffplay and open of screen fail in both cygwin and amiga.
I have now write a mail to SDL ML and ask what SDL backend should do, when a screen can not open in 3000*2000.
lets see what happen here.
also all ixemul for ffplay have a strange problem he find out.when use a filename for output or input file ram:test, then in snoopdos is not see that this file is open.
but when name "ram disk:test.mpg" then it work.
the speed of ffplay depend much from the libgcc that is linked.when link with libgcc from the gcc 4.3.2 build that use 040 FPU code, then it play 2-3* faster videos.
older gcc libs seem have only 68000 code in and when lib functions often used, then much slowdown is possible.(most speedbrake of 68000 only code is that 68000 cant multiply 2 longs with 1 asm instruction.there need asm 8 instructions for this.gcc3.4.0 compile as default only 68000.this builds work, but of course slow, so its important to use at least -m68020 -m68881 on compiler options.
if a gcc3.4.0 or 4.3.2 is used to compile ffmpeg make not so much diffrence.
-
This really is most impressive. Thank you Bernd, Piotr.
I wonder if a ffdshow port would be possible sometime. I guess it would have to link in with AHI or some such. At the moment, my Windows box does everything because it has MPCHC and even Linux doesn't come close to this players features. This is most certainly a setp in the right direction, really I am very impressed by this. Great efforts all round. Thank you again.
-
ffdshow? really? would that include reimplementing DirectShow for AmigaOS?
-
@bernd_afa
Maybe linking with Frank Wille's posixlib might help ?! I know from my experience with the warpos version of ffmpeg, that linking with this library (or atleast using some of the routines) could fix some problems.
[color=FF0000]x303[/color] :-D :-D :-D
-
Bernd,
Is that some case of self-inflicted torture?
Why insisting on using ixemul + sdl for ffmpeg and ffplay?
For ffmpeg, it may still be acceptable, but for ffplay (or any real application using ffmpeg), ixemul must really be avoided, especially as ffplay uses sdl threads, which are implemented as normal amigaos processes in our SDL libs, and it certainly can't work properly with ixemul.
So, just compile this stuff with libnix or any libc you want, as long as it doesn't use ixemul (and add missing libc functions if needed, it's not a big deal).
-
Wow. Tested on WinUAE.
Fast. Would like better documentation though.
Can't wait to try it on natinve hardware though.
-
@Fab
>For ffmpeg, it may still be acceptable, but for >ffplay (or any real application using ffmpeg), >ixemul must really be avoided, especially as >ffplay uses sdl threads, which are implemented >as normal amigaos processes in our SDL libs, >and it certainly can't work properly with >ixemul.
yes, sdl threads dont work correct with ixemul, but i have change ixemul so there work many games that use sdl-music.ffplay use 5 sdl threads and work currently stable with that code in SVN.but i think i have not find all places, the threaded picture viewer pv nit work as before, when want save a picture.
https://amiga.svn.sourceforge.net/svnroot/amiga/ixemul
use libnix is no good idea, because ixemul have much more and better Unix compatibility and i like the ixtrace feature to find Bugs faster.When later bigger programs want port, then it is better i think, i enhance ixemul to work also ok with amiga threads.
I have currently not look closer in pthread, what happen here, i wonder how this work without amiga tasks.I see amigaos define in offical source, but no specificv file that create amiga tasks.
here is what is currently new
Version 51.1
*
* add func log2 log2f lrint lrintf to math.h
* add func strtok_r to string.h
* add func sqrtf/fmod to libc.
* mmap use now page size alligned memory that is need by programs(GCC) to work ok
* correct handling for extern inline in C99 Mode see http://gcc.gnu.org/ml/gcc/2007-03/msg01096.html
* additional poolmem memsystem add.this let bugs find more easy because AOS memtracker work.
POOLMEM define can switch between them.
need by many Unix programs that create tasks with SDL.(vfork work as before)
* ix_CreateChildData function add in libc.a.This create correct Userdata structure ixemul need
to store filehandles and used memlist of current task when a task is create with amiga OS create Task.
change to follow Unix spec(not used in vfork process)
child tasks use mem list from parent task.poolmem enabled need
child tasks use same file handle as parent task
* Bugfix: llock get now correct aligned mem for packet call.(wget resume work again)
-
@bernd_afa
That is just wrong. ixemul just cannot be mixed with amigaos threads. It is clear that you have good intentions but really don't seem to fully understand the consequences of your actions.
You're basically forking ixemul. This is not good.
Since you're obviously going to do it anyway, could you please rename the library? ixemul-ng.library and ixnet-ng.library or something?
-
>Since you're obviously going to do it anyway, >could you please rename the library? ixemul->ng.library and ixnet-ng.library or something?
problem is, the makefile and files contain so much ixemul.library entries that it cost much time to find out what need change.maybe you cam do it ?
that 68k programs fail under MOS or OS4 is not possible, because the crt0.o check automatic for version.I can change version to 60.1
when from 2001 to 2009 ixemul version num is only increase from 48 to 51, then i think 60 is never reach in MOS or OS4 because MOS or OS4 use ixemul only for compatibility reasons and dont want make it much better compatible to Unix.
also there are clib2 newlib libnix, amicygnix out, many solutions that are newer, but as far i see, they reach not the compatibility of ixemul.
>It is clear that you have good intentions but >really don't seem to fully understand the >consequences of your actions.
yes i know, its not easy, but currently many programs run perfectly (before only crash).and when devs that notice crashes report me problems i can fix that fast, so sooner or later it get better, same as uae run near all amigaprograms ixemul should allow to compile near all Unix/Linux programs without too much work.
so i think its always better to enhance the lib instead of do more porting work in every program.
It also maybe help to get netscape bounty or firefox bounty more easy.
-
problem is, the makefile and files contain so much ixemul.library entries that it cost much time to find out what need change.maybe you cam do it ?
I don't have the time. It isn't rocket science however. You do understand how the ixemul build process works, right? (considering you've been releasing many new versions of ixemul you really ought to know...)
that 68k programs fail under MOS or OS4 is not possible, because the crt0.o check automatic for version.I can change version to 60.1
when from 2001 to 2009 ixemul version num is only increase from 48 to 51, then i think 60 is never reach in MOS or OS4 because MOS or OS4 use ixemul only for compatibility reasons and dont want make it much better compatible to Unix.
This does not solve the problem. The library needs to be renamed.
This way it is even possible to backport your stuff back to MorphOS if someone really wants it. As long as it is called ixemul.library it is not possible.
And unlike what you think ixemul is crucial for many things in MorphOS, such as GNU toolchain, perl etc.
yes i know, its not easy, but currently many programs run perfectly (before only crash).and when devs that notice crashes report me problems i can fix that fast, so sooner or later it get better, same as uae run near all amigaprograms ixemul should allow to compile near all Unix/Linux programs without too much work.
The problem is, some of these things can't be fixed without seriously breaking other things in the library (for example ixemul can never be safely mixed with apps that use AmigaOS OS functions extensively). ixemul is so complex it is very hard to see how you can break it with substle changes. It for sure is not meant to be changed by inexperienced coder.
also maybe help to get netscape bounty or firefox bounty more easy.
If you think ixemul somehow makes this any easier you're seriously misguided.
-
>You do understand how the ixemul build process >works, right? (considering you've been >releasing many new versions of ixemul you >really ought to know...)
No, i dont know how script file work in such complex build script as ixemul do.
that was one reason wy i use mos source, because the MOS build script work also on crosscompile with very small changes.
I spend btw much time to break not MOS build, so a MOS version from this seem too possible easy.
files that i cant use from MOS i name as _68k.c
>ixemul is so complex it is very hard to see how >you can break it with substle changes. It for >sure is not meant to be changed by >inexperienced coder.
i think it is also possible to change SDL to use pthreads same as unix version.
but i think pthread programs need no amigatasks and so it cant very bad debug a task, because AOS show only 1 task.
So i change ixemul the added code is very simple.only problem is that it must add in more places.
So it is possible that i forget a function.but i have security code add, so this func can detect easy when see stack backtrace and do not crash whole amiga.
here is what i do.
when a amigatask in sdl is create ) open ixemul.library is done.this create a valid ixemul struct.(also on old ixemul
BTW: MOS ixemul source read always on open ixemul call wbstartup message, this fail on programs start from workbench that use vfork command.i fix that.
then a new entry i add in userdata.
u_parent_userdata is set to parent process.this is the main process and when a sdl subtask create another sdl subtask this use too corrrect main task.
now in functions that do file io is that code need to get correct file handle for amiga tasks.
if (u.u_parent_userdata)f = u.u_parent_userdata->u_ofile[fd];
else f = u.u_ofile[fd];
vfork do not set u_parent_userdata, so all work as before and newer versions are 100% compatible.
same code is need for mem allocater, that correct mempool is used.
it is also possible if code use no errno setting or signalling to do this.
if (u.u_parent_userdata)u_ptr=u.u_parent_userdata;
that ixemul is full thread safe can see easy, when create more sdl tasks and do a printf to stdout or stderr
ixemul is the only lib that dont mix text of diffrent tasks in 1 line.
that missing IO functions can easy find i add in open this code.
if (u.u_parent_userdata){u.u_ofile[fd] = 0xdeadbeef;}
>If you think ixemul somehow makes this any >easier you're seriously misguided.
maybe, but as far i see, there is no 100% thread save Unix library on amiga.
in the past was activity in netscape done, a unstable version come, but because of errors that nobody find, it is give up i think, and this version get never stable because random thread problems.
but with a god thread safe ixmemul core and amiga tasks also in pthread, i think it is possible to find Problems or get no instability
-
@Piru
Now that i show codepieces and can see that the changes are 100% compatible, is it still usefull to change ixemul name ?
Because ixemul V51 have more features, wy it is not enough to bump 68k version to 60 or 70 is too possible.
it is better to find bugs and be 100% error free, if many programs can test with new code.
when look on ixemul from MOS there is always lots of compatibility break done and since year not much progress in compare to V51.
see readme.mos
"""""
- 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.
""""
for OS4 ixemul i see a post from amicygnix author that OS4 support no vfork.so here too lots problems can come.
there is maybe better on that systems, if there are no developers that want a ixemul that have best Unix compatibility, that the 68k programs that want open V60 use 68k ixemul.if somebody can tell me wy ixemul 68k V51 dont run in MOS or OS4, we can maybe get it working too.I build 68k Versions without trap V51 is build for 68020 68881.so there is no specific low level stuff in