[MPlayer-users] compiling on FC4 ppc test

[Bret Hughes]

On Sat, 2005-03-19 at 10:33, Dominik 'Rathann' Mierzejewski wrote:
> On Saturday, 19 March 2005 at 05:05, Bret Hughes wrote:
> > On Fri, 2005-03-18 at 21:22, Bret Hughes wrote:
> > > On Fri, 2005-03-18 at 18:18, Dominik 'Rathann' Mierzejewski wrote:
> > > > On Friday, 18 March 2005 at 07:24, Bret Hughes wrote:
> > > > > I am experimenting with a mac mini and trying to get hardware decoding
> > > > > of high res(1024X768) mpeg2 video working.  After dinking with the OS X
> > > > > side for a while (almost maxes the cpu about 97%) and FC3 ppc (100% cpu
> > > > > usage) I thought I would try FC4 test1 but I can't get it to pass the
> > > > > compiler test during configure.

<snip >

> Post your command line, build log and compiler version here (actually,
> follow bugreports.html) or file a report in MPlayer's bugzilla:
> http://bugzilla.mplayerhq.hu/ . We'll take it from there.



Thanks for the reply. Here is the scoop.  I am doing this on a Fedora 4
test 1 box on a mac mini.

I got pissed last night and dug through the ffmpeg
code that was puking and with some help from a guy on the fedora-devel
irc and the ffmpeg-devel list I found the issue.  The primary deal is
that gcc 4 has deprecated the cast as lvalue extension.  The culprit was
libavcodec/ppc/fdct_altivec.c and I submitted a patch to the
ffmpeg-devel list that performs explict casts for all the lines in
error.  Fron a post after my patch was sent it looks like I was close
enough that they are trying to find someone to test it by conparing
md5sums on files encoded before and after the patch.  I guess compiling
with a supported compiler.

I am attaching the ffmeg patch in case someone else wants to do this
before this stuff gets committed.

I am no C coder so if anyone has comments on what should be done
differently I am all ears.

FYI. All this was done against yesterdays mplayer cvs snapshot
(MPlayer-20050318).
fdct_altivec.c had not been touched for 16 months so the patch should
work against any recent version.


There was one other fix that it took to compile, an incomplete array
definition in libmpdemux/frequencies.h.

I commented out line 107:
//extern struct STRTAB chanlist_names[];

I could not find a reference to chanlist_names or STRTAB by greping the
code so I just got rid of it.

The compilation went fine after that using 
 ./configure --disable-gcc-checking
make
make install

> 
> As for hardware decoding, I assume you mean hardware scaling and
> colourspace conversion. It should work with Xvideo extension on your
> Radeon (it is supported on ppc, isn't it?). We need more details here,
> too.
> 

Now you are asking me to comment on stuff that is over my head.  I
assumed that there was some motion compensation or some such stuff built
into chips that claim hardware decoding of mpeg2 and or mpeg4 files.  My
experience with this is limited to the tremendous gains I got on a
M10000 mini-itx system when I finally got -vo xv -fs -zoom to work on a
1024 X 768 mpeg2 30 second clip with 60% cpu usage. This was compared to
-vo -x11 that took 47 seconds at 100% cpu.  I was hoping for something
similar on the mac since it is a well know chip (Radeon 9200) on a
faster processor and risc based to boot. I should probably start another
thread for these questions since it appears that my compilation issues
are overcome.

Thanks and feel free to correct anything I may have mis stated since I
don't know my rear from a hole in the ground when it comes to this
stuff. I am slowly gaining knowledge but man is it painful.

Bret