Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Dan Hollis wrote:
> 
> On Wed, 31 Jan 2001, Andrew Stevens wrote:
> > Actually, now that you mention it you're probably right.  I think the
> > latest version can transcode. The encoder part is even based on the
> > same original MSSG reference encoder.  I'd like to have contributed to
> > that rather than build something new but the developer didn't seem
> > interested in answering emails and so I moved on. I think mpeg2movie
> > still uses the original not-so-hot motion-compensation and rate
> > control code.  It does some nice multi-threading but (last I looked)
> > is still pretty light on MMX (etc) routines.
> 
> Latest mpeg2movie supposed to have really good advanced motion
> compensation and rate control, as well as "super advanced low bitrate
> mode".

The latest one I've seen and the one on the web-site is 1.4.  Looking
over the source to the encoder it is (functionally speaking) still to
all intents and purposes the MSSG reference encoder, warts and all. 

The main changes are that various routines tasks are now multithreaded
(this is nice!) and that sum-of-absolute-difference and variance
routines have MMX alternatives.  However, the algorithms are still the
(pretty naive) originals. I believe the "low bit rate mode" is nothing
more than tuned settings that (mildly) violate the usual
main-profile/main-level MPEG-2 constraints to make the most of the
possibilities of a software codec.   E.g. they generate almost no I
frames.  You can do this on pretty much any software MPEG encoder -
just "twiddle the knobs".  However, you of course can't do a lot of
this if you're encoding stuff that is supposed to be playable on
hardware players.

A curious "feature" is that by default (and for many recommended
settings) no B frames are generated.  This is probably necessary to
produce decent results as the motion compensation search radius is set
waaaaay too low (around 3 pel per frame-difference) for motion
compensation search to be effective between more widely spaced P
frames.   To give you some idea how low this is MPEG data suggests 10
p.p.f.d. as a minimum and the KFIR's docs suggest it manages the
equivalent of around 64.  This rather sub-optimal setting is probably
due to the slowness of the MC search algorithm: simple
spiral-exhaustive at 1-pel resolution, chrominance only.  This is
acheingly slow for sensible radii even with MMX and prone to "leak"
chrominance artefacting when quantisation is high.  Bit allocation is
the original reactive feedback on seperate IBP virtual buffers based
on macroblock variance. This is also pretty rough-and-ready as
variance is a fairly crude measure of likely macroblock coding
complexity (I prefer quantisation-weighted sum of DCT coeffecients). 
Lacking a predictive element it is prone to overshoots and hence
(visible) oscillations in quantisation.  There's no rate bounded VBR
(as needed for SVCD).  The code *has* also been heavily tidied from
the (rather yucky) original K&R C.

Frankly, Adam has done a decent job and produced a useful tool but
there's nothing there to warrant some of the hyperbole about the
encoder on his web-site.  The remarks he makes about MPEG-4 being
nothing more than a "wrapper" for MPEG-1 are particularly
cringe-worthy.   They are certainly close relatives but MPEG-4 (just
for starters) uses a predictive DCT coefficient coding scheme wheras
MPEG-1 doesn't.  This gains it 10-15% at medium (around 1Mbps) and
20-25% at low (< 700Kbps) data rates.


> I looked at sample mpeg and they are quite nice indeed.. but I have not
> yet tried transcoding kfir output through it...

Aside: the quality of source material makes a huge difference in MPEG
encoding.  Digital video sources can produce really nice results even
with less-than-astonishing encoders wheras even a truly excellent
encoder will produce mush if fed poor-quality noise source material.

If you post a URL I'll let you know how the KFIR stuff fares when
piped through mpeg2dec and my version of mpeg2enc!

	Andrew



Home | Main Index | Thread Index