[mpeg2] Re: MPEG encoder code (was: Kfir Mpeg2 to SVCD)

[Andrew Stevens <Andrew.Stevens@comlab.ox.ac.uk>]

Dan Hollis wrote:
> 
> On Wed, 31 Jan 2001, Andrew Stevens wrote:
> > If you post a URL I'll let you know how the KFIR stuff fares when
> > piped through mpeg2dec and my version of mpeg2enc!
> 
> BTW the bbmpeg guys are doing some interesting stuffs. Apparently they
> now have some tricks which give them better I frame results than even
> tsunami mpeg...

I haven't looked at bbmpeg for a while.  If what they're producing is
legit MPEG then probably what they're doing is setting
a nice custom DCT coefficient scaling matrix.    It makes  a big
difference on noisier material if you quantise down the HF
coefficients. Actually, we've exchanged source code in the past.  I
even looked at a common code base but the effort require to sync
Windows source code for Win compilers and gcc/Linux seemed
disproportionate.

> What does your version of mpeg2enc have that is special? ;-)

- A rather efficient (o.k. I invented it) hierarchical sub-sampling
based motion compensation search algorithm.  Gets to within a % or two
of optimal matching and delivers legit VCD MPEG-1 at 13 frames/sec
(352*288 PAL) at a motion compensation search radius of 16 p.p.f.d. on
a Duron 700.  (Yes, I *did* spend a lot of time gathering data and
testing alternative algorithms).

- Chrominance match checking to avoid chrominance artefacts during
"difficult" highly quantised sequences.

- Wholly rewritten predictive rate control that (like bbmpeg) properly
supports rate-limited VBR.

- Like bbmpeg all the main compute intensive routines (motion
compensation, prediction, rarte-control metrics, quantisation, and DCT
are MMX).  A couple of key routines where it makes a difference also
have SSE and 3D-Now versions.

- A thoroughly overhauled multiplexer with support for VCD and SVCD.

However as the label "beta2" and "beta3" would suggest it is still
work in progress...

- The input filters for .avi and quicktime streams need to be modded
to work YUV and RGB streams as well as MJPEG.

- More encoder control parameters need to be exposed.

- The multiplexer needs to be modified out to handle mux-ing allow
5.1MPEG and/or AC3 audio to allow really comprehensive coverage for
transcoding applications.  

- For low bit rate work scene-change detection / automatic GOP length
adjustment needs to be added (this should help quite a bit for
low-bit-rate applications).   

- For SVCD work it would probably make sense to add multi-threading
for folk with SMP machines like Adam did on mpeg3movie.

Its that are the main items.  The rest are fairly straight-forward in
that the relevant code already exists.

If I thought Adam were interested I'd *love* to merge all the MC and
rate-control stuff into mpeg3movie.   Save a lot of redundant effort. 
Perhaps I should email him again?

Andrew
PS
Re: MC search using 2D transform methods (e.g. fourier-xform then
phase analysis).  In theory this is very appealing.  However if you
work out the implications it is just not viable on a software (i.e.
general-purpose CPU) implementation.   You just don't have enough
multipliers and adders available to do enough "Butterflies per
second".  Furthermore, the big deal about xform methods is
O(n*lg(n)) scaling.  However, for the MC application you don't
actually need to scale that far.  You know in advance that n < 127.
Sum absolute difference is O(n*n) but for n < 127 and with a bit of
cunning using sub-sampling the constant scale factors are waaay
smaller.