[MPlayer-dev-eng] [PATCH] new mpeg muxer

[Joey Parrish]

On Wed, Feb 23, 2005 at 06:27:49PM -0500, D Richard Felker III wrote:
> ok, at some point someone should make a guide for how to encode
> (compliant) vcd/svcd/dvd with mencoder's new mpeg muxer.

I agree.  I'm playing with some things at the moment, but none of it
final, and none of it as good as TMPGenc.  (Although it is twice as
fast. :)

> - i seem to occasionally get weird out-of-order glitched frames during
>   really high motion scenes. is this due to buggy reordering of some
>   sort in the muxer, failure to enforce closed gops, or something
>   else? i think i can extract small samples that exhibit the problem
>   if you want to see one.

I've noticed this in some of my home-made DVDs.  I dug through the
source MPEGs, and the problem lies there.  The source is interlaced NTSC
MPEG2 from a Tivo, and there are (rarely, but noticably) missing fields.
Any correct way to deal with that other than a blurring deinterlace
filter?  I've never really liked the way those look.

I'm having compilance issues with dvd format, too.  I specified
format=dvd under mpegopts, but my dvd authoring app doesn't like the
streams.  Doesn't say why, mind you... :(

Also, mencoder wants to screw up audio sync pretty badly from my Tivo
recordings.  After an hour, I'm a whole scene off.  The story is:

-ovc lavc -lavcopts vcodec=mpeg2
  complains that "2997 / 100" is not a valid framerate for mpeg.
  which is stupid, because the source file is an mpeg.  it's upset
  over rounding and conversion errors introduced by the mplayer core
  itself.  (somewhere)  I'm not able to fix this off-hand.

-ovc lavc -lavcopts vcodec=mpeg2 -ofps 30000/1001
  encodes, but with massive audio sync problems.

-ovc lavc -lavcopts vcodec=mpeg2 -fps 30000/1001 -ofps 30000/1001
  encodes, same sync problems.

-ovc lavc -lavcopts vcodec=mpeg2 -mpegopts vframerate=30000/1001
  dies the same as without -ofps.

-ovc lavc -lavcopts vcodec=mpeg2:vstrict=-1
  encodes fine, and sync is almost correct.  (barely noticable desync
  after an hour.)  why?
  when this one is done, the terminal has lots of warnings about
  duplicate and dropped frames.  is this a neccessary process to cope
  with what is really a somewhat variable framerate source?  is this
  process somehow screwed up by -ofps/-fps?  if these flags are screwing
  it up we should either document the vstrict trick or fix the encoder
  so that we don't need to "trick" it into accepting a "nonstandard"
  framerate.  I vote for the second, but I can't find the right fix.

And I still can't help but feel like I'm missing something very
fundamental and important.  Am I just mad, or is this really hard?

--Joey

-- 
"Of the seven dwarves, the only one who shaved was Dopey.
That should tell us something about the wisdom of shaving."