VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Jun 20 2003 - 14:59:37 CDT

Hi,

On Fri, Jun 20, 2003 at 09:30:24PM +0200, Bogdan Costescu wrote:
> On Wed, 18 Jun 2003, John Stone wrote:
> > I'm assume that your goal is to produce an MPEG-1 movie, at standard
> > VCD profile etc. Here are things to be cognizant of when making
> > movies for low-bitrate playback (i.e. VideoCD or standard MPEG-1
> > rates):
>
> Why is there this association between MPEG-1 and low-bitrate and therefore
> low-quality ?

Well, simply put, because most people here are using freeware MPEG encoders
that do a fairly bad job with CBR rate control used in MPEG-1, particularly
when lower bitrates are used (i.e. VideoCD rates as discussed here in the
last two emails).
Most of the freeware encoders are based on the TM5 encoder, which had various
kinds of bugs in it, and thus they too have inherited these bugs, unknowingly.

Certainly the MPEG-1 encoder I helped develop when I worked at Heuris did
very well, but it is far more advanced than the encoders we're
talking about here, and it costs around $2,000 as a result of its
more advanced features.

> > - MPEG is a garbage-in/garbage-out medium.
>
> Well put :-)
> I'd like to add something that is obvious but still lots of people fail to
> realize it: the rendered frames should have the same resolution as the
> final movie. Most (all ?) MPEG creation programs can scale in software the
> frames to the movie resolution; however this scaling usually introduces
> artefacts in the pictures, before the MPEG encoding takes place. This
> adds to the digital noise and contributes to a lower quality of the
> result.

Yes, of course. If you use a real filtering algorithm the results can be
quite good, but if you have single-pixel details in the original image,
there's nothing one can do to prevent them from being destroyed when you
downsample significantly, even with a good algorithm.

> > - MPEG-1 targets 352x240 resolution. If you exceed this resolution,
> > you're asking for all kinds trouble both in encoding and playback.
>
> Well, let me disagree here :-)

Disagreement noted, but I still maintain from extensive experience that if
you want the be able to play the movie back on _all_ hardware, you should
stick to standard MPEG-1 SIF resolution and to something around 1.15Mbps
for the overall bitrate. Believe me, you'd be shocked at how many
buggy players are out there. If you only intend to use 'mplayer'
then you have more flexibility, but in general I would discourage people
from making movies with nonstandard bitrates and resolution settings unless
they only want to play it back on one or two machines.

> As stated above we want 2 kinds of movies. However, most important is that
> these movies should be playable with as few (if any) setup steps needed on
> the part of the viewer. By trial-and-error we have discovered that out of
> our OSes (Linux, IRIX and Windows) Windows seems to be the most picky
> platform when using its default codecs (a.k.a. filters) - it only plays
> MPEG-1 files with certain resolutions, which are (surprise !) those
> established by the TV standards; the bitrate should be constant; the frame
> rate should also ideally be one of the standard (again from TV) ones - if
> frames should be played slower, the same frame should be repeated for
> several "real" frames.

Yes. MPEG-1 only defines a small set of legal framerates, this is part
of the standard and you cannot define any other framerates, its an integer
framerate code stored in the video stream header. :)
Frame doubling is the only way to play things back slower, though an
intelligent MPEG encoder can insert "no-codes" to save bits.

> So the web movies that we create are 320x240 or 352x240, with 1150 Kbps.

These are safe for playback on most any hardware, and that's what I
recommend for people to do in general.

> The presentation movies are 720x576 using something like 8000 Kbps - as
> here we want the best quality, the bitrate might vary as well as the frame
> type sequence (some use only I, some IPP, or some more P frames). We've
> had no problems playing any of these files in Windows (98, 2000, XP)
> without installing any additional codecs or player software; in Linux, we
> use mplayer; I forgot the exact name of the IRIX player... Limited trials
> with these files on MacOS were also successful.

If you only need to use those files on your own laptops, more power to you,
but this is definitely not what I'd recommend for general use, the chances
of having trouble when the same presentation is played on someone else's
laptop grow tremendously once you exceed standard SIF resolution and
VideoCD bit rates...

> > The best software-based MPEG encoders can also "rewind"
>
> ... or make several passes. CCE (for Windows) allows even editting the
> profile that is kept between passes, such that the human can better direct
> what regions of the movie should be allocated more bits.

Smart encoders determine this automatically. Some can also import
'edit lists' from other packages, detect scene changes, and do
inverse-telecine by analyzing the incoming video stream :-)

> But this
> discussion becomes too technical :-) There are places on the 'net where
> movie creation topics are discussed; one starting point is
> http://www.doom9.org

Yes.
People may also wish to visit Tristan's web site: http//www.mpeg.org/
which has links to various MPEG topics of interest.

Thanks,
  John Stone
  vmd_at_ks.uiuc.edu 

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078