[FFmpeg-devel] [PATCH] lavfi: port mp test source

Michael Niedermayer michaelni at gmx.at
Wed Aug 10 00:42:06 CEST 2011


On Wed, Aug 10, 2011 at 12:28:17AM +0200, Stefano Sabatini wrote:
> On date Tuesday 2011-08-09 21:51:50 +0200, Michael Niedermayer encoded:
> > On Tue, Aug 09, 2011 at 08:59:53PM +0200, Stefano Sabatini wrote:
> > > On date Tuesday 2011-08-09 16:09:47 +0200, Michael Niedermayer encoded:
> > > > On Mon, Aug 08, 2011 at 02:43:15PM +0200, Stefano Sabatini wrote:
> > > > > ---
> > > > >  doc/filters.texi             |   57 ++++++
> > > > >  libavfilter/Makefile         |    1 +
> > > > >  libavfilter/allfilters.c     |    1 +
> > > > >  libavfilter/vsrc_mptestsrc.c |  392 ++++++++++++++++++++++++++++++++++++++++++
> > > > >  4 files changed, 451 insertions(+), 0 deletions(-)
> > > > >  create mode 100644 libavfilter/vsrc_mptestsrc.c
> > > > 
> > > > if it produces same output
> > > > then ok
> > > 
> > > After some comparation with showinfo, I had to change M_PI in my code
> > > with 3.141592654, at this point they issue the same output but with
> > > some behavior difference, for mp=test frames with number frame%30 are
> > > skipped, with mptestsrc they are not (which looks more correct).
> > 
> > the filter was used to reverse engeneer 8x8 dct based codecs and the
> > all black frames can be used to quickly spot where the different
> > parts of the test patterns start
> 
> I used showinfo for that ;-). Anyway how should look the sequence?
> 
> How about
> TEST1 TEST1 ... TEST1 BLACK TEST2 ... TEST2 BLACK ...
> ?
> 

LGTM


> Consider also that I'm adding the possibility to run separately each
> single test, in that case having a separation frame is pointless.

the way the filter was used was to create a test video that was then
encoded with a closed source encoder that worked only on a different
platform and the resulting bitstream analyzed.

seperate files and fighting with a shitty GUI to encode them X times
is more work than a single video with black frames.

Anyway this filter is probably largely of historic value so it doesnt
matter much.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110810/9b43700f/attachment.asc>


More information about the ffmpeg-devel mailing list