Re: Fixing mpeg2enc

Hi Steven,


> >>[3] The most-recent bitrate estimation code seriously undershoots
> >>the target.  The previous code (which, it looks like, I grabbed from
> >>CVS around March 15, 2005) does a much better job.
> >
> >I know I know.  It simply is not working properly yet.  In all
> >honesty I'm tempted to write this off (restore mpeg2encs single-pass
> >rate-control release) and put effort into ffmpeg.
> 
> I'd be happy with that solution too.  The old bitrate estimation did a
> fantastic job of maintaining a steady rate, both in terms of size and
> in terms of perceptible video quality.  I once tried to use ffmpeg to
> encode VideoCD-grade video -- the moving scenes looked horrible, and a
> following still-scene looked intensely high-resolution.  The
> transition was jarring.  I don't get those sorts of jarring
> transitions with mpeg2enc.  I vastly prefer whatever it is you're
> doing differently.

Sounds like differently tuned formula for bit-allocation based on
predicted/actual complexity.  It *should* be possible to use ffmpeg's
facility for user-defined rate-control Formulae to achieve something
pretty close.  However, I hope it should be possible to get the current
look-ahead control working pretty well without excessive effort.

Thinking about it ... I'm not sure what you mean with  'undershoot'.
There's currently no mechanism for specifying a target mean rate

> 
> >>[4] The most-recent mplex code seems to have serious trouble with
> >>A/V sync.  It looks perfect when viewed on my computer, but gets out
> >>of sync when played on an actual DVD player.
> ...  is there
> >any remux-ing going on elsewhere in the toolchain -> DVD?
> 
> No, there's no remuxing -- I wouldn't put up with such distortion in
> my output chain. :-)  It seems like it's in sync at the beginning,
> then quickly gets a good half-second or more out of sync and stays
> there.
> 
> I don't think I can reproduce that one with a short clip -- I may just
> have to mail you a DVD.

Thats really *weird* . mplex-internally its hard to see how audio could
first drift and then stop drifting.   You mention its only the
most-recent version, so presumably this problem hasn't always been
there.  Looking at the cvs logs there doesn't seem to have been any
change introduce that could cause anything like this since
RELEASE-1_8_0...


> 
> There's one more artifact I thought of, one that might be related to
> the above bugs.  On my computer screen, video looks perfect, but when
> I view it with a DVD player on a TV, whether a CRT-style TV or an
> LCD-style TV, it kind of looks like the video has been run through a
> "plaid" filter.  Even my highest-resolution video looks like it's
> melting on a very small scale, especially in not-so-brightly-lit
> areas.  I don't know how else to describe this one.

This sounds like decoder mismatch... (MPEG-2 isn't bit-accurately
specified, unlike MPEG-4) you can get subtle block artefacts if the
encoders idea of the decoded image and the actual decode are slightly
different.  Is this also a recent issue? If you can upload an .iso
someplace I'll take a peek...

cheers,
   Andrew



------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd