Mailing List archive

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

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



On Thu, 1 Feb 2001, Andrew Stevens wrote:
> Dan Hollis wrote:
> > 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...

Hey, I'm used to spending 26 hours encoding 45 minutes of 480x480 ntsc to
mpeg2, so i'm not worried about practical limits. I just want the best
quality possible ;)

> > 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.

What about the ones which feedback MC vectors as hints to the next
frames, to reduce the search space?

> > > - 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 ;-)

Nope, no source code... :P

Speaking of no-source-code, have you seen
http://rachmaninoff.ti.uni-mannheim.de/sampeg/ ?

-Dan




Home | Main Index | Thread Index