OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: FFmpeg diff needs testing

From: Jacob Meuser (jakemsrsdf.lonestar.org)
Date: Mon Aug 25 2008 - 15:19:09 CDT


On Mon, Aug 25, 2008 at 12:49:51PM -0400, Brad wrote:
> On Sun, 24 Aug 2008 23:31:32 +0200
> Matthias Kilian <kilioutback.escape.de> 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.
>

--
jakemsrsdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org