New version FFmpeg available

[x303]

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

[Matt_H]

Download from Aminet

[NovaCoder]

Cool :-D

What does this give you over the MPEG.library included with 3.9...eg more speed?

[Golem!dk]

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

[ChaosLord]

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.

[unusedunused]

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

[SHADES]

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.

[Golem!dk]

ffdshow? really? would that include reimplementing DirectShow for AmigaOS?

[x303]

@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

[Fab12]

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

[mgerics]

Wow. Tested on WinUAE.

Fast. Would like better documentation though.

Can't wait to try it on natinve hardware though.

[unusedunused]

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

[Piru]

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

[unusedunused]

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

[Piru]

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.