On Sun, 24 Aug 2008 23:31:32 +0200 Matthias Kilian <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 24, 2008 at 02:10:20AM -0400, Brad wrote: > > The following diff for FFmpeg corrects the architecture detection. > > This results in the AltiVec support now being enabled. I have now > > also added support for the sysctl method of detecting the pressence > > of AltiVec. In addition since the architecture detection support > > has been fixed for OpenBSD that means this also needs checking > > on SuperH systems (landisk), ARM systems (armish/zaurus) and MIPS > > systems (sgi). > > This seems to reduce ffplay cpu usage by 25% on a G4 (even more > when converting video files with ffmpeg). I didn't notice any > improvement on arm, however. > > And there's a big caveat: ffplay with altivec enabled fails on some > video files either by exiting immediately or by showing lots of > artefacts (there seems to be a tendency to "green out" the video, > i.e. you get green blurring patterns). > > The later problem is easy to reproduce; just convert any video file > with mplayer's mencode with -oac mp3lame -ovc lavc amd play the > resulting file on a G4 with ffplay. MPlayer does not use the FFmpeg port. On top of that MPlayer is always behind with the embedded copy of FFmpeg it does use. If you do want to test this use VLC/Xine (Xine-ui / Kaffeine), Transcode, etc. but not MPlayer. What input video format was being used when doing the conversion? Also what format of files were seeing this "green out"? There was a bug with the VLC1/WMV9 decoder with older FFmpeg that would cause this issue. > Ciao, > Kili > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
