[MPlayer-users] Support of ogmtools inside mencoder?[was: Ther is a way to encode directly in ogm format]

[D Richard Felker III]

On Tue, May 06, 2003 at 06:00:17PM +0200, Pere Castañer wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> On Tue, 6 May 2003 01:29:17 -0400
> Michael Waters <stonin at rogers.com> wrote:
> 
> > encoder can't encode to ogm directly.
> 
> Can be possible to add ogmtools support in mencoder? there's a technical issues that prevent of doing it? (seeking developers' opinions)
> 
> Because the method of ogmtools readme take too long. I mean that
> when I encode divx with mencoder first I cacule the lenght of the cd
> with frameno then I calcule the scale parameters, and then I can
> leave the pc doing the 2 video passes, and I can go to sleep!

WTF?? Why are you even using frameno? You're just going to throw away
the audio encoded at this pass (mp3) and replace it with ogg later,
which will probably average a different bitrate, so the size info it
tells you won't even be useful!!

Just learn how to use a 4-function desk calculator (or bc, if you're
scripting it, but using scripts for ripping DVDs is a very bad idea
since it almost always requires hand-tuning to get best quality, deal
with interlacing, etc.) to figure out what bitrate to use for video
after you've encoded the vorbis audio.

To other developers: IMO we should remove the frameno/3pass nonsense
at some point. It's buggy and lots of users misunderstand it and use
it when there's absolutely no point. Lame's bitrates are predictable
enough that you don't need to actually encode audio to decide what
video bitrate to use. But if this bitrate prediction nonsense is
really important to some people, we should incorporate it into the
2pass encoding, so that it's done along with video pass #1. That would
fix the bugs (A/V sync issues) caused by the current 3pass mode, since
video is actually decoded.

Rich