[FFmpeg-devel] [PATCH] make fast option with h264 actually do something..
Wed Feb 20 02:15:25 CET 2008
On Tue, Feb 19, 2008 at 06:54:52PM -0500, Rich Felker wrote:
> On Tue, Feb 19, 2008 at 09:22:31PM +0100, Michael Niedermayer wrote:
> > On Tue, Feb 19, 2008 at 09:10:38PM +0100, Michael Niedermayer wrote:
> > > On Tue, Feb 19, 2008 at 01:26:24AM -0500, Rich Felker wrote:
> > > > Currently, the FAST flag for h264 only affects motion functions for
> > > > non-ref frames, making it mostly useless. This patch makes it affect
> > > > all motion compensation. Benchmarks on my K6, using mplayer
> > > > -benchmark:
> > > >
> > > > Without fast: 17.6 sec
> > > > With current fast: 17.2 sec
> > > > With patch applied: 16.6 sec
> > > >
> > > > I did not notice any visible corruption, but even if there is some,
> > > > that's the idea of the 'fast' flag...
> > > >
> > > > Comments welcome.
> > >
> > > patch ok
> > after some more carefull tests, i retract that approval, patch rejected,
> > it breaks decoding of BA1_FT_C.264 with very vissible artifacts.
> Would it be possible to make the level configurable or to at least
> apply the fast-mode to all B-frames instead of only non-reference
> ones? Error should not have time to sufficiently accumulate during
> B-frame sequences, only over long intervals between I-frames.
Well h.264 does not forbid P frames to use B frames for prediction. I do
not know if any encoders use this of course. Also a B frame could use 2
past P frames instead of a past and future one.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel