mplayer 68k is an alpha version, i download some years ago on A1k.org.
i didn't find originl topic so, i don't know if someone has updated this version.

_________________

@Seiya

Ok.
Its working ok if used as video player with video output?

Can you share the archive?

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

PowerMac G5 Dual (not Daul :) 2,7 GHz MorphOS 3.9, Radeon X850XT:

-----

Lame with Altivec:

Ram Disk:> lame_vmx Hearth.wav
LAME 3.99.5 32bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding Hearth.wav to Hearth.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
12205/12205 (100%)| 0:08/ 0:08| 0:09/ 0:09| 35.823x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 4.1 95.9 96.5 2.2 1.3
Writing LAME Tag...done
ReplayGain: +3.5dB

-----

Lame without Altivec:

Ram Disk:> lame Hearth.wav
LAME 3.99.5 32bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding Hearth.wav to Hearth.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
12205/12205 (100%)| 0:43/ 0:43| 0:44/ 0:44| 7.3445x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 4.1 95.9 96.5 2.2 1.3
Writing LAME Tag...done
ReplayGain: +3.5dB

mplayer 68k link

Last edited by Seiya on 09-Jan-2018 at 10:36 PM.

_________________

@Tuxedo

If mplayer used even remotely my hd (ie for buffering instead of loading into the ram first), this could explain the output, given that my hd is unfortunately falling.

Anyhow, here's my Lame results:

System:Applications/Benchmark> lame --decode System:Applications/Benchmark/don't_break_my_hearth.mp3
input: System:Applications/Benchmark/don't_break_my_hearth.mp3
(44.1 kHz, 2 channels, MPEG-1 Layer III)
output: System:Applications/Benchmark/don't_break_my_hearth.wav
(16 bit, Microsoft WAVE)
skipping initial 1105 samples (encoder+decoder delay)
skipping final 466 samples (encoder padding-decoder delay)
Frame# 12205/12205 192 kbps

System:Applications/Benchmark> lame System:Applications/Benchmark/don't_break_my_hearth.wav
LAME 3.99.5 32bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding System:Applications/Benchmark/don't_break_my_hearth.wav
to System:Applications/Benchmark/don't_break_my_hearth.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
12205/12205 (100%)| 0:34/ 0:34| 0:34/ 0:34| 9.2925x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 4.1 95.9 96.5 2.2 1.3
Writing LAME Tag...done
ReplayGain: +3.5dB

I 'll try to perform lame and mplayer with files being accessed from ram to check if there is a speed imporvement.

EDIT: Yeap, that was the cause:

Ram Disk:> lame don't_break_my_hearth.wav
LAME 3.99.5 32bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding don't_break_my_hearth.wav to don't_break_my_hearth.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
12205/12205 (100%)| 0:28/ 0:28| 0:28/ 0:28| 11.290x| 0:00
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
128.0 4.1 95.9 96.5 2.2 1.3
Writing LAME Tag...done
ReplayGain: +3.5dB

^ 6 secs faster, CPU toped 100% whereas when loading/writting on the HD only 60-80%.

Dunno which result you want to include :P

EDIT2:

Here's the result for mplayer, when loading from ram, w/o the hd bottleneck, just pure cpu intensive (again 100% load) - slightly better results:

System:Applications/Video/MPlayer> mplayer -nosound -vo null -benchmark "Ram Disk:Fashion_DivX720p_ASP.divx"
MPlayer SVN-r37401 (C) 2000-2015 MPlayer Team
211 audio & 442 video codecs

Playing Ram Disk:Fashion_DivX720p_ASP.divx.
libavformat version 56.33.101 (internal)
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [DX50] 1280x720 24bpp 23.976 fps 8604.2 kbps (1050.3 kbyte/s)
Load subtitles in Ram Disk:
Opening video filter: [ass auto=1]
[ass] auto-open
[ass] Fontconfig disabled, only default font will be used.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 56.39.100 (internal)
[mpeg4 @ 0x2d884130]Warning: not compiled with thread support, using thread emulation
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
Audio: no sound
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 1280x720 => 1280x720 Planar YV12
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 1280x720 => 1280x720 Planar YV12
[VD_FFMPEG] DRI failure.


BENCHMARKs: VC: 36.066s VO: 12.902s A: 0.000s Sys: 1.407s = 50.375s
BENCHMARK%: VC: 71.5944% VO: 25.6124% A: 0.0000% Sys: 2.7932% = 100.0000%

Exiting... (End of file)

IDK though if loading files from ram is being permitted or I am cheating all way long :)

EDIT 3:

And a new update whereas both divx file and mplayer (it's about 23mb executable)) launched from ram. Equal as vast improvement!

Ram Disk:> mplayer -nosound -vo null -benchmark "Ram Disk:Fashion_DivX720p_ASP.divx"
MPlayer SVN-r37401 (C) 2000-2015 MPlayer Team

Playing Ram Disk:Fashion_DivX720p_ASP.divx.
libavformat version 56.33.101 (internal)
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [DX50] 1280x720 24bpp 23.976 fps 8604.2 kbps (1050.3 kbyte/s)
Load subtitles in Ram Disk:
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 56.39.100 (internal)
[mpeg4 @ 0x36038970]Warning: not compiled with thread support, using thread emulation
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
Audio: no sound
Starting playback...
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 1280x720 => 1280x720 Planar YV12
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 1280x720 => 1280x720 Planar YV12
V: 0.0 2/ 2 ??% ??% ??,?% 0 0
[VD_FFMPEG] DRI failure.
V: 87.1 2090/2090 41% 0% 0.0% 0 0


BENCHMARKs: VC: 36.427s VO: 0.023s A: 0.000s Sys: 3.314s = 39.764s
BENCHMARK%: VC: 91.6083% VO: 0.0578% A: 0.0000% Sys: 8.3339% = 100.0000%

Exiting... (End of file)

Last edited by Cool_amigaN on 08-Jan-2018 at 10:05 PM.
Last edited by Cool_amigaN on 08-Jan-2018 at 09:46 PM.
Last edited by Cool_amigaN on 08-Jan-2018 at 09:46 PM.
Last edited by Cool_amigaN on 08-Jan-2018 at 09:39 PM.

_________________

@recedent

WOW!
Seems that G5 AltiVec was really SUPER-fast!

@CoolAmigaN

still muimplayer was slow than expected, instead lmae was ok and however my results was from SFS0 hdd not from ram:

Dunno why you got so bad results...maybe semi-broken HDD?

PS I'll edit results tomorrow evening since I hope to get much results to include.

Last edited by Tuxedo on 08-Jan-2018 at 10:06 PM.
Last edited by Tuxedo on 08-Jan-2018 at 10:05 PM.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Quote:

Tuxedo wrote: @CoolAmigaN still muimplayer was slow than expected,

I think the MPlayer result is rather within expected limits. The FSB of the machine is 100MHz. The similatly clocked Powerbook for comparison has an FSB of 166MHz. Throughput of that maschines is quite higher.

You may rather compare that Powemac with a PegasosII with higher cpu clock.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Zylesea

my Pegasos2 @1131 was really faster with about 30% less clock...wasnt weird?

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

No, the next bottleneck on the system would be the FSB. The clock speed gets hammered by the slow bus rate. Heh, keep in mind that my PMAC 3.1 must be of older age than most PegsII lying around. Ancient tech :P

_________________

@Cool_amigaN

yes but why on RAM so much improvement?
How fsb can slowdonw things on hdd but not in ram?

Maybe do you have an ATA66 or so HDD?

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

updated

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

What i really wonder is why the X5000 is that slow in OGR and especially RC5.
Sure, the P5040 lacks Altivec, but comparing the non-Altivec G4 7447A@1667MHz results with the P5040@2200MHz is surprising. But the result indicates the 7447A is faster in RC5 - absolutely and especially on a per MHz base. On OGR it#s better but still on a per clock base for P5040 and 7447A are identical. But don't look to Altivec vs. P5040...

I know OS4 is a beta for it, but OGR/DNET does not really utilize the OS, hence this should not matter. The 5500 is said to be quite fast, NXP says it does 3.0 DMIPS/MHz whereas the 7447 is 2.3 DMIPS/MHz - and OGR/DNET should scale rather linearly with the DMIPS.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Zylesea

I think CPU cache size/speed may play role there. OGR-NG scales well with performance, RC5 - from my experience - is more problematic.

@Zylesea

welll...honestly I'm really interested to how perform MOS on x5000...
Anything from MOS team about that?


EDIT:

We ARE really lacking X5000, X1000 and Vambpire benchs!

Plz guys write back!

Last edited by Tuxedo on 10-Jan-2018 at 09:44 PM.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

here are mine for my X1000, RadeonHD 7950, OS4.1 FE Update 1:

GPmark:

GPmark: width 640, height 480, flags 0x80000000
Blitting Test: 156.0
Plasma: 131.8
Rotozoomer: 144.1
Rotozoomer Near: 145.9
Rotozoomer Far: 143.9
Radial Blur: 62.0
3D Bunny: 35.8

lame:

0.35/8.8965x

mplayer (altivec):

21.662s

MUI-mplayer

21.303s

dnetc:

dnetc v2.9112-521-CTR-16020313 for AmigaOS (OS 4.1, PowerPC).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://bugs.distributed.net/

[Jan 11 05:36:53 UTC] Automatic processor type detection found
a PowerPC PA6T processor.
[Jan 11 05:36:53 UTC] OGR-NG: using core #1 (KOGE 3.1 Hybrid).
[Jan 11 05:37:11 UTC] OGR-NG: Benchmark for core #1 (KOGE 3.1 Hybrid)
0.00:00:16.37 [20,916,029 nodes/sec]
[Jan 11 05:37:11 UTC] RC5-72: using core #4 (KKS 7450).
[Jan 11 05:37:31 UTC] RC5-72: Benchmark for core #4 (KKS 7450)
0.00:00:17.07 [9,051,485 keys/sec]
[Jan 11 05:37:31 UTC] Compare and share your rates in the speeds database at
http://www.distributed.net/speed/
(benchmark rates are for a single processor core)

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@tuxedo
maybe you could consider Quake and AmigaMark for this new 2018 benchmark edition.
AmigaMark is recently portend on OS4 or MOS (now i don't remember)

_________________

@Seiya

where do you found AmigaOS4 version?

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

i saw something on Aminet, but it is only mos version. No OS4, but there are the source.
http://aminet.net/util/moni/AmigaMARK-morphos.lha

_________________

@Seiya

ok, thats the same I saw...
if someone will compile for OS4 with same mos/os3 parameters I can add...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Quote:

We ARE really lacking X5000, X1000 and Vambpire benchs!

Well, for X5000 with MorphOS beta you could always use this (quite old, but still valid) benchmark made by pampers:

[Jan 21 17:18:21 UTC] Automatic processor type detection did not
recognize the processor (tag: "MOS:0x8024")
[Jan 21 17:18:21 UTC] OGR-NG: using core #0 (KOGE 3.1 Scalar).
[Jan 21 17:18:40 UTC] OGR-NG: Benchmark for core #0 (KOGE 3.1 Scalar)
0.00:00:16.37 [20,136,464 nodes/sec]
[Jan 21 17:18:40 UTC] OGR-NG benchmark summary :
Default core : #-1 (undefined) 0 nodes/sec
Fastest core : #0 (KOGE 3.1 Scalar) 20,136,464 nodes/sec
[Jan 21 17:18:40 UTC] RC5-72: using core #0 (MH 2-pipe).
[Jan 21 17:18:59 UTC] RC5-72: Benchmark for core #0 (MH 2-pipe)
0.00:00:16.32 [5,378,031 keys/sec]
[Jan 21 17:18:59 UTC] RC5-72: using core #1 (KKS 2-pipe).
[Jan 21 17:19:17 UTC] RC5-72: Benchmark for core #1 (KKS 2-pipe)
0.00:00:16.08 [5,476,368 keys/sec]
[Jan 21 17:19:17 UTC] RC5-72: using core #2 (KKS 604e).
[Jan 21 17:19:36 UTC] RC5-72: Benchmark for core #2 (KKS 604e)
0.00:00:16.07 [5,590,276 keys/sec]
[Jan 21 17:19:37 UTC] RC5-72: using core #5 (MH 1-pipe).
[Jan 21 17:19:55 UTC] RC5-72: Benchmark for core #5 (MH 1-pipe)
0.00:00:16.70 [5,258,979 keys/sec]
[Jan 21 17:19:56 UTC] RC5-72: using core #6 (MH 1-pipe 604e).
[Jan 21 17:20:15 UTC] RC5-72: Benchmark for core #6 (MH 1-pipe 604e)
0.00:00:16.08 [5,160,960 keys/sec]
[Jan 21 17:20:15 UTC] RC5-72 benchmark summary :
Default core : #-1 (undefined) 0 keys/sec
Fastest core : #2 (KKS 604e) 5,590,276 keys/sec