[FFmpeg-devel] [NOPATCH] lavfi/mp: drop tinterlace wrapper

[Stefano Sabatini]

On date Tuesday 2012-12-25 14:03:44 +0100, Michael Niedermayer encoded:
> On Tue, Dec 25, 2012 at 12:29:47PM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2012-09-05 10:33:46 +0200, Stefano Sabatini encoded:
> > > On date Wednesday 2012-09-05 04:31:56 +0200, Michael Niedermayer encoded:
> > > > On Wed, Sep 05, 2012 at 12:26:01AM +0200, Stefano Sabatini wrote:
> > > > > Hi,
> > > > > 
> > > > > some benchmarks comparing mp=tinterlace and interlace follow:
> > > > > 0:917992 decicycles in tinterlace, 4096 runs, 0 skips
> > > > > 0:884563 decicycles in mp=tinterlace, 8192 runs, 0 skips
> > > > 
> > > > you should pick lines with similar runs for comparission
> > > 
> > > 0:791404 decicycles in tinterlace, 4096 runs, 0 skips
> > > 0:761499 decicycles in mp=tinterlace, 4096 runs, 0 skips
> > > 1:10264 decicycles in tinterlace, 4096 runs, 0 skips
> > > 1:182090 decicycles in mp=tinterlace, 4096 runs, 0 skips
> > > 2:10917 decicycles in tinterlace, 4096 runs, 0 skips
> > > 2:184288 decicycles in mp=tinterlace, 4096 runs, 0 skips
> > > 3:818253 decicycles in tinterlace, 8192 runs, 0 skips
> > > 3:1407655 decicycles in mp=tinterlace, 8192 runs, 0 skips
> > > 4:442110 decicycles in tinterlace, 4096 runs, 0 skips
> > > 4:372288 decicycles in mp=tinterlace, 4096 runs, 0 skips
> > 
> > I plan to remove this filter, the difference in performance are mostly
> > due to the framework code so it is not something which can be
> > optimized at the filter level, *AND* mp=tinterlace is broken with
> > regards to timestamps and has less features, so there is little point
> > in keeping it.
> > 
> > I'll drop mp=tinterlace in two days if I read no objections.
> 

> code being 10% faster should not be droped.
> IMHO leave it, so others can compare, and improve either, if they want.
> 
> Also if mp can do it fast so can any filter, mp has more code then
> others to make the interfacing to libmpcodecs possible, any filter
> could duplicate that  but mp cant loose it so mp is more constrained
> and should never be faster.

Given that the two filters have different codepaths they are difficult
to compare (and the speed gain is somewhat irrelevant for such a
filter, which works mostly by operating on data/linesizes
pointers). Also mp=tinterlace is broken and has less features, thus
believing that someone has interest into using mp=tinterlace or
comparing it with tinterlace is delusional, while keeping two versions
of the filter will confuse people.
-- 
FFmpeg = Fundamentalist Free Minimal Peaceful Extreme Gigant