[MPlayer-users] Re: lavc-Options for *BEST* quality?

[D Richard Felker III]

On Tue, Feb 04, 2003 at 04:29:13AM +0000, Jason Lunz wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> dalias at aerifal.cx said:
> > course vorbis at -q0 sounds just as good and uses about 65kbit/s. This
> > is a savings of about 22 megs for a normal length movie, but when you
> > consider the extra 12 megs or so you waste on ogg page headers, it's
> > not really a big difference.
> 
> I just measured a few 700M .ogm files, and the total overhead was always
> about 1% (7M).  I dug out some old avis for comparison, and I didn't see
> that much difference, maybe an extra 3 megs or so. Maybe you were using
> an old version of ogmmerge?

My numbers were based on something I tried to do a few weeks ago:
remux an avi file with mp3 audio into ogm. I was hoping it would save
space, but it actually grew by 15 megs or so in the process. Perhaps
mp3-in-ogg has more overhead than ogg vorbis for some reason though.

In any case, even if the savings in overhead are only 2-4 megs, I
think doing vorbis-in-avi would be much better than ogm just for the
sake of having an index.

> file           bitrate      total      video      audio  overhead
> -----------------------------------------------------------------------------
> rushmore.avi   920/128  731926524  639513648   88880904  3531972 (3.4M, 0.48%)  
> aod.avi        852/128  709123722  613365454   92098825  3659443 (3.5M, 0.52%)  
> traffic.avi    514/128  715686394  568683344  141385995  5617055 (5.4M, 0.79%)  
> singles.ogm     890/85  732770345  662630351   63100765  7039229 (6.7M, 0.96%)
> zoolander.ogm  1006/80  733039525  672552326   53344661  7142538 (6.8M, 0.97%)  
> 
> Based on that, the improved vorbis bitrate far outweighs the ogg
> overhead.

Thanks for the numbers.

> As far as seeking goes, that's an mplayer issue with non-indexed files,
> not anything specific to ogg.

Seeking is inherently difficult with non-indexed vbr files. The only
way to get it to work right is by doing lots of seeks (in the file)
and reading lots of extra data until you get to exactly the right
spot. Things will be much improved if you cache an index while playing
the movie, but still something like mplayer -ss 1:00:00 foo.ogm will
be very slow and painful. For me something like this is the most
common case -- stopping in the middle of a movie for some reason and
wanting to resume where I left off. Right now it's impossible with
.ogm without hitting the seek buttons over and over til I get to the
right place. :(

Rich