On Mon, Aug 25, 2008 at 12:49:51PM -0400, Brad wrote: > 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.
I think the idea was to use an encoder that is not affected by the patch. makes sense to me, to separate possible encoding/decoding issues. > 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. ideally, one would decode to "raw" yuv or rgb, verify the raw stream, and then encode the raw stream. > > Ciao, > > Kili > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
