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

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

Dan Hollis wrote:
> 
> On Thu, 1 Feb 2001, Andrew Stevens wrote:
> > - 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.
> 
> I'm not so concerned with compressor speed, I'm more concerned with
> quality and I'll spend extra cpu if needed to compress better quality.

Quality is the objective (there are loads of easy tricks if speed is
all that matters).

The problem is that good compression often needs a big MC search
radius. MC scales with the square of radius (more or less).  In
practice (I use my MPEG encoder and buz as a digital VCR) you hit
severe practical limits unless you can get encoding down to no more
than 4 or 5 times real-time.  That's my tolerance threshold anyway.
Bear in mind also that comprssing MPEG-2 at 480x576 (PAL SVCD) is
*more* than 3 times as expensive as MPEG-1 CD due the many more motion
compensation types that need to be evaluated.  Its actually more like
6 times as as much work.   Furthermore, at higher resolutions you need
big MC radii even more... 


> > (Yes, I *did* spend a lot of time gathering data and testing
> > alternative algorithms).
> 
> I assume you've already read the motion estimation papers from
> http://citeseer.nj.nec.com/Compression/ ?


I spent quite some time in the E.Eng dept.'s library here on the net
;-).    Comp. Sci. is my job as well as my hobby. Actually, quite a
few of the various MC schemes people have proposed are pretty bogus. 
The papers are very encouraging.  Then you actually go out and
implement it and its... well, not quite so good as the paper may have
lead you to be believe.  Others (transform methods) are not really
suitable for software implementation.

> > - 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).
> 
> I've been told one of the best commercial mpeg encoders dynamically
> modifies GOP structure to best fit the material. Eg It can vary IPPPBP
> or IPBPB or IPBBBB or any other combination depending on the dynamic
> content.

Yes, thats definately what you want to do.  Its just doing it right
without absurd computational
overhead thats pretty hard.  Basically, you want to push your next P
frame out as far as possible without
significantly increasing its activity.  The B frames in-between can be
safely assumed to be
<= in cost to a P frame in the same place.  Conceptually pretty
clear.  Good tuning is  as always fiddly.  Its on "the list" ;-)

In practice most standard profiles limit you to no more than 2 B
frames in a row, however this isn't a big deal as beyond that you get
fairly steeply diminishing returns anyway (P frames are rarely more
than twice as large for identical SNR as B frames).


> > - For SVCD work it would probably make sense to add multi-threading
> > for folk with SMP machines like Adam did on mpeg3movie.
> 
> Clustering? Tsunami mpeg allows this, you can throw a cluster of machines
> on 100bt and have them all crunch video.

Thats really cool.  I didn't think they released source code though...
please don't tell me I'm wrong - I'll go
bang my head on a tree after a years wasted work if they do ;-)

> > 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?
> 
> Certainly, at least you can share techniques of compression.

That'd be possible if he responded to emails.  I kid you not: I don't
know anyone who has ever recieved a response. I gave up after a
while...

 
Andrew