Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
FFmpeg + FFplay SVN-r18880 (m68k)
« on: May 22, 2009, 07:19:26 AM »
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
« Last Edit: May 22, 2009, 07:28:34 AM by ami_stuff »
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #1 on: May 22, 2009, 04:30:53 PM »
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.
« Last Edit: May 22, 2009, 04:42:36 PM by ami_stuff »
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #2 on: May 22, 2009, 08:01:51 PM »
Quote from: Methuselas;455681
*laughs*


Imagine running it on an 030, which is what most people have! :lol:


Sure, imagine running it on 68000. :hammer:

Good luck with DivX on your 030 even with asm-optimized MooVId.
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #3 on: May 23, 2009, 01:04:44 AM »
Quote from: wawrzon;455575
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!


@wawrzon:

Do you have 060@50MHz or maybe overclocked?

I think that I can try to optimize mpegaudio decoder to run faster on the 68060 CPU, but to test if it really work faster I would need someone with a real 68060 CPU + installed OxyPatcher.

The problem is that 68060 CPU don't have "muls" instruction and this instruction SHOULD be used a lot with mpegaudio decoder. Right now this instruction is NOT USED, because I compiled ffmpeg for 68060 CPU, so GCC "emulates" "muls" instruction with longer code supported by 68060 CPU. I think it may be possible that 68060 + OxyPatcher would be faster compared to GCC's "emulated" code.

On the WinUAE mpegaduio decoder compiled for 68040 (with "muls" instruction) needs only 29 sec. to decode 5 min. MP3 file. 68060 build needs for the same task 1:25 min., so you can see how slow GCC code is.

x86, PPC and ARM CPUs have belowe functions asm-optimized:

#ifndef MULL
#   define MULL(a,b,s) (((int64_t)(a) * (int64_t)(b)) >> (s))
#endif

#ifndef MULH
//gcc 3.4 creates an incredibly bloated mess out of this
//#    define MULH(a,b) (((int64_t)(a) * (int64_t)(b))>>32)

static av_always_inline int MULH(int a, int b){
    return ((int64_t)(a) * (int64_t)(b))>>32;
}
#endif

#ifndef MUL64
#   define MUL64(a,b) ((int64_t)(a) * (int64_t)(b))
#endif

#ifndef MAC64
#   define MAC64(d, a, b) ((d) += MUL64(a, b))
#endif

#ifndef MLS64
#   define MLS64(d, a, b) ((d) -= MUL64(a, b))
#endif

/* signed 16x16 -> 32 multiply add accumulate */
#ifndef MAC16
#   define MAC16(rt, ra, rb) rt += (ra) * (rb)
#endif

/* signed 16x16 -> 32 multiply */
#ifndef MUL16
#   define MUL16(ra, rb) ((ra) * (rb))
#endif

#ifndef MLS16
#   define MLS16(rt, ra, rb) ((rt) -= (ra) * (rb))
#endif

Someone optimized for me two of the functions for 68020-68040 CPUs:

static inline av_const int64_t MAC64(int64_t d, int a, int b)
{
    union { int64_t x; int hl[2]; } x = { d };
    int h, l;
    __asm__ ("muls.l %5, %2:%3   \n\t"
             "add.l  %3, %1      \n\t"
             "addx.l %2, %0      \n\t"
             : "+dm"(x.hl[0]), "+dm"(x.hl[1]),
               "=d"(h), "=&d"(l)
             : "3"(a), "dmi"(b));
    return x.x;
}
#define MAC64(d, a, b) ((d) = MAC64(d, a, b))

static inline av_const int64_t MLS64(int64_t d, int a, int b)
{
    union { int64_t x; int hl[2]; } x = { d };
    int h, l;
    __asm__ ("muls.l %5, %2:%3   \n\t"
             "sub.l  %3, %1      \n\t"
             "subx.l %2, %0      \n\t"
             : "+dm"(x.hl[0]), "+dm"(x.hl[1]),
               "=d"(h), "=&d"(l)
             : "3"(a), "dmi"(b));
    return x.x;
}
#define MLS64(d, a, b) ((d) = MLS64(d, a, b))

but I need 68060 versions. The rest of the C functions should also be asm-optimized for 68060.
« Last Edit: May 23, 2009, 01:34:28 AM by ami_stuff »
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #5 on: May 23, 2009, 11:38:42 AM »
Quote from: Tumbleweed;455789
This rocks! I installed it last night and ran it this morning and its really good. I encoded a Futurama episode on my PC, using PocketDVD_Studio using the lowest settings for Video and Audio. Video 61kbs 15 fps; Audio AM raio quality 24kbps Mono and set the resolution to 160x128. I then burned the file to a DVD and transferred to my A4000D. Fired it up in FFPlay and hey presto its runnning fine - video at least; (my audio circuit is flakey due to leaky caps).

A4000D Specs as follows:

A4000D Kick v45.57 Workbench v45.3 BB1, BB2
CSMK11 060 128MB Ram
Z3 Fastlane 48MB
CV3D with scan doubler
Deneb 2.0
80GB IDE HD


If you really need to re-compress your episodes, next time try to use Cinepak.

The only  problem is that the code is not optimized at all, but no one will do it for free just to read that it is still not fast enough to watch your episodes on your 20 years old hardware. At least you can slideshow videos with the recent codecs. On WinUAE there is no problem with speed :)
« Last Edit: May 23, 2009, 11:49:41 AM by ami_stuff »
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #6 on: May 23, 2009, 12:12:10 PM »
Quote from: wawrzon;455805
how about replacing sdl parts of code, it displays via sdl i take it? maybe we should create a bounty to optimize it for the last century hw? :P no, im serious..


Yes, without SDL it might be faster because less code would be used. Also, SDL is not asm-optimized, only C code. FFmpeg's MP3 decoder should be repleaced with optimized mpega.library, but no one will do it.
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #7 on: May 23, 2009, 01:02:45 PM »
Quote from: wawrzon;455812
@ami_stuff: thinking again im not sure mp3 decoding and sdl display fuctions are critical. disabling audio doesnt bring that much speedup suprisingly at least at low quality player. i know, on 060 mp3 decoding is in fact already an expensive task, but anyway. from what was posted on amigans on topic of the new flash port, replacing sdl drawing fuctions with os4 native has not brought a major speedup. so probably it is just decoding that matters most.


This should be a start when someone want to optimized video player for m68k. MP2/MP3 codecs are used with all of the video files like AVI, MPG and when mpegaduio decoder is slow, you will not get any decent speed even with Cinepak video codec.

FFplay supports a lot of codecs, when you optimize DIvX, it will not speedup MPEG decoding process. Run "FFplay -formats", so you will see how much work it would require to optimize all of this stuff.

Again, SDL code is C only. When you repleace SDL with direct asm-rountines, it will be a lot faster WHEN you use for test uncompressed AVI files.
« Last Edit: May 23, 2009, 01:07:25 PM by ami_stuff »
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #8 on: May 23, 2009, 01:23:19 PM »
Quote from: wawrzon;455815
@ami_stuff: yeah. i could get this damn delfina with a mp3 decoder dsp, i wantde to do it for weeks. but i could throw as well these >100eur into the basket to optimize mpega.library. are you sure it has to be done from the scratch, there are numerous versions on the net. none asm optimized for mp3 decoding?


Yes, mpega.library should be fine for MP3 decoding, but it will not optimize DIvX codec, so as a result you will still have slow playback.

MP3's hardware decoder will not help you as long as FFplay don't support it or there is no mpega.library repleacement which uses your hardware decoder.

But of course first FFplay needs to have mpega.library support :)

When you have AVI file with DIvX video codec and MP3 audio codec, all of these codecs needs to be optimized, not only one, or you will not see any different.
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #9 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 ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #10 on: May 26, 2009, 03:08:00 PM »
@wawrzon:

Please read your PM.
 

Offline ami_stuffTopic starter

  • Full Member
  • ***
  • Join Date: May 2009
  • Posts: 100
    • Show all replies
Re: FFmpeg + FFplay SVN-r18880 (m68k)
« Reply #11 on: May 27, 2009, 01:33:06 AM »
BTW. About stability: You can try to run multiple videos at the same time... of course only under emulation. Nice effect :)