[XviD-devel] testing process

[Tom Jacobs]

hi

i have a few probs with using xvid_encraw. firstly my implementation is not
for x86 it is for a simplescalar architecture which is run on a simulator
on my x86 Linux box. xvid_encraw doesn't seam to like being compiled with
my compiler ( i dont think it is linking with any of the other xvid stuff,
it complains that nothing is declared). i think this may be because i
installed/got libxvidcore. is there away of doing the testing separate from
the encoding? so i can encode on the simulator and then use normal x86 tools
to test the output?

when looking at my results i wont quite have the 1:1 copy for my single
thread version (although it is just a macro switch away ;) this is because
i have slightly modified get_pmvs2 and get_pmvdata2. this was done so that
it never did the prediction from the left MB it used top left instead. pmvs
have although been reevaluated with the correct MB so that the decoding can
be done correctly. not sure how much that has made sense but baasically the
search is done with a 'wrong' prediction which doesn't use the left MB.

due to this the single threaded wont be the same as the stock xvid code. all
the extra threads although do produce the same file as this single threaded
version.

so what i am trying to show is that a) my modification at single thread
doesn't have a great detrimental affect on the encoder, and once this is
acceptable b) show that by using more threads a huge complexity reduction
can be achieved

hope all that makes sense

thanks for your help

Tom


Quoting Edouard Gomez <ed.gomez at free.fr>:

> Selon Tom Jacobs <T.R.Jacobs at lboro.ac.uk>:
> > i have nearly finished by threading of xvid and am looking more closely
> at
> > testing my code. i have numerous test sequences in qcif format. what is
> the
> > best way to test my work? i think i would like to know the psnr of my
> > modified code against the original image and an unmodified xvid so i
> can
> > see how my modifications affect the over all performance of the codec.
> i
> > can get the compressed mp4 back into qcif if that helps but i don't
> know
> > what programme would be best to use to obtains some results
>
> First of all, your modifications should not impact one thread coding,
> which
> means that for a single thread encoder, the resulting bitstream should be
> 1:1
> with non threaded encoder, eg: test it with md5sum.
>
> For all threaded cases, you have two ways to test your code:
>  - see how bigger streams are at constant quantizer (this measure the
> loss in
> coding efficiency caused by the ME zones splitting)
>  - see how much PSNR you lose at constant file size (2pass coding).
>
> And depending on your code changes, maybe all multi threaded cases should
> behave
> exactly the same, in that case test resulting streams with md5sum, if not
> then
> just forget about this.
>
> examples/xvid_encraw allows all that, PSNR tracking, framesize tracking
> etc...
> just feed it with raw yuv streams and choose the right options for your
> tests.
>
> xvid_encraw has the advantage to be a very thin layer upon xvidcore, so
> you're
> sure nothing introduces bugs in between xvidcore and the demuxer. Once
> xvid_encraw validate your changes, you can give a try at a normal test
> series
> with your favorite encoding app.
>
> --
> Edouard Gomez
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>