Is there any way H264 decoding could be speed up in MPlayer? Isn't there any Altivec-optimized H264 module that could be used?

I did some benchmarks with MUIMPlayer and with a 720p H264 video it seemed from the benchmark that the X1000 can only decode it at about half the speed. I kind of find that hard to believe if the CPU was fully utilized (and by fully I don't mean both cores) with the codec compiled for the deeper pipeline in the PA6T and had Altivec code.

Another disturbing fact I discovered was that during normal play with benchmark of the same video in 8000kbit mpeg2 format, 76% of the CPU time went into the cgx_wpa VO driver! That just has to be because of a superslow RAM->GFX speed because simple color conversion (which uses altivec btw) and copying just cannot be 3 times heavier than decoding the mpeg2 data.

So when can we expect overlay and a compiler with PA6T awareness?

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

For video play back enhancement with Radeon HD cards You may have to wait until enough Sam440ep and Sam460ex owners purchase the new driver to make development viable.For you now there is the option of using a Radeon 9250 by runing your PCI network card in a PCIe x1 slot with a PCIe x1 to pci adapter to free up a PCI slot for the 9250 card.

Last edited by Spectre660 on 16-Dec-2012 at 08:14 PM.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Deniil715

First, h264 decoding *is* altivec-optimized. Without it, it's about 20-30% slower depending on mem speed.

Then it would be surprising if the x1000 couldn't decode it... A mac mini / MorphOS with a G4@1.42GHz can do it easily for medium bitrates. For very high quality ones, using -lavdopts skiploopfilter=all saves 20% cpu, at quality expense.

The real bottleneck in your case is the lack of hw accelerated output. Overlay makes a *great* difference. Alternatively, you can fix cgx_vmem, it will give faster results than cgx_wpa, but yuv420/422 to rgb conversion will still have to be done by cpu.

For the record, MPlayer on AROS with a recent PC happened to be slower than a lame mac mini with MorphOS because of the lack of overlay and a really horrible ram->vram transfer speed with nouveau... :) I think it's not the case anymore, fortunately, but it was funny to see the stream decoded x times faster than realtime, and stuck because of totally ineffective gfx drivers. :)

@Fab

First, I'm not surprized it's a slide-show without overlay, seeing that a 720p mpeg2 video @ 8Mbit spends 76% in the vo driver, when just just barely making realtime playback...

Are you sure the OS4 version of mplayer is also built for altivec? Should be since the vo driver says it uses altivec for color conversion though...

Why I was wondering was because I used the -benchmark -vo null -nosound options and it seemed to take twice as long to "play" the video (10Mbit h264 MOV 720p - the same video) as it was long. Might have got the values wrong, need to check that again...

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

10 MBit as h264 is a *lot* for any old PowerPC, Altivec or not.

Has anyone done comparison between demuxing flv and mp4? If there's a difference, it could sometimes be meaningful.

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Deniil715

I think you solved your own question there with the mpeg2 test, test on a card with overlay to see what sort of improvement potential you have for the actual decoding process. If we somehow were to get access to the second core things might improve a lot, as you would have those 76% for the VO driver running from one core while the other could focus 100% on the decoding. Until then, your only hope is reducing the VO driver time by using overlay.

Edit: Now I caught on that you're running on vo null with nosound. Well in that case there's something fishy as my core2duo laptop at 3.067MHz managed 27 seconds on a 60 second 10Mbps test video (from monsters inc). So yes, that would be disappointing.

Last edited by olegil on 19-Feb-2013 at 10:09 AM.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Deniil715

Quote:

I did some benchmarks with MUIMPlayer and with a 720p H264 video it seemed from the benchmark that the X1000 can only decode it at about half the speed.

We did tests last year.

A/V

Quote:

720P encoded Mjpeg played back in real time with no audio loss. Audio ended with video playback.

So, the fastest codec for playback (which absolutely no one uses on the net) barely played back in real time.

H264 at 1/2 speed sounds about right.

In addition, you need to check sync for an -entire- file. It will -lose- A/V sync over time during playback.

sync problems discussed on morphzone as well

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

as most smartphones can also only decode in hardware.. theoretically we have a lattice xp2 on SAM460 boards (no info about size, I would expect it is too small) and some exotic 8 thread 500mips xena chip on X1000, where nobody knows how to use it ??

@Beeblebrox

Neither would help for h.264, but the X1000 has an unused core which could at least be set up in AMP mode or something for video decoding. Surely some enterprising bedroom coder could whip up something to allow mplayer to offload h.264 stuff to an extra core even if the OS doesn't support SMP?

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Yeah, should be possible to get that second core running by hacking it

Altivec could also be used before the OS supported it, as long as you made sure only one Altivec program was run at a time

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.