Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!xlink.net!rz.uni-karlsruhe.de!news.uni-stuttgart.de!news.belwue.de!news.belwue.de!fu-berlin.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [0/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 10:52:25 GMT
Organization: Technical University of Berlin, Germany
Lines: 83
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r9959$2l8@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77877 comp.graphics.animation:20012 comp.compression:20437 comp.multimedia:36441 alt.binaries.multimedia:40195 alt.binaries.pictures.utilities:37032 alt.binaries.pictures:21187 alt.binaries.pictures.d:20800 alt.answers:9853 comp.answers:12386 news.answers:45906

Archive-name: mpeg-faq/part0
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly

        ====================================================
        THE MPEG-FAQ           [Version 4.0 - 07. June 1995]
        ====================================================
        PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY
        Inh. Frank Gadegast          Fon/Fax: +49 30 3128103

        phade@cs.tu-berlin.de
        http://www.cs.tu-berlin.de/~phade


===========================================================================

This is my summary about MPEG.

It's the seventh publication of this file. Lots of information has been
added (which has surely brought errors with it, see Murphy's Law).

This edition is REALLY different to the previous one.

===========================================================================

You should receive nine files called:

  MPEG-FAQ: multimedia compression [0/8] <- that's this file
  MPEG-FAQ: multimedia compression [1/8] <- that are the eight parts of
  MPEG-FAQ: multimedia compression [2/8] <- the MPEG-FAQ-text-file
  MPEG-FAQ: multimedia compression [3/8]
  MPEG-FAQ: multimedia compression [4/8]
  MPEG-FAQ: multimedia compression [5/8]
  MPEG-FAQ: multimedia compression [6/8]
  MPEG-FAQ: multimedia compression [7/8]
  MPEG-FAQ: multimedia compression [8/8]


 UNPACKING the FAQ-File
========================

Save the eight files in the right order to ONE file, strip every header-
information of the file and there you are.

You can always get the newest version of the FAQ and the index-file
via Mosaic at http://www.cs.tu-berlin.de/~phade/mpegfaq/index.html


 SYSADM
========

If you are a system-administrator please ensure to delete the old version
of the MPEG-FAQ. Please store the new version as MPEGFA40.TXT on your local
ftp-server or BSS and compress it to your needs, but be sure the name
MPEGFA40 is included (hopefully in big letters) in the final name.


 NEWS
======

The FAQ itself will be posted as txt-file to several news-groups
include the *.answers and to alt.binaries.multimedia groups.


 ERRORS
========

If you can't unpack the FAQ, please reply immediately to me:

  phade@cs.tu-berlin.de

to prevent others from the same errors ...


Enjoy MPEG, Phade
 
<=====================================================>
 PHADE Software, Leibnizstr. 30, 10625 Berlin, GERMANY
 Inh. Frank Gadegast           Fon/Fax: +49 30 3128103

 phade@contrib.de    http://www.is.in-berlin.de/~phade

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!news.sprintlink.net!howland.reston.ans.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!fu-berlin.de!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [1/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 10:58:04 GMT
Organization: Technical University of Berlin, Germany
Lines: 1293
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r99fs$2nb@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77871 comp.graphics.animation:20006 comp.compression:20433 comp.multimedia:36436 alt.binaries.multimedia:40187 alt.binaries.pictures.utilities:37026 alt.binaries.pictures:21183 alt.binaries.pictures.d:20796 alt.answers:9849 comp.answers:12382 news.answers:45902

Archive-name: mpeg-faq/part1
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly
BEGIN -------------------- CUT HERE --------------------- 1/8

===========================================================================

~Subject: SECTION 0. - INTRO

        ====================================================
        THE MPEG-FAQ           [Version 4.0 - 07. June 1995]
        ====================================================
        PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY
        Inh. Frank Gadegast          Fon/Fax: +49 30 3128103

        phade@cs.tu-berlin.de
        http://www.cs.tu-berlin.de/~phade


It's the seventh publication of this file. Lots of information has been
changed (which has surely brought errors with it, see Murphy's Law).

This seventh addition is very different to the previous one, Version 3.2.

First:    The location of this file is:

          URL: ftp://ftp.cs.tu-berlin.de/pub/msdos/dos/graphics/mpegfa40.zip
               [130.149.17.7]

          My MPEG-related software and my DOS-ports of several
          programs can be found there too.

Second:   This FAQ is now in digest format (read below).

Third:    "The Internet MPEG CD-Rom" is there ! Our brilliant
          collecting of everything that belongs to MPEG. For only
          DM 49,90 ! Get it ! More than 600 MB of movies, songs,
          documentation and utilities ! Read below, about how to Order !

Fourth:   This FAQ is available now in HTML-format under the

                 URL=http://www.cs.tu-berlin.de/mpegfaq/

          So don't get irretated by some HTML-commands in this
          ASCII-text, that are just some pictures ...

Fifth:    This FAQ was and is copyrighted by the author and maintainer.
          Read the copyright information below.

Sixth:    The newest FAQ and other MPEG-related information and
          utilities for MSDOS and Sun's can always be loaded using
          WWW from:

                 URL=http://www.cs.tu-berlin.de/~phade

          And surely, there are more interesting things to find ;o)

Seventh:  New issues are: MPEG-1+, LAYER3-FAQ, MacAudioTools, WWW-pointer,
          MPEG hardware list


I add my comments in brackets [], lines (---- or ====) seperate the
chapters and questions.
 
Please try and find out more information yourself. I had enough to do by
getting and preparing this information. And only bother me with file-
request if its not possible for you to get it somewhere else !!!

If you want to contribute to this FAQ in any way, please email me
(probably by replying to this posting). My email address is:

  phade@cs.tu-berlin.de

Or send any additional information via fax or e-mail. The fax is only
reachable between Mo.-Fr. from 10.00-13.00 and from 15.00-18.30 german
time.

    KeyJ Phade (Frank Gadegast)


-------------------------------------------------------------------------------

~Subject: Disclaimer

            I HAVE NOTHING TO DO WITH THE NAMED COMPANIES, NO BUSINESS,
            IT'S JUST MY PERSONAL INTERESTED. COMPANIES ARE NAMED,
            BECAUSE THEY ARE THE FIRST, BRINGING REAL MULTIMEDIA TO THE
            WORLD. SURE I MAKE ADVERTS FOR THEM WITH THIS FAQ, BUT HOPE-
            FULLY YOU, AS A READER OF THIS FAQ, WILL FORCE THEM TO PRODUCE
            MORE AND BETTER PRODUCTS.

            MOST ADDITIONAL INFORMATION IS WRITTEN AS PERSONAL COMMENT,
            AND SHOULD NOT BE TAKEN AS PROOFEN FACTS. INFORMATION IS
            PRESENTED "AS IS", COULD BE OUT OF DATE AND CANNOT BE
            GARANTIED TO BE THE TRUTH. THIS INFOMATION COMES WITHOUT
            WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION OF
            WARRANTIES OF MERCHANTABILITY, FITNESS FOR PARTICULAR
            PURPOSE AND NON-INFRINGEMENT.

            UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, TORT, CONTRACT,
            OR OTHERWISE, SHALL THE AUTHOR BE LIABLE TO YOU OR ANY OTHER
            PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
            DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES
            FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR
            MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES.

            Frank Gadegast

-------------------------------------------------------------------------------

~Subject: Copyright information

            THIS COMPILATION OF INFORMATION IS COPYRIGHTED BY THE AUTHOR
            AND MAINTAINER, CURRENTLY FRANK GADEGAST. ANY NON-COMMERCIAL
            USE OF IT, OR PARTS OF IT IS ALLOWED, UNTIL THE USE OF IT IS
            REPORTED TO THE AUTHOR AND THE COMPILATION IS KEPT UNCHANGED
            ADDITONAL, IF PARTS OF IT ARE USED, INFORMATION HAS TO BE ADDED
            WITH THAT PART, WHO THE AUTHOR OF THAT PARTS IS, THAT IT BELONGS
            TO THE COMPLETE COMPILATION AND WHERE TO FIND THE COMPLETE
            COMPILATION.

            COMMERCIAL USE CAN BE GRANTED IN SPECIAL CIRCUMSTANCES, FEEL
            FREE TO ASK AND SEND A DESCRIPTION OF THE INTENDED USE, TO
            RECEIVE A CERTIFICATION.

            ANY NON-REPORTED OR NON-CERTIFIED COMMERCIAL USE OF THIS
            COMPILATION IS A VIOLATION OF GERMAN COPYRIGHT LAW !

            ANY RE-PUBLICATION OF INFORMATION IN THIS COMPILATION SHOULD
            BE REPORTED TO THE AUTHOR AND SHOULD TO BE QUOTED IN THE NEW
            PUBLICATION.

-------------------------------------------------------------------------------

~Subject: Digest format

It should be possible to read this FAQ with a threaded newsreader or emacs
in FAQ-mode to enable you, to jump from one question to another, because
this FAQ is organized as a digest.

You can move to the next question with the digest commands in gnus, rn or
other newsreaders, or with a regex search for ^~Subject or ^--.

-------------------------------------------------------------------------------

~Subject: What questions are getting answered in this FAQ ?

SECTION 0. - INTRO
    Disclaimer
    Copyright information
    Digest format
    What questions are getting answered in this FAQ ?
    SECTION 1. - WHAT IS MPEG-VIDEO/VIDEO
    What is MPEG ?
    What is MPEG-Audio then ?
    What is the Audio Layer 3 then ?
    What is MPEG-1+ ?
    What is MPEG-2 ?
    What happened at the MPEG - NY meeting ?
SECTION 2. - PROFESSIONAL SOFTWARE
    SUBSECTION - DOS
    MPEG Encoder by Xing
SUBSECTION - WINDOWS
    MPEG ARCADETM
    XingSound
    XingCD
SUBSECTION - UNIX
    Xing Distributed Media Architecture
    NVR Research Kit
    Demo of NVR Digital Media Development Kit
    How will I get the NVR-Software ?
SECTION 3. - FREE AVAILABLE SOFTWARE
SUBSECTION - DOS
    layr_100
    mpeg2ppm
    vmpeg
    cmpeg
    dmpeg
    secmpeg
    mpegstat
    enc11dos
    pvrg MPEG
SUBSECTION - Windows
    XingIt
    mpgaudio
SUBSECTION - WINDOWS-NT
    mpeg2ply
    mpegplay
SUBSECTION - OS/2
    mp
SUBSECTION - X-WINDOWS and UNIX
    Berkeley's MPEG Tools
    MPEG-1 Video Software Encoder
    MPEG Video Software Decoder
    MPEG Video Software Analyzer
    MPEG Blocks Analyzer
    MPEG Video Software Statistics Gatherer
    xmg
    mpegstat
    mplex
    xmplay
    xplayer
    xmpeg.tk
    mpeg2encode / mpeg2decode
    layr_100
    mpegaudio
    maplay
    Scanning MPEG's ...
    MPEG decoder...
    MPEGTool
    What is "SECMPEG" ?
    PVRG-MPEG Codec
    wdgt
SUBSECTION - VMS
    vms MPEG
SUBSECTION - MacIntosh
    Sparcle
    Qt2MPEG
    Audio on Macintosh ?!
SUBSECTION - Atari
SUBSECTION - Amiga
    MPEG2DCTV
SUBSECTION - NeXT
    MPEG_Play.app
    mpegnext
SUBSECTION - SGI
SECTION 4. - MPEG-RELATED HARDWARE
    MPEG audio Layer-3
    Video-Maker
    Some MPEG chips
    Optibase
    ReelMagic
    Cinerama
    XingIt!-card
    MPEG-decompression hardware list
    Amiga CD32
SECTION 5. - MAILBOX-ACCESS
    Genoabox
    Xing Technologies BBS and fax
SECTION 6. - FTP-ACCESS
    FTP-ACCESS - Overview
    MPEG-2 validation bitstreams
    Audio streams and utils
    Accessing Aminet
    Where will I find test-material for MPEG-encoders ?
SECTION 7. - WWW-ACCESS
    Where is the WWW-home of this FAQ ?
    An Interactive Explanation on the Web ?
    Where is the WWW-demo of "The Internet MPEG CD-Rom" ?
    Which archive is mostly related to MPEG-Audio ?
    What's with Bryan Woodworth ftp-area ?
    Rock'n'Roll stored in MPEG on the Web ?
    Where can I find space movies coded in MPEG ?
    Movies on Web-site
    Where can I find fractal movies coded in MPEG ?
    Is qt2mpeg on the Web ?
    What are other good URL's ?
SECTION 8. - MAIL ORDER
    The Internet MPEG CD-Rom
    Conversion, WWW and CD-Rom production service
    How can I order information from C-CUBE ?
SECTION 9. - ADDITIONAL INFORMATION
    What are the MPEG standard documents ?
    So, the Xing decoder is cheating, right ?
    What is Aware Inc. doing ?
    Will MPEG be included in QuickTime ?
    What's about MPEG-2 software ?
    What about good MPEG Hardware encoders (Optivision) ?
    What's about CD-I ?
    What is the PCMotion Player ?
    What is the MPEG-2 ISO number ?
    Some papers about MPEG-audio
    Where can I find more documents about what Berkeley is doing ?
    Is there a book about MPEG ?
    Who are CD-I producers ?
    Where can I get VideoCD and CD-I coding ?
    Where can I do MPEG encoding ?
    What the problem with all these file extensions for MPEG-files ?
    How can I do RTP encapsulation of MPEG1/MPEG2 ?
    Wo kann ich den MPEG-standard bestellen ?
SECTION 10. - WHERE TO FIND MORE INFOS
    What newsgroups discuss MPEG ?
    How can 'archie' help me ?
SECTION 11. - QUESTIONS

===========================================================================

~Subject: SECTION 1. - WHAT IS MPEG-VIDEO/VIDEO

-------------------------------------------------------------------------------

~Subject: What is MPEG ?

From comp.compression Mon Oct 19 15:38:38 1992
Sender: news@chorus.chorus.fr
Author: Mark Adler <madler@cco.caltech.edu>

[71] Introduction to MPEG (long)
       What is MPEG?
       Does it have anything to do with JPEG?
       Then what's JBIG and MHEG?
       What has MPEG accomplished?
       So how does MPEG I work?
       What about the audio compression?
       So how much does it compress?
       What's phase II?
       When will all this be finished?
       How do I join MPEG?
       How do I get the documents, like the MPEG I draft?

[ There is no newer version of this part so far. Whoever wants to update ]
[ this description, should do the job and send it over.                  ]

Written by Mark Adler <madler@cco.caltech.edu>.

Q. What is MPEG?
A. MPEG is a group of people that meet under ISO (the International
   Standards Organization) to generate standards for digital video
   (sequences of images in time) and audio compression.  In particular,
   they define a compressed bit stream, which implicitly defines a
   decompressor.  However, the compression algorithms are up to the
   individual manufacturers, and that is where proprietary advantage
   is obtained within the scope of a publicly available international
   standard.  MPEG meets roughly four times a year for roughly a week
   each time.  In between meetings, a great deal of work is done by
   the members, so it doesn't all happen at the meetings.  The work
   is organized and planned at the meetings.

Q. So what does MPEG stand for?
A. Moving Pictures Experts Group.

Q. Does it have anything to do with JPEG?
A. Well, it sounds the same, and they are part of the same subcommittee
   of ISO along with JBIG and MHEG, and they usually meet at the same
   place at the same time.  However, they are different sets of people
   with few or no common individual members, and they have different
   charters and requirements.  JPEG is for still image compression.

Q. Then what's JBIG and MHEG?
A. Sorry I mentioned them. Ok, I'll simply say that JBIG is for binary
   image compression (like faxes), and MHEG is for multi-media data
   standards (like integrating stills, video, audio, text, etc.).
   For an introduction to JBIG, see question 74 below.

Q. Ok, I'll stick to MPEG.  What has MPEG accomplished?
A. So far (as of January 1992), they have completed the "Committee
   Draft" of MPEG phase I, colloquially called MPEG I.  It defines
   a bit stream for compressed video and audio optimized to fit into
   a bandwidth (data rate) of 1.5 Mbits/s.  This rate is special
   because it is the data rate of (uncompressed) audio CD's and DAT's.
   The draft is in three parts, video, audio, and systems, where the
   last part gives the integration of the audio and video streams
   with the proper timestamping to allow synchronization of the two.
   They have also gotten well into MPEG phase II, whose task is to
   define a bitstream for video and audio coded at around 3 to 10
   Mbits/s.

Q. So how does MPEG I work?
A. First off, it starts with a relatively low resolution video
   sequence (possibly decimated from the original) of about 352 by
   240 frames by 30 frames/s (US--different numbers for Europe),
   but original high (CD) quality audio.  The images are in color,
   but converted to YUV space, and the two chrominance channels
   (U and V) are decimated further to 176 by 120 pixels.  It turns
   out that you can get away with a lot less resolution in those
   channels and not notice it, at least in "natural" (not computer
   generated) images.

<IMG SRC="yuv411.gif">

<IMG SRC="yuv422.gif">

<IMG SRC="yuv444.gif">

   The basic scheme is to predict motion from frame to frame in the
   temporal direction, and then to use DCT's (discrete cosine
   transforms) to organize the redundancy in the spatial directions.
   The DCT's are done on 8x8 blocks, and the motion prediction is
   done in the luminance (Y) channel on 16x16 blocks.  In other words,
   given the 16x16 block in the current frame that you are trying to
   code, you look for a close match to that block in a previous or
   future frame (there are backward prediction modes where later
   frames are sent first to allow interpolating between frames).
   The DCT coefficients (of either the actual data, or the difference
   between this block and the close match) are "quantized", which
   means that you divide them by some value to drop bits off the
   bottom end.  Hopefully, many of the coefficients will then end up
   being zero.  The quantization can change for every "macroblock"
   (a macroblock is 16x16 of Y and the corresponding 8x8's in both
   U and V).  The results of all of this, which include the DCT
   coefficients, the motion vectors, and the quantization parameters
   (and other stuff) is Huffman coded using fixed tables.  The DCT
   coefficients have a special Huffman table that is "two-dimensional"
   in that one code specifies a run-length of zeros and the non-zero
   value that ended the run.  Also, the motion vectors and the DC
   DCT components are DPCM (subtracted from the last one) coded.

Q. So is each frame predicted from the last frame?
A. No.  The scheme is a little more complicated than that.  There are
   three types of coded frames.  There are "I" or intra frames.  They
   are simply a frame coded as a still image, not using any past
   history.  You have to start somewhere.  Then there are "P" or
   predicted frames.  They are predicted from the most recently
   reconstructed I or P frame.  (I'm describing this from the point
   of view of the decompressor.)  Each macroblock in a P frame can
   either come with a vector and difference DCT coefficients for a
   close match in the last I or P, or it can just be "intra" coded
   (like in the I frames) if there was no good match.

   Lastly, there are "B" or bidirectional frames.  They are predicted
   from the closest two I or P frames, one in the past and one in the
   future.  You search for matching blocks in those frames, and try
   three different things to see which works best.  (Now I have the
   point of view of the compressor, just to confuse you.)  You try using
   the forward vector, the backward vector, and you try averaging the
   two blocks from the future and past frames, and subtracting that from
   the block being coded.  If none of those work well, you can intra-
   code the block.

   The sequence of decoded frames usually goes like:

   IBBPBBPBBPBBIBBPBBPB...

   Where there are 12 frames from I to I (for US and Japan anyway.)
   This is based on a random access requirement that you need a
   starting point at least once every 0.4 seconds or so.  The ratio
   of P's to B's is based on experience.

   Of course, for the decoder to work, you have to send that first
   P *before* the first two B's, so the compressed data stream ends
   up looking like:

   0xx312645...

   where those are frame numbers.  xx might be nothing (if this is
   the true starting point), or it might be the B's of frames -2 and
   -1 if we're in the middle of the stream somewhere.

   You have to decode the I, then decode the P, keep both of those
   in memory, and then decode the two B's.  You probably display the
   I while you're decoding the P, and display the B's as you're
   decoding them, and then display the P as you're decoding the next
   P, and so on.

Q. You've got to be kidding.
A. No, really!

Q. Hmm.  Where did they get 352x240?
A. That derives from the CCIR-601 digital television standard which
   is used by professional digital video equipment.  It is (in the US)
   720 by 243 by 60 fields (not frames) per second, where the fields
   are interlaced when displayed.  (It is important to note though
   that fields are actually acquired and displayed a 60th of a second
   apart.)  The chrominance channels are 360 by 243 by 60 fields a
   second, again interlaced.  This degree of chrominance decimation
   (2:1 in the horizontal direction) is called 4:2:2.  The source
   input format for MPEG I, called SIF, is CCIR-601 decimated by 2:1
   in the horizontal direction, 2:1 in the time direction, and an
   additional 2:1 in the chrominance vertical direction.  And some
   lines are cut off to make sure things divide by 8 or 16 where
   needed.

Q. What if I'm in Europe?
A. For 50 Hz display standards (PAL, SECAM) change the number of lines
   in a field from 243 or 240 to 288, and change the display rate to
   50 fields/s or 25 frames/s.  Similarly, change the 120 lines in
   the decimated chrominance channels to 144 lines.  Since 288*50 is
   exactly equal to 240*60, the two formats have the same source data
   rate.

Q. You didn't mention anything about the audio compression.
A. Oh, right.  Well, I don't know as much about the audio compression.
   Basically they use very carefully developed psychoacoustic models
   derived from experiments with the best obtainable listeners to
   pick out pieces of the sound that you can't hear.  There are what
   are called "masking" effects where, for example, a large component
   at one frequency will prevent you from hearing lower energy parts
   at nearby frequencies, where the relative energy vs. frequency
   that is masked is described by some empirical curve.  There are
   similar temporal masking effects, as well as some more complicated
   interactions where a temporal effect can unmask a frequency, and
   vice-versa.

   The sound is broken up into spectral chunks with a hybrid scheme
   that combines sine transforms with subband transforms, and the
   psychoacoustic model written in terms of those chunks.  Whatever
   can be removed or reduced in precision is, and the remainder is
   sent.  It's a little more complicated than that, since the bits
   have to be allocated across the bands.  And, of course, what is
   sent is entropy coded.

Q. So how much does it compress?
A. As I mentioned before, audio CD data rates are about 1.5 Mbits/s.
   You can compress the same stereo program down to 256 Kbits/s with
   no loss in discernable quality.  (So they say.  For the most part
   it's true, but every once in a while a weird thing might happen
   that you'll notice.  However the effect is very small, and it takes
   a listener trained to notice these particular types of effects.)
   That's about 6:1 compression.  So, a CD MPEG I stream would have
   about 1.25 MBits/s left for video.  The number I usually see though
   is 1.15 MBits/s (maybe you need the rest for the system data
   stream).  You can then calculate the video compression ratio from
   the numbers here to be about 26:1.  If you step back and think
   about that, it's little short of a miracle.  Of course, it's lossy
   compression, but it can be pretty hard sometimes to see the loss,
   if you're comparing the SIF original to the SIF decompressed.  There
   is, however, a very noticeable loss if you're coming from CCIR-601
   and have to decimate to SIF, but that's another matter.  I'm not
   counting that in the 26:1.

   The standard also provides for other bit rates ranging from 32Kbits/s
   for a single channel, up to 448 Kbits/s for stereo.

Q. What's phase II?
A. As I said, there is a considerable loss of quality in going from
   CCIR-601 to SIF resolution.  For entertainment video, it's simply
   not acceptable.  You want to use more bits and code all or almost
   all the CCIR-601 data.  From subjective testing at the Japan
   meeting in November 1991, it seems that 4 MBits/s can give very
   good quality compared to the original CCIR-601 material.  The
   objective of phase II is to define a bit stream optimized for these
   resolutions and bit rates.

Q. Why not just scale up what you're doing with MPEG I?
A. The main difficulty is the interlacing.  The simplest way to extend
   MPEG I to interlaced material is to put the fields together into
   frames (720x486x30/s).  This results in bad motion artifacts that
   stem from the fact that moving objects are in different places
   in the two fields, and so don't line up in the frames.  Compressing
   and decompressing without taking that into account somehow tends to
   muddle the objects in the two different fields.

   The other thing you might try is to code the even and odd field
   streams separately.  This avoids the motion artifacts, but as you
   might imagine, doesn't get very good compression since you are not
   using the redundancy between the even and odd fields where there
   is not much motion (which is typically most of image).

   Or you can code it as a single stream of fields.  Or you can
   interpolate lines.  Or, etc. etc.  There are many things you can
   try, and the point of MPEG II is to figure out what works well.
   MPEG II is not limited to consider only derivations of MPEG I.
   There were several non-MPEG I-like schemes in the competition in
   November, and some aspects of those algorithms may or may not
   make it into the final standard for entertainment video compression.

Q. So what works?
A. Basically, derivations of MPEG I worked quite well, with one that
   used wavelet subband coding instead of DCT's that also worked very
   well.  Also among the worked-very-well's was a scheme that did not
   use B frames at all, just I and P's.  All of them, except maybe one,
   did some sort of adaptive frame/field coding, where a decision is
   made on a macroblock basis as to whether to code that one as one
   frame macroblock or as two field macroblocks.  Some other aspects
   are how to code I-frames--some suggest predicting the even field
   from the odd field.  Or you can predict evens from evens and odds
   or odds from evens and odds or any field from any other field, etc.

Q. So what works?
A. Ok, we're not really sure what works best yet.  The next step is
   to define a "test model" to start from, that incorporates most of
   the salient features of the worked-very-well proposals in a
   simple way.  Then experiments will be done on that test model,
   making a mod at a time, and seeing what makes it better and what
   makes it worse.  Example experiments are, B's or no B's, DCT vs.
   wavelets, various field prediction modes, etc.  The requirements,
   such as implementation cost, quality, random access, etc. will all
   feed into this process as well.

Q. When will all this be finished?
A. I don't know.  I'd have to hope in about a year or less.

Q. How do I join MPEG?
A. You don't join MPEG.  You have to participate in ISO as part of a
   national delegation.  How you get to be part of the national
   delegation is up to each nation.  I only know the U.S., where you
   have to attend the corresponding ANSI meetings to be able to
   attend the ISO meetings.  Your company or institution has to be
   willing to sink some bucks into travel since, naturally, these
   meetings are held all over the world.  (For example, Paris,
   Santa Clara, Kurihama Japan, Singapore, Haifa Israel, Rio de
   Janeiro, London, etc.)

Q. Well, then how do I get the documents, like the MPEG I draft?
A. MPEG is a draft ISO standard. It's exact name is ISO CD 11172.
   The draft consists of three parts: System, Video, and Audio. The
   System part (11172-1) deals with synchronization and multiplexing
   of audio-visual information, while the Video (11172-2) and Audio
   part (11172-3) address the video and the audio compression techniques
   respectively.

   You may order it from your national standards body (e.g. ANSI in
   the USA) or buy it from companies like
     OMNICOM
     phone +44 438 742424
     FAX +44 438 740154

-------------------------------------------------------------------------------

~Subject: What is MPEG-Audio then ?

From: "Harald Popp" <POPP@iis.fhg.de>
From: mortenh@oslonett.no
Date:          Fri, 25 Mar 1994 19:09:06 +0100

Q.      What is MPEG?
A.      MPEG is an ISO committee that proposes standards for 
        compression of Audio and Video. MPEG deals with 3 issues: 
        Video, Audio, and System (the combination of the two into one 
        stream). You can find more info on the MPEG committee in other 
        parts of this document. 
        
Q.      I've heard about MPEG Video. So this is the same compression 
        applied to audio?
A.      Definitely no. The eye and the ear... even if they are only a 
        few centimeters apart, works very differently... The ear has 
        a much higher dynamic range and resolution. It can pick out 
        more details but it is "slower" than the eye.
        The MPEG committee chose to recommend 3 compression methods 
        and named them Audio Layer-1, Layer-2, and Layer-3. 

Q.      What does it mean exactly?
A.      MPEG-1, IS 11172-3, describes the compression of audio 
        signals using high performance perceptual coding schemes. 
        It specifies a family of three audio coding schemes, 
        simply called Layer-1,-2,-3, with increasing encoder 
        complexity and performance (sound quality per bitrate). 
        The three codecs are compatible in a hierarchical 
        way, i.e. a Layer-N decoder is able to decode bitstream data 
        encoded in Layer-N and all Layers below N (e.g., a Layer-3 
        decoder may accept Layer-1,-2 and -3, whereas a Layer-2 
        decoder may accept only Layer-1 and -2.)

Q.      So we have a family of three audio coding schemes. What does 
        the MPEG standard define, exactly?
A.      For each Layer, the standard specifies the bitstream format 
        and the decoder. It does *not* specify the encoder to 
        allow for future improvements, but an informative chapter 
        gives an example for an encoder for each Layer.    

Q.      What have the three audio Layers in common?
A.      All Layers use the same basic structure. The coding scheme can 
        be described as "perceptual noise shaping" or "perceptual 
        subband / transform coding". 
        The encoder analyzes the spectral components of the audio 
        signal by calculating a filterbank or transform and applies 
        a psychoacoustic model to estimate the just noticeable 
        noise-level. In its quantization and coding stage, the 
        encoder tries to allocate the available number of data 
        bits in a way to meet both the bitrate and masking 
        requirements.
        The decoder is much less complex. Its only task is to 
        synthesize an audio signal out of the coded spectral 
        components. 
        All Layers use the same analysis filterbank (polyphase with 
        32 subbands). Layer-3 adds a MDCT transform to increase 
        the frequency resolution.
        All Layers use the same "header information" in their 
        bitstream, to support the hierarchical structure of the 
        standard.   
        All Layers use a bitstream structure that contains parts that 
        are more sensitive to biterrors ("header", "bit 
        allocation", "scalefactors", "side information") and parts 
        that are less sensitive ("data of spectral components").  
        All Layers may use 32, 44.1 or 48 kHz sampling frequency.
        All Layers are allowed to work with similar bitrates:
        Layer-1: from 32 kbps to 448 kbps
        Layer-2: from 32 kbps to 384 kbps
        Layer-3: from 32 kbps to 320 kbps

Q.      What are the main differences between the three Layers, from a 
        global view?
A.      From Layer-1 to Layer-3,
        complexity increases (mainly true for the encoder),
        overall codec delay increases, and
        performance increases (sound quality per bitrate).

Q.      Which Layer should I use for my application?
A.      Good Question. Of course, it depends on all your requirements. 
        But as a first approach, you should consider the available 
        bitrate of your application as the Layers have been 
        designed to support certain areas of bitrates most 
        efficiently, i.e. with a minimum drop of sound quality.   
        Let us look a little closer at the strong domains of each 
        Layer.    
        
        Layer-1: Its ISO target bitrate is 192 kbps per audio 
        channel.
        Layer-1 is a simplified version of Layer-2. It is most useful 
        for bitrates around the "high" bitrates around or above 
        192 kbps. A version of Layer-1 is used as "PASC" with the 
        DCC recorder.

        Layer-2: Its ISO target bitrate is 128 kbps per audio 
        channel.
        Layer-2 is identical with MUSICAM. It has been designed as 
        trade-off between sound quality per bitrate and encoder 
        complexity. It is most useful for bitrates around the 
        "medium" bitrates of 128 or even 96 kbps per audio 
        channel. The DAB (EU 147) proponents have decided to use 
        Layer-2 in the future Digital Audio Broadcasting network.   
   
        Layer-3: Its ISO target bitrate is 64 kbps per audio channel. 
        Layer-3 merges the best ideas of MUSICAM and ASPEC. It has 
        been designed for best performance at "low" bitrates 
        around 64 kbps or even below. The Layer-3 format specifies 
        a set of advanced features that all address one goal: to 
        preserve as much sound quality as possible even at rather 
        low bitrates. Today, Layer-3 is already in use in various 
        telecommunication networks (ISDN, satellite links, and so 
        on) and speech announcement systems. 

Q.      So how does MPEG audio work?
A.      Well, first you need to know how sound is stored in a 
        computer. Sound is pressure differences in air. When picked up 
        by a microphone and fed through an amplifier this becomes 
        voltage levels. The voltage is sampled by the computer a 
        number of times per second. For CD audio quality you need to 
        sample 44100 times per second and each sample has a resolution 
        of 16 bits. In stereo this gives you 1,4Mbit per second
        and you can probably see the need for compression.
 
        To compress audio MPEG tries to remove the irrelevant parts 
        of the signal and the redundant parts of the signal. Parts of 
        the sound that we do not hear can be thrown away. To do this 
        MPEG Audio uses psychoacoustic principles.
 
Q.      Tell me more about sound quality. How good is MPEG audio 
        compression? And how do you assess that?
A.      Today, there is no alternative to expensive listening tests. 
        During the ISO-MPEG-1 process, 3 international listening tests 
        have been performed, with a lot of trained listeners, 
        supervised by Swedish Radio. They took place in 7.90, 3.91 
        and 11.91. Another international listening test was 
        performed by CCIR, now ITU-R, in 92.      
        All these tests used the "triple stimulus, hidden reference" 
        method and the so-called CCIR impairment scale to assess the 
        audio quality. 
        The listening sequence is "ABC", with A = original, BC = pair 
        of original / coded signal with random sequence, and the 
        listener has to evaluate both B and C with a number 
        between 1.0 and 5.0. The meaning of these values is:
        5.0 = transparent (this should be the original signal)
        4.0 = perceptible, but not annoying (first differences 
              noticable)
        3.0 = slightly annoying   
        2.0 = annoying
        1.0 = very annoying
        With perceptual codecs (like MPEG audio), all traditional 
        parameters (like SNR, THD+N, bandwidth) are especially 
        useless. 

        Fraunhofer-IIS (among others) works on objective quality 
        assessment tools, like the NMR meter (Noise-to-Mask-Ratio), 
        too. If you need more informations about NMR, please 
        contact nmr@iis.fhg.de

Q.      Now that I know how to assess quality, come on, tell me the 
        results of these tests.
A.      Well, for details you should study one of those AES papers 
        listed below. One main result is that for low bitrates (60 
        or 64 kbps per channel, i.e. a compression ratio of around 
        12:1), Layer-2 scored between 2.1 and 2.6, whereas Layer-3 
        scored between 3.6 and 3.8. 
        This is a significant increase in sound quality, indeed! 
        Furthermore, the selection process for critical sound material 
        showed that it was rather difficult to find worst-case 
        material for Layer-3 whereas it was not so hard to find 
        such items for Layer-2.  
        For medium and high bitrates (120 kbps or more per channel), 
        Layer-2 and Layer-3 scored rather similar, i.e. even 
        trained listeners found it difficult to detect differences 
        between original and reconstructed signal.
 
Q.      So how does MPEG achieve this compression ratio?
A.      Well, with audio you basically have two alternatives. Either 
        you sample less often or you sample with less resolution (less 
        than 16 bit per sample). If you want quality you can't do much 
        with the sample frequency. Humans can hear sounds with 
        frequencies from about 20Hz to 20kHz. According to the Nyquist 
        theorem you must sample at least two times the highest 
        frequency you want to reproduce. Allowing for imperfect 
        filters, a 44,1kHz sampling rate is a fair minimum. So
        you either set out to prove the Nyquist theorem is wrong or 
        go to work on reducing the resolution. The MPEG committee 
        chose the latter.
        Now, the real reason for using 16 bits is to get a good 
        signal-to-noise (s/n) ratio. The noise we're talking 
        about here is quantization noise from the digitizing 
        process. For each bit you add, you get 6dB
        better s/n. (To the ear, 6dBu corresponds to a doubling of 
        the sound level.) CD-audio achieves about 90dB s/n. This 
        matches the dynamic range of the ear fairly well. That is, you 
        will not hear any noise coming from the system itself (well, 
        there is still some people arguing about that, but lets not 
        worry about them for the moment).
        So what happens when you sample to 8 bit resolution? You get 
        a very noticeable noise floor in your recording. You can 
        easily hear this in silent moments in the music or between 
        words or sentences if your recording is a human voice. 
        Waitaminnit. You don't notice any noise in loud passages, 
        right? This is the masking effect and is the key to MPEG Audio 
        coding. Stuff like the masking effect belongs to a science 
        called psycho-acoustics that deals with the way the human 
        brain perceives sound.
        And MPEG uses psychoacoustic principles when it does its 
        thing. 
        
Q.      Explain this masking effect.
A.      OK, say you have a strong tone with a frequency of 1000Hz. 
        You also have a tone nearby of say 1100Hz. This second tone is 
        18 dB lower. You are not going to hear this second tone. It is 
        completely masked by the first 1000Hz tone. As a matter of 
        fact, any relatively weak sounds near a strong sound is 
        masked. If you introduce another tone at 2000Hz also 18 dB 
        below the first 1000Hz tone, you will hear this.
        You will have to turn down the 2000Hz tone to something like 
        45 dB below the 1000Hz tone before it will be masked by the 
        first tone. So the further you get from a sound the less 
        masking effect it has.
        The masking effect means that you can raise the noise floor 
        around a strong sound because the noise will be masked anyway. 
        And raising the noise floor is the same as using less bits 
        and using less bits is the same as compression. Do you get it?
 
Q.      I don't get it.
A.      Well, let me try to explain how the MPEG Audio Layer-2 encoder 
        goes about its thing. It divides the frequency spectrum (20Hz 
        to 20kHz) into 32 subbands. Each subband holds a little slice 
        of the audio spectrum. Say, in the upper region of subband 8, 
        a 6500Hz tone with a level of 60dB is present. OK, the 
        coder calculates the masking effect of this sound and finds 
        that there is a masking threshold for the entire 8th
        subband (all sounds w. a frequency...) 35dB below this tone. 
        The acceptable s/n ratio is thus 60 - 35 = 25 dB. The equals 4 
        bit resolution. In addition there are masking effects on band 
        9-13 and on band 5-7, the effect decreasing with the distance 
        from band 8.
        In a real-life situation you have sounds in most bands and the 
        masking effects are additive. In addition the coder considers 
        the sensitivity of the ear for various frequencies. The ear 
        is a lot less sensitive in the high and low frequencies. Peak 
        sensivity is around 2 - 4kHz, the same region that the human 
        voice occupies. 
        The subbands should match the ear, that is each subband should
        consist of frequencies that have the same psychoacoustic 
        properties. In MPEG Layer 2, each subband is 750Hz wide 
        (with 48 kHz sampling frequency). It would have been better if
        the subbands were narrower in the low frequency range and 
        wider in the high frequency range. That is the trade-off 
        Layer-2 took in favour of a simpler approach.        
        Layer-3 has a much higher frequency resolution (18 times 
        more) - and that is one of the reasons why Layer-3 has a much 
        better low bitrate performance than Layer-2.                
        But there is more to it. I have explained concurrent masking, 
        but the masking effect also occurs before and after a strong 
        sound (pre- and postmasking).
 
Q.      Before?
A.      Yes, if there is a significant (30 - 40dB ) shift in level. 
        The reason is believed to be that the brain needs some 
        processing time. Premasking is only about 2 to 5 ms. The 
        postmasking can be up till 100ms.
        Other bit-reduction techniques involve considering tonal and 
        non-tonal components of the sound. For a stereo signal you 
        may have a lot of redundancy between channels. All MPEG 
        Layers may exploit these stereo effects by using a "joint-
        stereo" mode, with a most flexible approach for Layer-3.      
        Furthermore, only Layer-3 further reduces the redundancy 
        by applying huffmann coding. 
        
Q.      What are the downside?
A.      The coder calculates masking effects by an iterative process 
        until it runs out of time. It is up to the implementor to 
        spend bits in the least obtrusive fashion.
        For Layer 2 and Layer 3, the encoder works on 24 ms of sound 
        (with 1152 sample, and fs = 48 kHz) at a time. For some 
        material, the time-window can be a problem. This is 
        normally in a situation with transients where there are large
        differences in sound level over the 24 ms. The masking is 
        calculated on the strongest sound and the weak parts will 
        drown in quantization noise. This is perceived as a "noise-
        echo" by the ear. Layer 3 addresses this problem 
        specifically by using a smaller analysis window (4 ms), if 
        the encoder encounters an "attack" situation. 
        
Q.      Tell me about the complexity. What are the hardware demands? 

A.      Alright. First, we have to separate between decoder and 
        encoder. 
        Remember: the MPEG coding is done asymmetrical, with a much 
        larger workload on the encoder than on the decoder.
        For a stereo decoder, variuos real-time implementations exist 
        for Layer-2 and Layer-3. They are either based on single-DSP 
        solutions or on dedicated MPEG audio decoder chips. So
        you need not worry about decoder complexity.
        For a stereo Layer-2-encoder, various DSP based solutions with 
        one or more DSPs exist (with different quality, also).
        For a stereo Layer-3-encoder achieving ISO reference quality, 
        the current real-time implementations use two DSP32C and 
        two DSP56002. 
        
Q.      How many audio channels?
A.      MPEG-1 allows for two audio channels. These can be either 
        single (mono), dual (two mono channels), stereo or 
        joint stereo (intensity stereo (Layer-2 and Layer-3) or m/s-
        stereo (Layer-3 only)). 
        In normal (l/r) stereo one channel carries the left audio 
        signal and one channel carries the right audio signal. In
        m/s stereo one channel carries the sum signal (l+r) and the 
        other the difference (l-r) signal. In intensity stereo the 
        high frequency part of the signal (above 2kHz) is combined. 
        The stereo image is preserved but only the temporal envelope 
        is transmitted.
        In addition MPEG allows for pre-emphasis, copyright marks and
        original/copy marks. MPEG-2 allows for several channels in 
        the same stream.
 
Q.      What about the audio codec delay?
A.      Well, the standard gives some figures of the theoretical 
        minimum delay:
        Layer-1: 19 ms (<50 ms)
        Layer-2: 35 ms (100 ms)
        Layer-3: 59 ms (150 ms)
        The practical values are significantly above that. As they 
        depend on the implementation, exact figures are hard to 
        give. So the figures in brackets are just rough thumb 
        values.    
        Yes, for some applications, a very short delay is of critical 
        importance. E.g. in a feedback link, a reporter can only talk 
        intelligibly if the overall delay is below around 10 ms. 
        If broadcasters want to apply MPEG audio coding, they have to 
        use "N-1" switches in the studio to overcome this problem 
        (or appropriate echo-cancellers) - or they have to forget 
        about MPEG at all. 
        But with most applications, these figures are small enough to 
        present no extra problem. At least, if one can accept a Layer-
        2 delay, one can most likely also accept the higher Layer-3 
        delay.

Q.     OK, I am hooked on! Where can I find more technical 
       informations about MPEG audio coding, especially about Layer-
       3?   
A.     Well, there is a variety of AES papers, e.g.

       K. Brandenburg, G. Stoll, ...: "The ISO/MPEG-Audio Codec: A 
       Generic Standard for Coding of High Quality Digital Audio", 
       92nd AES, Vienna 1992, pp.3336
   
       E. Eberlein, H. Popp, ...: "Layer-3, a Flexible Coding 
       Standard",    94th AES, Berlin 93, pp.3493   
   
       K. Brandenburg, G. Zimmer, ...: "Variable Data-Rate Recording 
       on a PC Using MPEG-Audio Layer-3", 95th AES, New York 93
   
       B. Grill, J. Herre,... : "Improved MPEG-2 Audio Multi-Channel 
       Encoding", 96th AES, Amsterdam 94

       And for further informations, please contact layer3@iis.fhg.de

Q.     Where can I get more details about MPEG audio?
A.     Still more details? No shit. You can get the full ISO spec 
       from Omnicom. The specs do a fairly good job of obscuring 
       exactly how these things are supposed to work... Jokes aside, 
       there are no description of the coder in the specs. The specs 
       describes in great detail the bitstream and suggests 
       psychoacoustic models. 
 
Originally written by Morten Hjerde <100034,663@compuserve.com>, 
modified and updated by Harald Popp (layer3@iis.fhg.de).

Harald Popp
Audio & Multimedia ("Music is the *BEST*" - F. Zappa)
Fraunhofer-IIS-A, Weichselgarten 3, D-91058 Erlangen, Germany
Phone: +49-9131-776-340
Fax:   +49-9131-776-399
email: popp@iis.fhg.de

-------------------------------------------------------------------------------

~Subject: What is the Audio Layer 3 then ?

Informations about MPEG Audio Layer-3

Version 1.50 - 1. 95

This text is organized as a kind of Mini-FAQ (Frequently Asked
Questions). It covers several topics:

1. ISO-MPEG Standard
2. MPEG Audio Codec Family ("Layer 1, 2, 3")
3. Applications
4. Products 
5. Support by Fraunhofer-IIS
6. Shareware Information

For further comments and questions regarding Layer-3, please contact:
- layer3@iis.fhg.de

For further informations about MPEG, you may also like to contact:
- phade@cs.tu-berlin.de


1. ISO-MPEG Standard

Q: What is MPEG, exactly?
A: MPEG is the "Moving Picture Experts Group", working under the joint 
   direction of the International Standards Organization (ISO) and the 
   International Electro-Technical Commission (IEC). This group works on 
   standards for the coding of moving pictures and associated audio.
   
Q: What is the status of MPEG's work, then? What about MPEG-1, -2, and so 
   on?
A: MPEG approaches the growing need for multimedia standards step-by-
   step. Today, three "phases" are defined:

MPEG-1:"Coding of Moving Pictures and Associated Audio for 
Digital Storage Media at up to about 1.5 MBit/s"  
Status: International Standard IS-11172, completed in 10.92

MPEG-2:"Generic Coding of Moving Pictures and Associated 
Audio"
Status: International Standard IS-13818, completed in 11.94

MPEG-3: does no longer exist (has been merged into MPEG-2)

MPEG-4: "Very Low Bitrate Audio-Visual Coding"
Status: Call for Proposals first deadline 1. 10. 95

Q: MPEG-1 and MPEG-2 are  ready-for-use. How do the standards look like?
A: Both standards consist of 4 main parts.
   The structure is the same for MPEG-1 and MPEG-2.
   -1: System describes synchronization and multiplexing of video and audio
   -2: Video describes compression of video signals
   -3: Audio describes compression of audio signals 
   -4: Compliance Testing describes procedures for determining the characteristics
   of coded bitstreams and the decoding process and for testing compliance with
   the requirements stated in the other parts.

Q: How do I get the MPEG documents?
A: You order it from your national standards body.
   E.g., in Germany, please contact:
   DIN-Beuth Verlag, Auslandsnormen
   Mrs. Niehoff, Burggrafenstr. 6, D-10772 Berlin, Germany
   Phone: +49-30-2601-2757, Fax: +49-30-2601-1231


2. MPEG Audio Codec Family ("Layer 1, 2, 3")
   
Q: Talking about MPEG audio coding, I heard a lot about "Layer 1, 2 and 3". 
   What does it mean, exactly?   
A: MPEG describes the compression of audio signals using high performance 
   perceptual coding schemes. It specifies a family of three audio coding 
   schemes, simply called Layer-1,-2,-3, with increasing encoder complexity 
   and performance (sound quality per bitrate) from 1 to 3. 
   The three codecs are compatible in a hierarchical way, i.e. a Layer-N 
   decoder is able to decode bitstream data encoded in Layer-N and all Layers 
   below N (e.g., a Layer-3 decoder may accept Layer-1,-2 and -3, whereas a 
   Layer-2 decoder may accept only Layer-1 and -2.)

Q: So we have a family of three audio coding schemes. What does the MPEG 
   standard define, exactly?
A: For each Layer, the standard specifies the bitstream format and the 
   decoder. To allow for future improvements, it does *not* specify the 
   encoder, but an informative chapter gives an example for an encoder for 
   each Layer.    

Q: What have the three audio Layers in common?
A: All Layers use the same basic structure. The coding scheme can be 
   described as "perceptual noise shaping" or "perceptual subband / transform 
   coding". 
   The encoder analyzes the spectral components of the audio signal by 
   calculating a filterbank or transform and applies a psychoacoustic model 
   to estimate the just noticeable noise-level. In its quantization and coding 
   stage, the encoder tries to allocate the available number of data bits in a 
   way to meet both the bitrate and masking requirements.
   The decoder is much less complex. Its only task is to synthesize an audio 
   signal out of the coded spectral components.
   All Layers use the same analysis filterbank (polyphase with 32 subbands). 
   Layer-3 adds a MDCT transform to increase the frequency resolution.
   All Layers use the same "header information" in their bitstream, to support 
   the hierarchical structure of the standard.
   All Layers have a similar sensitivity to biterrors. They use a bitstream 
   structure that contains parts that are more sensitive to biterrors ("header", 
   "bit allocation", "scalefactors", "side information") and parts that 
   are less sensitive ("data of spectral components").
   All Layers support the insertion of programm-associated information 
   ("ancillary data") into their audio data bitstream.
   All Layers may use 32, 44.1 or 48 kHz sampling frequency.
   All Layers are allowed to work with similar bitrates:
   Layer-1: from 32 kbps to 448 kbps
   Layer-2: from 32 kbps to 384 kbps
   Layer-3: from 32 kbps to 320 kbps
   The last two statements refer to MPEG-1; with MPEG-2, there is an 
   extension for the sampling frequencies and bitrates (see below).

Q: What are the main differences between the three Layers, from a global 
   view?
A: From Layer-1 to Layer-3,
   complexity increases (mainly true for the encoder),
   overall codec delay increases, and
   performance increases (sound quality per bitrate).

Q: What are the main differences between MPEG-1 and MPEG-2 in the audio 
   part?
A: MPEG-1 and MPEG-2 use the same family of audio codecs, Layer-1, -2 
   and -3. The new audio features of MPEG-2 are:
   "low sample rate extension" to address very low bitrate applications 
   with limited bandwidth requirements (the new sampling frequencies 
   are 16, 22.05 or 24 kHz, the bitrates extend down to 8 kbps),
   "multichannel extension" to address surround sound applications 
   with up to 5 main audio channels (left, center, right, left surround, 
   right surround) and optionally 1 extra "low frequency enhancement 
   (LFE)" channel for subwoofer signals; in addition, a "multilingual 
   extension" allows the inclusion of up to 7 more audio channels.

Q: A lot of new stuff! Is this all compatible to each other?
A: Well, more or less, yes - with the execption of the low sample rate 
   extension. Obviously, a pure MPEG-1 decoder is not able to handle the 
   new "half" sample rates.

Q: You mean: compatible!? With all these extra audio channels? Please 
   explain!
A: Compatibility has been a major topic during the MPEG-2 definition phase. 
   The main idea is to use the same basic bitstream format as defined in 
   MPEG-1, with the main data field carrying two audio signals (called L0 
   and R0) as before, and the ancillary data field carrying the multichannel 
   extension information. Without going further into details, three terms can 
   be explained here:
   "forwards compatible": the MPEG-2 decoder has to accept any 
   MPEG-1 audio bitstream (that represents one or two audio channels)
   "backwards compatible": the MPEG-1 decoder should be able to 
   decode the audio signals in the main data field (L0 and R0) of the 
   MPEG-2 bitstream
   "Matrixing" may be used to get the surround information into L0 and 
   R0:
   L0 = left signal + a * center signal + b * left surround signal
   R0 = right signal + a * center signal + b * right surround signal 
   Therefore, a MPEG-1 decoder can reproduce a comprehensive downmix of 
   the full 5-channel information. A MPEG-2 decoder uses the multichannel 
   extension information (3 more audio signals) to reconstruct the five 
   surround channels.

Q: I heard something about a new NBC mode for MPEG-2 audio? What does 
   it mean?
A: "NBC" stands for "non-backwards compatible". During the development 
   of the backwards compatible MPEG-2 standard, the experts encountered 
   some trouble with the compatibility matrix. The introduced quantisation 
   noise may become audible after dematrixing. Although some clever 
   strategies have been devised to overcome this problem, the question 
   remained how much better a non-compatible multichannel codec might 
   perform.
   So ISO-MPEG decided to address that issue in a "NBC" working group - 
   among the proponents are AT&T, Dolby, Fraunhofer, IRT, Philips, and 
   Sony. Their work will lead to an addendum to the MPEG-2 standard 
   (13818-8).

Q: O.K., that should do for a first overview. Are there some papers for a more 
   detailed information?
A: Sure! You'll find more technical informations about MPEG audio coding 
   in a variety of AES papers (AES = Audio Engineering Society). The AES 
   organizes two conventions per year, and perceptual audio coding has been 
   a topic since the middle of the 80s. Some interesting papers might be:

K. Brandenburg, G. Stoll, et al.: "The ISO/MPEG-Audio Codec: A 
Generic Standard for Coding of High Quality Digital Audio", 92nd 
AES, Vienna Mar. 92, pp. 3336; revised version ("ISO-MPEG-1 
Audio: A Generic Standard...") published in the Journal of AES, 
Vol.42, No. 10, Oct. 94

S. Church, B. Grill, et al.: "ISDN and ISO/MPEG Layer-3 Audio 
Coding: Powerful New tools for Broadcast and Audio Production", 
95th AES, New York Oct. 93, pp. 3743

E. Eberlein, H. Popp, et al.: "Layer-3, a Flexible Coding Standard", 
94th AES, Berlin Mar. 93, pp. 3493   
   
B. Grill, J. Herre, et al.: "Improved MPEG-2 Audio Multi-Channel 
Encoding", 96th AES, Amsterdam Feb. 94, pp. 3865

J. Herre, K. Brandenburg, et al.: "Second Generation ISO/MPEG 
Audio Layer-3 Coding", 98th AES, Paris Feb. 95

F.-O. Witte, M. Dietz, et al.: "'Single Chip Implementation of an 
ISO/MPEG Layer-3 Decoder", 96th AES, Amsterdam Feb. 94, pp. 
3805

For ordering informations, contact:

AES
60 East 42nd Street, Suite 2520
New York, NY 10165-2520, USA
phone: (212) 661-8528, fax: (212) 682-0477	

Another interesting publication: the "Proceedings of the Sixth Tirrenia 
International Workshop on Digital Communications", Tirrenia Sep. 93, 
Elsevier Science B.V. Amsterdam 94 (ISBN 0 444 81580 5).

An excellent tutorial about MPEG-2 has recently been published in a 
German technical journal (Fernseh- und Kino-Technik); part 4, by E. F. 
Schroeder and J. Spille, talks about the audio part (7/8 94, p. 364 ff).

And for further informations, please feel free to contact layer3@iis.fhg.de.


3. Applications

Q: O.K., let us concentrate on one or two audio channels. Which Layer shall I 
   use for my application?
A: Good Question. Of course, it depends on all your requirements. But as a 
   first approach, you should consider the available bitrate of your 
   application as the Layers have been designed to support certain areas of 
   bitrates most effectively. Roughly, today you can achieve a data reduction 
   of around
   1:4	with Layer-1 (or 192 kbps per audio channel),
   1:6..8	with Layer-2 (or 128..96 kbps per audio channel), and 
   1:10..12	with Layer-3, (or 64..56 kbps per audio channel),
   and still the reconstructed audio signal will maintain a "CD-like" sound 
   quality. This may be used as a first "thumb rule" - let's talk about details 
   later on.

Q: Why does the performance increase with the number of the Layer? Why 
   does the standard define a family of audio codecs instead of one single 
   powerful algorithm?
A: Well, the MPEG standard has forged together two main coding schemes 
   that offered advantages either in complexity (MUSICAM) or in 
   performance (ASPEC).
   Layer-2 is identical with the MUSICAM format. It has been designed as a 
   trade-off between sound quality per bitrate and encoder complexity. So it is 
   most useful for the "medium" range of bitrates (96..128 kbps per channel).
   For higher bitrates, even a simplified version, the Layer-1, performs well 
   enough. Layer-1 has originally been developed for a target bitrate of 192 
   kbps per channel. It is used as "PASC" within the DCC recorder.
   For lower bitrates (64 kbps per channel or even less), the Layer-2 format 
   suffers from its build-in limitations, and with decreasing bitrate, artefacts 
   become audible more and more. Here is the strong domain of the most 
   powerful MPEG audio format, Layer-3. It specifies a set of unique features 
   that all address one goal: to preserve as much sound quality as possible 
   even at very low bitrates.

Q: Wait a second! I understand that Layer-3 has been an important asset to 
   the MPEG-1 standard, to address the high-quality low bitrate 
   applications. With the advent of  the "low sample rate extension (LSF)" in 
   MPEG-2, is it still necessary to rely on Layer-3 to achieve a high-quality 
   sound at low bitrates?
A: Yes, for sure! Please, don't mix up MPEG-1 and MPEG-2 LSF. MPEG-2 
   LSF is useful only for applications with limited bandwidth (11.25 kHz, at 
   best). For applications with full bandwidth, MPEG-1 Layer-3 at 64 or 56 
   kbps per channel achieves the best sound quality of all ISO codecs.
   For applications with limited bandwidth, MPEG-2 LSF Layer-3 provides 
   an excellent sound quality at 56 kbps for monophonic speech signals and 
   still a good sound quality at only 64 kbps total bitrate for stereo music 
   signals (with around 10 kHz bandwidth). The latest MPEG ISO listening 
   test (in September 94 at NTT Japan, doc. MPEG 94/437) proved the 
   superior performance of Layer-3 in MPEG-1 and MPEG-2 LSF.

Q: Tell me more about sound quality. How do you assess that?
A: Today, there is no alternative to expensive listening tests. During the ISO-
   MPEG process, a number of international listening tests have been 
   performed, with a lot of trained listeners. All these tests used the "triple 
   stimulus, hidden reference" method and the "CCIR impairment scale" to 
   assess the sound quality.
   The listening sequence is "ABC", with A = original, BC = pair of original 
   / coded signal with random sequence, and the listener has to evaluate both 
   B and C with a number between 1.0 and 5.0. The meaning of these values 
   is:
   5.0 = transparent (this should be the original signal)
   4.0 = perceptible, but not annoying (first differences noticable)  
   3.0 = slightly annoying   
   2.0 = annoying
   1.0 = very annoying

Q: Is there really no alternative to listening tests?
A: No, there is not. With perceptual codecs, all traditional "quality" 
   parameters (like SNR, THD+N, bandwidth) are rather useless, as any 
   codec may introduce noise and distortions as long as it does not affect the 
   perceived sound quality. So, listening tests are necessary, and, if carefully 
   prepared and performed, lead to rather reliable results.
   Nevertheless, Fraunhofer-IIS works on objective sound quality assessment 
   tools, too. There is already a first product available, the NMR meter, a 
   real-time DSP-based measurement tool that nicely supports the analysis of 
   perceptual audio codecs. If you need more informations about the Noise-to-
   Mask-Ratio (NMR) technology, feel free to contact nmr@iis.fhg.de.

Q: O.K., back to these listening tests. Come on, tell me some results.
A: Well, for details you should study one of those AES papers or MPEG 
   documents listed above. The main result is that for low bitrates (64 kbps 
   per channel or below), Layer-3 always scored significantly better than 
   Layer-2. Another important conclusion is the draft recommendation of the 
   task group TG 10/2 within the ITU-R. It recommends the use of low bit-
   rate audio coding schemes for digital sound-broadcasting applications 
END ---------------------- CUT HERE --------------------- 1/8
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!news.mathworks.com!news.alpha.net!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!fu-berlin.de!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [2/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 10:58:25 GMT
Organization: Technical University of Berlin, Germany
Lines: 1306
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r99gh$2nh@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77872 comp.graphics.animation:20007 comp.compression:20434 comp.multimedia:36437 alt.binaries.multimedia:40189 alt.binaries.pictures.utilities:37028 alt.binaries.pictures:21184 alt.binaries.pictures.d:20797 alt.answers:9850 comp.answers:12383 news.answers:45903

Archive-name: mpeg-faq/part2
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly
BEGIN -------------------- CUT HERE --------------------- 2/8
   (doc. BS.1115).

Q: Very interesting! Tell me more about this recommendation!
A: The task group TG 10/2 concluded its work in October 93. The draft 
   recommendation defines three fields of broadcast applications:
   - distribution and contribution links (20 kHz bandwidth, no audible 
   impairments with up to 5 cascaded codecs)
   Recommendation: Layer-2 with 180 kbps per channel
   - emission (20 kHz bandwidth)
   Recommendation: Layer-2 with 128 kbps per channel
   - commentary links (15 kHz bandwidth)
   Recommendation: Layer-3 with 60 kbps for monophonic and 120 kbps
   for stereophonic signals

Q: I see. Medium bitrates - Layer-2, low bitrates - Layer-3. What's about a 
   bitrate of 96 kbps per channel that seems to be "somewhere in between" 
   Layer-2 and Layer-3 domains?
A: Interesting question. In fact, a total bitrate of 192 kbps for stereo music is 
   useful for real applications, e.g. emission via satellite channels. The ITU-R 
   required that emission codecs should score at least 4.0 on the CCIR 
   impairment scale, even for the most critical material. At 128 kbps per 
   channel, Dolby's AC-2, Layer-2 and Layer-3 fulfilled this requirement. 
   Finally, Layer-2 got the recommendation mainly because of its 
   "commonality with the distribution and contribution application".
   Further tests for emission were performed at 192 kbps joint-stereo coding. 
   Layer-3 clearly met the requirements, Layer-2 fulfilled them only 
   marginally, with doubts remaining during further tests with cascaded 
   codecs in 1993. In the end, the task group decided to pronounce no 
   recommendation for emission at 192 kbps.

Q: Someone told me that in the ITU-R tests, there was some trouble with 
   Layer-3, specifically on male voice in the German language. Still, Layer-3 
   got the recommendation for "commentary links". Can you explain that?
A: Yes. For commentary links, the quality requirements for speech were to be 
   equivalent to 14-bit linear PCM, and for music, some perceptible 
   impairments were to be tolerated. In the test in 1992, Layer-3 was by far 
   the only codec that fulfilled these requirements (e.g. overall monophonic, 
   Layer-3 scored 3.6 in contrast to Layer-2 at 2.05 - and for male German 
   speech, Layer-3 scored 4.4 in contrast to Layer-2 at 2.4).
   Further tests were performed in 1993 using headphones. They showed that 
   MPEG-1 Layer-3 with monophonic speech (the test item is German male
   voice) at 60 kbps did not fully meet the quality requirements. The ITU 
   decided to recommend Layer-3 and to include a temporary footnote that 
   will be removed as soon as an improved Layer-3 codec fulfills the 
   requirements completely, i.e. even with that well-known critical male 
   German speech item (for many other speech items, Layer-3 has no trouble 
   at all).

Q: O.K., a Layer-2 codec at low bitrates may sound poor today, but couldn't 
   that be improved in the future? I guess you just told me before that the 
   encoder is not fixed in the standard.
A: Good thinking! As the sound quality mainly depends on the encoder 
   implementation, it is true that there is no such thing as a "Layer-N"- 
   quality. So we definitely only know the performance of the reference 
   codecs used during the international tests. Who knows what will happen in 
   the future? What we do know now, is:
   Today, in MPEG-1 and MPEG-2, Layer-3 provides the best sound quality 
   at low bitrates, by far better than Layer-2.
   Tomorrow, both Layers may improve. Layer-2 has been designed as a 
   trade-off between quality and complexity, so the bitstream format allows 
   only limited innovations. In contrast, even the current reference Layer-3-
   codec does not exploit all of the powerful mechanisms inside the Layer-3 
   bitstream format.  

Q: What other topics do I have to keep in mind? Tell me about the complexity 
   of Layer-3.
A: O.K. First, we have to separate between decoder and encoder, as the 
   workload is distributed asymmetrically between them, i.e. the encoder 
   needs much more computation power than the decoder.
   For a stereo Layer-3-decoder, you may either use a DSP (e.g. one 
   DSP56002 from Motorola) or an "ASIC", like the masc-programmed DSP 
   chip MAS 3503 C from Intermetall, ITT. Some rough requirements are:
   computation power around 12 MIPs
   Data ROM 2.5 Kwords
   Data RAM 4.5 Kwords
   Programm ROM 2 to 4 Kwords
   word length at least 20 bit
   Intermetall (ITT) estimated an overhead of around 30 % chip area for 
   adding the necessary Layer-3 modules to a Layer-2-decoder. So you need 
   not worry too much about decoder complexity.
   For a stereo Layer-3-encoder achieving reference quality, our current real-
   time implementations use two DSP32C (AT&T) and one 	DSP56002. With 
   the advent of the 21060 (Analog Devices), even a single-chip stereo 
   encoder comes into view.
 
Q: Quality, complexity - what about the codec delay?
A: Well, the standard gives some figures of the theoretical minimum delay:
   Layer-1: 	19 ms (<50 ms)
   Layer-2: 	35 ms (100 ms)
   Layer-3: 	59 ms (150 ms)
   The practical values are significantly above that. As they depend on the 
   implementation, exact figures are hard to give. So the figures in brackets 
   are just rough thumb values - real codecs may show significant higher 
   values.

Q: For some applications, a very short delay is of critical importance: e.g. in a 
   feedback link, a reporter can only talk intelligibly if the overall delay is 
   below around 10 ms. Here, do I have to forget about MPEG audio at all?
A: Not necessarily. In this application, broadcasters may use "N-1" switches 
   in the studio to overcome this problem - or they may use equipment with 
   appropriate echo-cancellers. 
   But with many applications, these delay figures are small enough to 
   present no extra problem. At least, if one can accept a Layer-2 delay, one 
   can most likely also accept the higher Layer-3 delay.

Q: Someone told me that, with Layer-3, the codec delay would depend on the 
   actual audio signal, varying over the time. Is this really true? 
A: No. The codec delay does not depend on the audio signal.With all Layers, 
   the delay depends on the actual implementation used in a specific codec, so 
   different codecs may have different delays. Furthermore, the delay depends 
   on the actual sample rate and bitrate of your codec.   
   
Q: All in all, you sound as if anybody should use Layer-3 for low bitrates. 
   Why on earth do some vendors still offer only Layer-2 equipment for these 
   applications?
A: Well, maybe because they started to design and develop their systems 
   rather early, e.g. in 1990. As Layer-2 is identical with MUSICAM, it has 
   been available since summer of 1990, at latest. In that year, Layer-3 
   development started and could be successfully finished at the end of 1991. 
   So, for a certain time, vendors could only exploit the already existing part 
   of the new MPEG standard.   
   Now the situation has changed. All Layers are available, the standard is 
   completed, and new systems may capitalize on the full features of MPEG 
   audio.

4. Products

Q: What are the main fields of application for Layer-3?
A: Simply put: all applications that need high-quality sound at very low 
   bitrates to store or transmit music signals. Some examples are:
   - high-quality music links via ISDN phone lines (basic rate)
   - sound broadcasting via low bitrate satellite channels
   - music distribution in computer networks with low demands for channel 
   bandwidth and memory capacity
   - music memories for solid state recorders based on ROM chips
		
Q: What kind of Layer-3 products are already available?
A: An increasing number of applications benefit from the advanced features 
   of MPEG audio Layer-3. Here is a list of companies that currently sell 
   Layer-3 products. For further informations, please contact these companies 
   directly.

Layer-3 Codecs for Telecommunication:
-	AETA, 361 Avenue du Gal de Gaulle (*)
	F-92140 Clamart, France
	Fax: +33-1-4136-1213 (Mr. Fric)
(*)	products announced for 1995
-     	Dialog 4 System Engineering GmbH, Monreposstr. 57
     	D-71634 Ludwigsburg, Germany
     	Fax: +49-7141-22667 (Mr. Burkhardtsmaier)
-	PKI Philips Kommunikations Industrie, Thurn-und-Taxis-Str. 14
     	D-90411 Nuernberg, Germany
     	Fax: +49-911-526-3795 (Mr. Konrad)
-	Telos Systems, 2101 Superior Avenue
     	Cleveland, OH 44114, USA
     	Fax: +1-216-241-4103 (Mr. Church)

Speech Announcement Systems:
-	Meister Electronic GmbH, Koelner Str. 37
     	D-51149 Koeln, Germany
	Fax: +49-2203-1701-30 (Mr. Seifert)

PC Cards (Hardware and/or Software):
-     	Dialog 4 System Engineering GmbH, Monreposstr. 57
     	D-71634 Ludwigsburg, Germany
     	Fax: +49-7141-22667 (Mr. Burkhardtsmaier)
-	Proton Data, Marrensdamm 12 b
	D-24944 Flensburg, Germany
	Fax: +49-461-38169 (Mr. Nissen)

Layer-3-Decoder-Chips:
-	ITT Intermetall GmbH, Hans-Bunte-Str. 19
     	D-79108 Freiburg, Germany
     	Fax: +49-761-517-2395 (Mrs. Mayer)

Layer-3 Shareware Encoder/Decoder:
-	Mailbox System Nuernberg (MSN), Innerer Kleinreuther Weg 21
 	D-90408 Nuernberg, Germany
	Fax: +49-911-9933661 (Mr. Hanft) 
	Shareware (version 1.00) is available for:
	-	IBM-PCs or Compatibles with MS-DOS:
		L3ENC.EXE and L3DEC.EXE should work on practically 
		any PC with 386 type CPU or better. For the encoder, a 
		486DX33 or better is recommended.
		On a 486DX2/66 the current shareware decoder performs in 
		1:3 real-time, and the shareware encoder in 1:14 real-time 
		(with stereo signals sampled with 44.1 kHz).
	-	Sun workstations:
		On a SPARC station 10, the decoder works in real time, the 
		encoder performs in 1:5 real-time.
		For more information, refer to chapter 6.

5. Support by Fraunhofer-IIS

Q: I understand that Fraunhofer-IIS has been the main developer of MPEG 
   audio Layer-3. What can they do for me?
A: The Fraunhofer-IIS focusses on applied research. Its engineers have 
   profound expertise in real-time implementations of signal-processing 
   algorithms, especially of Layer-3. The IIS may support a specific Layer-3 
   application in various ways:
   - detailed informations
   - technical consulting
   - advanced C sources for encoder and decoder
   - training-on-the-job
   - research and development projects on contract basis.
   For more informations, feel free to contact:
   - Fraunhofer-IIS, Weichselgarten 3
     D-91058 Erlangen, Germany
     Fax: +49-9131-776-399 (Mr. Popp)

Q: What are the latest audio demonstrations disclosed by Fraunhofer-IIS?
A: At the Tonmeistertagung 11.94 in Karlsruhe, Germany, the IIS 
   demonstrated:
   - real-time Layer-3 decoder software (mono, 32 kHz fs) including sound 
   output on ProAudioSpectrum running on a 486DX2/66
   - playback of Layer-3 stereo files from a CD-ROM that has been produced 
   by Intermetall and contains Layer-3 data of up to 15 h of stereo music 
   (among others, all Beethoven symphonies); the decoder is a small board 
   that is connected to the parallel printer port. It mainly carries 3 chips: a 
   PLD as data interface, the MAS 3503 C stereo decoder chip, and the 
   ASCO Digital-Analog-Converter. The board has two cinch adapters that 
   allow a very simple connection to the usual stereo amplifier.
   - music-from-silicon demonstration by using the standard 1 Mbyte 
   EPROMs to store 1.5 minutes of CD-like quality stereo music
   - music link (with around 6 kHz bandwidth) via V.34 modem at 28.8 kbps 
   and one analog phone line

6. Shareware Information

The Layer 3 Shareware is copyright Fraunhofer - IIS 1994 1995.
The shareware packages are available:
- via anonymous ftp from

URL=ftp://fhginfo.fhg.de/pub/layer3/
    [153.96.1.4]
You may download our Layer-3 audio software package from the directory 
/pub/layer3. You will find the following files:

 	For IBM PCs:
   	l3v100.txt     	a short description of the files found in l3v100.zip
   	l3v100.zip     	encoder, decoder, documentation and a sample bitstream
  	l3v100n.txt    a short description of the files found in l3v100n.zip
   	l3v100n.zip    encoder, decoder and documentation (no bitstream)  
   	bstr100.l3     	a sample bitstream encoded with l3enc version 1.00

 	For SUN workstations: 
   	l3v100.sun.txt     	short description of the files found in l3v100.sun.zip
   	l3v100.sun.tar.gz  	encoder, decoder, documentation and a sample 
			bitstream
   	l3v100n.sun.txt   	short description of the files found in 	
			l3v100n.sun.zip
   	l3v100n.sun.tar.gz 	encoder, decoder and documentation (no bitstream)  
   	bstr100.l3       	sample bitstream encoded with version 1.00 of the 
			encoder

-  via direct modem download (up to 14.400 bps)
Modem telephone number  : +49 911 9933662	Name: FHG
Packet switching network: (0) 262 45 9110 10290	Name: FHG
(For the telephone number, replace "+" with your appropriate international 
dial prefix, e.g. "011" for the USA.)
Follow the menus as desired.

- via shipment of diskettes (only including registration)
You may order a diskette directly from:
	Mailbox System Nuernberg (MSN)
 	Hanft & Hartmann
 	Innerer Kleinreuther Weg 21
 	D-90408 Nuernberg, Germany

Please note: MSN will only ship a diskette if they get paid for the 
registration fee before. The registration fee is 85 Deutsche Mark (about 50 
US$) (plus sales tax, if applicable) for one copy of the package. The 
preferred method of payment is via credit card. Currently, MSN accepts 
VISA, Master Card / Eurocard / Access credit cards. For details see the file 
REGISTER.TXT found in the shareware package.
 
 You may reach MSN also via Internet: msn@iis.fhg.de
     or via Fax: +49 911 9933661
     or via BBS: +49 911 9933662		Name: FHG
     or via X25: 0262 45 9110 10290     	Name: FHG
	(e.g. in USA, please replace "+" with "011"

-	via email
You may get our shareware also by a direct request to msn@iis.fhg.de. In 
this case, the shareware is split into about 30 small uuencoded parts...

END-OF-INFO.TXT 1.50 E

Harald Popp
Audio & Multimedia ("Music is the *BEST*" - F. Zappa)
Fraunhofer-IIS-A, Weichselgarten 3, D-91058 Erlangen, Germany
Phone: +49-9131-776-340
Fax:   +49-9131-776-399
email: popp@iis.fhg.de
P.S.: Look out for planetoid #3834!

-------------------------------------------------------------------------------

~Subject: What is MPEG-1+ ?

This was a little mail-talk between harti@shb.contrib.de (Stefan Hartmann)
and hgordon@system.xingtech.com.

Q: What is MPEG-1+ ?

   It's MPEG-1 at MPEG-2 (CCIR) resolution. It will maybe be used
   fir TV-on-top-boxes for broadcasting or video-on-demand projects
   to enhance the picture quality.

Q: I see. Is this a new standard ?

   No. MPEG-1 allows the definition of frames until 4000x4000 pixel, but
   that is usally not used.

Q; So what's different ?

   I understand that the effective resolution is approximately 550 x 480.
   Typical datarates are 3.5Mbps - 5.5Mbps (sports programming and perhaps
   movies are higher).

Q: Is the video quality lower than with real MPEG-2 movies ?

   The quality is better than cable TV, and in my area, we don't have cable.
   They de-interlace and compress the full frames.  My understanding is that
   this is about 5%-10% less efficient than taking advantage of MPEG-2
   interfield motion vectors.

Q: If the fields are deinterlaced, do you see the interlace artifacts, so that
   a moving object in one field is already more into one direction, than in the  
   other field ?

   Probably the TV-receiver also gives it out interlaced again to the TV- 
   set, so this does not produce this interlace artifact like on
   PCs with live video windows displaing both fields....

Q: Can you record this anyhow on a VCR ? Does the SAT-Receiver have a
   video- output, so you can record movies to tape ?

   You should be able to record to tape, though they may have some record
   blocking hardware which has to be overcome with video stabilizing
   hardware.

Q: What kind of realtime encoders do they use at the broadcast station ?

   CLI (Compression Labs) is the manufacturer, using C-Cube chipsets (10
   CL-4000's per MPEG-1+ encoder).

Q: Is there any written info about this MPEG-1 Plus technology available on
   the net ?

   Not that I'm aware. Maybe C-Cube has a Web site.


[So it's up to you, dear reader, to find more and to tell me where it is ;o) ]

Frank Gadegast, phade@cs.tu-berlin.de

-------------------------------------------------------------------------------

~Subject: What is MPEG-2?

MPEG-2 FAQ
version 3.7 (May 11, 1995)
by Chad Fogg (cfogg@chromatic.com)

The MPEG (Moving Pictures Experts Group) committee began its life in
late 1988 by the hand of Leonardo Chairiglione and Hiroshi Yasuda with
the immediate goal of standardizing video and audio for compact discs.
Over the next few years, participation amassed from international
technical experts in the areas of Video, Audio, and Systems, reaching
over 200 participants by 1992.   

By the end of the third year (1990), a syntax emerged, which when
applied to code SIF video and compact disc audio samples  rates at a
combined coded bitrate of 1.5 Mbit/sec, approximated the perceptual
quality of consumer video tape (VHS).  After demonstrations proved that
the syntax was generic enough to be applied to bit rates and sample
rates far higher than the original primary target application, a second
phase (MPEG-2) was initiated within the committee to define a syntax
for efficient representation of broadcast video.  Efficient
representation of interlaced (broadcast) video signals was more
challenging than the progressive (non-interlaced) signals coded by
MPEG-1. Similarly, MPEG-1 audio was capable of only directly
representing two channels of sound. MPEG-2 would introduce a scheme to
decorrelate mutlichannel discrete surround sound audio.

Need for a third phase (MPEG-3) was anticipated in 1991 for High
Definition Television, although it was later discovered by late 1992
and 1993 that the MPEG-2 syntax simply scaled with the bit rate,
obviating the third phase.  MPEG-4 was launched in late 1992 to explore
the requirements of a more diverse set of applications, while finding a
more efficient means of coding low bit rate/low sample rate video and
audio signals.

Today, MPEG (video and systems) is exclusive syntax of the United
States Grand Alliance HDTV specification, the European Digital Video
Broadcasting Group, and the high density compact disc (lead by rivals
Sony/Philips and Toshiba).

What is MPEG video syntax ?

MPEG video syntax provides an efficient way to represent image
sequences in the form of more compact coded data. The language of the
coded bits is the syntax.  For example, a few tokens can represent an
entire block of 64 samples. MPEG also describes a decoding
(reconstruction) process where the coded bits are mapped from the
compact representation into the original, raw format of the image
sequence. For example, a flag in the coded bitstream signals whether
the following bits are to be decoded with a DCT algorithm or with a
prediction algorithm. The algorithms comprising the decoding process
are regulated by the semantics defined by MPEG. This syntax can be
applied to exploit common video characteristics such as spatial
redundancy, temporal redundancy, uniform motion, spatial masking, etc.

MPEG Myths

A brief summary myths.

1. Compression Ratios over 100:1

Articles in the press and marketing literature will often make the
claim that MPEG can achieve high quality video with compression ratios
over 100:1.  These figures often include the oversampling factors in
the source video.  In reality, the coded sample rate specified in an
MPEG image sequence is usually not much larger than 30 times the
specified bit rate.   Pre-compression through subsampling is chiefly
responsible for 3 digit ratios for all video coding methods, including
those of the non-MPEG variety.

2. MPEG-1 is 352x240

Both MPEG-1 and MPEG-2 video syntax can be applied at a wide range of
bitrates and sample rates.  The MPEG-1 that most people are familiar
with has parameters of 30 SIF pictures (352 pixels x 240 lines) per
second and a bitrate less than 1.86  megabits/sec----a combination
known as "Constrained Parameters Bitstreams".  This popular
interoperability point is promoted by Compact Disc Video (White Book).
In fact, it is syntactically possible to encode picture dimensions as
high as 4095 x 4095 and a bitrates up to 100 Mbit/sec.  With the advent
of the MPEG-2 specification, the most popular combinations have
coagulated into Levels, which are described later in this text.  The
two most common are affectionately known as SIF (e.g. 352 pixels x 240
lines x 30 frames/sec), or Low Level, and CCIR 601 (e.g. 720
pixels/line x 480 lines x 30 frames/sec), or Main Level.

3. Motion Compensation displaces macroblocks from previous pictures

Macroblock predictions are formed out of arbitrary 16x16 pixel (or 16x8
in MPEG-2) areas from previously reconstructed pictures. There are no
boundaries which limit the location of a macroblock prediction within
the previous picture,  other than the edges of the picture.


4. Display picture size is the same as the coded picture size

In MPEG, the display picture size and frame rate may differ from the
size (resolution) and frame rate encoded into the bitstream.  For
example, a regular pattern of pictures in a source image sequence may
be dropped (decimated), and then each picture may itself be filtered
and subsampled prior to encoding. Upon reconstruction, the picture may
be interpolated and upsampled back to the source size and frame rate.
In fact, the three fundamental phases (Source Rate, Coded Rate, and
Display Rate) may differ by several parameters.  The MPEG syntax can
separately describe Coded and Display Rates through sequence_headers,
but the Source Rate is known only by the encoder.


5. Picture coding types (I, P, B) all consist of the same macroblocks types.

All macroblocks within an I picture must be coded Intra (like a
baseline JPEG picture).  However, macroblocks within a P picture may
either be coded as Intra or Non-intra (temporally predicted from a
previously reconstructed picture). Finally, macroblocks within the B
picture can be independently selected as either Intra, Forward
predicted, Backward predicted, or both forward and backward
(Interpolated) predicted. The macroblock header contains an element,
called macroblock_type, which can flip these modes on and off like
switches.  macroblock_type is possibly the single most powerful element
in the whole of video syntax. Picture types (I, P, and B) merely enable
macroblock modes by widening the scope of the semantics.  The component
switches are:

  1. Intra  or Non-intra
  2. Forward temporally predicted (motion_forward)
  3. Backward temporally predicted (motion_backward)
      (2+3 in combination represent “Interpolated”)
  4. conditional replenishment (macroblock_pattern).
  5. adaptation in quantization (macroblock_quantizer). 
  6. temporally predicted without motion compensation

The first 5 switches are mostly orthogonal (the 6th is derived from the
1st and 2nd in P pictures, and does not exist in B pictures).  Some
switches are non-applicable in the presence of others.  For example, in
an Intra macroblock, all 6 blocks by definition contain DCT data,
therefore there is no need to signal either the macroblock_pattern or
any of the temporal prediction switches.  Likewise, when there is no
coded prediction error information in a Non-intra macroblock, the
macroblock_quantizer signal would have no meaning.


6. Sequence structure is fixed to a specific I,P,B frame pattern.

A sequence may consist of almost any pattern of I, P, and B pictures
(there are a few minor semantic restrictions on their placement).  It
is common in industrial practice to have a fixed pattern (e.g.
IBBPBBPBBPBBPBB), however, more advanced encoders will attempt to
optimize the placement of the three picture types according to local
sequence characteristics in the context of more global
characteristics.  Each picture type carries a penalty when coupled with
the statistics of a particular picture (temporal masking, occlusion,
motion activity, etc.).

The variable length codes of the macroblock_type switch provide a
direct clue, but it is the full scope of semantics of each picture type
spell out the costs-benefits. For example, if the image sequence
changes little from frame-to-frame, it is sensible to code more B
pictures than P.  Since B pictures by definition are never fed back
into the prediction loop (i.e. not used as prediction for future
pictures), bits spent on the picture are wasted in a sense (B pictures
are like temporal spackle).  Application requirements also govern
picture type placement: random access points, mismatch/drift reduction,
channel hopping, program indexing, and error recovery & concealment.


The 6 Steps to Claiming Bogously High Compression Ratios:

MPEG video is often quoted as achieving compression ratios over 100:1,
when in reality the sweet spot rests between 8:1 and 30:1.

Heres how the fabled greater than 100:1 reduction ratio is derived for
the popular Compact Disc Video (White Book) bitrate of 1.15 Mbit/sec.

Step 1.  Start with the oversampled rate

  Most MPEG video sources originate at a higher sample rate than the
  "target sample rate encoded into the final MPEG bitstream.  The most
  popular studio signal, known canonically as D-1 or CCIR 601 digital
  video, is coded at 270 Mbit/sec.

The constant, 270 Mbit/sec, can be derived as follows:

Luminance (Y): 858 samples/line x 525 lines/frame x 30 frames/sec x 
               10 bits/sample ~= 135 Mbit/sec

R-Y          (Cb):    429 samples/line x 525 lines/frame x 30 frames/sec x 
               10 bits/sample ~= 68 Mbit/sec   	

B-Y          (Cb):    429 samples/line x 525 lines/frame x 30 frames/sec x 
               10 bits/sample ~= 68 Mbit/sec   	

Total:       27 million samples/sec x  10 bits/sample =  270 Mbit/sec.

So, our compression ratio is:  270/1.15... an amazing  235:1 !!


Step 2. Include blanking intervals

Only 720 out of the 858 luminance samples per line contain active
picture information.  In fact, the debate over the true number of
active samples is the cause of many hair-pulling cat-fights at TV
engineering seminars and conventions, so it is safer to say that the
number lies somewhere between 704 and 720.  Likewise, only 480 lines
out of the 525 lines contain  active picture information.  Again, the
actual number is somewhere between 480 and 496.  For the purposes of
MPEG-1s and MPEG-2s famous conformance points (Constrained Parameters
Bitstreams and Main Level, respectively), the number shall be 704
samples x 480 lines for luminance, and 352 samples x 480 lines for each
of the two chrominance pictures. Recomputing the source rate, we arrive
at:

(luminance)      
   704 samples/line x 480 lines x 30 fps x 10 bits/sample ~= 104 Mbit/sec 

(chrominance)  
  2 components x 352 samples/line x 480 lines x 30 fps x 10 bits/sample 
   ~= 104 Mbit/sec 

Total:  ~  207 Mbit/sec

The ratio (207/1.15)  is now only 180:1


Step 3.  Include higher bits/sample

The MPEG sample precision is 8 bits.  Studio equipment often quantize
samples with 10 bits of accuracy.  The 2-bit improvement to the dynamic
range is considered useful for suppressing noise in multi-generation
video.

The ratio is now only 180 * (8/10 ), or  144:1

Step 4.  Include higher chroma ratio

The famous CCIR-601studio signal represents the chroma signals (Cb, Cr)
with half the horizontal sample density as the luminance signal, but
with full vertical resolution.  This particular ratio of subsampled
components is known as 4:2:2.  However, MPEG-1 and MPEG-2 Main Profile
specify the exclusive use of the 4:2:0 format, deemed sufficient for
consumer applications, where both chrominance signals have exactly half
the horizontal and vertical resolution as luminance (the MPEG Studio
Profile, however, centers around the 4:2:2 macroblock structure). Seen
from the perspective of pixels being comprised of samples from multiple
components, the 4:2:2 signal can be expressed as having an average of 2
samples per pixel (1 for Y, 0.5 for Cb, and 0.5 for Cr).  Thanks to the
reduction in the vertical direction (resulting in a 352 x 240
chrominance frame), the 4:2:0 signal would, in effect, have an average
of 1.5 samples per pixel (1 for Y, and 0.25 for Cb and Cr each). Our
source video bit rate may now be recomputed as:

  720 pixels x 480 lines x 30 fps x 8 bits/sample x 1.5 samples/pixel 
     = 124 Mbit/sec

... and the ratio is now 108:1.

Step 5.  Include pre-subsampled image size

As a final act of pre-compression, the CCIR 601 frame is converted to
the SIF frame by a subsampling of 2:1 in both the horizontal and
vertical directions.... or 4:1 overall.  Quality horizontal subsampling
can be achieved by the application of a simple FIR filter (7 or 4 taps,
for example), and vertical subsampling by either dropping every other
field (in effect, dropping every other line) or again by an FIR filter
(regulated by an interfield motion detection algorithm).  Our ratio now
becomes:

    352 pixels x 240 lines x 30 fps x 8 bits/sample x 1.5 samples/pixel 
   ~= 30 Mbit/sec !!

.. and the ratio is now only 26:1 

Thus, the true A/B comparison should be between the source sequence at
the 30 Mbit/sec stage, the actual specified sample rate in the MPEG
bitstream, and the reconstructed sequence produced from the 1.15
Mbit/sec coded bitstream.

Step 6.   Don’t forget the 3:2 pulldown

A majority of high-end programs originates from film.  Most of the
movies encoded onto Compact Disc Video were in captured and reproduced
at 24 frames/sec.  So, in such an image sequence, 6 out of the 30
frames every second are in fact redundant and need not be coded into
the MPEG bitstream, leading to the shocking discovery that the actual
soure bit rate has really been  24 Mbit/sec all along, and the
compression ratio a mere 21:1 !!!  Even at the seemingly modest 20:1
ratio, discrepancies will appear between the 24 Mbit/sec source
sequence and the reconstructed sequence.  Only conservative ratios in
the neighborhood of 8:1 have demonstrated true transparency for
sequences with complex spatial-temporal characteristics (i.e.  rapid,
divergent motion and sharp edges, textures, etc.).  However, if the
video is carefully encoded by means of pre-processing and intelligent
distribution of  bits, higher ratios can be made to appear at least
artifact-free.


What are the parts of the MPEG document?

The MPEG-1 specification (official title: ISO/IEC 11172 Information
technology  Coding of moving pictures and associated audio for digital
storage media at up to about 1.5 Mbit/s, Copyright 1993.) consists of
five parts.  Each document is a part of the ISO/IEC number 11172.  The
first three parts reached International Standard in 1993.  Part 4
reached IS in 1994.  In mid 1995, Part 5 will go IS.

Part 1---Systems:  The first part of the MPEG standard has two primary
purposes:  1). a syntax for transporting packets of audio and video
bitstreams over digital channels and storage mediums (DSM),  2). a
syntax for synchronizing video and audio streams.

Part 2---Video: describes syntax (header and bitstream elements) and
semantics (algorithms telling what to do with the bits). Video breaks
the image sequence into a series of nested layers, each containing a
finer granularity of sample clusters (sequence, picture, slice,
macroblock, block, sample/coefficient).  At each layer, algorithms are
made available which can be used in combination to achieve efficient
compression.  The syntax also provides a number of different means for
assisting decoders in synchronization, random access, buffer
regulation, and error recovery.  The highest layer, sequence, defines
the frame rate and picture pixel dimensions for the encoded image
sequence.

Part 3---Audio: describes syntax and semantics for three classes of
compression methods. Known as Layers I, II, and III, the classes trade
increased syntax and coding complexity for improved coding efficiency
at lower bitrates.  The Layer II is the industrial favorite, applied
almost exclusively in satellite broadcasting (Hughes DSS) and  compact
disc video  (White Book).  Layer I has similarities in terms of
complexity, efficiency, and syntax to the Sony MiniDisc and the Philips
Digitial Compact Cassette (DCC). Layer III has found a home in ISDN,
satellite, and Internet audio applications. The sweet spots for the
three layers are 384 kbit/sec (DCC), 224 kbit/sec (CD Video, DSS), and
128 Kbits/sec (ISDN/Internet), respectively.

Part 4---Conformance: (circa 1992) defines the meaning of  MPEG
conformance for all three parts (Systems, Video, and Audio), and
provides two sets of test guidelines for determining compliance in
bitstreams and decoders.  MPEG does not directly address encoder
compliance.

Part 5---Software Simulation: Contains an example ANSI C language
software encoder and  compliant decoder for video and audio.  An
example systems codec is also provided which can multiplex and
demultiplex separate video and audio elementary streams contained in
computer data files.


As of March 1995, the MPEG-2 volume consists of a total of 9 parts
under ISO/IEC 13818.  Part 2 was jointly developed with the ITU-T,
where it is known as recommendation H.262. The full title is:
Information Technology--Generic Coding of Moving Pictures and
Associated Audio. ISO/IEC 13818. The first five parts are organized in
the same fashion as MPEG-1(System, Video, Audio, Conformance, and
Software).  The four additional parts are listed below:

Part 6  Digital Storage Medium Command and Control (DSM-CC): provides a
syntax for controlling VCR- style playback and random-access of
bitstreams encoded onto digital storage mediums such as compact disc.
Playback commands include Still frame, Fast Forward, Advance, Goto.

Part 7  Non-Backwards Compatible Audio (NBC):  addresses the need for a
new syntax to efficiently de- correlate discrete mutlichannel surround
sound audio.  By contrast, MPEG-2 audio (13818-3) attempts to code the
surround channels as an ancillary data to the MPEG-1
backwards-compatible Left and Right channels. This allows existing
MPEG-1 decoders to parse and decode only the two primary channels while
ignoring the side channels (parse to /dev/null).  This is analogous to
the Base Layer concept in MPEG-2 Scalable video. NBC candidates include
non-compatible syntaxs such as Dolby AC-3.  Final document is not
expected until 1996.

Part 8  10-bit video extension.  Introduced in late 1994, this
extension to the video part (13818-2) describes the syntax and
semantics to coded representation of video with 10-bits of sample
precision.  The primary application is studio video (distribution,
editing, archiving).  Methods have been investigated by Kodak and
Tektronix which employ Spatial scalablity, where the 8-bit signal
becomes the Base Layer, and the 2-bit differential signal is coded as
an Enhancement Layer.  Final document is not expected until 1997 or
1998.  [Part 8 will be withdrawn]

<IMG SRC="mpeg2lay.gif">

<IMG SRC="mpeg2la2.gif">

Part 9  Real-time Interface (RTI): defines a syntax for video on demand
control signals between set-top boxes and head-end servers.

What is the evolution of an MPEG/ISO document?

In chronological order:

Abbr.    ISO/Committee notation            Author's notation        
-----    -------------------------------   -----------------------------
 -       Problem (unofficial first stage)  barroom witticism or dare
NI       New work Item                     Napkin Item
NP       New Proposal                      Need Permission
WD       Working Draft                     We’re Drunk
CD       Committee Draft                   Calendar Deadlock
DIS      Draft International Standard      Doesn't Include Substance
IS       International Standard            Induced patent Statements


Introductory paper to MPEG?

Didier Le Gall, "MPEG: A Video Compression Standard for Multimedia
Applications," Communications of the ACM, April 1991, Vol.34, No.4, pp.
47-58


MPEG in periodicals?

The following journals and conferences have been known to contain
information relating to MPEG:


  IEEE Transactions on Consumer Electronics
  IEEE Transactions on Broadcasting
  IEEE Transactions on Circuits and Systems for Video Technology
  Advanced Electronic Imaging
  Electronic Engineering Times (EE Times)
  IEEE Int'l Conference on Acoustics, Speech, and Signal Processing (ICASSP)
  International Broadcasting Convention (IBC)
  Society of Motion Pictures and Television Engineers Journal (SMPTE)
  SPIE conference on Visual Communications and Image Processing


MPEG Book?

Several MPEG books are under development.  

An MPEG book will be produced by the same team behind the JPEG book:
Joan Mitchell and Bill Pennebaker.... along with Didier Le Gall. It is
expected to be a tutorial on MPEG-1 video and some MPEG-2 video. Van
Nostran Reinhold in 1995.

A book, in the Japanese language, has already been published (ISBN:
4-7561-0247-6).  The title is called MPEG by ASCII publishing.

Keith Jack's second edition of Video Demystified, to be published in
August 1995, will feature a large chapter on MPEG video.  Information:
ftp://ftp.pub.netcom/pub/kj/kjack/



MPEG is a DCT based scheme?

The DCT and Huffman algorithms receive the most press coverage (e.g.
"MPEG is a DCT based scheme with Huffman coding"), but are in fact less
significant when compared to the variety of coding modes signaled to
the decoder as context-dependent side information. The MPEG-1 and
MPEG-2 IDCT has the same definition as H.261, H.263, JPEG.


What are constant and variable bitrate streams?

Constant bitrate streams are buffer regulated to allow continuos
transfer of coded data across a constant rate channel without causing
an overflow or underflow to a buffer on the receiving end.  It is the
responsibility of the Encoders Rate Control stage to generate
bitstreams which prevent buffer overflow and underflow.  The constant
bit rate encoding can be modeled as a reservoir:  variable sized coded
pictures flow into the bit reservoir, but the reservoir is drained at a
constant rate into the communications channel.  The most challenging
aspect of a constant rate encoder is, yes, to maintain constant channel
rate (without overflowing or underflow a buffer of a fixed depth) while
maintaining constant perceptual picture quality.

In the simplest form, variable rate bitstreams do not obey any buffer
rules, but will maintain constant picture quality.  Constant picture
quality is easiest to achieve by holding the macroblock quantizer step
size constant (e.g. level 16 of 31).  In its most advanced form, a
variable bitrate stream may be more difficult to generate than
constant bitrate streams.  In advanced variable bitrate streams, the
instantaneous bit rate (piece-wise bit rate) may be controlled by
factors such as:  1. local activity measured against activity over
large time intervals (e.g. the full span of a movie), or 2.
instantaneous bandwidth availability of a communications channel.

Summary of bitstream types
Bitrate type
Applications

constant-rate
fixed-rate communications channels like the original Compact Disc,
digital video tape, single channel-per-carrier broadcast signal, hard
disk storage

simple variable-rate
software decoders where the bitstream buffer (VBV) is the storage
medium itself (very large).  macroblock quantization scale is typically
held constant over large number of macroblocks.

complex variable-rate
Statistical muliplexing (multiple-channel-per-carrier broadcast
signals), compact discs and hard disks where the servo mechanisms can
be controlled to increase or decrease the channel delivery rate,
networked video where overall channel rate is constant but demand is
variably share by multiple users, bitstreams which achieve average
rates over very long time averages



What is statistical multiplexing ?

Progressive explanation:
In the simplest coded bitstream, a PCM (Pulse Coded Modulated) digital
signal, all samples have an equal number of bits. Bit distribution in a
PCM image sequence is therefore not only uniform within a picture,
(bits distributed along zero dimensions), but is also uniform across
the full sequence of pictures.

Audio coding algorithms such as MPEG-1s Layer I and II are capable of
distributing bits over a one dimensional space, spanned by a frame.  In
layer II, for example, an audio channel coded at a bitrate of 128
bits/sec and sample rate of 44.1 Khz will have frames (which consist of
1152 subband coefficients each) coded with approximately 334 bits.
Some subbands will receive more bits than others.

In block-based still image compression methods which employ 2-D
transform coding methods, bits are distributed over a 2 dimensional
space (horizontal and vertical) within the block. Further, blocks
throughout the picture may contain a varying number of bits as a
result, for example, of adaptive quantization. For example, background
sky may contain an average of only 50 bits per block, whereas complex
areas containing flowers or text may contain more than 200 bits per
block.  In the typical adaptive quantization scheme, more bits are
allocated to perceptually more complex areas in the picture.  The
quantization stepsizes can be selected against an overall picture
normalization constant, to achieve a target bit rate for the whole
picture. An encoder which generates coded image sequences comprised of
independently coded still pictures, such as JPEG Motion video or MPEG
Intra picture sequences,  will typically generate coded pictures of
equal bit size.

MPEG non-intra coding introduces the concept of the distribution of
bits across multiple pictures, augmenting the distribution space to 3
dimensions. Bits are now allocated to more complex pictures in the
image sequence, normalized by the target bit size of the group of
pictures, while at a lower layer, bits within a picture are still
distributed according to more complex areas within the picture. Yet in
most applications, especially those of the Constant Bitrate class, a
restriction is placed in the encoder which guarantees that after a
period of time, e.g. 0.25 seconds, the coded bitstream achieves a
constant rate (in MPEG, the Video Buffer Verifier regulates the
variable-to-constant rate mapping).  The mapping of an inherently
variable bitrate coded signal to a constant rate allows consistent
delivery of the program over a fixed-rate communications channel.

Statistical multiplexing takes the bit distribution model to 4
dimensions:  horizontal, vertical, temporal, and program axis.  The 4th
dimension is enabled by the practice of mulitplexing multiple programs
(each, for example, with  respective video and audio bitstreams) on a
common data carrier. In the Hughes' DSS system, a single data carrier
is modulated with a payload capacity of 23 Mbits/sec, but a typical
program will be transported at average bit rate of 6 Mbit/sec each. In
the 4-D model, bits may be distributed according the relative
complexity of each program against the complexities of the other
programs of the common data carrier.  For example, a program undergoing
a rapid scene change will be assigned the highest bit allocation
priority, whereas the program with a near-motionless scene will receive
the lowest priority, or fewest bits.


How does MPEG achieve compression? 

Here are some typical statistical conditions addressed by specific
syntax and semantic tools:

1. Spatial correlation:  transform coding with 8x8 DCT.
 
2. Human Visual Response---less acuity for higher spatial frequencies:
lossy scalar quantization of the DCT coefficients.

3. Correlation across wide areas of the picture:  prediction of the DC
coefficient in the 8x8 DCT block.

4. Statistically more likely coded bitstream elements/tokens:  variable
length coding of macroblock_address_increment, macroblock_type,
coded_block_pattern, motion vector prediction error magnitude, DC
coefficient prediction error magnitude.


5. Quantized blocks with sparse quantized matrix of DCT coefficients:
end_of_block token (variable length symbol).

6. Spatial masking:  macroblock quantization scale factor.

7. Local coding adapted to overall picture perception (content
dependent coding):  macroblock quantization scale factor.

8. Adaptation to local picture characteristics:  block based coding,
macroblock_type, adaptive quantization.

9. Constant stepsizes in adaptive quantization:  new quantization scale
factor signaled only by special macroblock_type codes.  (adaptive
quantization scale not transmitted by default).

10. Temporal redundancy:  forward, backwards macroblock_type and motion
vectors at macroblock (16x16) granularity.

11. Perceptual coding of macroblock temporal prediction error: adaptive
quantization and quantization of DCT transform coefficients (same
mechanism as Intra blocks).

12. Low quantized macroblock prediction error:  No prediction error for
the macroblock may be signaled within macroblock_type.  This is the
macroblock_pattern switch.

13. Finer granularity coding of macroblock prediction error: Each of
the blocks within a macroblock may be coded or not coded. Selective
on/off coding of each block is achieved with the separate
coded_block_pattern variable-length symbol, which is present in the
macroblock only of the macroblock_pattern switch has been set.

14. Uniform motion vector fields (smooth optical flow fields):
prediction of  motion vectors.

15. Occlusion:  forwards or backwards temporal prediction in B
pictures.  Example: an object becomes temporarily obscured by another
object within an image sequence. As a result, there may be an area of
samples in a previous picture (forward reference/prediction picture)
which has similar energy to a macroblock in the current picture (thus
it is a good prediction), but no areas within a future picture
(backward reference) are similar enough. Therefore only forwards
prediction would be selected by macroblock type of the current
macroblock. Likewise, a good prediction may only be found in a future
picture, but not in the past.  In most cases, the object, or
correlation area,  will be present in both forward and backward
references.  macroblock_type can select the best of the three
combinations.

16. Sub-sample temporal prediction accuracy: bi-linearly interpolated
(filtered) "half-pel" block predictions.  Real world motion
displacements of objects (correlation areas) from picture-to-picture do
not fall on integer pel boundaries, but on  irrational . Half-pel
interpolation attempts to extract the true object to within one order
of approximation, often improving compression efficiency by at least 1
dB.

17. Limited motion activity in P pictures: skipped macroblocks. When
the motion vector is zero for both the horizontal and vertical vector
components, and no quantized prediction error for the current
macroblock is present. Skipped macroblocks are the most desirable
element in the bitstream since they consume no bits, except for a
slight increase in the bits of the next non-skipped macroblock.

18. Co-planar motion within B pictures: skipped macroblocks.  When the
motion vector is the same as the previous macroblocks, and no quantized
prediction error for the current macroblock is present.

What is the difference between MPEG-1 and MPEG-2 syntax?

Section D.9 of ISO/IEC 13818-2 is an informative piece of text
describing the differences between MPEG-1 and MPEG-2 video syntax.  The
following is a little more informal.

Sequence layer:
MPEG-2 can represent interlaced or progressive video sequences,
whereas  MPEG-1 is strictly meant for progressive sequences since the
target application was Compact Disc video coded at 1.2 Mbit/sec.

MPEG-2 changed the meaning behind the aspect_ratio_information
variable, while significantly reducing the number of defined aspect
ratios in the table.  In MPEG-2, aspect_ratio_information refers to the
overall display aspect ratio (e.g. 4:3,  16:9), whereas in MPEG-2, the
ratio refers to the particular pixel.  The reduction in the entries of
the aspect ratio table also helps interoperability by limiting the
number of possible modes to a practical set, much like frame_rate_code
limits the number of display frame rates that can be represented.
Optional picture header variables called display_horizontal_size and
display_vertical_size can be used to code unusual display sizes.

frame_rate_code in MPEG-2 refers to the intended display rate, whereas
in MPEG-1 it referred to the coded frame rate.  In film source video,
there are often 24 coded frames per second.   Prior to bitstream
coding, a good encoder will eliminate the redundant 6 frames or 12
fields from a 30 frame/sec video signal which encapsulates an
inherently 24 frame/sec video source.  The MPEG decoder or display
device will then repeat frames or fields to recreate or synthesize the
30 frame/sec display rate.  In MPEG-1, the decoder could only infer the
intended frame rate, or derive it based on the Systems layer time
stamps.  MPEG-2 provides specific picture header variables called
repeat_first_field and top_field_first which explicitly signal which
frames or fields are to be repeated, and how many times.

To address the concern of software decoders which may operate at rates
lower or different than the common television rates, two new variables
in MPEG-2 called frame_rate_extension_d and frame_rate_extension_n can
be combined with frame_rate_code to specify a much wider variety of
display frame rates.  However, in the current set of define profiles
and levels, these two variables are not allowed to change the value
specified by frame_rate_code.  Future extensions or Profiles of MPEG
may enable them.

In interlaced sequences, the coded macroblock height (mb_height) of a
picture must be a multiple of 32 pixels, while the width, like MPEG-1,
is a coded multiple of 16 pixels.  A discrepancy between the coded
width and height of a picture and the variables horizontal_size and
vertical_size, respectively, occurs when either variable is not an
integer multiple of macroblocks.  All pixels must be coded within
macroblocks, since there cannot be such a thing as fractional
macroblocks.  Never intended for display, these overhang pixels or
lines exist along the left  and bottom edges of the coded picture.  The
sample values within these trims can be arbitrary, but they can affect
the values of samples within the current picture, and especially future
coded pictures.  In the current pictures, pixels which reside within
the same 8x8 block as the overhang pixels are affect by the ripples of
DCT quantization error.  In future coded pictures,  their energy can
propagate anywhere within an image sequence as a result of motion
compensated prediction.  An encoder should fill in values which are
easy to code, and should probably avoid creating motion vectors which
would cause the Motion Compensated Prediction stage to extract samples
from these areas.  The application should probably select
horizontal_size and vertical_size that are already multiples of 16 (or
32 in the vertical case of interlaced sequences) to begin with.


Group of Pictures:
The concept of the Group of Pictures layer does not exist in MPEG-2.
It is an optional header useful only for establishing a SMPTE time code
or for indicating that certain B pictures at the beginning of an edited
sequence comprise a broken_link.  This occurs when the current B
picture requires prediction from a forward reference frame (previous in
time to the current picture) has been removed from the bitstream by an
editing process.  In MPEG-1, the Group of Pictures header is mandatory,
and must follow a sequence header.


Picture layer:
In MPEG-2, a frame may be coded progressively or interlaced, signaled
by the progressive_frame variable.  In interlaced frames
(progressive_frame==0), frames  may then be coded as either a frame
picture (picture_structure==frame) or as two separately coded field
pictures (picture_structure==top_field or
picture_structure==bottom_field).  Progressive frames are a logic
choice for video material which originated from film, where all pixels
are integrated or captured at the same time instant.  Most electronic
cameras today capture pictures in two separate stages: a top field
consisting of all odd lines of the picture are nearly captured in the
time instant, followed by a bottom field of all even lines.  Frame
pictures provide the option of coding each macroblock locally as either
field or frame.  An encoder may choose field pictures to save memory
storage or reduce the end-to-end encoder-decoder delay by one field
period.


There is no longer such a thing called D pictures in MPEG-2 syntax.
However, Main Profile @ Main Level MPEG-2 decoders, for example, are
still required to decode D pictures at Main Level (e.g. 720x480x30
Hz).  The usefulness of D pictures, a concept from the year 1990,  had
evaporated by the time MPEG-2 solidified in 1993.

repeat_first_field was introduced in MPEG-2 to signal that a field or
frame from the current frame is to be repeated for purposes of frame
rate conversion (as in the 30 Hz display vs. 24 Hz coded example
above). On average in a 24 frame/sec coded sequence, every other coded
frame would signal the repeat_first_field flag.  Thus the 24 frame/sec
(or 48 field/sec) coded sequence would become a 30 frame/sec (60
field/sec) display sequence.  This processes has been known for decades
as 3:2 Pulldown. Most movies seen on NTSC displays since the advent of
television have been displayed this way. Only within the past decade
has it become possible to interpolate motion to create 30 truly unique
frames from the original 24. Since the repeat_first_field flag is
independently determined in every frame structured picture, the actual
pattern can be irregular (it doesnt have to be every other frame
literally).  An irregularity would occur during a scene cut, for
example.


Slice:
To aid implementations which break the decoding process into parallel
operations along horizontal strips within the same picture, MPEG-2
introduced a general semantic  mandatory requirement that all
macroblock rows must start and end with at least one slice.  Since a
slice commences with a start code, it can be identified by
inexpensively parsing through the bitstream along byte boundaries.
Before, an implementation might have had to parse all the variable
length tokens between each slice (thereby completing a significant
stage of decoding process in advance) to know the exact position of
each macroblock within the bitstream.  In MPEG-1, it was possible to
code a picture with only a single slice.  Naturally, the mandatory
slice per macroblock row restriction also facilitates error recovery.

MPEG-2 also added the concept of the slice_id.  This optional 6-bit
element signals which picture a particular slice belongs to.  In badly
mangled bitstreams, the location of the picture headers could become
garbled.  slice_id allows a decoder to place a slice in the proper
location within a sequence.  Other elements in the slice header, such
as slice_vertical_position, and the macroblock_address_increment of the
first macroblock in the slice uniquely identify the exact macroblock
position of the slice within the picture.  Thus within a window of 64
pictures, a lost slice can find its way.



Macroblock:
motion vectors are now always represented along a half-pel grid.  The
usefulness of an integer-pel grid (option in MPEG-1) diminished with
practice.  A intrinsic half-pel accuracy can encourage use by encoders
for the significant coding gain which half-pel interpolation offers.

In both MPEG-1 and MPEG-2, the dynamic range of motion vectors is
specified on a picture basis. A set of pictures corresponding to a
rapid motion scene may need a motion vector range of up to +/- 64
integer pixels.  A slower moving interval of pictures may need only a
+/- 16 range. Due to the syntax by which motion vectors are signaled in
a bitstream, pictures with little motion would suffer unnecessary bit
overhead in describing motion vectors in a coordinate system
established for a much wider range. MPEG-1s f_code picture header
element prescribed a radius shared by horizontal and vertical motion
vector components alike. It later became practice in industry to have a
greater horizontal search range (motion vector radius) than vertical,
since motion tends to be more prominent across the screen than up or
down (vertical).  Secondly, a decoder has a limited frame buffer size
in which to store both the current picture under decoding and the set
of pictures (forward, backward) used for prediction (reference) by
subsequent pictures.  A decoder can write over the pixels of the oldest
reference picture as soon as it no longer is needed by subsequent
pictures for prediction.  A restricted vertical motion vector range
creates a sliding window, which starts at the top of the reference
picture and moves down as the macroblocks in the current picture are
decoded in raster order.  The moment a strip of pixels passes outside
this window, they have ended their life in the MPEG decoding loop.  As
a result of all this, MPEG-2 created separate into horizontal and
vertical range specifiers (f_code[][0] for horizontal, and f_code[][1]
for vertical), and placed greater restrictions on the maximum vertical
range than on the horizontal range.  In Main Level frame pictures, this
is range is [- 128,+127.5] vertically, and [-1024,+1023.5]
horizontally. In field pictures, the vertical range is restricted to [-
64,+63.5].

Macroblock stuffing is now illegal in MPEG-2.  The original intent
behind stuffing in MPEG-1 was to provide a means for finer rate control
adjustment at the macroblock layer.  Since no self-respecting encoder
would waste bits on such an element (it does not contribute to the
refinement of the reconstructed video signal), and since this unlimited
loop of stuffing variable length codes represent a significant headache
for hardware implementations which have a fixed window of time in which
to parse and decode a macroblock in a pipeline, the element was
eliminated in January 1993 from the MPEG-2 syntax.  Some feel that
macroblock stuffing was beneficial since it permitted macroblocks to be
coded along byte boundaries.  A good compromise could have been a
limited number of stuffs per macroblock.  If stuffing is needed for
purposes of rate control, an encoder can pad extra zero bytes before
the start code of the next slice. If stuffing is required in the last
row of macroblocks of the picture, the picture start code of the next
picture can be padded with an arbitrary number of bytes.  If the
picture happens to be the last in the sequence, the sequence_end_code
can be stuffed with zero bytes.

The dct_type flag in both Intra and non-Intra coded macroblocks of
frame structured pictures signals that the reconstructed samples output
by the IDCT stage shall be organized in field or frame order.   This
flag provides an encoder with a sort of poor mans motion_type by
adapting to the interparity (i.e. interfield) characteristics of the
macroblock without signaling a need for motion vectors via the
macroblock_type variable. dct_type plays an essential role in Intra
frame pictures by organizing lines of a common parity together when
there is significant interfield motion within the macroblock.  This
increases the decorrelation efficiency of the DCT stage.   For
non-intra macroblocks, dct_type organizes the 16 lines (... luminance,
8 lines chrominance) of the macroblock prediction error. In combination
with motion_type, the meaning....


dct_type
motion_format
interpretation

frame
Intra coded
block data is frame correlated

field
Intra coded
block data is more strongly correlated along lines of 
opposite parity

frame
Field predicted
1. a low-cost encoder which only possesses frame 
motion estimation may use dct_type to decorrelate 
the prediction error of a prediction which is 
inherently field by characteristic

2. an intelligent encoder realizes that it is more bit 
efficient to signal frame prediction with field 
dct_type for the prediction error, than it is to signal 
a field prediction.

field
Field predicted
A typical scenario.  A field prediction tends to form a 
field-correlated prediction error.

frame
Frame predicted
A typical scenario.  A frame prediction tends to form a 
frame-correlated prediction error.

field
Frame predicted
Makes little sense. If the encoder went through the 
trouble of finding a field prediction in the first place, 
why select frame organization for the prediction error?


prediction modes now include field, frame, Dual Prime, and 16x8 MC.
The combinations for Main Profile and  Simple Profile are shown below.

Frame pictures
motion_type
motion 
vectors 
per MB
fundamental 
prediction block 
size (after half-
pel)
interpretation

Frame
1
16x16
same as MPEG-1, with possibly different 
treatment of prediction error via dct_type

Field
2
16x8
Two independently coded predictions are 
made: one for the 8 lines which correspond 
to the top field, another for the 8 bottom 
field lines.

Dual Prime
1
16x8
Two independently coded predictions are 
made: one for the 8 lines which correspond 
to the top field, another for the 8 bottom 
END ---------------------- CUT HERE --------------------- 2/8
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!news.mathworks.com!news2.near.net!howland.reston.ans.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!fu-berlin.de!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [3/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 10:59:09 GMT
Organization: Technical University of Berlin, Germany
Lines: 1306
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r99ht$2ni@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77875 comp.graphics.animation:20010 comp.compression:20436 comp.multimedia:36440 alt.binaries.multimedia:40193 alt.binaries.pictures.utilities:37031 alt.binaries.pictures:21186 alt.binaries.pictures.d:20799 alt.answers:9852 comp.answers:12385 news.answers:45905

Archive-name: mpeg-faq/part3
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly
BEGIN -------------------- CUT HERE --------------------- 3/8
field lines.  Uses averaging of two 16x8 
prediction blocks from fields of opposite 
parity to form a prediction for the top and 
bottom 8 lines.  A second vector is derived 
from the first vector coded in the bitstream.



Field pictures
motion_type
motion 
vectors 
per MB
fundamental 
prediction block 
size (after half-
pel)
interpretation

Field
1
16x16
same as MPEG-1, with possibly different 
treatment of prediction error via dct_type

16x8
2
16x8
Two independently coded predictions are 
made: one for the 8 lines which correspond 
to the top field, another for the 8 bottom 
field lines.

Dual Prime
1
16x16
A single prediction is constructed from the 
average of two 16x16 predictions taken from 
fields of opposite parity.



concealment motion vectors can be transmitted in the headers of intra
macroblocks to help error recovery.  When the macroblock data that the
concealment motion vectors are intended for becomes corrupt, these
vectors can be used to specify a concealment 16x16 area to be extracted
from the previous picture.  These vectors do not affect the normal
decoding process, except for motion vector predictions.

Additional chroma_format  for 4:2:2 and 4:4:4 pictures.  Like MPEG-1,
Main Profile syntax is strictly limited to 4:2:0 format, however, the
4:2:2 format is the basis of the 4:2:2 Profile (aka Studio Profile).
In 4:2:2 mode, all syntax essentially remains the same except where
matters of block count are concerned.  A coded_block_pattern extension
was added to handle signaling of the extra two prediction error
blocks.  The 4:4:4 format is currently undefined in any Profile.

chroma_format
multiplex order within Macroblock
Application

4:2:0  (6 blocks)
YYYYCbCr
main stream television, consumer entertainment.

4:2:2  (8 blocks)
YYYYCbCrCbCr
studio production environments, professional 
editing equipment, distribution and servers

4:4:4 (12 blocks)
YYYYCbCrCbCrCbCrCbCr
computer graphics



Non-linear macroblock quantization was introduced in MPEG-2 to increase
the precision of quantization at high bit rates, while increasing the
dynamic range for low bit rate use where  larger step size is needed.
The quantization_scale_code may be selected between a linear (MPEG-1
style) or non-linear scale on a picture (frame or field) basis. The new
non-linear range corresponds to a dynamic range of 0.5 to 54 with
respect to the linear (MPEG-1 style) range of 1 to 31.


Block:

alternate scan  introduced a new run-length entropy scanning pattern
generally more efficient for the statistics of interlaced video
signals. Zig-zag scan is the appropriate choice for progressive
pictures.

intra_dc_precision: the MPEG-1 DC value is mandatory quantized to a
precision of 8 bits.  MPEG-2 introduced 9, 10, and 11 bit precision set
on a picture basis to increase the accuracy of the DC component, which
by very nature, has the most significant contribution towards picture
quality.  Particularly useful at high bit rates to reduce
posterization. Main and Simple Profiles are limited to 8, 9, or 10 bits
of precision.  The 4:2:2 High Profile, which is geared towards higher
bitrate applications (up to 50 Mbits/sec), permits all values (up to 11
bits).

separate quantization matrices for Y and C: luminance (Y) and
chrominance (Cb,Cr) share a common intra and non-intra DCT coefficient
quantization 8x8 matrix in MPEG-1 and MPEG-2 Main and Simple Profiles.
The 4:2:2 Profile permits separate quantization matrices to be
downloaded for the luminance and chrominance blocks.  Cb and Cr still
share a common matrix.

intra_vlc_format:  one of two tables may now be selected at the picture
layer for variable length codes (VLCs) of AC run-length symbols in
Intra blocks.  The first table is identical to that specified for
MPEG-1 (dc_coef_next). The newer second table is more suited to the
statistics of Intra coded blocks, especially in I- frames.  The best
illustration between Table 0 and Table 1is the length of the symbol
which represents End of Block (EOB).  In Table zero, EOB is 2 bits.  In
Table one, it is 4 bits.  The implication is that the EOB symbol is
2^-n probable within the block, or from an alternative perspective,
there are an average of 3 to 4 non-zero AC coefficients in Non-intra
blocks, and 9 to 16 coefficients in Intra blocks.  The VLC tree of
Table 1 was intended to be a subset of Table 0, to aid hardware
implementations.  Both tables have 113 VLC entries (or events).

escape: When no entry in the VLC exists for a AC Run-Level symbol, an
escape code can be used to represent the symbol. Since there are only
63 positions within an 8x8 block following the first coefficient, and
the dynamic range of the quantized DCT coefficients is [-2047,+2048],
there are (63*2047), or 128,961 possible combinations of Run and Level
(the sign bit of the Level follows the VLC).  Only the 113 most common
Run-Level symbols are represented in Table 0 or Table 1.  The length of
the escape symbol (which is always 6 bits) plus the Run and Level
values in MPEG-1 could be 20 or 28 bits in length.  The 20 bit escape
describes levels in the range [-127,+127].  The 28 bit double escape
has a range of [-255, +255].  MPEG-2 increased the span to the full
dynamic range of quantized IDCT coefficients, [-2047, +2047] and
simplified the escape mechanism with a single representation for this
event.   The total length of the MPEG-2 escape codeword is 24 bits (6
bit VLC followed by a 6-bit Run value, and 12 bit Level value).  It was
an assumption by MPEG-1 designers that no quantized DCT coefficient
would need greater representation than 10 bits [-255,+255].  Note:
MPEG-2 escape mechanism does not permit the value -2048 to be
represented.

mismatch control:  The arithmetic results of all stages are defined
exactly by the normative MPEG decoding process, with the single
exception of the Inverse Discrete Cosine Transform (IDCT). This stage
can be implemented with a wide variety of IDCT implementations.  Some
are more suited for software, others for programmable hardware, and
others still for hardwired hardware designs. The IDCT reference formula
in the MPEG specification would, if directly implemented, consume at
least 1024 multiply and 1024 addition operations for every block. A
wide variety of fast algorithms exist which can reduce the count to
less than 200 multiplies and 500 adds per block by exploiting the
innate symmetry of the cosine basis functions. A typical fast IDCT
algorithm would be dwarfed by the cost of the other decoder stages
combined. Each fast IDCT algorithm has different quantization error
statistics (fingerprint), although subtle when the precision of the
arithmetic is, for example, at least 16-bits for the transform
coefficients and 24-bits for intermediate dot product values.
Therefore, MPEG cannot standardize a single fast IDCT algorithm. The
accuracy can be defined only statistically.  The IEEE 1180
recommendation (December 1990) defines the error tolerance between an
ideal direct-matrix floating point implementation (a direct
implementation of the MPEG reference formula) and the test IDCT.

Mismatch control attempts to reduce the drift between different IDCT
algorithms by eliminating bit patterns which statistically have the
greatest contribution towards mismatches between the variety of
methods. The reconstructions of two decoders will begin to diverge over
time since their respective IDCT designs will reconstruct occasional,
slightly different 8x8 blocks.

MPEG-1s mismatch control method is known canonicially as Oddification,
since it forces all quantized DCT coefficients to negative values. It
is a slight improvement over its predecessor in H.261.  MPEG-2 adopted
a different method called, again canonically, LSB Toggling, further
reducing the likelihood of mismatch. Toggling affects only the Least
Significant Bit (LSB) of the 63rd AC DCT coefficient (the highest
frequency in the DCT matrix).  Another significant difference between
MPEG-1 and MPEG-2 mismatch control is, in MPEG-1, oddification is
performed on the quantized DCT coefficients, whereas in MPEG-2,
toggling is performed on the DCT coefficients after inverse
quantization.  MPEG-1s mismatch control method favors programmable
implementation since a block of DCT coefficients when quantized.

Sample:
The two chrominace pictures (Cb, Cr) possess only half the resolution
in both the horizontal and vertical direction as the luminance picture
(Y).  This is the definition of the 4:2:0 chroma format. Most
television displays require that at least the vertical chrominance
resolution matches the luminance (4:2:2 chroma format). Computer
displays may further still demand that the horizontal resolution also
be equivalent (4:4:4 chroma format). There are a variety of filtering
methods for interpolating the chrominance samples to match the sample
density of luminance. However, the official location or center of the
lower resolution chrominance sample should influence the filter design
(relative taps weights), otherwise the chrominance plane can appear to
be shifted by a fractional sample in the wrong direction.

The subsampled MPEG-1 chroma position has a center exactly half way
between the four nearest neighboring luminance samples.  To be
consistent with the subsampled chrominance positions of 4:2:2
television signals, MPEG-2 moved the center of the chrominance samples
to be co-located horizontally with the luminance samples.


Misc.:

copyright_id extension can identify whether a sequence or subset of
frames within the sequence is copyrighted, and provides a unique 64-bit
copyright_id_number registered with the ISO/IEC.

Syntax can now signal frame sizes as large as 16383 x 16383. Since
MPEG-1 employed a meager 12-bits to describe horizontal_size and
vertical_size , the range was limited to 4095x4095.  However, MPEGs
Levels prescribe important interoperability points for practical
decoders. Constrained Parameters MPEG-1 and MPEG-2 Low Level limit the
sample rate to 352x240x30 Hz.  MPEG-2s Main Level defines the limit at
720x480x30 Hz. Of course, this is simply the restriction of the dot
product of horizontal_size, vertical_size, and frame_rate. The Level
also places separate restrictions on each of the these three
variables.

Reflecting the more television oriented manner of MPEG-2, the optional
sequence_display_extension() header can specify the chromaticy of the
source video signal as it was prior to representation by MPEG syntax.
This information includes: whether the original video_format was
composite or component, the opto-electronic transfer_characteristics,
and RGB->YCbCr matrix_coefficients. The picture_display_extension()
provides more localized source composite video characteristics on a
frame by frame basis (not field-by-field), with the syntax elements:
field_sequence, sub_carrier_phase, and burst_amplitude.  This
information can be used by the displays post-processing stage to
reproduce a more refined display sequence.

Optional pan & scan syntax was introduced which tells a decoder on a
frame-by-frame basis how to, for example, window a 4:3 image within the
wider 16:9 aspect ratio of the coded frame.  The vertical pan offset
can be specified to within 1/16th pixel accuracy.

<IMG SRC="mpeg2pan.gif">


How does MPEG syntax facilitate parallelism ?

For MPEG-1, slices may consist of an arbitrary number of macroblocks.
They can be independently decoded once the picture header side
information is known. For parallelism below the slice level, the coded
bitstream must first be mapped into fixed-length elements.  Further,
since macroblocks have coding dependencies on previous macroblocks
within the same slice, the data hierarchy must be pre-processed down to
the layer of DC DCT coefficients.  After this, blocks may be
independently inverse transformed and quantized, temporally predicted,
and reconstructed to buffer memory.  Parallelism is usually more of a
concern for encoders.  In many encoders today, block matching (motion
estimation) and some rate control stages (such as activity and/or
complexity measures) are processed for macroblocks independently.
Finally, with the exception that all macroblock rows in Main Profile
MPEG-2 bitstreams must contain at least one slice, an encoder has the
freedom to choose the slice structure.

What is the MPEG color space and sample precision?

MPEG strictly specifies the YCbCr color space, not YUV or YIQ or YPbPr
or YDrDb or any other many fine varieties of color difference spaces.
Regardless of any bitstream parameters, MPEG-1 and MPEG-2 Video Main
Profile specify the 4:2:0 chroma_format, where the color difference
channels (Cb, Cr) have half the "resolution" or sample grid density in
both the horizontal and vertical direction with respect to luminance.

MPEG-2 High Profile includes an option for 4:2:2 chroma_format, as does
the MPEG 4:2:2 Profile (a.k.a.  Studio Profile) naturally. Applications
for the 4:2:2 format can be found in professional broadcasting,
editing,  and contribution-quality distribution environments.  The
drawback of the 4:2:2 format is simply that it increases the size of
the macroblock from six 8x8 blocks (4:2:0) to eight, while increasing
the frame buffer size and decoding bandwidth by the same amount (33
%).  This increase places the buffering memories well past the magic
16-Mbit limit for semiconductor DRAM devices, assuming the pictures are
stored with a maximum of  414,720 pixels (720 pixels/line x 576
lines/frame).  The maximum allowable pixel resolution could be reduced
by 1/3 to compensate (e.g. 544 x 576). However, if a hardware decoders
operate on a macroblock basis in the pipeline, on-chip static memories
(SRAM) will increase by 1/3.  The benefits offered by 1/3 more pixels
generally outweighs full vertical chrominance resolution. Other
arguments favoring 4:2:0 over 4:2:2 include:

  Vertical decimation increases compression efficiency by reducing
  syntax overhead posed in an 8 block (4:2:2) macroblock structure.

  You're compressing the hell out of the video signal, so what possible
  difference can the 0:0:2 chromiance high-pass make?

Is 4:2:0 the same as 4:1:1 ?

No, no, definitely no.  The following table illustrates the nuances
between the different chroma formats for a frame with pixel dimensions
of 720 pixels/line x 480 lines/frame.

CCIR 601 (60 Hz) image          Chroma sub-sampling factors
format  Y               Cb, Cr  Vertical        Horizontal


chroma 
format
pixels/
line
Y
lines/
frame
Y
pixels/
line
Cb, Cr
lines/
frame
Cb, Cr
horizontal 
subsampling 
factor
vertical 
subsampling 
factor

4:4:4
720
480
720
480
none
none

4:2:2
720
480
360
480
2:1
none

4:2:0
720
480
360
240
2:1
2:1

4:1:1
720
480
180
480
4:1
none

4:1:0
720
480
180
120
4:1
4:1


3:2:2, 3:1:1, and 3:1:0 are less common variations, but have been
documented.  As shocking as it may seem, the 4:1:0 ratio was used by
Intels DVI for several years.

The 130 microsecond gap between successive 4:2:0 lines in progressive
frames, and 260 microsecond gap in interlaced frames, can introduce
some difficult vertical frequencies, but most can be alleviated through
pre- processing.

What is the sample precision of MPEG ?  How many colors 
can MPEG represent ?

By definition, MPEG samples have no more and no less than 8-bits
uniform sample precision (256 quantization levels).  For luminance
(which is unsigned) data, black corresponds to level 0, white is level
255.  However, in CCIR recommendation 601 chromaticy, luminance (Y)
levels 0 through 14 and 236 through 255 are reserved for blanking
signal excursions. MPEG currently has no such clipped excursion
restrictions, although decoder might take care to insure active samples
do not exceed these limits.  With three color components per pixel, the
total combination is roughly 16.8 million colors (i.e. 24-bits).


How are the subsampled chroma samples cited ?


It is moderately important to properly co-site chroma samples,
otherwise a sort of chroma shifting effect (exhibited as a halo) may
result when the reconstructed video is displayed.  In MPEG-1 video, the
chroma samples are exactly centered between the 4 luminance samples
(Fig 1.)   To maintain compatibility with the CCIR 601 horizontal
chroma locations and simplify implementation (eliminate need for phase
shift), MPEG-2 chroma samples are arranged as per Fig.2.

  Y   Y   Y   Y             Y   Y   Y   Y            YC  Y   YC  Y
   C       C                C         C
  Y   Y   X   Y             Y   Y   Y   Y            YC  Y   YC  Y

  Y   Y   Y   Y             Y   Y   Y   Y            YC  Y   YC  Y
    C       C               C         C
  Y   Y   Y   Y             Y   Y   Y   Y            YC  Y   YC  Y

  Fig.1 MPEG-1               Fig.2  MPEG-2           Fig.3 MPEG-2 and 
 4:2:0 organization         4:2:0 organization         CCIR Rec. 601
                                                     4:2:2 organization


How do you tell an MPEG-1 bitstream from an MPEG-2 
bitstream ?

A. All MPEG-2 bitstreams must contain specific extension headers that
immediately follow MPEG-1 headers.  At the highest layer, for example,
the MPEG-1 style sequence_header() is followed by sequence_extension().
Some extension headers are specific to MPEG-2 profiles.  For example,
sequence_scalable_extension()  is not allowed in Main Profile
bitstreams.

A simple program need only scan the coded bitstream for byte-aligned
start codes to determine whether the stream is MPEG-1 or MPEG-2.

What are start codes? 

These 32-bit byte-aligned codes provide a mechanism for cheaply
searching coded bitstreams for commencement of various layers of video
without having to actually parse variable-length codes or perform any
decoder arithmetic.  Start codes also provide a mechanism for
resynchronization in the presence of bit errors.  A start code may be
preceded by an arbitrary number of zero bytes.  The zero bytes can be
use to guarantee that a start code occurs within a certain location, or
by rate control to increase the bitrate of a coded bitstream.

Coded block pattern 

 Coded block pattern:
(CBP --not to be confused with Constrained Parameters!)  When the frame
prediction is particularly good, the displaced frame difference(DFD, or
temporal macroblock prediction error) tends to be small, often with
entire block energy being reduced to zero after quantization.  This
usually happens only at low bit rates.  Coded block patterns prevent
the need for transmitting EOB symbols in those zero coded blocks.
Coded block patterns are transmitted in the macroblock header only if
the macrobock_type flag indicates so.

Why is the DC value always divided by 8 ?

Clarification point: The DC value of Intra coded blocks is quantized by
a constant stepsize of 8 only in MPEG-1, rendering the 11-bit dynamic
range of the IDCT DC coefficient to 8-bits of accuracy. MPEG-2 allows
for DC precision of 8, 9, 10, or 11 bits.  The quantization stepsize is
fixed for the duration of the picture, set by the intra_dc_precision
flag in the picture_extension_header().

Why is there a special VLC for  DCT_coefficient_first:?

Since the coded_block_pattern in NON-INTRA macroblocks signals every
possible combination of all-zero valued and non-zero blocks, the
dct_coef_first mechanism assigns a different meaning to the VLC
codeword (run = 0, level =+/- 1) that would otherwise represent EOB
(10) as the first coefficient in the zig-zag ordered Run-Level token
list.

What’s the deal with  End of Block ?

Saves unnecessary run-length codes.  At optimal bitrates, there tends
to be few AC coefficients concentrated in the early stages of the
zig-zag vector. In MPEG-1, the 2-bit length of EOB implies that there
is an average of only 3 or 4 non-zero AC coefficients per block.  In
MPEG-2 Intra (I) pictures, with a 4-bit EOB code in Table 1, this
estimate is between 9 and 16 coefficients. Since EOB is required for
all coded blocks, its absence can signal that a syntax error has
occurred in the bitstream.

What’s  this “Macroblock stuffing,” dammit ?:

A genuine pain for VLSI implementations, macroblock stuffing was
included in MPEG-1 to maintain smoother, constant bitrate control for
encoders.  However, with normalized complexity/activity measures and
buffer management performed a priori (before coding of the macroblock,
for example) and local monitoring of coded data buffer levels now a
common operation in encoders, (e.g. MPEG-2 encoder Test Model), the
need for such localized bitrate smoothing evaporated. Stuffing can be
achieved through slice start code padding if required. A good rule of
thumb is: if you find often yourself wishing for stuffing more than
once per slice, you probably don't have a very good rate control
algorithm.  Nonetheless, to avoid any temptation, macroblock stuffing
is now illegal in MPEG-2  (A general syntax restriction brought to you
by the Implementation Studies Subgroup!)

What’s the deal with slice_vertical_position and 
macroblock_address_increment?

The absolute position of the first macroblock within a slice is known
by the combination of slice_vertical_position and the
macroblock_address_increment.  Therefore, the proper place of a lost
slice found in a highly corrupt bitstream can be located exactly within
the picture.  These two syntax elements are also the only known means
of detecting slice gaps----areas of the picture which are not
represented with any information (including skipped macroblocks).  A
slice gap occurs when the current macroblock address of the first
macroblock in a slice is greater than the previous macroblock address
by more than 1 macroblock unit. A slice overlap occurs when the current
macroblock address is less than or equal to the previous macroblocks
address.  The previous macroblock in both instances is the last known
macroblock within the previous slice. Because of the semantic
interpretation of slice gaps and overlaps, and because of the syntactic
restrictions for slice_vertical_position and
macroblock_address_increment, it is not syntactically possible for a
skipped macroblock to be represented in the first and last positions of
a slice.  In the past, some (bad) encoders would attempt to signal a
run of skipped macroblocks to the end of the slice. These evil skipped
macroblocks should be interpreted by a compliant decoder as a gap, not
as a string of skipped macroblocks.

What is meant by modified Huffman VLC tables:

The VLC tables in MPEG are not Huffman tables in the true sense of
Huffman coding, but are more like the tables used in Group 3 fax. They
are entropy constrained, that is, non-downloadable and optimized for a
limited range of bit rates (sweet spots).  A better way would be to say
that the tables are optimized for a range of ratios of bit rate to
sample rate (e.g. 0.25 bits/pixel to 1.0 bits/pixel). With the
exception of a few codewords, the larger tables were carried over from
the H.261 standard drafted in the year 1990. This includes the AC
run-level symbols, coded_block_pattern, and macroblock_address_increment.  
MPEG-2 added an "Intra table," also called "Table 1".  Note that the
dct_coefficient tables assume positive/negative coefficient PMF
symmetry.


How does MPEG handle 3:2 pulldown?

MPEG-1 video decoders had to decide for themselves when to perform 3:2
pulldown if it was not indicated in the presentation time stamps (PTS)
of the Systems layer bitstream.  MPEG-2 provides two flags
(repeat_first_field, and top_field_first) which explicitly describe
whether a frame or field is to be repeated. In progressive sequences,
frames can be repeated 2 or 3 times.  Simple and Main Profile limit are
limited to repeated fields only.  It is a general syntactic restriction
that repeat_first_field can only be signaled (value ==1) in a frame
structured picture.  It makes little sense to repeat field pictures in
an interlaced video signal since the whole process of 3:2 pulldown
conversion was meant to convert progressive, film sequences to the
display frame rate of interlaced television.

In the most common scenario, a film sequence will contain 24 frames
every second.  The bit_rate element in the sequence header will
indicate 30 frames/sec, however.  On average, every other coded frame
will signal a repeat field (repeat_first_field==1) to pad the frame
rate from 24 Hz to 30 Hz:


(24 coded frames/sec)*(2 fields/coded frame)*(5 display fields/4 coded
  fields) = 30 display frames/sec


After all this standardization, what’s left for research?


A . Despite the fact that a comprehensive worldwide standard now exists
for digital video, many areas remain wide open for research:  advanced
encoding and pre-processing, motion estimation, macroblock decision
models, rate control and buffer management in editing environments,
implementation complexity reduction, etc. Many areas have yet to be
solved ... (and discovered)..

Are some encoders better than others ?

A. Definitely. For example, the motion estimation search range of a
has  great influence over final picture quality.  At a certain point a
very large range can actually become detrimental (it may encourage
large differential motion vectors). Practical ranges are usually
between  +/- 15 and +/- 32.  As the range doubles, for instance, the
search area quadruples. (like the classic relationship between in
increase in linear vs. area).

Rate control marks a second tell-tale area where some encoders perform
significantly better than others.

And finally, the degree of "pre-processing" (now a popular buzzword in
the business) signals that the encoder belongs to an elite marketing
class.


Is the encoder standardized ?

A. The encoder rests just outside the normative scope of the standard,
as long as the bitstreams it produces are compliant.  The decoder,
however, is almost deterministic: a given bitstream should reconstruct
to a unique set of pictures. However, since the IDCT  function is the
ONLY non-normative stage in the decoder, an occasional error of a Least
Significant Bit per prediction iteration is permitted. The designer is
free to choose among many DCT algorithms and implementations.  The IEEE
1180 test referenced in Annex A of the MPEG-1 (ISO/IEC 11172-2) and
MPEG-2 (ISO/IEC 13818-2) Video specifications spells out the
statistical mismatch tolerance between the Reference IDCT, which is a
separable 8x1 "Direct Matrix" DCT implemented with 64-bit floating
point accuracy, and the IDCT you are testing for compliance.


What is the TM (Test Model) ?
What is the TM rate control and adaptive quantization technique ?

A. The Test model (MPEG-2) and Simulation Model (MPEG-1) were not, by
any stretch of the imagination, meant to epitomize state-of-the art
encoding quality.  They were, however, designed to exercise the syntax,
verify proposals, and test the relative compression performance of
proposals in a timely manner that could be duplicated by
co-experimenters.  Without simplicity, there would have been no doubt
endless debates over model interpretation.  Regardless of all else,
more advanced techniques would probably trespass into proprietary
territory.

The final test model for MPEG-2 is TM version 5b, a.k.a. TM version 6,
produced in March 1993 (the time when the MPEG-2 video syntax was
frozen). The final MPEG-1 simulation model is version 3 (SM-3).  The
MPEG-2 TM rate control method offers a dramatic improvement over the SM
method.  TM adds more accurate estimation of macroblock complexity
through use of limited  a priori information. Macroblock quantization
adjustments are computed on a macroblock basis, instead of
once-per-macroblock row (which in the SM-3 case consisted of an entire
slice).

How does the TM work?

Rate control and adaptive quantization are divided into three steps:

Step One: Target Bit Allocation

In Complexity Estimation, the global complexity measures assign
relative weights to each picture type (I,P,B).  These weights (Xi, Xp,
Xb) are reflected by the typical coded frame size of I, P, and B
pictures (see typical frame size discussion). I pictures are usually
assigned the largest weight since they have the greatest stability
factor in an image sequence and contain the most new information in a
sequence.  B pictures are assigned the smallest weight since B energy
do not propagate into other pictures and are usually more highly
correlated with neighboring P and I pictures than P pictures are.

The bit target for a frame is based on  the frame type, the remaining
number of bits left in the Group of Pictures (GOP) allocation, and the
immediate statistical history of previously coded pictures (sort of a
moving average global rate control, if you will).

Step Two:       Rate Control via Buffer Monitoring

Rate control attempts to adjust bit allocation if there is significant
difference between the target bits (anticipated bits) and actual coded
bits for a block of data.  If the virtual buffer begins to overflow,
the macroblock quantization step size is increased, resulting in a
smaller yield of coded bits in subsequent macroblocks. Likewise, if
underflow begins, the step size is decreased.   The Test Model
approximates that the target picture has spatially uniform distribution
of bits.  This is a safe approximation since spatial activity and
perceived quantization noise are almost inversely proportional.  Of
course, the user is free to design a custom distribution,  perhaps
targeting more bits in areas that contain more complex yet highly
perceptible data such as text.

Step Three:     Adaptive Quantization

The final step modulates the macroblock quantization step size obtained
in Step 2 by a local activity measure. The activity measure itself is
normalized against the most recently coded picture of the same type (I,
P, or B). The activity for a macroblock is chosen as the minimum among
the four 8x8 block luminance variances.  Choosing the minimum block is
part of the concept that a macroblock is no better than the block of
highest visible distortion (weakest link in the chain).

Decision:
[deferred to later date]

Can motion vectors be used to determine object velocity?

Motion vector information cannot be reliably used as a means of
determining object velocity unless the encoder model specifically set
out to do so.  First, encoder models that optimize picture quality
generate vectors that typically minimize prediction error and,
consequently, the vectors often do not represent true object
translation from picture-to-picture.  Standards converters that
resample one frame rate to another (as in NTSC to PAL) use different
methods (motion vector field estimation, edge detection, et al) that
are not concerned with Rate-Distortion theory. Second, motion vectors
are not transmitted for all macroblocks anyway.

Is it possible to code interlaced video with MPEG-1 syntax?

A. Two methods can be applied to interlaced video that maintain
syntactic compatibility with MPEG-1 (which was originally designed for
progressive frames only).  In the field concatenation method, the
encoder model can carefully construct predictions and prediction errors
that realize good compression but maintain field integrity (distinction
between adjacent fields of opposite parity). Some pre-processing
techniques can also be applied to the interlaced source video that
would, e.g., lessen sharp vertical frequencies.

This technique is not terribly efficient of course.  On the other hand,
if the original source was progressive (e.g. film), then it is more
trivial to convert the interlaced source to a progressive format before
encoding.  (MPEG-2 would then only offer slightly superior performance
through such MPEG-2 enhancements as greater DC coefficient precision,
non-linear mquant, intra VLC, etc.) Reconstructed frames are usually
re- interlaced in the Display process following the decoding stages.

The second syntactically compatible method codes fields as separate
pictures. Rumors have spread that this approach does not quiet work
nearly as well as the pretend its really a frame method.

Can MPEG be used to code still frames ?

Yes.  MPEG Intra pictures are similar to baseline sequential JPEG pictures.

There are, of course, advantages and disadvantages to using MPEG over
JPEG to represent still pictures.

Disadvantages:

1. MPEG has only one color space (YCbCr)

2. MPEG-1 and MPEG-2 Main Profile luma and chroma share quanitzation
and VLC tables (4:2:0 chroma_format)

3. MPEG-1 is syntactically limited to 4k x 4k images, and 16k x 16k for MPEG-2.

Advantages:

1. MPEG possesses adaptive quantization which permits better rate
control and spatial masking.

2. With its limited still image syntax,  MPEG averts any temptation to
use unnecessary, expensive, and academic encoding methods that have
little impact on the overall picture quality (you know who you are).

3. Philips' CD-I spec. has a requirement for a MPEG still frame mode,
with double SIF image resolution.  This is technically feasible mostly
thanks to the fact that only one picture buffer is needed to decode a
still image instead of the 2.5 to 3 buffers needed for IPB sequences.


Why was the 8x8 DCT size chosen?

 A. Experiments showed little compaction gains could be achieved with
 larger transform sizes, especially in light of the increased
implementation complexity. A fast DCT algorithm will require roughly
double the number of arithmetic operations per sample when the linear
transform point size is doubled. Naturally, the best compaction
efficiency has been demonstrated using locally adaptive block sizes
(e.g. 16x16, 16x8,  8x8, 8x4, and 4x4) [See Gary Sullivan and Rich
Baker "Efficient Quadtree  Coding of Images and Video," ICASSP 91, pp
2661-2664.].

Inevitably, adaptive block transformation sizes introduce additional
side information overhead while forcing the decoder to implement
programmable or hardwired recursive  DCT algorithms. If the DCT size
becomes too large, then more edges (local discontinuities) and the like
become absorbed into the transform block, resulting in wider
propagation of Gibbs (ringing) and other unpleasant phenomena.
Finally, with larger transform sizes, the DC term is  even more
critically sensitive to quantization noise.

Why was the 16x16 prediction size chosen?

The 16x16 area corresponds to the Least Common Multiple (LCM) of 8x8
blocks, given the normative 4:2:0 chroma ratio. Starting with medium
size images, the 16x16 area provides a good balance between side
information overhead & complexity and motion compensated prediction
accuracy.  In gist, experiments showed that the 16x16 was a good
trade-off between complexity and coding efficiency.

What do B-pictures buy you?

A. Since bi-directional macroblock predictions are an average of two
macroblock areas, noise is reduced at low bit rates (like a 3-D filter,
if you will).  At nominal MPEG-1 video (352 x 240 x 30, 1.15 Mbit/sec)
rates, it is said that B-frames improves SNR by as much as 2 dB. (0.5
dB gain is usually considered worth-while in MPEG). However, at higher
bit rates, B- frames become less useful since they inherently do not
contribute to the  progressive refinement of an image sequence (i.e.
not used as prediction by subsequent coded frames).  Regardless,
B-frames are still politically controversial.

B pictures are interpolative in two ways: 1. predictions in the
bi-directional macroblocks are an average from block areas of two
pictures 2. B pictures "fill in" like a digital spackle the immediate
3-D video signal without contributing to the overall signal quality
beyond that immediate point in time.  In other words, a B picture,
regardless of its internal make-up of macroblock types, has a life
limited only to itself.  As mentioned before, B picture energy does not
propagate into other frames.  In a sense, bits spent on B pictures are
wasted.

Why do some people hate B-frames?

A. Computational complexity, bandwidth, end-to-end delay, and picture
buffer size are the four B-frame Pet Peeves. Computational complexity
in the decoder is  increased since some macroblock modes require
averaging between two block predictions (macroblock_motion_forward==1
&& macroblock_motion_backward==1).

Worst case, memory bandwidth is increased an extra 15.2 MByte/s
(assuming 4:2:0 chroma_format at Main Level), not including any half
pel or page-mode overhead) for this extra directional prediction. To
really rub it in, an extra picture buffer is needed to store the future
reference picture (backwards prediction frame).  Finally, an extra
picture delay is introduced in the decoder since the frame used for
backwards prediction needs to be transmitted to the decoder and
reconstructed before the intermediate B-pictures in display order can
be decoded.

Cable television have been particularly adverse to B-frames since, for
CCIR 601 rate video, the extra picture buffer pushes the decoder DRAM
memory requirements past the magic 8- Mbit (1 Mbyte) threshold into the
evil realm of 16 Mbits (2 Mbyte).---- although 8-Mbits is fine for 352
x 480 B picture sequence. However, cable often forgets that DRAM does
not come in convenient high-volume (low cost) 8- Mbit packages as does
friendly 4-Mbit and 16-Mbit packages.  In a few years, the cost
difference between 16 Mbit and 8 Mbit will become insignificant
compared to the bandwidth savings gain through higher compression.  For
the time being, some cable boxes will start with 8-Mbit and allow
future drop-in upgrades to the full 16-Mbit.


How are interlaced and progressive pictures indicated in 
MPEG?

The following tree may help illustrate the possible layers of
progressive and interlaced coding modes:



          MPEG-2 sequence
         /               \
  progressive            interlaced sequence
  sequence                 /            \
                   Field picture        Frame picture
                                        /         \
                                       /           \
                 Frame or field prediction     Frame MB prediction only
                   /               \
               Field dct           Frame dct 



What does it mean to be compliant with MPEG ?

There are two areas of conformance/compliance in MPEG:

1. Compliant bitstreams
2. Compliant decoders

Technically speaking, video bitstreams consisting entirely of I-frames
are syntactically compliant with the MPEG specification.  The I-frame
sequence simply utilizes a rather limited subset of the full syntax.
Compliant bitstreams must obey the range limits (e.g. motion vectors
ranges, bit rates, frame rates, buffer sizes) and permitted syntax
elements in the bitstream (e.g. chroma_format, B-pictures, etc).

Decoders, however, must be able to decode all combinations of legal
bitstreams.. For example, a decoder which is incapable of decoding P or
B frames is definitely not a Main Profile or Constrained Parameters
decoder! Likewise, full arithmetic precision must be obeyed before any
decoder can be called "MPEG compliant."   The IDCT, inverse quantizer,
and motion compensated predictor must meet the accuracy requirements
defined in the MPEG document. Real-time conformance is more complicated
to measure than arithmetic precision, but it reasonable to expect that
decoders that skip frames on reasonable bitstreams are not likely to be
considered compliant.

What are Profiles and Levels?

A. MPEG-2 Video Main Profile and Main Level is analogous to MPEG-1's
CPB, with  sampling limits at CCIR 601 parameters (720x480x30 Hz  or
720x576x24 Hz).  "Profiles" limit syntax (i.e. algorithms), whereas
"Levels" limit coding parameters (sample rates, frame dimensions, coded
bitrates, etc.). Together, Video Main Profile and Main Level
(abbreviated as MP@ML) normalize complexity within feasible limits of
1994 VLSI technology (0.5 micron), yet still meet the needs of the
majority of applications. MP@ML is the conformance point for most cable
and satellite TV systems.

[insert a description of each Profiles and Levels here]

Can MPEG-1 encode higher sample rates than 352 x 240 x 30 Hz ?

A. Yes. The MPEG-1 syntax permits sampling dimensions as high as 4095 x
4095 x 60 frames per second.  The MPEG most people think of as "MPEG-1"
is really a kind of subset known as Constrained Parameters bitstream
(CPB).

What are Constrained Parameters Bitstreams?

MPEG-1 CPB are a limited set of sampling and bitrate parameters
designed to normalize decoder computational complexity, buffer size,
and memory bandwidth while still addressing the widest possible range
of  applications. The parameter limits were intentionally designed to
permit decoder implementations integrated with 4 Megabits (512 Kbytes)
of DRAM.

Bitstream Parameter
Limit 

pixels/line
704

lines/frame
480 or 576

pixels/frame
101,376 pixels

pixels/second
2,534,400

frames/sec
30 Hz

bit rate
1.86 Mbit/sec

buffer size
40 Kbytes


The sampling limits of CPB are bounded at the ever popular SIF rate:
396 macroblocks (101,376 pixels) per picture if the picture rate is
less than or equal to 25 Hz, and 330 macroblocks (84,480 pixels) per
picture if the picture rate is 30 Hz. The MPEG nomenclature loosely
defines a pixel or "pel" as a unit vector containing a complete
luminance sample and one fractional (0.25 in 4:2:0 format) sample from
each of the two chrominance (Cb and Cr) channels. Thus, the
corresponding bandwidth figure can be computed as:

	 352 samples/line x 240 lines/picture x 30 pictures/sec x 1.5
	 samples/pixel

 or 3.8 Ms/s (million samples/sec) including chroma, but not including
 blanking intervals.  Since most decoders are capable of sustaining VLC
decoding at a faster rate than 1.8 Mbit/sec, the coded video bitrate
has become the most often waived parameter of CPB. An encoder which
intelligently employs the syntax tools should achieve SIF quality
saturation at about 2 Mbit/sec, whereas an encoder producing streams
containing  only I (Intra) pictures might require as much as 8 Mbit/sec
to achieve the same video quality.

Why is Constrained Parameters so important?

 A. It is an optimum point that allows (just barely) cost effective
 VLSI implementations in 1992 technology (0.8 microns).  It also
implies a nominal guarantee of interoperability for decoders and a
reasonable class of performance for encoders.  Since CPB is the most
popular canonical MPEG-1 conformance point, MPEG devices which are not
capable of at least meeting SIF rates are usually not considered to be
true MPEG by industry.

 Picture buffers (i.e. "frame stores") and coded data buffering
 requirements for MPEG-1 CPB fit just snugly into 4 Mbit of memory
(DRAM).

Who uses constrained parameters bitstreams?

A. Principal CPB applications are Compact Disc video (White Book or
CD-I) and desktop video.  Set-top TV decoders fall into a higher
sampling rate category known as "CCIR 601" or "Broadcast rate," which
as a rule of   thumb, has sampling dimensions and bandwidth 4 times
that of SIF (Constrained Parameter sample rate limit).

Are there ways of circumventing constrained parameters bitstreams for
SIF  class applications and decoders ?

 A. Yes, some.  Remember that CPB limits pictures by macroblock count
 (or pixels/frame). 416 x 240 x 24 Hz sampling rates are still within
these constraints. Deviating from 352 samples/line could throw off many
decoder implementations which possess limited horizontal sample rate
conversion abilities. Some decoders do in fact  include a few rate
conversion modes, with a filter usually implemented via binary taps
(shifts and adds).  Likewise, the target sample rates are usually
limited or ratios (e.g. 640, 540, 480 pixels/line, etc.).  Future MPEG
decoders will likely include on-chip arbitrary sample rate converters,
perhaps capable of operating in the vertical direction (although there
is little need of this in applications using standard TV monitors where
line count is constant, with the possible exception of windowing in
cable box graphical user interfaces).

Also, many CD videos are letterboxed at the 16:9 aspect ratio.  The
actual coded and display sampling dimensions are 384 x 216 (note
384/216 = 16/9).  These programs are typically movies coded at the more
manageable 24 frames/sec.

Are there any other conformance points like CPB for MPEG-1?

 A. Undocumented ones, yes.  A second generation of decoder chips
 emerged on the market   about 1 year after the first wave of SIF-class
decoders.  Both LSI Logic and SGS-Thomson introduced CCIR 601 class
MPEG-1 video decoders to fill in the gap between canonical MPEG-1 (SIF)
and the emergence of Main Profile at Main Level (CCIR 601) MPEG-2
decoders.  Under non-disclosure agreement, C-Cube had the  CL- 950,
although since Q2'94, the CL-9100 is now the full MPEG-2 successor in
production.  MPEG-1 decoders in the CCIR 601 class, or Main Level, were
all too often called MPEG-1.5 or MPEG-1++ decoders.  For the first year
of operation, the Direct Broadcasting Satellite service in the United
States (Hughes Direct TV and Hubbards USSB) called only upon MPEG-1
syntax to represent interlaced video before switching to full MPEG-2
syntax.

What frame rates are permitted in MPEG?

A limited set is available for the choosing in MPEG-1 and the currently
defined set of Profiles and Levels of MPEG-2, although "tricks" could
be played with Systems-layer Time Stamps to convey non-standard picture
rates.  The set is: 23.976 Hz (3-2 pulldown NTSC), 24 Hz (Film),  25 Hz
(PAL/SECAM or 625/60 video), 29.97 (NTSC), 30 Hz (drop-frame NTSC  or
component 525/60), 50 Hz (double-rate PAL), 59.97 Hz (double rate
NTSC),  and 60 Hz (double-rate, drop-frame NTSC/component 525/60
video).

Only 23.976, 24, 25, 29.97, and 30 Hz are within the conformance space
of Constrained Parameter Bitstreams and Main Level.


What areas can be improved upon to create a better syntax 
than MPEG?

Several  improvements can be made to the MPEG syntax while remaining
within the framework of block based coding. As implementation
technology improves with time, the ratio of computation to sample rate
can be increased for the same implementation cost. With each
evolutionary stage in the shrinking of the semiconductor lithography
process (line width), more complex coding methods become economically
realizable. Some of the well-known or well-anticipated areas for
improvement are described below:

Intra coding:
For intra pictures, subband methods such as wavelets combined with
improved quantization and entropy coders could gain as much as 2-4 dB
over MPEG Intra pictures.  The problem becomes more complex when
considering the coding of Intra Macroblocks in mixed pictures, such as
P or B, since the extend of a subband must, in the simplest of
schemes,  be limited to the dimensions of a macroblock.


Prediction error coding
One of the strongest gripes against MPEG is the use of the DCT for
decorrelation of prediction error blocks.  One explanation is that the
DCT is suited for the statistical correlation of intra signals, but
less suited for the statistics of prediction error (Non-Intra) signals.
One common proposal is to replace the DCT with a Vector Quantizer.
Prediction error (Non-intra) blocks typically contain far fewer bits
than intra blocks.  (The bits that comprise a Non-intra blocks can be
thought of as having been previously distributed over previous blocks
in previous pictures in the form of coefficients and side
information...)

Finer coding unit granularity’s:
The size of the transform block could be made smaller, larger, or both
(myriad of different sizes).  Likewise, the size of the motion
compensation block can be made larger or smaller.  The cost is more
complex semantics (more decoder complexity) and the overhead bits to
select the block size.  Instead of sharing the same side information,
the blocks within the macroblock could be assigned their own motion
vectors, macroblock quantization scale factors, etc.

Many advanced techniques were in investigated by MPEG during the
formative stages of the specification, but were eventually eliminated
for falling below a threshold set for coding gain vs. implementation
complexity. Often, proposals presented a significant departure from the
main stream algorithms under consideration. Each bit added to the
syntax, or rule added to the semantics represents several gates to a
silicon implementation, or from a software perspective, an extra table,
if-then or case statement at multiple points in the decoding program.



What are the similarities and differences between MPEG and 
H.263

During its formative stages, H.263 was known as "H.26P" or "H.26X". It
is an ITU-T standard for low-bitrate video and audio teleconferencing.
It is designed to be more efficient (at least 2dB) than H.261 for bit
rates below 64 kbits/sec (ISDN B channel).  The primary target bit
rate, approximately 27,000 bits/sec,  is the payload rate of the V.34
(a.k.a "V.Fast" or "V.Last") modem standard.  In a typical scenario, 20
kbit/sec would be allocated for the video portion, and 6.5 kbit/sec for
the speech portion.

Since the H.261 syntax was defined in 1990, techniques and
implementation power have naturally improved.  H.263 collects many of
the advanced  methods proposed during MPEGs formative stages into a
syntax which shares a common basis more with MPEG-1 video than with
H.261.

The detailed differences and similarities are summarized below:

Sample rate, precision, and color space:
H.263 pictures are transmitted with QCIF dimensions.  MPEG and JPEG
allow nearly any picture size to be described in the headers.  A fixed
picture size promotes interoperability by forcing all implementors to
operate at a common rate, rather than by allowing implementors to get
away with whatever lowest sample rate the consumer can be tricked into
buying.  Another reason for a fixed sample rate is that, unlike MPEG
which is generic, H.263 is geared towards a specific application
(teleconferencing).  Other MPEG applications such as CD Video and Cable
TV define their own fixed parameters. Chromaticy is again YCbCr, 4:2:0
macroblock structure, and 8 bits of uniform sample precision.

[details deferred]



How would you describe MPEG to the Data Compression 
expert?

A. MPEG video is a block-based coding scheme.


How does MPEG video really compare to TV, VHS, laserdisc ?

A. VHS picture quality can be achieved for film source video at about 1
million bits per second (with careful application of proprietary
encoding methods).  Objective comparison of  MPEG to VHS is complex.
The luminance response curve of VHS places -3 dB (50% response, the
common definition of bandlimit) at around analog 2 MHz (digital
equivalent to 200 samples/line). VHS chroma is considerably less dense
in the horizontal direction than MPEG's 4:2:0 signal (compare 80
samples/line equivalent to 176 !!).  From a sampling density
perspective, VHS is superior only in the vertical direction (480
luminance lines compared to 240).  When other analog factors are taken
into account, such as interfield crosstalk and the TV monitor Kell
factor, the perceptual vertical advantage becomes much less than 2:1.
VHS is also prone to such inconveniences as timing errors (an annoyance
addressed by time base correctors), whereas digital video is fully
discretized. Duplication processes for pre-recorded VHS tapes at high
speeds (5 to 15 times real time playback speed)  introduces additional
handicaps. In gist, MPEG-1 at its nominal parameters can match VHSs
sexy low-pass-filtered look, but for critical sequences, is probably
overall inferior to a well mastered, well duplicated VHS tape.

With careful coding schemes, broadcast NTSC quality can be approximated
at about 3 Mbit/sec, and PAL quality at about 4 Mbit/sec for film
source video.  Of course, sports  sequences with complex spatial-
temporal activity should be treated with higher bit rates, in the
neighborhood of  5 and 6 Mbit/sec. Laserdisc is perhaps the most
difficult medium to make comparisons with.

First, the video signal encoded onto a laserdisc is composite, which
lends the signal to the familiar set of artifacts (reduced color
accuracy of YIQ, moirse patterns, crosstalk, etc).  The medium's
bandlimited signal is often defined by laserdisc player manufacturers
and main stream publications as capable of rendering up to 425 TVL (or
frequencies with Nyquist at 567 samples/line). An equivalent component
digital representation would therefore have sampling dimensions of 567
x 480 x  30 Hz. The carrier-to-noise ratio of a laserdisc video signal
is typically better  than 48 dB.  Timing accuracy is excellent,
certainly better than VHS.  Yet some of the clean characteristics of
laserdisc can be simulated with MPEG-1 signals as low as 1.15 Mbit/sec
(SIF rates),  especially for those areas of medium detail (low spatial
activity) in the presence of uniform motion (affine motion vector
fields). The appearance of laserdisc or Super VHS quality can therefore
be obtained for many video sequences with low bit rates, but for the
more general class of images sequences, a bit rate ranging from 3 to 6
Mbit/sec is necessary.


What are the typical coded sizes for the MPEG frames?

Typical bit sizes for the three different picture types:
Level
I
P
B
Average

30 Hz SIF
@ 1.15 Mbit/sec
150,000
50,000
20,000
38,000

30 Hz CCIR 601
@ 4 Mbit/sec
400,000
200,000
80,000
130,000


Note: the above example is taken from a standard test sequence coded by
the Test Model method, with an I frame distance of 15 (N = 15), and a P
frame distance of 3 (M = 3).

Of course, among differing source material, scene changes, and use of
advanced encoder models these numbers can be significantly different.

At what bitrates is MPEG-2 video optimal? 

The Test subgroup has defined a few example "Sweet spot" sampling
dimensions and bit rates for MPEG-2:

Dimensions
Coded rate
Application

352x480x24 Hz 
(progressive)
2 Mbit/sec
Equivalent to VHS quality.  Intended for film source video. Half 
horizontal 601(HHR).  Looks almost broadcast NTSC quality

544x480x30 Hz 
(interlaced).
4 Mbit/sec
PAL broadcast quality (nearly full capture of 5.4 MHz luminance 
signal).  544 samples matches the width of a 4:3 picture windowed 
within 720 sample/line 16:9 aspect ratio via pan&scan

704x480x30 
Hz.(interlaced)
6 Mbit/sec
Full CCIR 601 sampling dimensions


These numbers may be too ambitious.  Bit rates of 3, 6, and 8 Mbit/sec
respectively provide transparent quality for the above application
examples when generated by a reasonably sophisticated encoder.

Why does film perform so well with MPEG ?


1. The frame rate is 24 Hz (instead of 30 Hz) which is a savings of
some 20%.

2. Film source video is inherently progressive.  Hence no fussy
interlaced spectral frequencies.

3. The pre-digital source was severely oversampled (compare 352 x 240
SIF to 35 millimeter film at, say, 3000 x 2000 samples).  This can
result in a very high quality signal, whereas most video cameras do not
oversample, especially in the vertical direction.

4. Finally, the spatial and temporal modulation transfer function (MTF)
characteristics (motion blur, etc) of film are more amenable to the
transform and quantization methods of MPEG.

What is the best compression ratio for MPEG ?

The MPEG sweet spot is about 1.2 bits/pel Intra and 0.35 bits/pixel
inter. Experimentation has shown that intra frame coding with the
familiar DCT-Quantization-Huffman hybrid algorithm achieves optimal
performance at about an average of 1.2 bits/sample or about 6:1
compression ratio. Below this point, artifacts become non-transparent.

Is there an MPEG file format?

The traditional descriptors that file formats provide in headers, such
image height, width, color space, etc., are already embedded within the
MPEG bitstream in the sequence header.  Directory file formats are
described in the White Book and DVD specifications.


What is the Digital Video Disc (DVD) ?

In 1994, Toshiba united with Thomson Consumer Electronics, Pioneer, and
a handful of Hollywood studios to define a new 12 cm diameter compact
disc format for broadcast rate digital video. The new format basically
increases the effective areal storage density over the 1982 Red Book
format by some 6:1 (800 Mbytes vs 5 GBytes).  This is achieved through
a combination of shorter laser wavelength, finer track pitch, inter-pit
pitch, and better optics. The thickness of the disc is reduced from the
Red Book's 1.2 millimeters to 0.6 millimeters. However, the new format
can be glue two 0.6 mm thick discs back-to-back, forming a double- size
disc 1.2 mm thick with a total capacity of 10 Gbytes. A two hour movie,
encoded onto only one side, would contain a video bistream average at 5
Mbit/sec. Or 10 Mbit/sec if distributed on both sides of a disc.  Most
of the 6:1 gain is achieved though more efficient encoding of bits onto
the disc.  Only a 2:1 factor comes purely from the reduction in
wavelength.

By comparison, today's double-sided analog video laserdiscs have a
diameter of 30 cm (571 cm^2 of usable area), and a thickness of 2.4
millimeters.  Storage capacity is a maximum of 65 minutes per side.

A future potential format for HDTV may employ a blue wavelength laser
(0.4 microns), offering another 2:1 increase in areal density, or 20
Gbytes total.  Other alternatives include larger disc sizes. For
example, if bit coding at DVD areal densities were applied to the
familiar 30 cm disc, the average bitrate for the 65 minutes of video
per side would be nearly 70 Mbit/sec !!





What is the MPEG committee ?

 In fact, MPEG is a nickname.  The official title is: ISO/IEC JTC1 SC29 WG11.

END ---------------------- CUT HERE --------------------- 3/8
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!news.sprintlink.net!EU.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!fu-berlin.de!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [4/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 11:00:57 GMT
Organization: Technical University of Berlin, Germany
Lines: 1306
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r99l9$2rr@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77873 comp.graphics.animation:20008 comp.compression:20435 comp.multimedia:36439 alt.binaries.multimedia:40192 alt.binaries.pictures.utilities:37030 alt.binaries.pictures:21185 alt.binaries.pictures.d:20798 alt.answers:9851 comp.answers:12384 news.answers:45904

Archive-name: mpeg-faq/part4
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly
BEGIN -------------------- CUT HERE --------------------- 4/8
   ISO:  International Organization for Standardization
   IEC:  International Electrotechnical Commission
   JTC1: Joint Technical Committee 1
   SC29: Sub-committee 29
   WG11: Working Group 11  (moving pictures with... uh, audio)


What ever happened to MPEG-3 ?

MPEG-3 was to have targeted HDTV applications with sampling dimensions
up to 1920 x 1080 x 30 Hz and coded bitrates between 20 and 40
Mbit/sec.  It was later discovered that with some (syntax compatible)
fine tuning, MPEG-2 and MPEG-1 syntax worked very well for HDTV rate
video.  The key is to maintain an optimal balance between sample rate
and coded bit rate.

 Also, the standardization window for HDTV was rapidly closing.  Europe
 and the United States were on the brink of committing to
analog-digital subnyquist hybrid algorithms (D-MAC, MUSE, et al).  By
1992, European all-digital projects such as HD-DIVINE and VADIS
demonstrated better picture quality with respect to bandwidth using the
MPEG syntax.  In the United States, the Sarnoff/NBC/Philips/Thomson
HDTV consortium had used MPEG-1 syntax from the beginning of its
all-digital proposal, and with the exception of motion artifacts (due
to limited search range in the encoder), was deemed to have the best
picture quality of all three digital proponents in the early 1993
bake-off. HDTV is now part of the MPEG-2 High-1440 Level and High Level
toolkit.




Why bother having an MPEG-2 ?

A. MPEG-1 was optimized for CD-ROM or applications at about 1.5
Mbit/sec. Video was strictly non- interlaced (i.e. progressive).  The
international cooperation executed well enough for MPEG-1, that the
committee began to  address applications at broadcast TV sample rates
using the CCIR 601 recommendation (720 samples/line by 480 lines per
frame by 30 frames per second or about 15.2 million samples/sec
including chroma) as the reference.

Unfortunately, today's TV scanning pattern is interlaced.  This
introduces a duality in block coding:  do local redundancy areas
(blocks) exist exclusively in a field or a frame.(or a particle or
wave) ?  The answer of course is that some blocks are one or the other
at different times, depending on motion activity. The additional man
years of experimentation and implementation between MPEG-1 and MPEG-2
improved the method of block-based transform coding.

It is often remarked that MPEG-2 spent several hundred man years and
10s of millions of dollars yet only gained 20% coding efficiency over
MPEG-1 for interlaced video signals.  However, the collaborative
process brought companies together, and from that came a standard well
agreed upon.  In many ways, the political achievement dwarfs the
technical one.  Also, MPEG-2 was exploratory.  Coding of interlaced
video was unknown territory.  It took some considerable convincing to
demonstrate that a simple syntax, akin to MPEG-1, was as efficient as
other proposals.  Left by themselves, each company would probably have
produced a diverse scope of syntax.

Is MPEG patented ?

Many of the companies which participated in the MPEG committee have
indicated that they hold patents to fundamental elements of the MPEG
syntax and semantics.  Already, the group known as the "IRT consortium"
(CCETT, IRT, et al) have defined royalty fees and licensing agreements
for OEMs of MPEG Layer I and II audio encoders and decoders.  The fee
is $1 USD per audio channel in small quantities, and $0.50 USD per
channel in large quantities.

A royalty and licensing agreement has yet to be reached among holders
of  Video and Systems patents, however the figure has already been
agreed upon, ranging from $3 to $4 per implementation. Whether it is
retroactively applicable or not to products already sold, or whether it
is possible to avoid the patents via approximation techniques, is not
known. The non-profit organization,CableLabs (Boulder, Colorado), is
responsible for leading the MPEG Intellectual Property Rights effort
(known canonically as the "MPEG Patent Pool.").  An agreement is
expected by mid 1995.

In order to reach the IS (International Standard) document stage, all
parties must have sent in a letter to ISO stating they agree to license
their intellectual property on fair and reasonable terms,
indiscriminately. For MPEG-1 and MPEG-2, this was accomplished in mid
1993.

Companies which hold patents often cross-license each other.  Each
party does not have to pay royalties to one another.

What is White Book

The White Book specifies the file structure and indexing of multiplexed
MPEG video and audio streams.  White Book also specifies  the Karaoke
application's reference table which describes programs and their sector
locations.  At the lowest layer, White Book builds upon the CD-ROM XA
spec.. Extension data includes screen pointing devices, address list of
all Intra pictures within a program, CD version number, Closed Caption
data, and information indexing of MPEG still pictures.

The specific MPEG parameter definitions of White Book are:

Audio coding method:  MPEG-1 Layer II
Sampling rate:  44.1 kHz
Coded bit rate:  224 Kbits/sec
Mode:  stereo, dual channel, or intensity stereo

Video coding method:  MPEG-1
Permitted sample rates: 
352 pixels/line x 240 lines/frame x 29.97 frames/sec    (NTSC rate)
352 pixels/line x 240 lines/frame x 23.976 frames/sec  (NTSC film rate)
352 pixels/line x 288 lines/frame x 25 frame/sec          (PAL rate)
Maximum bitrate:  1.1519291 bits/sec

Recommendations include:
   pixel aspect ratios:  1.0950 (352x240) or 0.9157 (352 x 288)
  Intra pictures be placed at least once every 2 seconds.

Still pictures: ("Intra" picture_coding_type only) 
  Normal res:  352 x 240    or   352 x 288  (maximum 46 Kbytes coded size)
  Double res:   704 x 480    or   704 x 576  (maximum 224 Kbytes coded size)


The other books are:

Red Book:  this is the original Compact Disc Audio specification (circa
1980).  All other books (Yellow, Green, Orange, White) are identical at
the low-level, sharing a common base with Red Book.  This grandfather
specification defines sectors, tracks, and channel coding (8/14 EFM
outer forward error correction (FEC), 8-bit polynomial interleaved
Reed-Soloman inner forward error correction, etc), and physical
parameters (disc diameter 12 cm, laser wavelength 0.8 microns, track
pitch, land-to-pit spacing, digital modulation, etc.).

Yellow Book: first CD-ROM specification (circa 1986).  Later appended
by the CD-ROM XA spec.

Green Book: CD-I (Compact Disc Interactive).

Orange Book:  Kodak Photo CD

ISO 9660: (circa 1988) describes file structure for CD-ROM XA (circa
1988). Similar to MS-DOS, filenames are case insensitive and limited to
8 characters, and 3 extension characters (8.3 format).  Many CD-ROMs
containing MPEG are nothing more than Yellow Book CD which treat
multiplexed video and audio bitstreams as an ordinary file.


Further information can be retrieved from:

Philips Consumer Electronics B.V.
Coordination Office Optical & Magnetic Media Systems
Building SWA-1
P.O. Box 80002
5600 JB Eindhoven
The Netherlands
Tel: +31 40 736409
Fax: +31 40 732113



What are some typical picture sizes and their associated 
applications ?


352 x 240	SIF.  CD WhiteBook Movies, video games.
352 x 480	HHR.  VHS equivalent
480 x 480	Bandlimited (4.2 Mhz) broadcast NTSC.
544 x 480	Laserdisc, D-2, Bandlimited PAL/SECAM.
640 x 480	Square pixel NTSC
720 x 480	CCIR 601. Studio D-1. Upper limit of Main Level.



Future topics:

How are MPEG video and audio streams synchronized?
What is Digital Video Cassette (DVC) ?
How does the D-VHS format encode MPEG signals?
What is MPEG-4 ?
The high level and low level differences between MPEG, JPEG, H.261, and H.263
MPEG in applications
More on DVD.
Details on DVB
Implementations (semiconductor chips)
Software Complexity and performance.  Well known speedup methods.
MPEG software on the Internet (audio, video, systems)
Specific MPEG articles in literature.
Current activities of MPEG-4
MPEG Compliance bitstreams

-----
cfogg@chromatic.com

-------------------------------------------------------------------------------

~Subject: What happened at the MPEG - NY meeting ?

From: cfogg@ole.cdac.com (Chad Fogg)
Date: 22 Jul 93 05:31:41 GMT

INTERNATIONAL ORGANISATION FOR STANDARDISATION
ORGANISATION INTERNATIONALE DE NORMALISATION
ISO/IEC JTC1/SC29/WG11
CODING OF MOVING PICTURES AND ASSOCIATED AUDIO

ISO/IEC JTC1/SC29/WG11  N0500
July 16, 1993

Source:	ISO/IEC JTC1/SC29/WG11
~Title:	Press Release (Final) -- MPEG New York Meeting
Status:	For immediate release


Summary

This week in New York, at a meeting hosted by Columbia University, the 
Moving Picture Experts Group (MPEG) completed definition of MPEG-2 
Video, MPEG-2 Audio, and MPEG-2 Systems.  MPEG therefore confirmed 
that it is on schedule to produce, by November 1993, Committee Drafts of 
all three parts of the MPEG-2 Standard, for balloting by its member 
countries.

To ensure that a harmonized solution to the widest range of applications 
is achieved, MPEG, an ISO/IEC working group designated ISO/IEC 
JTC1/SC29/WG11, is working jointly with the ITU-TS Study Group 15 
"Experts Group for ATM Video Coding." MPEG also collaborates with 
representatives from other parts of ITU-TS, and from EBU, ITU-RS, SMPTE, 
and the North American HDTV community.


MPEG-2 Video

MPEG is developing the MPEG-2 Video Standard, which specifies the coded 
bit stream for high-quality digital video.  As a compatible extension, 
MPEG-2 Video builds on the completed MPEG-1 Video Standard (ISO/IEC IS 
11172-2), by supporting interlaced video formats and a number of other 
advanced features, including features to support HDTV.  

As a generic International Standard, MPEG-2 Video is being defined in 
terms of extensible profiles, each of which will support the features 
needed by an important class of applications. At the March MPEG meeting 
in Sydney, the MPEG-2 Main Profile was defined to support digital video 
transmission in the range of about 2 to 15 Mbits/sec over cable, satellite, 
and other broadcast channels, as well as for Digital Storage Media (DSM) 
and other communications applications. Building on this success at this 
week's New York meeting, MPEG experts from participating countries in 
Asia, Australia, Europe, and North America further defined parameters of 
the Main Profile and Simple Profile suitable for supporting HDTV formats.

This week the MPEG experts also extended the features of the Main Profile 
by defining a hierarchical/scalable profile.  This profile aims to support 
applications such as compatible terrestrial TV/HDTV, packet-network 
video systems, backward-compatibility with existing standards (MPEG-1 
and H.261), and other applications for which multi-level coding is 
required.  For example, such a system could give the consumer the option 
of using either a small portable receiver to decode standard definition TV, 
or a larger fixed receiver to decode HDTV from the same broadcast signal.

This week's accomplishments in New York mean that the technical 
definition of MPEG-2 Video has been completed.  This was a critical 
milestone, and shows that MPEG-2 Video is on schedule for a Committee 
Draft in November.


MPEG-2 Audio

MPEG is developing the MPEG-2 Audio Standard for low bitrate coding of 
multichannel audio. MPEG-2 Audio coding will supply up to five full 
bandwidth channels (left, right, center, and two surround channels), plus 
an additional low frequency enhancement channel, and/or up to seven 
commentary/multilingual channels. The MPEG-2 Audio Standard will also 
extend the stereo and mono coding of the MPEG-1 Audio Standard (ISO/IEC 
IS 11172-3) to half sampling-rates (16 kHz, 22.05 kHz, and 24 kHz), for 
improved quality for bitrates at or below 64 kbits/s, per channel.

This week in New York, MPEG produced an updated version of the MPEG-2 
Audio Working Draft, and is on track for achieving a Committee Draft 
specification by the November MPEG meeting.

The MPEG-2 Audio multichannel coding Standard will provide 
backward-compatibility with the existing MPEG-1 Audio Standard 
(ISO/IEC IS 11172-3). Together with ITU-RS, MPEG is organizing formal 
subjective testing of the proposed MPEG-2 multichannel audio codecs and 
up to three non-backward-compatible (NBC) codecs. The NBC codecs are 
included in order to determine whether an NBC mode should be introduced 
as an addendum to the standard. If the results show clear evidence that an 
NBC mode improves the performance, a formal call for NBC proposals will 
be issued by MPEG, with a view to incorporate these features in the audio 
syntax.


MPEG-2 Systems

<IMG SRC="mpeg2sys.gif">

MPEG is developing the MPEG-2 Systems Standard to specify coding 
formats for multiplexing audio, video, and other data into a form suitable 
for transmission or storage. There are two data stream formats defined: 
the Transport Stream, which can carry multiple programs simultaneously, 
and which is optimized for use in applications where data loss may be 
likely, and the Program stream, which is optimized for multimedia 
applications, for performing systems processing in software, and for 
MPEG-1 compatibility.

Both streams are designed to support a large number of known and 
anticipated applications, and they retain a significant amount of 
flexibility such as may be required for such applications, while providing 
interoperability between different device implementations.  The 
Transport Stream is well suited for transmission of digital television and 
video telephony over fiber, satellite, cable, ISDN, ATM, and other 
networks, and also for storage on digital video tape and other devices.  It 
is expected to find widespread use for such applications in the very near 
future.

The Program Stream is similar to the MPEG-1 Systems standard (ISO/IEC 
11172-1).  It includes extensions to support new and future applications.  
Both the Transport Stream and Program Stream are built on a common 
Packetized Elementary Stream packet structure, facilitating common 
video and audio decoder implementations and stream type conversions.  
This is well-suited for use over a wide variety of networks with 
ATM/AAL and alternative transports. This week in New York, MPEG 
completed definitions of the features, syntax, and semantics of the 
Transport and Program Streams, enabling product designers to proceed.  
Among other items, the Transport Stream packet length was fixed at 188 
bytes, including the 4-byte header.  This length is suited for use with ATM 
networks, as well as a wide variety of other transmission and storage 
systems.


MPEG-4

Work on a new MPEG initiative for very low bitrate coding of audiovisual 
programs has been approved by unanimous ballot of all national bodies of 
ISO/IEC JTC1. This work will begin officially at the next MPEG meeting in 
Brussels in September 1993.  It is scheduled to result in a draft 
specification in 1997.

This work will require the development of fundamentally new algorithmic 
techniques.  In conjunction with the MPEG meeting this week in New York, 
a one-day seminar was held on current research ideas applicable to low 
bitrate coding.  Demonstrations and papers were presented on a number of 
techniques, including model-based image coding, human interaction with 
multimedia environments, and low-bitrate speech coding.

When completed, the MPEG-4 standard will enable a whole spectrum of 
new applications, including interactive mobile multimedia 
communications.

===========================================================================

~Subject: SECTION 2. - PROFESSIONAL SOFTWARE

The named tools are:

SECTION 2. - PROFESSIONAL SOFTWARE
SUBSECTION - DOS
    MPEG Encoder by Xing
SUBSECTION - WINDOWS
    MPEG ARCADETM
    XingSound
    XingCD
SUBSECTION - UNIX
    NVR Research Kit
    Demo of NVR Digital Media Development Kit
    How will I get the NVR-Software ?

-------------------------------------------------------------------------------

~Subject: SUBSECTION - DOS

-------------------------------------------------------------------------------

~Subject: MPEG Encoder by Xing

The MPEG Encoder is available starting from 349.-DM incl. VAT.
BTW, the encoder still sells for 349.-DM and the MCI-driver for 199.-DM

[ The MCI-driver is nice, because it allows you to include movies in      ]
[ other documents. But it includes only the MPLAYER.EXE-icon in the       ]
[ document (not the first picture of the movie), the movie runs at        ]
[ whatever position (not where the icon is !), when you double-click it.  ]

[ Xing should have a close look at Microsoft's AVI-driver ;o) (but there  ]
[ movies are incredible slow and small, compared to MPEG  :o(             ]

---------------------------------------------------------------------------

~Subject: SUBSECTION - WINDOWS

---------------------------------------------------------------------------

~Subject: MPEG ARCADETM

Mediamatics Inc.'s MPEG ARCADETM Player is a software only, full
implementation of the MPEG-I ISO 11172 standard. The entire MPEG-1
decompression, both video and audio is implemented in software (along with
system stream parsing and video/audio synchronization). Finally, a MCI-DV
Media Player interface is provided to control/playback MPEG-1 encoded system
stream files. This media player is  fully compliant with OPEN PC MPEG
consortium's MpegVideo command set. This player will soon be available in
the retail market from major manufacturers of graphics cards, who will be
bundling our Arcade Player with their recently announced video-enabled
graphics cards. Arcade Player is currently offered only
to OEMs and has been licensed by Brooktree, Western Digital.

Arcade Player - Key Features:
*  Performance benchmarks:
    24-30 fps with synchronized audio on a Pentium  PCI system with a video
enabled graphics card.
   [Note: assumes graphics subsystem to contain a hardware color space
converter]
*  Supports Windows 3.1, Windows95TM and Windows NT operating system.
*  Supports playback of CD-I/VideoCD/CD-Karaoke format encoded content.
*  Tested with major DCI-aware graphics devices from companies such as
   Brooktree, Western Digital, Trident, S3, Cirrus, Avance, Alliance etc.

For More information:
Mediamatics Inc.
4633 Old Ironsides Drive #328
Santa Clara, CA 95054
Ph: 408-496-6360
Fx: 408-496-6634
Email: info@mediamatics.com

---------------------------------------------------------------------------

~Subject: XingSound

[ Well, the encoder costs, but the decoder is PD ! But, attention ]
[ they say, they support full-MPEG-audio, but sure they are not.  ]
[ They do dirty tricks again, had a look at the streams, tststs   ]
[ Buts good stuff and its helping the MPEG-comunity.              ]


XingSound Realtime MPEG Audio Layer II Encoding on the PC !

Here it is: the first low cost REALTIME MPEG AUDIO Encoding on the PC via
a high quality 16 Bits Stereo DSP based Audio-Soundcard and the famous
Xing Technology XingSOUND(tm) MPEG Audio Encoder software.

The XingSound MPEG audio encoder encoder supports the DSP on the Soundcard
and enables realtime 15:1 compression of high quality Audio material without
any audible loss in quality.

REALTIME means REALTIME !

Wait no longer endless time (hours) to convert your WAV-files offline, like a
few shareware encoders do. No just record your songs in realtime to MPEG Audio
MP2 files. Compression factor can be set .

Comfortable record software coming with the package and also an offline WAV to
MP2 converter.

All software runs under win3.x !

With the optinal MPEG Audio- MCI-driver you can paste your MPEG audio files
directly via Media player into your applications and save huge disk space
compared when using 16 bits Stereo WAV files !

Also , when the DSP Soundcard is installed, you get full CD-quality
STEREO playback with 16 bits resolution ! (if other soundcard is installed,
XingSound MPEG player will only play in Mono)


Available only as a bundled package consisting of:

1. XingSound MPEG Audio Realtime software for Windows 3.x incl. free MPEG audio
win3.x player program, WAV to MP2 offline converter, Realtime DSP supported
Audio recorder program, Realtime DSP supported FULL Stereo CD-quality MPEG
Audio playback

2. 16 bits Stereo CD-quality DSP Soundcard, with win3.x drivers
(can be used as a normal Windows soundcard as well, Soundblaster and WSS
compatible, jumperless design, options set via software, Sony CD-ROM I/O onbord)

All manuals have english language !

---------------------------------------------------------------------------

~Subject: XingCD

<IMG SRC="xingcd2.gif">

It is the first AVI to MPEG Encoder, which allows you to make
MPEG system streams from AVI movies.

This means, you can directly use a Motion JPEG capture board at 352x288
resolution to capture Realtime video,
edit it with Adobe Premiere for Windows and make a Video CD out of it,
using the new XingCD Encoder.

The XingCD Encoder is software only, so there is no further hardware
required. It converts the AVI Video file to MPEG Video and the sound WAV file
to MPEG Audio and interleaves (multiplexes) these 2 bitstreams into an MPEG
system layer bitstream, so it could be played back via a REEL MAGIC card
for instance or the new Inside Technology MPEG player card for the PC.

The new MPEG Encoder supports full IBP format and is compatible with the
ISO11172 MPEG system layer description.

Price is 995.-US$, but this is still cheaper than a 20K US$ realtime MPEG
capture board.....

It can also encode from single TGA or BMP pics and it supports various
output format of:
352x240, 352x288, 160x120 and custom output resolution.
Rescales source to desired ouput resolution etc...

Encode Process runs in the background.

I hope, we will get soon many "fresh" MPEG Video CDs !

---------------------------------------------------------------------------

~Subject: SUBSECTION - UNIX

---------------------------------------------------------------------------

~Subject: Xing Distributed Media Architecture

{XDMA} Network Description

The Xing Distributed Media Architecture ("XDMA"), developed by Xing Technology Corporation
("Xing") is the first commercially available low-cost solution for world-wide and local network
delivery of live and on-demand video+audio.  The National Broadcasting Company (NBC) has
broadly deployed XDMA for broadcast delivery of financial news programming to subscribers in
the U.S and Europe.  New applications are being developed with XDMA for distance learning,
corporate communications, news delivery and computer based training in corporate,
educational, government and health care markets, employing wide area, local area and ISDN
networks.

How XDMA Differs from other Video Networks

Existing "on-demand" multimedia (video) network architectures are based on tightly coupled
point-to-point client-server communication, which result in 4 major limitations:

	1.  significant interaction is required between client and server for flow control,
		requiring complex server programming and signficant data overhead (on
		the order of 25% - 50%);

	2.  servers are not designed to deliver the same streams simultaneously
		to multiple users, making "live" delivery to multiple users impractical;

	3.  LAN-based server architectures are not designed to operate (and generally
		don't work well) over wide area networks; and

	4.  communication protocols employed are proprietary, and do not directly support the
		TCP/IP international standard

XDMA represents a significantly different multimedia network architecture, based on the
concept of "streaming media".  This architecture supports both "on-demand" as well as "live" It
video and audio delivery which does not require close coupling between the client and server.
It easily supports "broadcasting" or "multicasting" of live or on-demand content to multiple
simultaneous users over local as well as wide area networks.  The benefits of XDMA are
reduced network component complexity, significantly increased network flexibility, and
significantly reduced network overhead.  Moreover, Xing's approach is built around
international standards-based components - Unix and (in 3rd quarter 1995) Windows NT
servers, TCP-IP connections, MPEG video and audio compression, and HTTP-HTML client
server communication.  This allows better economies in implementation and easy integration
into existing communication networks.

Technical Description

XDMA was developed as a client-server media distribution architecture which can operate
independently or complement existing WWW (World Wide Web) HTTP / HTML architectures
on local area networks, private data wide area networks and public data wide area networks
(e.g. Internet).

XDMA delivers *streaming* multimedia - pictures, video and sound - based on the MPEG
international standards for video and audio compression from Unix and (in 3rd quarter 1995)
Windows NT servers.  When integrated with WWW, XDMA augments existing WWW
architectures by providing a Common Gateway Interface (CGI) to existing Web (HTTP)
servers, and viewer extensions to popular "Web HTML browsers" (i.e. Mosaic, Netscape,
Winweb, Spyglass, etc).  As such, XDMA can take advantage of user authentication
procedures as supported by current Web browsers and HTTP servers.

Streaming of multimedia data is a significantly different way of delivery, as the user can view /
hear the data as it is being transmitted instead of waiting for file transfer completion, and there
is no requirement for complex file systems such as Netware or NFS.

In addition, XDMA uses standard TCP-IP network protocols, and takes advantage of new
"multicast IP" protocols (RFC 1112) for data delivery, allowing multiple users to simultaneously
view / hear the same data streams without duplication of data or use of intrusive broadcast
protocols.

A typical XDMA configuration will include some of the following components:
	* XDMA Network Encoders
		- video+audio
		- audio only
		- file transmitter / encoder emulator
	* XDMA Network Servers
	* XDMA Network Clients
		- for PC Windows
		- for X-Windows
		- Standalone
	* XDMA Network Routers
	* XDMA Network Editors
	* XDMA Network Manager
as described below.

XDMA Benefits

	* compatible with existing enterprise TCP/IP networks, including Ethernet,
		ATM, FDDI, ISDN, T1 and Frame Relay
	* adds live and on-demand video and audio services to private and public WAN's
		and LAN's without infrastructure changes
	* low overhead (3%) video and audio streams are fully routable
	* all network components are SNMP manageable (3rd quarter 1995)
	* network congestion is controlled by on-the-fly bitrate reduction of video and
		audio streams;  streams are scalable from full rate down to ISDN
		BRI (56-128kbps)
	* SQL database management of XDMA streams (3rd quarter 1995)
	* servers may be distributed for load balancing and stream caching
	* software-only and hardware accelerated video and audio decode provided
		on client systems
	* user interface customizable through HTML / HTTP (Web / Mosaic) interface
	* compressed video and audio streams compliant with MPEG-1 and MPEG-2
		(ISO/ICE 11172 and 13818) international standards
		


XDMA Applications

Applications requiring "media on-demand" benefit from XDMA's simplified approach.  The
advantage becomes most apparent in applications with a combination of "on-demand" and
"live" media delivery requirements, especially when the clients are geographically dispersed.
NBC is using XDMA to deliver multiple simultaneous live financial and news video broadcast
channels to financial market subscribers (money managers, stock brokers, financial analysts)
in cities throughout the US and Europe as part of their "NBC Desktop Video" service.  Xing is
developing similar delivery services for other commercial TV and radio programmers.

Although commercial broadcast services provide very visible and compelling examples for
Xing's capabilities, the largest volume applications for "streaming media" will  be in corporate,
educational, government and health-care networks with "on-demand" and "live" communication
requirements, including training, presentations, status reporting, and occassionally,
entertainment.  Because of the rapid proliferation of TCP-IP / HTTP / HTML ( Internet + World
Wide Web + Mosaic), the infrastructure for integration of Xing "streaming media" architectures
is quickly developing.

Representative XDMA applications include:

	* Commercial broadcast delivery systems;
	* Internet Service Provider delivery of radio and TV programming;
	* On-line marketing, sales, service and customer support;
	* Enterprise-wide training, corporate information systems and regulatory
		compliance;
	* Medical information systems, including live monitoring and on-demand
		multimedia information retrieval;
	* Educational systems for live and on-demand distance learning as well
		media production;
	* Government networks for live and on-demand delivery of news events
		and briefings to policy makers and dissemination of public information;
	* Media production and distribution; and
 	* Information archives

XDMA and ISDN

XDMA is ideally suited for ISDN remote access server and regional server applications such as
distance learning and news delivery, through its ability to provide on-the-fly MPEG stream
bitrate reduction and service of large numbers of simultaneous users.  Xing is currently
developing a reference platform for ISDN regional servers which delivers both high resolution /
low frame rate as well as low resolution / 30 frame per second video streams.  Demonstration
of this capability will be available via Xing's World Wide Web site - http://www.xingtech.com, as
well as via direct ISDN dial-in - 805/473-7200.

Xing Technology Corporation

Xing is the world's leading producer of PC based software technologies and products for digital
compression and decompression of video and audio in accordance with the MPEG (Moving
Pictures Expert Group) international standards.  Technology licensees include Microsoft, Intel,
Pacific Bell, NTT Japan, Fujitsu, Hewlett Packard and IBM.  In addition, Xing provided the key
technologies to NBC for the development of the first wide area digital video broadcast delivery
system ("NBC Desktop Video").


Glossary

MPEG  -  Motion Picture Experts Group.  The international standards for compression of video
and audio.  There are actually two standards - MPEG-1 (ISO/IEC 11172) and MPEG-2
(ISO/IEC 13818).  MPEG-1 was originally designed for delivery of video to consumer devices
at single speed CD-ROM data rates (150kbytes/sec), and is therefore lower resolution and
lower quality than MPEG-2, which was designed for delivery of broadcast and HDTV quality
video.  Each MPEG specification actually has 3 parts which define the video stream, the audio
stream and the video+audio encapsulating transport stream.

TCP-IP  -  Transmission Control Protocol + Internet Protocol.  A collection of communications
protocols (including TCP, IP, UDP, ARP, IGMP, ICMP, RAP, RIP, SNMP) that are the basis of
the Internet and all Unix networking.  Because TCP-IP can support both local and wide area
networking, while Novell's Netware protocols were designed only to support local area
networking, TCP-IP is rapidly become the standard as well for PC Windows networking
through an interface called "WINSOCK".

HTML+HTTP  -  Hypertext Markup Language + Hypertext Transport Protocol.  HTML is a page
description language and HTTP is a communications protocol that runs on top of TCP-IP.
Combined, HTML+HTTP define the basis for applications such as Mosaic and Netscape, which
are the primary tools for navigating the Internet's "World Wide Web".  HTML defines the
contents of pages which are viewed on the "Web", and HTTP defines the way an HTML
browser talks with an HTML server (refered to as an HTTPD or Web server).  It is important to
note that HTML+HTTP can be used on local area networks and private data networks, and are
rapidly becoming the standard for in-house corporate information systems which are not
necessarily Internet connected.

URL=http://xingtech.com/

---------------------------------------------------------------------------

~Subject: NVR Research Kit

[ Its really nice software, but its expensive !  You find the infos and ]
[ software on there ftp-server (see below !), don't forget to order a   ]
[ licence key. There are several nice and long MPEG-movies to ftp !!!   ]

[ If you require a demo version, please send mail to support@nvr.com    ]

From: Chris Jacobson <chrisj@dinghy.nvr.com>
Date: Thu, 13 May 93 10:31:32 -0700


                       North Valley Research
                       Digital Media Systems

North Valley Research is pleased to announce immediate availability of
a family of products for working with video and other time-based media
in a UNIX environment.  These products are the first, affordable software
products that enable the end user to take video and audio all the way
from video camera or tape to an MPEG sequence that can be played back in
real-time on most Sun SPARCstations.  Starting now until May 5th, 1993,
individual products can be purchased for $150 in quantities of 30 or
more; or under $300 for quantity 1.

These software products have well-designed Motif user interfaces and a
robust architectural design.  The first set of products is sold as a kit, and
consists of three user interfaces:

  - The Player.  This tool provides a viewing mechanism for working with
      + MPEG sequences
      + analog video (requires the Parallax XVideo board)
      + JPEG movies (requires the Parallax XVideo board with JPEG option)

  - The Recorder.  This tool enables the user to peruse analog material
    with an interface very similar to the Player, but in addition, allows
    you to create JPEG movies using the JPEG hardware on the Parallax XVideo
    board.

  - The Compressor.  This tool allows you to choose input files, specify
    the compression characteristics and finally, compress them with
    our software MPEG compression engine.

The MPEG playback mechanism is purely software, requires no special
framebuffer, and depending on the size of picture, the size of the window
and bandwidth of the bitstream, can run at 6 - 30 fps with synchronized
audio.  The color is dithered from 19 bits down to 7 bits,
gamma-corrected, with real-time adjustments for contrast and brightness.
The displayed window can be one or four times the size of the MPEG sequence
picture size.  For example, a sequence compressed at 320x240 can be played
back at 320x240 or 640x480 (depending on the performance of the host
computer).

Both the MPEG compression and playback mechanisms support:
  + variable I:P:B ratios
  + variable picture sizes from 64x48 to 320x240
  + variable and fixed bit rate
  + three motion estimation algorithms (Jain & Jain and two Exhaustive methods)

The MPEG compressor is relatively fast for compression that includes motion
estimation, and depending on the input stream and the selected compression
parameters, can compress a twenty second sequence in as little as an hour.

The JPEG record and playback is accomplished with the aid of the Parallax
XVideo board.  Recording and playback of JPEG movies is controlled by
a special software engine that always keeps the audio and video synchronized.
Recorded sequences may be "running records" from a camera or broadcast, or
assembled from a controllable video source with in and out points.
Both the Player and Recorder support Sony's ViSCA/LANC, and Pioneer 4400
disc players (and other compatible models).  VideoMedia's VLAN will be
added in the future.

                         Prices and Availability
                         -----------------------

All prices below are retail, with a special, 40%-off, introductory price
in parenthesis.  These special prices are good until May 5, 1993.

All products require:
    Operating System: Solaris 1.0.1
    Computer: SPARCstation 1+, 2, IPC, IPX

Availability: All products are available for immediate delivery
Media:        8mm tape or Quarter-inch cartridge (QIC)
Terms:        P.O. prior to shipment, net 30 days with credit

NVR Digital Media Player:
    Includes:     Support for audio and viewing analog video, JPEG movies
		  and software MPEG.

    Requirements: For analog video: Parallax XVideo board
		  For JPEG movies: Parallax XVideo board with JPEG option
		  For MPEG playback: most any 8-bit pseudo-color frame-buffer,
		      including CG3, CG4, CG6 and Parallax XVideo.
		      Black-and-white monochrome support available on request.

    Prices:        1 floating license $495 ($297 intro)
                  10 floating license $2,000 ($1,200 intro)
                  30 floating license $4,500 ($2,700 intro)

NVR Digital Media Recorder
    Includes:     Support for viewing analog video and creating JPEG movies
    Requirements: Parallax XVideo board
    Price:        1 floating license $1,595 ($960 intro)

NVR Digital Media Compressor
    Includes:     Support for compressing JPEG movies (both audio
		  and video) into MPEG.  Other input formats available on
		  request.
    Requirements: No special display requirements
    Price:        1 floating license $2,495 ($1,495 intro)

Development Kit:
    Includes:     5 Player licenses
	          1 Recorder license
	          1 Compressor license.
    Requirements: As above for each product
    Price:        $3,995 ($2,395 intro)

Support and Maintenance:
    Includes:     software upgrades
		  email support
		  limited phone support
    Price:        15% of purchased product price (Free intro!)

                     Further Information
                     -------------------
You can reach us at:
     North Valley Research, Inc.
     15262 NW Greenbrier Parkway
     Beaverton, OR 97006
     Tel: (503) 531-5705
     Fax: (503) 690-2320
     email (sales and marketing): marketing@nvr.com
     email (technical questions): support@nvr.com

This and other text-only versions of our product sheets are available via
anonymous ftp to nvr.com (192.82.231.50).  Look in /pub/NVR.  We are happy
to mail paper versions of our product sheets on request.

If you require a demo version, please call or send mail to support@nvr.com.

---------------
Todd Brunhoff
Vice President, R&D
North Valley Research

---------------------------------------------------------------------------

~Subject: Demo of NVR Digital Media Development Kit

    $Revision: 1.2 $
    $Date: 1994/08/06 19:49:42 $

We are pleased to make available another release of NVR's digital media
development kit, version 2.0.3.  You should already have a license key.
If you don't, please contact us at support@nvr.com.

This version has several fixes for bugs and some important improvements
over version 2.0.2.  In particular:
   - Support added for Alias PIX files
   - Support added for playing XING sequences that have illegal syntax
     (extra picture info and non-increasing temporal references)
   - 400% speed improvement for RGB --> Y/Cr/Cb conversion in the compressor
     and imageop (you'll want this if you are compressing any rgb files,
     such as SGI rgb files).
   - the deinterlace operator (in imageop and the compressor) was broken
     in version 2.0.2.  You would only notice this if you are compressing
     abekas or other interlaced files.

The 2.0.x version is a significant improvement over our last major release,
1.0.4.  Briefly, this software offers:
   - MPEG video compression
   - image processing and compatibility with many image file formats,
     including JPEG, TIFF, SGI RGB and others.
   - MPEG audio compression
   - compatibility with a variety of audio files, including AIFF, AIFC
     Sun Audio and Parallax movie files.
   - MPEG system multiplexing
   - real-time, synchronized playback of any combination of video and audio
     files.   This means you can play back MPEG video files with AIFF, or
     you can play back MPEG system streams containing MPEG video and
     MPEG audio.  And everything in between
   - a variety of tools for converting image file formats and audio file
     formats.
   - a real-time video/audio recording program (Sun and Parallax hardware
     required)

The software package is available in several pieces via anonymous ftp to

URL=ftp://nvr.com/pub/NVR-software/
    [192.82.231.50]

Look in /pub/NVR-software for the license 
agreement and README file.  It also contains about 25 megabytes of data and 
software, so first fetch the README file and read it to decide what you 
need.  If you only need the software, you should get one of

    SGI-Product-2.0.3.tar.Z
    Sun-Product-2.0.3.tar.Z

depending on the kind of hardware you have.

Turning on the software
-----------------------
If you already have a demo key from us, simply install the software 
described above and copy the file $NVRHOME/adm/keys/demokeys from the 
previous version into the same place in the new version.  Then type:

    % installkeys

This will give enable the software as before.  If you don't have a demo
key and would like one, please contact us at support@nvr.com.
---------------
internet: toddb@nvr.com                                             c--Q Q
US:       Todd Brunhoff; North Valley Research;                         `
          15262 NW Greenbriar Pkwy; Beaverton, OR  97006                -
Phone:    (503) 690-2357
Fax:      (503) 690-2320


---------------------------------------------------------------------------

~Subject: How will I get the NVR-Software ?

From: Todd Brunhoff <toddb@nvr.com>
Date: Tue, 18 May 93 09:23:26 -0700

The price list and text-only versions of our product sheets are available via
anonymous ftp to

URL=ftp://nvr.com/pub/NVR-data-sheets/
    [192.82.231.50].

Look in /pub/NVR-data-sheets.  
If you need glitzy paper versions to convey credibility, we are
happy to mail our product sheets on request.

The demonstration software package comes in several pieces via anonymous ftp to

URL=ftp://nvr.com/pub/NVR-software/
    [192.82.231.50)

Look in /pub/NVR-software for the license agreement
and README file.  Briefly you will need:
    /pub/NVR-software/Manual.evenpages-1.0.2.ps.Z
    /pub/NVR-software/Manual.oddpages-1.0.2.ps.Z
    /pub/NVR-software/Product-1.0.4.tar.Z
    /pub/NVR-software/README
and some selection from
    /pub/contrib/mpeg and /pub/contrib/jpeg
depending on the kind of hardware you have.

If you get our software via ftp, send us an email note and we will give you
a demo license key so you can run it.
---------------
internet: toddb@nvr.com                                             c--Q Q
US:       Todd Brunhoff; North Valley Research;                         `
          15262 NW Greenbriar Pkwy; Beaverton, OR  97006                -
Phone:    (503) 531-5707
Fax:      (503) 690-2320

===========================================================================

~Subject: SECTION 3. - FREE AVAILABLE SOFTWARE

The named tools are:

SUBSECTION - DOS
    layr_100
    mpeg2ppm
    vmpeg
    cmpeg
    dmpeg
    secmpeg
    mpegstat
    enc11dos
    pvrg MPEG
SUBSECTION - Windows
    XingIt
    mpgaudio
SUBSECTION - WINDOWS-NT
    mpeg2ply
    mpegplay
SUBSECTION - OS/2
    mp
SUBSECTION - X-WINDOWS and UNIX
    Berkeley's MPEG Tools
    MPEG-1 Video Software Encoder
    MPEG Video Software Decoder
    MPEG Video Software Analyzer
    MPEG Blocks Analyzer
    MPEG Video Software Statistics Gatherer
    mpegstat
    mplex
    xmplay
    xplayer
    xmpeg.tk
    mpeg2encode / mpeg2decode
    layr_100
    mpegaudio
    maplay
    Scanning MPEG's ...
    MPEG decoder...
    MPEGTool
    What is "SECMPEG" ?
    PVRG-MPEG Codec
    wdgt
SUBSECTION - VMS
    vms MPEG
SUBSECTION - MacIntosh
    Sparcle
    Qt2MPEG
    Audio on Macintosh ?!
SUBSECTION - Atari
SUBSECTION - Amiga
    MPEG2DCTV
SUBSECTION - NeXT
    MPEG_Play.app
    mpegnext
SUBSECTION - SGI

---------------------------------------------------------------------------

~Subject: SUBSECTION - DOS

---------------------------------------------------------------------------

~Subject: layr_100

From: "Matthias Hanft" <HFT@iis.fhg.de>
Date:          Thu, 23 Jun 1994 18:10:28 +0200
Subject:       SUN and PC Version of MPEG Audio Codec Shareware

Shareware encoder/decoder for Sun workstations and PC's

 The encoder takes about 5 minutes for encoding of 1 minute of stereo audio
 data on a SPARC station 10. The decoder works in real time.

Availability of the shareware packages:

-  via anonymous ftp from

URL=ftp://fhginfo.fhg.de/pub/layer3/
    [153.96.1.4]

 You may download our Layer-3 audio software package from the
 directory /pub/layer3. You will find the following files:
 For IBM PCs:
   layer3.txt    a short description of the files found in layer3.zip
   layer3.zip    encoder, decoder, documentation and a sample bitstream
   layer3nb.txt  a short description of the files found in layer3nb.zip
   layer3nb.zip  encoder, decoder and documentation (no bitstream)
   bitstr.l3     sample bitstream
 For SUN workstations:
   l3sun.txt     a short description of the files found in l3sun.zip
   l3sun.zip     encoder, decoder, documentation and a sample bitstream
   l3sunnb.txt   a short description of the files found in l3sunnb.zip
   l3sunnb.zip   encoder, decoder and documentation (no bitstream)
   bitstr.l3     sample bitstream

-  via direct modem download (up to 14.400 bps)

    Modem telephone number  : +49 911 9933662           Name: FHG
    Packet switching network: (0) 262 45 9110 10290     Name: FHG
    (For the telephone number, replace "+" with your appropriate
    international dial prefix, e.g. "011" for the USA.)
    Follow the menus as desired.

-  via shipment of diskette (only including registration)

 You may order a diskette directly from:

 Mailbox System Nuernberg (MSN)
 Hanft & Hartmann
 Innerer Kleinreuther Weg 21
 D-90408 Nuernberg
 Germany

 Please note: MSN will only ship a diskette if they get paid for the
 registration fee before. The registration fee is 85 Deutsche Mark
 (plus sales tax, if applicable) for one copy of the package. The
 preferred method of payment is via credit card. Currently, they can
 accept VISA, Master Card / Eurocard / Access credit cards.

 You may reach MSN also via Internet: msn@iis.fhg.de
                     or via Fax: +49 911 9933661
                     or via BBS: +49 911 9933662        Name: FHG
                     or via X25: 0262 45 9110 10290     Name: FHG
                     (e.g. in USA, please replace "+" with "011")

- via email

 You may get our shareware also by a direct request to msn@iis.fhg.de.
 In this case, the shareware is split into about 30 small uuencoded
 parts...

--- cut here ---

The file l3v099c_sun.tar is the tarred version of the

  shareware ISO-MPEG Audio Layer 3 software only Encoder and Decoder
  Version 0.99c for SUN work stations.
  copyright Fraunhofer - IIS 1994

(the file l3v099c_sun.tar.gz is compressed with GNU zip)

Here are the highlights of the Layer3 shareware package:
 - evaluate highest quality perceptual audio compression technique
   available today
 - software only encoder and decoder implementations
 - implements ISO/MPEG Audio standard ISO/IEC IS 11172-3, Layer 3
      (restriction: no support of Layer I and II, no realtime)
 - wide range of compression ratios including
       6:1   fully transparent quality
      11:1   64 kbps per channel, very high quality
      16:1   still better than your average 16 bit 44.1 kHz sound card
 - music data is input in raw format (16 bit signed integer)
 - 44.1kHz sampling frequency (version 1.0 supports also 32 kHz and 48 kHz)
 - packed bit stream conforming to ISO/MPEG Layer III
 - output of decoder is in raw format (16 bit signed integer)
 - optional .WAV header for decoder output data. Resulting music files
   can be played with Windows Media Player.
 - written by the very same people at Fraunhofer-IIS who did the
   Layer 3 codecs for the ISO and CCIR tests (best sound quality at
   low bit rates at all listening tests).
 - commercial real time products for encoding and/or decoding of
   ISO/MPEG Layer 3 auddio are available. Contact one of the companies
   listed in the file info.txt.

The package consists of the following files

   l3enc          encoder program
   l3dec          decoder program
   bitstr.l3      demo layer 3 bitstream (128 kBit/s, stereo, 44.1 kHz)
   manual.txt     instructions for encoder and decoder programs
   register.txt   information on registration. PLEASE READ THIS!
   info.txt       infos on ISO MPEG Layer III and Layer III products
   readme.txt     this file

The song used for bitstr.l3 is named "funky" and was composed and
arranged by Juergen Herre. "Funky" is copyright Juergen Herre 1994.

You may use "Funky" for all evaluation purposes of this shareware product.
You may not use "Funky" for commercial purposes (e.g. radio broadcasting).

You may also download l3v099cn_sun.tar.Z (l3v099cn_sun.tar.gz) which consists
of all files found in l3v099c_sun.tar (l3v099c_sun.tar.gz) minus bitstr.l3
(Bitstr.l3 is about 1 MB of data for 1 minute of stereo music at 128 kBit/s,
44.1 kHz sampling frequency).

bitstr.l3 is also available seperately.

All brand names are registered trade marks of their respective owners.

--- cut here ---

Regards

Matthias Hanft

--
* Matthias Hanft * FhG-IIS * Am Weichselgarten 3 * D-91058 Erlangen *
* Phone: +49-9131-776-361 *** Fax: 399 *** E-Mail: hanft@iis.fhg.de *

---------------------------------------------------------------------------

Subject: MPEG1-IIS

Public C source code for MPEG1 audio decoder available now

The source code for the MPEG1 audio decoder layer 1, 2 and 3 is
now available on fhginfo.fhg.de (153.96.1.4).

There are two files:
   mpeg1_iis.tar.Z     (Unix: lines seperated by line feed only)
   mpeg1iis.zip        (PC: lines seperated by carriage return and line feed)

They are in the directory /incoming now but will be moved to the directory
/pub/layer3/public_c.
 
Please note that the public C code for the decoder is *not* identical to
the shareware provided by Fraunhofer IIS.

However we at Fraunhofer IIS did check that the layer 3 part of the public
C source decoder works correctly. (As usual this does not imply any 
warranties).

popp@iis.fhg.de (Harald Popp)

---------------------------------------------------------------------------

~Subject: mpeg2ppm

This is the MPEG to PPM converter running under DOS. Its based
on the MPEG-decoder called "mpeg_play" by the Berkeley Research
Group. The basic idea was coming from the PPM-patch by Jef
Poskanzer. Many thanks to both.

SHAREWARE
---------

MPEG2PPM is inexpensive shareware. If you are continuing using
it after a 30 day trial-period, please send a letter containing
the filled and signed registration-form and the little donation
of 10 $ or 15 DM in cash to the adress below.

ATTENTION: The dots the shareware version of MPEG2PPM produces
are just delay, to force you to register.

ATTENTION: A registration is recommended for commercial use.

ATTENTION: The full-licenced version is restricted to a local
           area netword (company) or a privat single host.

MPEG2PPM will  decode  a  (video-only)  MPEG-I-stream and
extract the rebuild frames as PPM-files (Portable Pixmap).
The  extracted  frames will be numbered starting from zero
(0), the first part of the filename is  derived  from  the
original MPEG-stream, the files extension will be .PPM.

The final PPM-files will be in 24-bit-format.

MPEG2PPM  expects  MPEG-1  video  streams only. It can not
handle multiplexed MPEG streams  or  video+audio  streams.
The  converter  uses  the  paris  entropy coding table set
(which I believe to be the MPEG-1 standard).

MPEG2PPM was developed by

PHADE Software
Inh. Frank Gadegast
Leibnizstr. 30
10625 Berlin GERMANY

phade@contrib.de

---------------------------------------------------------------------------

~Subject: vmpeg

VMPEG is now out in Version 1.5, Stefan sold the full version,
but the "Lite" version is still available to the public, he included
a nice button player interface, audio (!!), systemstream and CD support.
It's just the best MPEG-utility for the end-user ever seen, yo !

From: stefan@lis.e-technik.tu-muenchen.de (Stefan Eckart)


                              VMPEG V1.2
                       DOS / Windows MPEG player
                           by Stefan Eckart

                            September 1994

1. Features
===========

 - full MPEG-1 video standard (ISO 11172-2): I,P,B frames of arbitrary size

 - plays system layer (ISO 11172-1) files (audio is discarded)

 - high speed: e.g. 21 frames/s on a 386DX/33 for a 160x120 I frame
               sequence (mjackson.mpg)

 - supports VGA and a variety of SVGAs

 - display options: 4x4 ordered dither normal size (8 bit)
                    4x4 ordered dither double size (8 bit)
                    grayscale (8 bit)
                    true color (24 bit)

  - requires:

    - '386,'486 or '586 processor (no '286)
    - 4 MB RAM
    - VGA or Super VGA
    - Windows version: Windows 3.1, Win32s and optionally WinG


2. Overview
===========

VMPEG is a fast decoder / viewer for MPEG encoded video sequences (.mpg
files). MPEG (Moving Pictures Expert Group) is a video compression algorithm
standardized by the International Organization for Standardization (ISO) and
the International Electrotechnical Commision (IEC) as ISO/IEC IS 11172. Main
application of MPEG is the storage and retrieval of video on/from Compact
Disk at a rate of about 1.5 Mbit/sec.

VMPEG can play MPEG system layer streams containing both video and audio.
Most streams from CD-ROM (Video-CD) are of this type. The audio stream is
discarded by the decoder. VMPEG automatically detects whether the file is a
video compression layer or a system layer file. I have also included a small
END ---------------------- CUT HERE --------------------- 4/8
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kei.com!news.mathworks.com!gatech!howland.reston.ans.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [5/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 11:02:04 GMT
Organization: Technical University of Berlin, Germany
Lines: 1306
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r99nc$2s3@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77882 comp.graphics.animation:20014 comp.compression:20443 comp.multimedia:36451 alt.binaries.multimedia:40219 alt.binaries.pictures.utilities:37040 alt.binaries.pictures:21189 alt.binaries.pictures.d:20802 alt.answers:9855 comp.answers:12388 news.answers:45908

Archive-name: mpeg-faq/part5
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly
BEGIN -------------------- CUT HERE --------------------- 5/8
utility (MPGSPLIT) which extracts the video and audio streams from a system
layer stream into separate files (cf. MPGSPLIT.DOC).

The DOS version of VMPEG is compiled with the GNU C compiler (gcc) into '386
code and runs under the DOS extender GO32 by DJ Delorie which is included in
the archive file. The DOS version of VMPEG cannot be run from Windows.

The Windows version of VMPEG is the first release for Windows. It is not as
thoroughly tested as the DOS version but already seems to be reasonably
stable. Please feel free to report any bugs you encounter to my email
address. The Windows version requires Windows 3.1 and the free Windows
extensions MS Win32s (32 bit support) and optionally WinG (screen output
acceleration). These packages are available by anonymous ftp from (currently)

URL=ftp://ftp.microsoft.com:/developr/win32dk/sdk-public/Win32s115a.Zip
URL=ftp://ftp.microsoft.com:/developr/drg/WinG/WINGBT.ZIP

and perhaps somewhere on CompuServe.


3. Installation
===============

3.1 DOS version
---------------

- You need at least a '386 with a VGA and 512 KB of RAM. 4 MB are strongly
  recommended. XT, AT, EGA and CGA are not supported. A '387 is not required
  nor does it increase speed. VMPEG doesn't use floating point.

- You should leave about 2 MB of RAM (XMS) unused: if you have, say,
  a 4 MB system you shouldn't reserve more than 2 MB for a RAM drive.
  Otherwise the DOS extender would start swapping memory pages from and to
  disk. This would slow down the program, even if swapping to a RAM drive.

- If you have installed EMM386 make sure you don't have specified the
  'noems' option in your config.sys file.

- Create a subdirectory for installation:

  md \vmpeg
  cd \vmpeg

- Unzip the archive into this subdirectory:

  pkunzip -d vmpeg12.zip

- Edit VMPEG.BAT and VMPEG24.BAT; you probably have to change drive
  and/or path specifications and to select a suitable graphics driver
  (see paragraph 4).


3.2 Windows version
-------------------

- Install Win32s and (optionally) WinG. These packages come with their own
  installation instructions. Basically you have to run the setup program
  supplied with them.

  Installation of Win32s copies a couple of files (w32sys.dll, win32s.ini,
  win32s16.dll, winmm16.dll) to the Windows system directory and creates a
  WIN32S subdirectory with additional files. It also adds two entries
  (for winmm16.dll and w32s.386) to the system.ini file in the Windows
  directory. You can deinstall Win32s by removing these files and restoring
  your original system.ini file (saved in system.old by the setup program).

  Installation of WinG is optional. I have included two versions of VMPEG,
  one with WinG calls (VMPEGWIN.EXE) and one without (VMPEGNWG.EXE).
  The WinG version is faster, but the difference is only notable for
  large (CIF/SIF) MPEGs (may depend on your SVGA).

  WinG adds several files (wing.dll, wing32.dll, wingde.dll, wingdib.drv,
  wingpal.wnd, dva.386) to the system directory and adds an entry for DVA.386
  to your system.ini file. To deinstall WinG simply remove this entry from
  system.ini.

  If you start VMPEG (or any other program using WinG) for the first time,
  a performance test window appears which adapts and optimizes WinG for the
  VGA in your PC. This takes a while (about 3 minutes on my computer), don't
  despair...

- Create a subdirectory for installation:

  md \vmpeg
  cd \vmpeg

- Unzip the archive into this subdirectory:

  pkunzip -d vmpeg12.zip

  if you don't need the DOS version, you can delete vmpeg, go32.exe, the
  drivers subdirectory and the vmpeg*.bat batch files

- You can start the program (vmpegwin.exe / vmpegnwg.exe) either from the
  file manager or from the program manager (File->Run menu item) or you can
  define a program entry in the program manager (File->New menu item).

- both VMPEG and the Win32s libraries need a lot of memory (about 3-5 MB in
  total), and you may therefore have to increase the size of the swap file.
  4 MB of RAM are sufficient, however, to run the program without swapping
  (except during program startup).


4. Graphics Drivers (DOS version)
=================================

The DRIVERS subdirectory contains a set of graphics drivers for different
Super VGAs. Select the one that matches your graphics card by editing the
file VMPEG.BAT (for 8 bit display). If none of the drivers work, you may try
to use the (go32 internal) VESA driver and a TSR VESA BIOS extension. A
collection of such drivers is available at

URL=ftp://oak.oakland.edu/pub/msdos/graphics/vesadrv2.zip

and on all other SimTel mirrors.

True color support requires VESA BIOS. It works for my configuration (a
Cirrus Logic GD5422 based card with VESA BIOS) and should work for most other
'well behaved' boards as well. You may have to adjust the -y option in the
last line of VMPEG24.BAT. The number indicates the length of each scanline.
This is usually either 1920 or 2048. If the frames appear scattered over the
screen, the setting is probably wrong... If you get incorrect colors (red
sky, blue faces) you have a card with reversed RGB order. Simply replace the
-y... by a -Y... to fix this.


5. Troubleshooting
==================

DOS version:

If you get a message about the CPU not being in Real Mode, you have to remove
the noems option from the EMM386.EXE (or any other EMS emulator) line in your
CONFIG.SYS.

Windows version:

If you get the message 'Can't find WING32.DLL' you don't have WinG properly
installed. Either install WinG or use VMPEGNWG.EXE instead.

If starting VMPEGWIN briefly switches to text mode and displays the message
'This program cannot be run in DOS mode', Win32s is not installed properly.

If you get 'Out of Memory' errors, you have to increase the size of your
swap file (from the control panel).


6. Command Line Options
=======================

The following command line options are valid for both DOS and Windows
versions. To specify options to the Windows version, you have to run it
from the program manager (File->Run menu). Of course you can set all
these options interactively after starting vmpegwin (without command
line options).

  vmpeg [options] input.mpg
  vmpeg24 [options] input.mpg
  vmpegwin [options] input.mpg
  vmpegwng [options] input.mpg

options:

  -l  loop the sequence (infinitely until you press a key)

  -x1 skip B frames
  -x2 skip B and P frames, i.e. only I frames are displayed; you should
      use this option for I-frame-only sequences (including Xing compatible
      streams) to make the program run faster (as it doesn't have to manage
      reference frames)

  -d0 (default) ordered 4x4 dither
  -d1 grayscale
  -d2 similar to -d0 but display magnified by a factor of 2

      True color mode is selected by using vmpeg24 instead of vmpeg. In this
      case the -d switch isn't effective.

DOS version only:

  -in displace output by n pixel in horizontal direction
  -jn displace output by n pixel in vertical direction

      VMPEG centers the MPEG on the screen. If the frame is larger than
      the screen you can use the -i and -j options to pan the visible
      area. positive n shifts to the right or bottom, negative n to the
      left or upwards.

  -zn reduce display speed. This is done by a counting loop, so you
      have to experiment until you get the speed you want.


The program can be terminated by pressing an arbitrary key (DOS version).


7. Remarks
==========

Please report bugs (don't forget to mention which version of VMPEG you are
using!) to my email address:

  stefan@lis.e-technik.tu-muenchen.de

or by mail to:

  Stefan Eckart
  Kagerstr. 4
  D-81669 Muenchen, Germany


8. Acknowledgements, Copyrights
===============================

This program comes without any warranty. Your are using it at your own
risk. VMPEG is copyrighted software (C) Stefan Eckart, 1994. You may
use, copy and distribute this program without restrictions but only in
unmodified form and without charging money for it.

GO32.EXE, DRIVERS\*.GRD:

   Copyright (C) DJ Delorie
                 24 Kirsten Ave
                 Rochester NH  03867-2954

These files are part of DJGPP which is available from

    host:      oak.oakland.edu (or another SimTel mirror)
    login:     ftp
    password:  send your e-mail address
    directory: /pub/msdos/djgpp

other DRIVERS:

 Copyright (C) 1991 DJ Delorie, 24 Kirsten Ave, Rochester NH 03867-2954
 Copyright (C) 1992 Csaba Biegl, 820 Stirrup Dr, Nashville, TN 37221

VMPEG:

The library VMPEG is linked with is

 Copyright (c) Regents of the University of California.

 acknowledgement:  ``This product includes software developed by the
 University of California, Berkeley and its contributors''

 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
 * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The program is compiled with GNU GCC, the C compiler of the Free
Software Foundation (FSF), Inc. 675 Mass Ave, Cambridge, MA 02139, USA.
VMPEG does not contain code covered by the FSF General Public License.


9. Known Bugs
=============

Interframe coded macroblocks theoretically can experience wrap-around
(255<->0). This happens rarely enough to live with it (fixing would
reduce speed for all sequences).

Accuracy of the IDCT does not meet the requirements of IEEE 1180-1990. It is,
however, a reasonable trade-off between speed and image quality.

Display should be synchronized to the frame rate signalled in the sequence
header.

The program should use VESA BIOS supplied information instead of the -y
option.


10. References
==============

1. Coding of moving pictures and associated audio for digital storage
   media up to about 1,5 Mbit/s, International Standard ISO/IEC
   IS 11172, 1993.

2. Frequently Asked Questions (FAQ) of the alt.binaries.pictures
   and comp.compression newsgroup: contains an introduction to MPEG.

3. Documentation of the PVRG MPEG software: a thorough overview
   covering many aspects of MPEG.

4. Documentation of the MSSG MPEG-2 codec (mpeg2codec, see below).


Appendix A: Related Software
============================

This list is probably incomplete, but it's all I'm aware of. Of course
there are programs for other systems as well (Mac, Amiga etc.).

mpeg2codec     MPEG-1 and MPEG-2 codec from the MPEG Software Simulation Group
               Authors: Stefan Eckart, C. Fogg, C. Aeyung, S. Papuc
               Includes source code for Unix X11 and Windows (Win32s / NT)
               and compiled versions for PC.

URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/ or
URL=ftp://ftp.netcom.com/pub/cf/cfogg/mpeg2/

mpeg2play      a speed optimized version of the decoder from mpeg2codec

URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/mpeg2play/

mpeg_play      MPEG Video Software Decoder (Version 2.0; Jan 27, 1993)
               Authors: Lawrence A. Rowe, Ketan Patel, and Brian Smith
               Computer Science Division-EECS, Univ. of Calif. at
               Berkeley

URL=ftp://toe.cs.berkeley.edu/pub/multimedia/mpeg/mpeg-2.0.tar.Z

cmpeg          an MPEG encoder for the PC (DOS, 640K, no '386 req.)
               for Targa, PBMPLUS and Alchemy RAW images
               Author: Stefan Eckart

URL=ftp://garbo.uwasa.fi:/pc/graphics/cmpeg10.zip

dmpeg          MPEG decoder and player for the PC (DOS, 640K, VGA)
               Author: Stefan Eckart

URL=ftp://garbo.uwasa.fi/pc/graphics/dmpeg11.zip

mpegwin        Port of mpeg_play for MS-Windows
               by: Michael Simmons, msimmons@ecel.uwa.edu.au
               toe.cs.berkeley.edu:/pub/multimedia/mpeg/Ports/mpegw*
               (HiColor & TrueColor support, Shareware)

mpeg.exe       DOS MPEG player from Xing Technologies (XingIt V2.1)
               (high speed, but decodes only a small subset of the
                MPEG standard, audio (.WAV,.MP2) support, Windows)
               mpegview.zip (available from many ftp sites)

MPEGv1.1/1.2alpha
               MPEG Software Encoder/Decoder
               Authors: Portable Video Research Group (PVRG)

URL=ftp://havefun.stanford.edu:/pub/mpeg/
    MPEGv*.tar.Z

disp
               a display program for pictures and animations
               including MPEG (based on mpeg_play)
               contains additional drivers that can also be used
               with VMPEG.
               Author: Jih-Shin Ho, u7711501@bicmos.ee.nctu.edu.tw

URL=ftp://NCTUCCCA.edu.tw/PC/graphics/disp/
               


APPENDIX B: MPEG files
======================

Two good sources for MPEG files:

  s2k-ftp.cs.berkeley.edu:/pub/multimedia/mpeg/movies
  havefun.stanford.edu:/pub/mpeg

High quality MPEGs you simply can't afford to miss:

  tennis.mpg
  flowg.mpg
  bike.mpg


--
Stefan Eckart, stefan@lis.e-technik.tu-muenchen.de
Kagerstr. 4, D-81669 Munich, Germany.

Stefan Eckart, stefan@lis.e.technik.tu-muenchen.de

---------------------------------------------------------------------------

~Subject: cmpeg

Stefan Eckart's CMPEG, another Freeware MPEG maker!

Here is another MPEG creator!   This one supports 8086+, so if you 
thought you couldn't make MPEGs, boy were YOU wrong. :-)   Can make 
Xing (I-frame) or normal MPEGs (which contain I, P & B frames, and 
offer better compression).   Be full aware of the fact that the 
slower your machine, the longer it will take to compress your files 
into an MPEG animation (does this need to be said?).  (Don't expect 
eyeball-charring performance from your 286, please..)

Due to its small size, I am offering CMPEG here at a2i.  Access info:

---------------------------------------------------------------------------

~Subject: dmpeg

Public Domain MPEG decoder by Stefan Eckart  June 1993

1. Features

DMPEG is another MPEG decoder/player for the PC:

 - decodes (nearly) the full MPEG video standard
   (I,P,B frames, frame size up to at least 352x288)
 - can save decoded sequence in 8 or 24bit raw file for
   fast off-line display (two pass mode)
 - optional on-screen display during decoding
 - several dithering options for 8 bit displays:
     ordered dither, Floyd-Steinberg, grayscale
 - selectable color-space
 - runs under DOS, 640KB RAM, no MS-Windows or '386 required
 - compact (small code / small data models, 16 bit arithmetic)
 - supports VGA, many Super-VGAs (including VESA) and
   some TrueColor SVGAs

DMPEG is both an MPEG viewer AND converter.  When viewing, it is important
to note that it is markedly slower than the Xing player.  That is, unless
you CONVERT the MPEG to DMPEG's proprietary RAW format.  You then use a
special player, included, which will show the RAW format animation on VGA,
SVGA, or VESA screens!  And, hey 286 users, this one actually works on
80286 machines (albeit a little slowly).

The converter does a remarkable job, and I use it for the "essential" MPEGs
that I would like to view at the highest speed possible.  If you have the
anim loaded in RAMdisc then you have a really nice framerate even on a
lowly 386!  :)   In the newly released 1.1 version, the converter and
viewer are now included in one executable.

It is important to note that this viewer will allow users to see MPEGs that
the Xing player will not.  This is because DMPEG is programmed to view all
3 frametypes, while Xing's player isn't.  If the MPEG won't view using
Xing, try this player, DMPEG.

---------------------------------------------------------------------------

~Subject: secmpeg

[ This is the README.DOS file out of the SECMPEG-archive. Read below in ]
[ the UNIX-section for more information about SECMPEG.                  ]

       SECMPEG is a program based on a rather  complex  algorythm
       to  ensure  a  confidentiality and a integrity service for
       the video-stream MPEG-I.


SECMPEG.ZIP (c) 1994 by Frank Gadegast and Juergen Meyer

This is my DOS-port of the MPEG-filter called "secmpeg".
Read the provided file README and the man-page first.

It was compiled with the DOS-port of the GNU GCC-compiler,
called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please
read the GNU-Licence-file 'LICENCE.GNU'.

You find the DOS executable in this distribution under
'secmpeg.exe'.


NEEDS and INSTALL

Cause of DJGCC, the final executable is not running under
DPMI (so not in a Windows-DOS-Box) nor on a 286-machine.

The executable 'GO32.EXE' has to be somewhere in the PATH.
If running on a 386, the emulationfile 'EMU387' has to be,
where the environment variable GO32 is pointing to, so if
the emu-file is in D:\LIB enter:

set GO32=emu d:/lib/emu387

       Permission to use, copy, modify, and distribute this soft-
       ware and its documentation for any purpose and without fee
       is hereby granted, provided that the archive remains  com-
       plete,  that  this author notice will appear in all copies
       and as long as you don't try to make money off it, or pre-
       tend that you wrote it.

---------------------------------------------------------------------------

~Subject: mpegstat

[ The first tool to test a MPEG-I-stream ! Including statistics, frame- ]
[ order, decoding times !! Now you can test, if archives are ok or if a ]
[ file uudecoded ok without playing it ! This code is surely based on   ]
[ the berkeley-decoder.                                                 ]


MPEGSTAT.ZIP (c) 1994 by PHADE Software

This is my DOS-port of the MPEG-filter called "mpegstat".

It was compiled with the DOS-port of the GNU GCC-compiler,
called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please
read the GNU-Licence-file 'LICENCE.GNU'.

WHERE IS IT ?

It will be posted the alt.binaries.pictures.utilities group these days.
Reposts come as requested.

It will stored on our ftp-server in the next days (probably there):

URL=ftp://ftp.cs.tu-berlin.de/pub/msdos/dos/graphics/mpegstat.zip
    [130.149.17.7]


NEEDS and INSTALL

The executable 'GO32.EXE' has to be somewhere in the PATH.
If running on a 386, the 387-emulationfile 'EMU387' has to be,
where the environment variable GO32 is pointing to, so if the
emu-file is in D:\LIB enter:

set GO32=emu d:/lib/emu387

That should do, KeyJ Phade (phade@cs.tu-berlin.de)
 
---------------------------------------------------------------------------

~Subject: enc11dos

[ Well, and soon as it was out, I ported Berkeley's new MPEG-ecndoder ]
[ to DOS as well, here the README.DOS file. For more information see  ]
[ below in the UNIX-section.                                          ]

ENC11DOS.ZIP (c) 1993 by PHADE Software

This is my DOS-port of the MPEG-encoder called "mpeg_encode"
by the Berkeley Research Group.

It was compiled with the DOS-port of the GNU GCC-compiler,
called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please
read the GNU-Licence-file 'LICENCE.GNU'.

WHERE IS IT ?

It will be posted the alt.binaries.pictures.utilities group these days.
Reposts come as requested.

It will stored on our ftp-server in the next days (probably there):

URL=ftp://ftp.cs.tu-berlin.de/pub/msdos/dos/graphics/enc11dos.zip
    [130.149.17.7]

NEEDS and INSTALL

The executable 'GO32.EXE' has to be somewhere in the PATH.
If running on a 386, the 387-emulationfile 'EMU387' has to be,
where the environment variable GO32 is pointing to, so if the
emu-file is in D:\LIB enter:

set GO32=emu d:/lib/emu387

That should do, KeyJ Phade (phade@cs.tu-berlin.de)

---------------------------------------------------------------------------

~Subject: pvrg MPEG

[ Well, this is just class. The Stanford-Codec is now available for ]
[ DOS-users. The file is usually called PVRGMPEG.ZIP, it supports   ]
[ IPB-Frames and Xing-Format ! Sometimes called MPGCODEC too.       ]

From: glogan@taynet.co.uk
Subject: PVRG MPEG CODEC
Date: 15 Jun 93 20:09:52 +0100

This archive contains the following files:

	README.1ST      This file
	PVRGMPEG.EXE    My port of the PVRG MPEG CODEC
	PPM2CYUV.EXE    My port of the PVRG YUV file splitter
	CYUV2PPM.EXE    My port of the PVRG YUV file combiner
	MAKEMPEG.TXT    Details of how I did the port
	USEMPEG.TXT     Details on using PVRGMPEG
	SHORT.MPG       A XING compatible version of short.mpg supplied
			by PVRG with the source code.
	SHORT*.GIF      The 10 frames in GIF format to make SHORT.MPG

I hope I have not offended anybody by putting this archive together. I offer 
no warranty of any description with respect to my porting.

All of the EXE files were compiled by me from Publicly available source code
from the FTP sites listed in MAKEMPEG.TXT.

I would like to thank the PVRG group for writing such an excellent encoder
and for their help in getting at the Alpha release of v1.2 so quickly (I can't 
name this person as the PVRG copyright notice forbids it). Also I would like
to thank Jelle van Zeijl for sending me the XING patch originally written by 
Mats Loftvist which has subsequently been included the Alpha release of v1.2.

Have fun and please mail me to let me know how you get on. A copy of any
interesting movies would be appreciated.

This is the MAKEMPEG.TXT file from pvrgmpeg.zip it may help you port the PVRG
MPEG CODEC to your platform.

Hi All you Eager MPEG Makers, here is how to port the PVRG MPEG
encoder/decoder to DOS/PC (386).

Tools required:
	Well the ones that I used.

		GNU C version 2.2.2
		An uncompress util for UNIX .Z files
		An untar util for UNIX tar files
		Text Editor (sorry some code needs tweaked)
		Note: Diff from the GNU File utilities, could be used instead
Source required:
        1)
		/pub/mpeg/MPEGv1.2.alpha.tar.Z
			from havefun.stanford.edu

		/pub/mpeg/MPEGDOCv1.1.tar.Z
			from havefun.stanford.edu
			documentation still to be updated.

	2)      The DOS port of PPM2CYUV called ppm2cyuv.exe
	3)      Image Alchemy from a number of ftp sites.
			eg /mirrors4/garbo.uwasa.fi/graphics/alch16.zip
				at wuarchive.wustl.edu
 
Image Alchemy may be replaced with giftoppm.exe from the pbmplus set of
graphics tools.

Graham Logan
June 15th 1993
glogan@taynet.co.uk

---------------------------------------------------------------------------

~Subject: SUBSECTION - Windows

---------------------------------------------------------------------------

~Subject: XingIt

[ This is Xing's new Public-Domain-Player. It is enhanced, but still   ]
[ has of bugs. You have to deinstall the old .DLL's and the MCI-driver ]
[ to have it running proper. The DOS-MPEG-Player included in this file ]
[ (named MPEGVIEW.EXE) doesn NOT run with all Soundblaster-compatible  ]
[ cards and kills the machine quit often.                              ]

		 XingIt! MPEG Player Software Demo
			   (August 27,1993)

The file MPEGVIEW.EXE installs Xing Technology, Inc.'s XingIt! MPEG
Player Software Demo for IBM PC compatibles. Xing's "XingIt!" real-time 
video MPEG capture board, including encoding software, video and sound editor, 
and the full-featured player is available direct from Xing Technology, 
Inc. in Arroyo Grande, CA (See below for order info).

The file MPEGVIEW.EXE is a self extracting archive. To install the player,
create a new directory on your hard drive and copy MPEGVIEW.EXE into it.
Change to that directory and type MPEGVIEW to extract the player files.

MPEGVIEW.EXE also contains a DOS version of the player, MPEG.EXE.
To run the DOS version, change to the directory where you extracted
MPEGVIEW.EXE and type "MPEG MPEGFILENAME.MPG".

---------------------------------------------------------------------------

~Subject: mpgaudio

Now there is the MPEG AUdio Player for Win3.1 !

This program is Shareware. To encode your own MPEG Audio files, you need
to buy the MPEG AUdio Software Encoder program for Win3.1 .

[ Look above. ]

---------------------------------------------------------------------------

~Subject: SUBSECTION - WINDOWS-NT

---------------------------------------------------------------------------

~Subject: mpeg2ply

[The June 30 edition of mpeg2w11 does not contain encoder port]

                    MPEG Software Simulation Group codecs
                             for Windows 32s 
                           (MPEG-L@netcom.com)

MPEG2DEC.EXE and MPEG2ENC.EXE are Windows 32s ports with integrated
display functions of the MPEG Software Simulation Group's programs. 

MPEG2PLY.EXE is the port of mpeg2play---Stefan Eckart's variation of
mpeg2decode which optimizes speed through fast decoding methods such as
approximation techniques, loop unravelling, et al.

All Win32s programs were ported with Microsoft Visual C++.  Only the
main() program and display files (mpeg2dec.c, mpeg2enc.c, or mpeg2ply.c) 
differ from the standard "Unix distribution."

If you do not have a 32-bit Windows environment (e.g. Win 4.0 Chicago,
Windows NT), but plain old Windows 16 (e.g. Windows 3.1), yet you do
possess either a 386, 486, or Pentium-based PC, you can download the
Microsoft 32-bit extension program, "Win32s" from the Microsoft FTP
site:

URL=ftp://ftp.microsoft.com/developers/DEVTOOLS/Win32SDK/Win32s115a.zip
    [198.105.231.1]

(this is the latest edition--June 23, 1994)

Win32s archive (mpeg2w11.zip):      

 mpeg2dec:   
   mpeg2dec.c             Main() routine.  Initiates application and display.
   mpeg2dec.r             MS Visual C++ resource file.
   makefile               MS Visual C++ project file.
   gui.h                  #include constants for MS GUI values.
   mpeg2dec.exe           Speed-optimized executable
   grayleo.ico            mpeg2dec.exe 32x32 4-bit System Palette icon


About the windows icon:
The 32x32 4-bit icon for MPEG2DEC.EXE and MPEG2ENC.EXE is a silhouette
of Dr. Leonardo Chiariglione (CSELT, Italy), none other than our
co-founder and exhaulted lifetime Convenor of MPEG.

Acknowledgement:
Many thanks to Sorin Papuc (sop@compcore.com) for porting these programs
to Windows 32s.

---------------------------------------------------------------------------

~Subject: mpegplay

[ This new version of it, is running now extremly nice, the subsystem ]
[ is no harm at all. The file should be known as MPEGW32W.ZIP.        ]

From: michael@ecel.uwa.edu.au (Michael Simmons  - division)

MPEGPLAY V1.61 (c) 1993,1994 Michael Simmons

Please READ ALL of this file!

This is Release Version 1.61 of my port of the Berkeley mpeg player.

Note this version requires the WIN32s V1.15a Windows(tm) Extender.
Also this version will only work under (beta 612) of Windows NT(tm) V3.5 or later.

Features added in this version include
(1) Support for MPEG1 System Layer files (you don't have to split them now).
(2) Support for the Microsoft(tm) WinG(tm) Windows(tm) gaming library.
(3) Improved colours for the Ordered and 2x2 Order dithers.
(4) "Save As" For all the Mosaic Users.
(5) Improved Error handling for corrupt/non standard mpeg files.
(6) Support for CDI(tm) and VideoCD Streams. Either as an extracted MPEG
    sequence or as a RAW CDROM grab.
(7) Recompiled using the Microsoft Daytona(tm?) (beta 612) SDK Compiler.

Please Email me with any suggestions you may have on improving the player!
(See the section CONTACTING ME).

This player can play standard mpeg files that include P and B frame
encoding, and large 354x288 movie files. 
It has several display options including mono, gray scale, color dither and
Full colour (for Hicolor graphic cards).
8MB of Ram or greater is recommended if large Image size MPEG files 
are played.

This program is SHAREWARE Please read the REGISTER.TXT file for 
information on registering your copy. 

To install the player.  
If you don't have Win32s V1.15a installed, install it first.
Unzip the file disk1.zip to a floppy disk. 
Then run the setup.exe file via the Progman File-Run Menu
Item. 
Note: This will also install the Microsoft WinG(tm) extensions to Windows(tm)
Should you wish to remove these extensions at a later date
please refer to the section near the end of this Readme.txt file.

Read the Disclaimer in the online Help before loading any mpeg movie files.

The latest version of this software can be found first on

URL=ftp://ftp.ecel.uwa.edu.au/users/michael/

UNREGISTERED VERSION LIMITATIONS:
The unregistered version will display the About box at startup. 
IT WILL ALSO NOT HANDLE FILES BIGGER THAN 1MB!

DISTRIBUTION:

The Unregistered Version of the Player may be freely Re-Distributed so long as
(1) None of the files are modified.
(2) All files in this archive are re-distributed together.
(3) None of the files are removed from this archive.
(4) It is clearly stated that this program is Shareware, extended use of
    which requires payment to myself Michael Simmons as described in the
    players about box and the REGISTER.TXT file.
(5) If any additional files are added it must be clearly stated 
    which files have been added, who added these files and why!. 
    It must be stated that I "Michael Simmons" am in no way responsible 
    for these additional files.
(6) None of the added files can instruct the user or modify the player 
    in any way possible to enable the Unregistered Version Limitations 
    to be overcome.

The Registered Version may only be Re-Distributed with my written
approval.

KNOWN BUGS:
The player does not like certain PD/Shareware desktop addons (Clocks etc).
A small number of people are getting a GPF in POINTER.DLL. If you have
this problem and solve it please contact me. So far I can not reproduce
the fault.
The player does not multitask while scanning a file to determine whether
or not it is a system layer or straight video file. This is only a problem
on large misaligned RAW CDI or VideoCD grabs.
RAW CDI or VideoCD grabs have only be tested on 4 CDI Disks. Given the
variation found between these disks I would not be surprised if there
are problems with some disks.
If you are having a problem with a certain CDI/VideoCD disk please send a
copy (both original CD's) of it to me. If I don't already have it I will treat
it as a registration fee.
If you have a problem and are really stuck 
try and find a machine on which it works and compare the two configurations.
If you really really get stuck then see the section CONTACTING ME.

CHANGE LOG: (there is more to read after this section)

Changes V1.0 -> V1.2
(1) Re complied using the latest (March) WIN32 Beta.
(2) Includes the latest (March) Win32s windows 3.1 extension.
(3) Fix bug in finding help file. The working directory can now be different
    to the Command Line directory.
(4) Increase number of clicks at startup to 4 

Changes V1.2 -> 1.25
(1) Major rewrite of source code to clean up bugs
(2) Now saves options in a .ini file
(3) Can split a multi stream MPEG into separate files.
(4) Loop is now a separate option
(5) Can be set to skip over B and P frames ( best to stop and rewind player 1st)
(6) Decrease the number of About Box clicks to one
(7) Can started via the file manager (associate .mpg with the player)
(7b) Also startable from other applications i.e. NCSA Mosaic.
(8) Recompiled with the release version of the Visual C++ for NT compiler
(9) includes the Win32s version 1.1 files
(10) Can change InputBufferSize in .ini file (i.e. InputBufferSize=80000)
(11) Don't have to Close MPEG before OPEN ing
(12) MPEG images are properly clipped when they are displayed
(13) Hopefully no one will have any display problems now (try Use Small DIBS)

Changes V1.25 -> V1.30
(1) Increased speed 10-20% (mainly P B frames and gray, Full/Hi Color dither).
(2) Fixed bug, old mpegs causing exceptions (bus.mpg,flower.mpg,flowb.mpg etc).
(3) Decreased the memory usage.
(4) Added HiColor Dither (Uses 16 Bit DIBS,These are not supported by many
    drivers yet, NT emulates support in the GDI).
(5) Dropped Fs2 and Fs4 dither (use Fs2Fast)

Changes V1.30 -> V1.50
(1) Added Push button, VCR like controls.
(2) Now has a Separate Video Window.
(3) Automatically Displays the 1st frame of the MPEG.
(4) Redraws the current frame when needed.
(5) Displays MPEG File Name, Image Dimensions and File Size in Video Caption
(6) Saves all window positions correctly when exiting.
(7) Detects when saved windows position is off the screen.
(8) Added Experimental Set+Blt Mode for transferring images to the screen.

Changes V1.50 -> V1.60
(1) Support for MPEG1 System Layer files (you don't have to split them now).
(2) Support for the Microsoft(tm) WinG(tm) Windows(tm) gaming library.
(3) Improve colors for the Ordered and 2x2 Order dithers.
(4) "Save As" For all the Mosaic Users.
(5) Improve Error handling for corrupt/non standard mpeg files.
(6) Support for CDI(tm) and VideoCD Streams. Either as an extracted MPEG
    sequence or as a RAW CDROM grab.
(7) Recompiled using the Daytona (beta 612) SDK Compiler.

ACKNOWLEDGMENTS:

This code was derived from the U.C. Berkeley MPEG Player (version 2.0)
developed by L.A. Rowe, K. Patel, and B. Smith (Rowe@CS.Berkeley.EDU).
Permission to use their code in this Sharware product was obtained.
THAT code included the following copyright:

/*
 * Copyright (c) 1992 The Regents of the University of California.
 * All rights reserved.
 * 
 * Permission to use, copy, modify, and distribute this software and its
 * documentation for any purpose, without fee, and without written agreement is
 * hereby granted, provided that the above copyright notice and the following
 * two paragraphs appear in all copies of this software.
 * 
 * IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
 * DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT
 * OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
 * CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 * 
 * THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANT ABILITY
 * AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS
 * ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
 * PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
 */
/*

OTHER ACKNOWLEDGMENTS:
Frank Gadegast (the MPEG FAQ Maintainer) for his helpful suggestions.
Many others for their suggestions and support.

PATENTS:
Should this player infringe on a patent held by someone somewhere.
Please contact me as soon as possible. See the section CONTACTING ME

CONTACTING ME:
In any correspondence please clearly state your email and snail mail addresses!

I have been receiving a large number of emails. 
In-order to handle these efficiently I would ask that you note the following:
(1) If possible look on

URL=ftp://ftp.ecel.uwa.edu.au/users/michael/faq.txt

(2) Mark all emails that do not require a reply "No Reply Expected". I will READ THESE!
(3) Bounced replies due to incorrect email addresses (unless obvious) will not 
    be chased up!

Email to michael@ecel.uwa.edu.au
Talk to michael@div-pc-michael.ecel.uwa.edu.au  (8:30am to 5:00pm WA time).
Phone to (Int)+ 61 9 344 1998 (Home number with answering machine)
Don't automatically expect me to ring outside of Western Australia.
I can be contacted via snail mail to PO Box 506,NEDLANDS WA 6009,AUSTRALIA

NOTE None of the source code to this player is on any of the machines
     connected to the net via the University of Western Australia.
IF   someone on network news is flaming me or my port of the player. Please
     Email me about it.

OTHER INFO:
There is another mpeg player for windows available for free from

URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/mpeg2w11.zip

I have nothing to do with this player. None of the source for that player
is related to mine.

All of the money from registration is being spent on tools and 
hardware to improve the player and further my knowledge of MPEG and 
programming.
This player is written and maintained in my free time. It is in no-way
related to the University of Western Australia.
They have indicated they have no interest in the player or its copyright.

The Source to this player is NOT Available!

HOW TO REMOVE THE WIN32s EXTENSIONS to WINDOWS(tm)

(1) exit to DOS.
(2) backup your hard disk.
(3) delete the Win32s directory and all its files.
(4) edit the system.ini file in the window directory.
    and remove the line device=C:\WINDOWS\SYSTEM\WIN32S\W32S.386
(5) return to windows
(6) remove the Win32 Applications Progman group

HOW TO REMOVE THE WING EXTENSIONS TO WINDOWS(tm)

(1) exit to DOS.
(2) backup your hard disk.
(3) delete the following files from you c:\windows\system directory
    dva.386
    wing.dll
    wing32.dll
    wingde.dll
    wingdib.drv
    wingpal.wnd
(4) edit the system.ini file in the window directory.
    and remove the line device=C:\WINDOWS\SYSTEM\dva.386
(5) return to windows

Windows NT, Win32s, Windows 3.1, WinG are trademarks of the Microsoft Corporation.
CDI is a trademark of Phillips.

---------------------------------------------------------------------------

~Subject: SUBSECTION - OS/2

---------------------------------------------------------------------------

~Subject: mp

mp.lha               gfx/show    45K  83 MPEG player for EHB display.

---------------------------------------------------------------------------

~Subject: SUBSECTION - X-WINDOWS and UNIX

---------------------------------------------------------------------------

~Subject: Berkeley's MPEG Tools

[ These tools were still in Beta-Version when the FAQ was compiled ]
[ Try ftp to

URL=ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/

[ find the next 4 tools.                                           ]

This version of the Berkeley MPEG Tools packages together the decoder 
(mpeg_play), the encoder (mpeg_encode), and three analysis tools (mpeg_stat,
mpeg_blocks, and mpeg_bits).  Our last estimate was that over 60,000 copies 
of the decoder have been FTP'd since the first release in November 1991,
and over 15,000 copies of the encoder have been FTP'd since it was released 
in July 1993.

For other information on multimedia research at U.C. Berkeley, see the home
page for the Plateau Multimedia Research Group.
	http://www-plateau.cs.berkeley.edu/plateau.html

Further about the FTP site is included in INDEX.  See ANNOUNCE for our
posted announcement of the tools.

(Last updated: May 5, 1995)

-- 
Eugene Hung                             eyhung@garnet.berkeley.edu
Peter's Theorem:
  Incompetence plus incompetence equals incompetence.

---------------------------------------------------------------------------

~Subject: MPEG-1 Video Software Encoder

                 MPEG-1 Video Software Encoder
                (Version 1.5; May 8, 1995)

     Lawrence A. Rowe, Kevin Gong, Eugene Hung, Ketan Patel, Steve Smoot
       and Dan Wallach
    Computer Science Division-EECS, Univ. of Calif. at Berkeley

This directory contains the freely distributed Berkeley MPEG-1 Video 
Encoder.  The encoder implements the standard described in the ISO/IEC
International Standard 11172-2.  The code has been compiled and tested 
on the following platforms:

 DECstation 5000 and Alpha
 HP PA-RISC (HP/UX 9.X) (i.e., HP 9000/7XX and 9000/3XX)
 SGI Indigo running IRIX 5.0.1
 Sun Sparc (SunOS 4.X)

In addition, Rainer Menes from the Technical University of Munich has
ported the encoder and decoder to the Macintosh.  You can get that code
directly from him (menes@statistik.tu-muenchen.de), or from the 
Berkeley FTP archive (mm-ftp.CS.Berkeley.EDU).  If you decide to port 
the code to a new architecture, please let us know so that we can 
incorporate the changes into our sources.

This directory contains everything required to build the encoder
and run it.  We have included source code, makefiles, binaries
for selected platforms, documentation, and test data.  Installation 
instructions are given in the file named src/mpeg_encode/INSTALL.  A man 
page is given in the file doc/mpeg_encode.1.  A detailed user 
manual is provided in postscript format in the file doc/user-manual.ps.

The encoder will accept any input file format as long as you provide 
a script to convert the images to PPM, YUV, JPEG, or JMOVIE format.  Input 
file processing is described in the file doc/INPUT.FORMAT.  Options to 
control input file processing and compression parameters are specified in 
a parameter file.  Very little error processing is done when reading 
this file.  We suggest you start with the sample parameter file 
examples/template.param and modify it.  See also examples/default.param.

The convert directory of Mpeg-Tools contains utilities you might find 
useful including: 

programs to do PPM/YUV conversion and programs to convert Parallax
XVideo JPEG files into PPM, YUV, or JPEG frames.

The motion vector search window can be specified, including half-pixel
block matching, in the parameter file.  We have implemented several 
search algorithms for P-frames including: 1) exhaustive search, 
2) subsampled search, and 3) logarithmic search.  We have also implemented
several alternatives for B-frame block matching including: 1) interpolate
best forward and best backward block, 2) find backward block for best
forward or vice-versa (called CROSS2), and 3) exhaustive cross product
(i.e., go out for coffee and a donut!). The search algorithms are controlled
by options in the parameters file.  For tips on choosing the right search
technique, see the user manual.

The encoder can be run on one computer (i.e., sequential) or on several
computers (i.e., parallel).  Our goal is to produce a portable, easy-to-use
encoder that we can use to encode large volumes of video material for
the Berkeley VOD system (see paper VodsProp93.ps.Z on the FTP archive).
The parallelism is done on a sequence of pictures.  In other words, you 
can spawn one or more children to encode continuous runs pictures. The 
uncompressed data can be accessed either through NFS or TCP sockets.  
The goal is to allow you to encode using multiple processors, think 
spare cycles on workstations, to speed up the encoding time.  Although
performance depends on the speed of individual processors, the file system
and network, and the P/B frame search methods, we have encoded 3.75
frames/second on 8 HP Snakes running in parallel as compared with 0.6
frames/second on 1 Snake.  These are preliminary results. We are continuing 
to experiment with and tune the code.  Instructions to run the parallel system 
are given in the man page and the parallel.param example parameter file.

We have done some tuning to produce a reasonable encoder, but there are
many more optimizations that we would like to incorporate.  These 
extensions are listed in the file doc/EXTENSIONS.  If you succeed in 
implementing any of them, please let us know! 

Send bug reports to:

mpeg-bugs@CS.Berkeley.EDU
   Problems, questions, or patches should be sent to this address.

Anyone interested in providing financial support for this research or 
discussing other aspects of this project should contact Larry Rowe at 
Rowe@CS.Berkeley.EDU (+1 510-642-5117).

This software is freely distributed.  That means, you may use it for 
any non-commercial purpose.  However, patents are held by several companies 
on various aspects of the MPEG video standard.  Companies or individuals
who want to develop commercial products that include this code must
acquire licenses from these companies.  For information on licensing, see
Appendix F in the standard.

ACKNOWLEDGEMENTS:

We gratefully thank Hewlett-Packard and Fujitsu who provided financial
support for this work.  We also want to thank the following people and
organizations for their help:

    Jef Poskanzer who developed the pbmplus package.
    ---------
    Copyright (C) 1989, 1991 by Jef Poskanzer.

    Permission to use, copy, modify, and distribute this software and its
    documentation for any purpose and without fee is hereby granted, provided
    that the above copyright notice appear in all copies and that both that
    copyright notice and this permission notice appear in supporting
    documentation.  This software is provided "as is" without express or
    implied warranty.
    ---------

    Eiichi Kowashi of Intel and Avideh Zakhor of U.C. Berkeley who
    provided valuable suggestions on motion vector searching.

    Chad Fogg of the University of Washington who has helped us 
    understand many issues in MPEG coding and decoding.

    Rainer Menes of the Technical University of Munich who has ported the
    the Berkeley MPEG encoder and decoder to the Macintosh, and he has 
    provided us with many suggestions to improve the code.

    Robert Safranek of ATT for comments, suggestions, and most of the
    code for custom quantization tables.

    Jim Boucher of Boston University for jmovie2jpeg.

    The San Diego SuperComputing Center for providing facilities to 
    develop some of the code contained within.

-- 
Eugene Hung                             eyhung@garnet.berkeley.edu

---------------------------------------------------------------------------

~Subject: MPEG Video Software Decoder

                  MPEG Video Software Decoder
                  (Version 2.1; May 1 1995)

 Lawrence A. Rowe, Ketan Patel, Brian Smith, Steve Smoot, and Eugene Hung
      Computer Science Division-EECS, Univ. of Calif. at Berkeley

This directory contains a public domain MPEG video software
decoder. The decoder is implemented as a library that will
take a video stream and display it in an X window on an 8, 24
or 32 bit deep display.  The main routine is supplied to
demonstrate the use of the decoder library. Several dithering
algorithms are supplied based on the Floyd-Steinberg, ordered
dither, and half-toning algorithms that tradeoff quality and
performance. Neither the library nor the main routine handle
real-time synchronization or audio streams.

The decoder implements the standard described in the Committee 
Draft ISO/IEC CD 11172 dated December 6, 1991 which is
sometimes refered to as "Paris Format." The code has been
compiled and tested on the following platforms:

 HP PA-RISC (HP/UX 9.X, X11R5) (i.e., HP 9000/7XX and 9000/3XX)
 Sun Sparc (SunOS 4.X, X11R5)
 DECstation 5000 and Alpha
 Silicon Graphics Indigo
 MIPS RISC/os 4.51

If you decide to port the code to a new architecture, please let
us know if there are any significant changes, so that we can incorporate
them into our sources. 

This directory contains everything required to build and
display video. We have included source code, a makefile, an Imakefile,
installation instructions, and a man page. Data files can
be obtained from the same ftp site this was located in.
See the INSTALL file for instructions on how to
compile and run the decoder. 

The data files were produced by XING. XING data does not take
advantage of P or B frames (ie, frames with motion compensation). 
Performance of the player on XING data is significantly slower 
(half or less) than the performance when motion compensated MPEG 
data is decoded. We are very interested in running the software 
on other MPEG streams.  Please contact us if you have a stream 
that does not decode correctly. Also, please send us new streams
produced by others that do utilize P and B frames.

Our future plans include porting the decoder to run on other
platforms, integrating it into a video playback system that
supports real-time synchronization and audio streams, and
further experiments to improve the performance of the
decoder. Vendors or other organizations interested in supporting 
this research or discussing other aspects of this project should 
contact Larry Rowe at Rowe@CS.Berkeley.EDU.

Other Versions:
There are three variations of the old mpeg_play:
  One added a very nice Motif interface (variously named 
	mpeg_play-2.0.1 and xmpegplay).
  One was mpegvga.patch and let linux play straight to a VC.
  One was an X interface (mpegplayer.tar.gz on linux sites)
We have notified the authors of those programs, and will
have new versions of them here as soon as they can find the time
to update them.


Reporting bugs:
    If you find any bugs in this software, please send them to
    mpeg-bugs@plateau.cs.berkeley.edu.  Since this software
    is unsupported, we make no guarantees about how long it will
    take to fix the bug, or if it will be fixed at all.  Bug fixes
    will be cheerfully accepted.  Please include as much detailed
    information as possible, including:

	1) the version number of the program you are using (cf. VERSION)
	2) the data file that caused the bug (if possible)
	3) the OS version and machine type you ran the program on
	4) the compiler used to compile the program

ACKNOWLEDGEMENTS:
	We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor
	Research Corporation for financial support.

	We also want to thank the following people for their help:

	Tom Lane of the Independent JPEG Group provided us with
		the basic inverse DCT code used by our player.
		(tom_lane@g.gp.cs.cmu.edu)

	Reid Judd of Sun Microsystems provided advice and assistance.

	Todd Brunhoff of NVR provided advice and assistance.

	Toshihiko Kawai of Sony provided advice and assistance.

-- 
Eugene Hung                             eyhung@garnet.berkeley.edu

---------------------------------------------------------------------------

~Subject: MPEG Video Software Analyzer

                  MPEG Video Software Analyzer
                  (Version 1.0; May 81995)

 Lawrence A. Rowe, Doug Banks, Steve Smoot, and Sam Tze-San Fung 
 Computer Science Division-EECS, Univ. of Calif. at Berkeley

This directory contains a public domain tool to monitor and modify 
MPEG video streams.  mpeg_bits takes as input an mpeg stream and
presents graphical feedback on the distribution of bits in the
stream, on a macroblock-by-macroblock level.  mpeg_bits also provides
a simple user interface to generate specifics files that can be
used by mpeg_encode to re-encode a stream, modifying the encoding 
on a macroblock-by-macroblock level.  [The present version of mpeg_encode
does not support this..]

This tool does not support system layer streams.

mpeg_bits supports the standard described in the Committee 
Draft ISO/IEC CD 11172 dated December 6, 1991 which is
sometimes refered to as "Paris Format." The code has been
compiled and tested at least once on the following platforms:
	
 HP PA-RISC (HP/UX 9.X, X11R5) (i.e., HP 9000/7XX and 9000/3XX)
 Sun Sparc (SunOS 4.X, X11R5)

If you decide to port the code to a new architecture, please let
us know about important changes, so that we can incorporate the changes
into our sources. 

This directory contains everything required to build and use
mpeg_bits.  We have included source code, a makefile, installation
instructions, and a man page.  
END ---------------------- CUT HERE --------------------- 5/8
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.kei.com!news.mathworks.com!gatech!howland.reston.ans.net!Germany.EU.net!netmbx.de!zrz.TU-Berlin.DE!cs.tu-berlin.de!phade
From: phade@cs.tu-berlin.de (Frank Gadegast)
Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers
Subject: MPEG-FAQ: multimedia compression [6/8]
Followup-To: alt.binaries.multimedia
Date: 9 Jun 1995 11:02:59 GMT
Organization: Technical University of Berlin, Germany
Lines: 1306
Approved: news-answers-request@MIT.EDU
Expires: 31 Dec 1995 12:00:00 GMT
Message-ID: <3r99p3$2s9@news.cs.tu-berlin.de>
Reply-To: phade@cs.tu-berlin.de
NNTP-Posting-Host: benjamin.cs.tu-berlin.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4
Keywords: MPEG, FAQ, Compression
Xref: senator-bedfellow.mit.edu comp.graphics:77883 comp.graphics.animation:20015 comp.compression:20444 comp.multimedia:36452 alt.binaries.multimedia:40221 alt.binaries.pictures.utilities:37041 alt.binaries.pictures:21190 alt.binaries.pictures.d:20803 alt.answers:9856 comp.answers:12389 news.answers:45909

Archive-name: mpeg-faq/part6
Last-modified: 1995/06/07
Version: v 4.0 95/06/07
Posting-Frequency: bimonthly
BEGIN -------------------- CUT HERE --------------------- 6/8

See the INSTALL file for instructions on how to
compile and run the analyzer.

Our future plans consist of more fully supporting an interactive
editor paradigm; specifying changes directly on the display, 
seeing the results of edits on the video stream immediately
as they occur, etc.  We would also like to port the code to
run on more platforms, and add support for system layer streams.
Vendors or other organizations interested in supporting 
this research or discussing other aspects of this project should 
contact Larry Rowe at Rowe@CS.Berkeley.EDU.

Reporting bugs:
    If you find any bugs in this software, please send them to
    mpeg-bugs@plateau.cs.berkeley.edu.  Since this software
    is unsupported, we make no guarantees about how long it will
    take to fix the bug, or if it will be fixed at all.  Bug fixes
    will be cheerfully accepted.  Please include as much detailed
    information as possible, including:

	1) the version number of the program you are using (cf. VERSION)
	2) the data file that caused the bug (if possible)
	3) the OS version and machine type you ran the program on
	4) the compiler used to compile the program

ACKNOWLEDGEMENTS:
	We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor
	Research Corporation for financial support.

	We also want to thank the following people for their help:

	Tom Lane of the Independent JPEG Group provided us with
		the basic inverse DCT code used by our player.
		(tom_lane@g.gp.cs.cmu.edu)

	Reid Judd of Sun Microsystems provided advice and assistance.

	Todd Brunhoff of NVR provided advice and assistance.

	Toshihiko Kawai of Sony provided advice and assistance.

-- 
Eugene Hung                             eyhung@garnet.berkeley.edu

---------------------------------------------------------------------------

~Subject: MPEG Blocks Analyzer

                    MPEG Blocks Analyzer
                  (Version 1.0; Feb 1 1995)

                       Ketan Patel
                       Steve Smoot 
                       Brian Smith
                     Sam Tze-San Fung

 Computer Science Division-EECS, Univ. of Calif. at Berkeley

This directory contains a public domain MPEG video software
analyzer.  It operates by playing a video stream in one window, while
another window displays the block type and motion vectors for each block in
the current frame.

The decoder implements the standard described in the Committee 
Draft ISO/IEC CD 11172 dated December 6, 1991 which is
sometimes refered to as "Paris Format." The code has been
compiled and tested on the following platforms:


 HP PA-RISC (HP/UX 8.X, X11R4) (i.e., HP 9000/7XX and 9000/3XX)
 Sun Sparc (SunOS 4.X, X11R5)

This directory contains everything required to build and
display video. We have included source code, a makefile, 
installation instructions, and a man page. Data files can
be obtained from the same ftp site this was located in.
See the INSTALL file for instructions on how to
compile and run mpeg_blocks.

Problems, questions, or patches should be sent to:
	mpeg-bugs@Plateau.CS.Berkeley.EDU

ACKNOWLEDGEMENTS:
	We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor
	Research Corporation for financial support.

	We also want to thank the following people for their help:

	Tom Lane of the Independent JPEG Group provided us with
		the basic inverse DCT code used by our player.
		(tom_lane@g.gp.cs.cmu.edu)

	Reid Judd of Sun Microsystems provided advice and assistance.

	Todd Brunhoff of NVR provided advice and assistance.

	Toshihiko Kawai of Sony provided advice and assistance.

-- 
Eugene Hung                             eyhung@garnet.berkeley.edu

---------------------------------------------------------------------------

~Subject: MPEG Video Software Statistics Gatherer

              MPEG Video Software Statistics Gatherer
                  (Version 2.2; May 8, 1995)

 Lawrence A. Rowe, Steve Smoot, Ketan Patel, and Brian Smith
 Computer Science Division-EECS, Univ. of Calif. at Berkeley

This directory contains a public domain MPEG video statistics gatherer.
The decoder implements the standard described in the Committee 
Draft ISO/IEC CD 11172 dated December 6, 1991 which is
sometimes referred to as "Paris Format." The code has been
compiled and tested on the following platforms:

 HP PA-RISC (HP/UX 9.X) (i.e., HP 9000/7XX and 9000/3XX)
 Sun Sparc (SunOS 4.X)
 DECstation 5000 and Alpha
 Sequent
 Irix 4.0.5
 Linux

See the CHANGES file for information on all the improvements over 2.0

See the manual page for information on how to use mpeg_stat.

Send bug reports to mpeg-bugs@plateau.cs.berkeley.edu,
job offers (PhD in '96) to smoot@cs.berkeley.edu ;-)

Vendors or other organizations interested in supporting 
this research or discussing other aspects of this project should 
contact Professor Larry Rowe at rowe@CS.Berkeley.EDU.

FUTURE PLANS:
In the next version I'd like to beef up the verification code and do
something with system layer audio (when present).  In addition (major
though) MPEG-2 would be cool.  If you send me code to do any of this, it
will be much appreciated.  (In general, though, I'll only be improving it
to meet my thesis needs. -srs)

INSTALL:
  If you have gcc, type "make"
  See the file INSTALL for slightly more help.

AUDIO (we don't do audio, but Chad Fogg points out):
  CCETT has been distributing executables only of their Audio bitstream
  syntax verifier.  The site address is: 161.105.2.22
  Audio conformance bitstreams are also at ftp.tnt.uni-hannover.de 

ACKNOWLEDGEMENTS:
	We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor
	Research Corporation for financial support.

	We also want to thank the following people for their help:

	Tom Lane of the Independent JPEG Group provided us with
		the basic inverse DCT code used by our player.
		(tom_lane@g.gp.cs.cmu.edu)

	Reid Judd of Sun Microsystems provided advice and assistance.

	Todd Brunhoff of NVR provided advice and assistance.

	Toshihiko Kawai of Sony provided advice and assistance.

-- 
Eugene Hung                             eyhung@garnet.berkeley.edu

---------------------------------------------------------------------------

~Subject: xmg

XMG v1.0 - The X MPEG Grabber  
*******************************

DESCRIPTION
+++++++++++

XMG is a utility for the X Window System which allows you to create MPEG-1 video streams by repeatedly
grabbing a window on the screen and then joining the frames into an MPEG sequence. XMG has several
options that modify its behaviour, but it also provides sensible defaults for most of them. The two switches that
you'll use most of the time are -fps (or -fpm) and -frames. These specify the number of frames per second (or
per minute) and the total number of frames to grab. Here's an example invocation : 

        xmg -fps 1 -frames 20

This specifies that we want to grab 20 frames, one per second, and also that we want to see what's going on
during the grabbing process. At this point the XMG window will appear : 

                         

Click on the "Grab" button and then click with the left mouse button inside the window that you want to grab.
Once you've done this, the grabbing process will begin immediately, displaying some progress information as
it does it. It is possible to change a few parameters directly from inside the window, instead of specifying them
on the command line. When all the frames have been grabbed, the MPEG encoding process begins: go off and
make yourself a nice cup of tea and come back later. By default the program creates a file called xmgout.mpg
in the current directory. This file can then be viewed with any MPEG player which supports I,P and B frames
of any size (Xing for example, doesn't support them). You can specify a different name for the output file with
the -output switch. For example, the command : 

        xmg -fps 1 -frames 20 -output mympeg.mpg

will create a file called mympeg.mpg. When XMG is grabbing the frames, it stores them in a temporary RLE
compressed and archived format called XLA. This file can become quite large very quickly, especially if you're
grabbing several frames of a certain size. This file will be created by default in the /tmp directory with the
name xmgtmp.$$$. This can be changed with the -tmp option : 

        xmg -fps 1 -frames 20 -tmp /empty/xmpeggrab.tmp

which will create it in the /empty directory with the name xmpeggrab.tmp. Make sure you've got plenty of
space on the device ! To actually perform the encoding, XMG requires a parameter file. By default this file is
called xmg.param and has to be in the current directory. Don't worry if you haven't got one : XMG will create
a default one for you and use that. A different parameter file can be specified with the -param switch : 

        xmg -fps 1 -frames 20 -param flower.param

This will use the file flower.param. A description of the possible contents of the paramter file is provided later
on. 

SYNOPSIS
++++++++

    xmg
        -help
        -display host:dpy
        -frames nframes
        -fps nfps
        -fpm nfpm
        -terse 
        -output filename
        -tmp filename
        -param filename

OPTIONS
+++++++

-fps nfps : specifies the number of frames per second to grab. Even if the machine you're using is slow, XMG
will grab the server during the grab, so that no other application can write to the screen at the same time. As
soon as the frame has been grabbed, the server is released so that the other applications can redraw their client
area. 

-fpm nfpm : specifies the number of frames per minute to grab. 

-frames nframes : specifies the number of frames to grab in total. 

-output filename : specifies a name and location for the generated MPEG stream. By default XMG creates a
file in the current directory called xmgout.mpg. 

-tmp filename : specifies a name and location for the temporary storage of the grabbed frames. This file is
deleted when XMG has completed the encoding process. The default is /tmp/xmgtmp.$$$ 

-terse : does not display the XMG status window during the grabbing/encoding process. The default is to
display the XMG window. 

-param : specifies a name and location for the parameter file. By default the file is called xmg.param and has to
be in the current directory. If one doesn't exist, a default one will be created for you. 

PARAMETER FILE
++++++++++++++

The parameter file MUST contain the following lines : 

PATTERN pattern
---------------

pattern is a sequence of I's, P's and B's, that specifies the order of the frames in the MPEG stream. 

GOP_SIZE n
----------

n is roughly the number of frames in a Group of Pictures (roughly because a GOP must begin with an I-frame) 

SLICES_PER_FRAME n
------------------

n is roughly the number of slices per frame. Note, at least one MPEG player may complain if slices do not start
at the left side of an image. To ensure this does not happen, make sure the number of rows is divisible by
SLICES_PER_FRAME. 

PIXEL (FULL or HALF)
--------------------

use half-pixel motion vectors, or only full-pixel ones 

RANGE 
------

use a search range of +/- n pixels 

PSEARCH_ALG algorithm
---------------------

algorithm must be one of {EXHAUSTIVE, TWOLEVEL, SUBSAMPLE, LOGARITHMIC}. Tells what kind
of search procedure should be used for P-frames. Exhaustive gives the best compression, but logarithmic is the
fastest. You select the desired combination of speed and compression. TWOLEVEL is an exhaustive full-pixel
search, followed by a local half- pixel search around the best full-pixel vector (the PIXEL option is ignored
for this search algorithm). BSEARCH_ALG algorithm must be one of {SIMPLE, CROSS2, EXHAUSTIVE}.
Tells what kind of search procedure should be used for B-frames. Simple means find best forward and
backward vectors, then interpolate. Cross2 means find those two vectors, then see what backward vector best
matches the best forward vector, and vice versa. Exhaustive does an n-squared search and is EXTREMELY
slow in relation to the others (Cross2 is about twice as slow as Simple). 

IQSCALE
-------

use n as the qscale for I-frames 

PQSCALE
-------

use n as the qscale for P-frames 

BQSCALE
-------

use n as the qscale for B-frames 

REFERENCE_FRAME (ORIGINAL or DECODED)
-------------------------------------

If ORIGINAL is specified, then the original images are used when computing motion vectors. To be more
accurate, use DECODED, in which the decoded images are used. This should increase the quality of the image,
but will take a bit longer to encode. 

The lines may appear in any order, except the following exceptions. 

NOTES
+++++

If XMG was compiled with the -DMITSHM switch enabled, then shared memory will be used if available and
will increase performance noticeably. 

AUTHOR
++++++

Tristan Tarrant - University of Sussex, UK, tristant@cogs.susx.ac.uk 

CREDITS
+++++++

MPEG encoding based on mpeg_encode by : 

Kevin Gong - University of California, Berkeley, keving@cs.berkeley.edu 

Ketan Patel - University of California, Berkeley, kpatel@cs.berkeley.edu 

Dan Wallach - University of California, Berkeley, dwallach@cs.berkeley.edu 

BUGS AND LIMITATIONS
++++++++++++++++++++

XMG works only on Pseudo-Color displays. No known bugs. 

Tristan Tarrant, tristant@cogs.susx.ac.uk

---------------------------------------------------------------------------

~Subject: mpegstat

Tom Pfeifer (pfeifer@fokus.gmd.de) announces:

[ mpegstat.tar.Z was uploaded to mm-ftp.cs.berkeley.edu, the DOS-port ]
[ is available on ftp.cs.tu-berlin.de                                 ]
[ It will probably included in the next version of Berkeley's encoder ]

This is mpegstat v1.0 - an analyzing took for MPEG-I video streams for Unix. 
It is based on the Berkeley MPEG player v2.0, utilizing the Berkeley parsing 
and decoding routines for the MPEG data stream.


MPEGSTAT is  a  useful utility for analyzing MPEG-I video
streams. It is based on the Berkeley  MPEG  movie  player.
MPEGSTAT reads  a  video  stream from a file or stdin and
shows the frame type pattern as it is found while parsing.
After  the  stream  is  completely  parsed it displays the
frame pattern as it would be displayed by a  MPEG  viewer.
It then generates a summary of various mpeg format related
statistics.  MPEGSTAT works for MPEG movies that are Paris
format compatible.


Authors

Multimedia  systems  project - Technical University of Berlin, Germany
Tom   Pfeifer,   Dept.   of    Computer    Science, pfeifer@fokus.gmd.de
Jens  Brettin - Alexander Schulze - Harald Masche - Dirk Schubert

---------------------------------------------------------------------------

~Subject: mplex

*********************************************************************
*                                                                   *
*         ANNOUNCING OF A FREE MPEG 1/SYSTEMS MULTIPLEXER           *
*                                                                   *
*   thanks to                                                       *
*   ^^^^^^^^^                                                       *
*    SIEMENS LTD, CORPORATE RESEARCH AND DEVELOPMENT ZFE ST SN 11   *
*         TECHNICAL UNIVERSITY OF MUNICH, PROF. SCHLICHTER          *
*                                                                   *
*********************************************************************


Hello all.

This is an announcing for all of those that have already been waiting
on the release of my code for multiplexing one  MPEG 1 Audio  and one
MPEG 1 Video Stream   into a  MPEG 1/SYSTEMS  multiplexed data stream
according to the ISO/IEC 11172-1 specs.  Sorry for all of those  that
needed the code really bad and kept mailing me on it. I couldn't hold
my promises because of copyright release on part of the University.

But here it is: I uploaded the source code on

URL=ftp://hpsystem2.informatik.tu-muenchen.de//pub/comp/graphics/mpeg/mplex/mplex-1.0beta.tar.gz
    [131.159.0.198]
    ftp.informatik.tu-muenchen.de

.gz means it is compressed with GNU zip. Should somebody not have it,
you can find it on our FTP server under

   /pub/comp/gnu/gzip/

else, just try

   get mplex-1.0beta.tar.Z

Our FTP server will do an on-the-fly-compressing with the 'compress'
(.Z) format.


Now to the code itself:

I have been kept really busy with my papers on multiplexing (they will
shortly be available on the FTP server also, I will post on that),  so
sorry if I couldn'g tighten the code up a bit.  There is no real docu-
mentation yet, please try out the code.  Feel free to email me for any
further questions.

As of now, this code will only run under standard UN*X-Style platforms
providing a (K&R-Style) C compiler (GNU CC is fine). It tested fine on
SUN's, HEWLETT PACKARD's series 700, SILICON GRAPHICS machine's.
There is * NO DOS PORT AVAILABLE (YET) *.

Contact me if you are planning such a thing.

There will be better releases, and I promise to clean up the code soon.

:)

This Software is released under the terms of the GNU public license,
see the tar archive for further details. Feel free to archive the code
on other FTP servers or post it to newsgroups, if there is such
interest.


Research done at 

    SIEMENS LTD, CORPORATE RESEARCH AND DEVELOPMENT ZFE ST SN 11
    TECHNICAL UNIVERSITY OF MUNICH, PROF. SCHLICHTER

Christoph Moar             moar@Informatik.TU-Muenchen.DE (Christoph Moar)

---------------------------------------------------------------------------

~Subject: xmplay

[ Here it is !! The first, fully-featured MPEG-player with X11-interface. ]
[ XMPLAY exists currently in Version 1.0, patches are available. The next ]
[ Version 1.1 is currently in development. Thats the announcement !       ]

            XMPLAY [Version 1.1] - Sun Apr 10 14:51:22 MDT 1994

      This distribution is the result of a project worked out at the
      Technical University (TU) Berlin, held in Winter 93/94 by
      Tom Pfeifer. The basic idea is created by Frank Gadegast,
      the programing work was then done by Juergen Meyer, Metin
      Cetinkaya and Frank Gadegast.

This software is ftp-able from:

URL=ftp://ftp.cs.tu-berlin.de/pub/incoming/xmplay-1.0.tar.gz
    [130.149.17.7]
    quepasa.cs.tu-berlin.de
URL=ftp://ftp.cs.tu-berlin.de/pub/incoming/xmplay-1.0.patch.tar.gz

[ Just to remember .gz means, its compressed using GNU's zip, called ]
[ gzip. Use gunzip to uncompress.                                    ]


XMPLAY [Version 1.1]

<IMG SRC="xmplay1.gif"> <IMG SRC="xmplay2.gif">

XMPLAY is a very nice directory-browser under X11 to use XMPEG,
the interactive X11-MPEG-player.

MPEG is a video-format described by the ISO-standard ISO CD11172.
This implementation here can handle MPEG-stream written down
at the MPEG-group-meeting in Paris '92. It can handle IPB-frames
but no system- nor audio-information.

<IMG SRC="xmplay3.gif"> <IMG SRC="xmplay4.gif">

Additional you get a little utility called MPEGINFO, showing you, if called
with the filename of a MPEG-file the most important parameter it can read
dirrectly from its header, like size, picture rate or frame-style.

It should work under nearly every system, 'cause it's programed without
MOTIF, the X11-Toolit or other stupid things, that are always causing
problems. It only needs the X11-library, no matter if you're using
Release 3, 4 or Release 5.

In addition it has lots of defines to let it run under BSD, SYSV, ISC,
Solaris, SunOS, A/UX, SCO or XENIX and you don't have to hack a difficult
Imake- or Makefile and you will not have trouble with build-in pathnames !!!

It's specially made for those systems, that don't have super hardware
or that have problems with the Toolkit or MOTIF.


XMPEG [Version 1.1]

<IMG SRC="xmpeg1.gif"> <IMG SRC="xmpeg3.gif">

XMPEG is a MPEG-video-player based on the MPEG-widget-implementation
from Jim Frost and the MPEG-movie-player "mpeg_play" from the Portable
Video Research Group at Berkeley.

It just adds a few buttons and is normally getting called
from XMPLAY, but can be used as stand-alone to include into other
programs. Its programmed with the same methods than XMPLAY.

<IMG SRC="xmpeg2.gif"> <IMG SRC="xmpeg4.gif">


You can ftp XMPLAY from 'quepasa.cs.tu-berlin.de' from the
directory '/pub/msdos/incoming'.


If you get problems (not really possible) to compile it or if you have
comments send them to the authors, reachable at:

        phade@cs.tu-berlin.de (responsible for compiling and X11)
        jm@cs.tu-berlin.de (responsible for the mpeg-code) or
        brain@cs.tu-berlin.de

---------------------------------------------------------------------------

~Subject: xplayer

           Version 2.0; Jan 27, 1993)
		  (Motif interface; Jan 30, 1994)

        Lawrence A. Rowe, Ketan Patel, and Brian Smith
 Computer Science Division-EECS, Univ. of Calif. at Berkeley

                  Motif Interface: Daeron Meyer
           The Geometry Center, University of Minnesota

There are several mailing lists established for messages about
the decoder:

mpeg-list-dist@CS.Berkeley.EDU
deo Software Decoder
                  (Version 2.0; Jan 27, 1993)
		  (Motif interface; Jan 30, 1994)

        Lawrence A. Rowe, Ketan Patel, and Brian Smith
 Computer Science Division-EECS, Univ. of Calif. at Berkeley

                  Motif Interface: Daeron Meyer
           The Geometry Center, University of Minnesota

There are several mailing lists established for messages about
the decoder:

mpeg-list-dist@CS.Berkeley.EDU
   General information on the decoder for everyone interested
   should be sent to this list.  This should become active after
   11/20/92

mpeg-list-request@CS.Berkeley.EDU
   Requests to join or leave the list should be sent to this
   address. The subject line should contain the single word
   ADD or DELETE.

mpeg-bugs@CS.Berkeley.EDU
   Problems, questions, or patches should be sent to this address.

If you have any questions or bug reports for the motif version
(and I'm sure there will be plenty) please send mail to:

   daeron@geom.umn.edu

Also check out the online web documentation for the motif version:

   http://www.geom.umn.edu/docs/mpeg_play/mpeg_play.html

---------------------------------------------------------------------------

~Subject: xmpeg.tk

<IMG SRC="xmpegtk1.gif"> <IMG SRC="xmpegtk2.gif">

It's a bit confusing to have now 2 utilities having the same name
(as xmpeg is already a part of the XMPLAY distritution. It would
be nice to rename the following tool to xmpeg.tk, contacted the author
about that but got no reply :o(


xmpeg (ver 0.5b)

Tk/Tcl based front end to mpeg_play.


xmpeg is a simple script that allows users of mpeg_play to have a graphical
front end to mpeg_play. This means that one does not have to remember 
what the command line switches are needed, or what kinds of dithering are 
available. The idea for this came about when we started using NCSA's xmosaic.
Sometimes it would take 10 minutes to retrieve an mpeg file and it would only
be displayed once. If you missed it or wanted to view it again, you would
have to retreive it again and again. Thus xmpeg came into play. 
It takes a file name as an argument (a temp file in xmosaic's case)
and allows the user to specify the settings they wish to use. Then the user
clicks on 'Play Anim' and mpeg_play is invoked.

REQUIREMENTS: In order to use xmpeg you should have Tk 3.3, Tcl 7.0 and
mpeg_play 2.0. This has been tested on Sun's running SunOS 4.1.3.


Comments and/or questions should be directed to Alexei Rodriguez
(alexei@cis.ufl.edu).

AVAILABILITY:  xmpeg is available at

URL=ftp://ftp.cis.ufl.edu/pub/xmpeg
    [128.227.100.252]

I will upload it to harbor.ecn.purdue.edu.

---------------------------------------------------------------------------

~Subject: mpeg2encode / mpeg2decode

From: cfogg@netcom.com (Chad Fogg)
Subject: MPEG-2 source code and MS-DOS executables available via anon. FTP

We, the MPEG Software Simulation Group, are releasing our MPEG-2 and
MPEG-1 Video encoder and decoder source code, along with example bitstreams
and pre-compiled MS-DOS executables.  Please read the following extracts
from our README file for more information:

			  mpeg2encode / mpeg2decode
			  =========================
	      MPEG-2 Encoder / Decoder, Version 1.0, May 1994

			MPEG Software Simulation Group
			      (MPEG-L@netcom.com)

Contents:
1. Overview
2. Introduction
3. Contacting the MPEG Software Simulation Group
4. Availability 
5. Installation
6. Acknowledgements
7. History of the technical report


1. Overview
===========

This directory contains our implementation of an ISO/IEC DIS 13818-2 codec. 
It converts uncompressed video frames into MPEG-1 and MPEG-2 video 
coded bitstream sequences, and vice versa.

The files mpeg2enc.doc and mpeg2dec.doc in the doc/ directory contain
further information about the codec. The doc directory also contains an
FAQ file answering frequently asked questions about MPEG. A precompiled
version of the programs for MSDOS (requires at least a '386) and a set
of verification files are available separately.

Subdirectories src/mpeg2enc and src/mpeg2dec contain the source code
for the encoder and decoder, subdirectory par/ contains a couple of
example encoder parameter files for 25 and 30 frames/sec MPEG-2 and
MPEG-1 video.


2. Introduction
===============

MPEG-2 Video is a generic method for compressed representation of video
sequences using a common coding syntax defined in the document ISO/IEC
13818 Part 2 (CD: Nov. 1993, DIS: March 1994) by the International
Organization for Standardization (ISO) and the International
Electrotechnical Commission (IEC), in collaboration with the
International Telecommunications Union (ITU) as Recommendation H.262.
The MPEG-2 concept is similar to MPEG-1, but includes extensions to
cover a wider range of applications. The primary application targeted
during the MPEG-2 definition process was the all-digital transmission
of broadcast TV quality video at coded bitrates between 4 and 9
Mbit/sec.  However, the MPEG-2 syntax has been found to be efficient
for other applications such as those at higher bit rates and sample
rates (e.g. HDTV). The most significant enhancement over MPEG-1 is the
addition of syntax for efficient coding of interlaced video (e.g. 16x8
block size motion compensation, Dual Prime, et al).  Several other more
subtle enhancements (e.g. 10-bit DCT DC precision, non-linear
quantization, VLC tables, improved mismatch control) are included 
which have a noticeable imporvement on coding efficiency, even for
progressive video. Other key features of MPEG-2 are the scalable
extensions which permit the division of a continuous video signal into
two or more coded bit streams representing the video at different
resolutions, picture quality (i.e. SNR), or picture rates.

The MPEG Software Simulation Group is currently developing MPEG
software with the purpose of providing aid in understanding the various
algorithms which comprise an encoder and decoder, and giving a sample
implementation based on advanced encoding models. The MPEG-2 software
project is on on-going development. Since the current version of the
encoder already employs a reasonable (and the most popular) subset of
the MPEG-2 signal coding toolkit, and there appears to be sufficient
public interest, we have decided to make a first public release of the
code.

This encoder can also be used for generating good quality constant
bitrate MPEG-1 sequences and is (to our knowledge) the first public
release of an encoder based on the relatively sophisticated TM5 coding
model.


3. Contacting the MPEG Software Simulation Group
================================================

We welcome any project-specific questions, comments, suggestions, bug
reports etc. They should be sent to the Internet address: 

      MPEG-L@netcom.com 

which automatically forwards them to the authors.


4. Availability
===============

The current version of the codec source code is available by anonymous
ftp from:

URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/ or
URL=ftp://ftp.netcom.com/pub/cf/cfogg/mpeg2/

This directory contains the following files:

  README                         this file
  mpeg2codec_v1.0.tar.gz         codec source code and documentation
  mpeg2codec_verify_v1.0.tar.gz  verification archive       
  mpeg2v10.zip                   MS-DOS executable archive  
  tennis.m2v                     sample MPEG-2 video sequence (8 frames 704x576)
  tennis.par, tennis.stat.gz     parameter file and statistics output
                                 for tennis.m2v
 
You need gunzip (GNU zip/unzip) to uncompress the .gz archives.

Alternatively, the files may be retrieved by sending E-mail to:  

  ftp-request@netcom.com

... with the following line in the body of the message:

  SEND cfogg/mpeg2/mpeg2codec_v1.0.tar.gz

You can retrieve the directory listings by sending the following command
to ftp-request@netcom.com:

  DIR cfogg/mpeg2

General information can be retrieved with the command:   HELP


5. Installation
===============
[ommitted from this Usenet posting]

6. Acknowledgements
===================

Authors of the current release are:

Stefan Eckart    (stefan@lis.e-technik.tu-muenchen.de)
Chad Fogg        (cfogg@netcom.com)
Cheung Auyeung   (auyeung@mot.com)


7. History of Technical Report Project
======================================

The Technical Report, a document which primarily consists of
a C source code program, was initiated by the MPEG committee to: 

 - Provide an example of MPEG video syntax being intelligently employed 
   to generate good quality video.
 - A reference tool for implementors
 - Aid in understanding the MPEG specification 

MPEG would like to especially thank Dr. Stefan Eckart for his
contributions have greatly helped the MPEG-2 Technical Report project
start onto a successful path towards the final 13818-5 document.

MPEG lends a kind acknowledgement to Arian Koster (PTT) for initiating
the MPEG-1 technical report project in Autumn 1992, and Leonardo
Chiariglione (Chairman of MPEG) and Didier Le Gall (Chairman of MPEG
Video) for support throughout both projects.  Also many thanks to MPEG-1
project contributors Peter Au (Hughes Aircraft), Ron Burns (Hughes
Aircraft), Stefan Eckart (Technical University of Munich), Chad Fogg,
Tsuyoshi Hanamura (Waseda University), Kinya Oosa (Nippon Steel), Brian
Quandt (Heuris Logic) and Hiroshi Watanabe (NTT).

Regards,

Chad Fogg
MPEG Chair for Software Simulation
cfogg@netcom.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Version 1.1a of the MPEG Software Simulation Group's MPEG-2 codec is
now available via anonymous ftp from

URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/mpeg2codec_v1.1a.tar.gz
    [192.100.81.1]

If you have mpeg2codec_v1.1.tar.gz and the program 'patch', it is sufficient to download
mpeg2codec_v1.1_v1.1a.diff to upgrade vom v1.1 to v1.1a.

The most import difference between v1.1 and v1.1a is the fix of a bug which
caused decoding of MPEG-1 sequences to fail if the compiler assumes 'char' to
be unsigned. Thanks to all who had offered assistance in finding this bug.

A Windows 32s port of mpeg2decode (and mpeg2play), courtesy of CompCore, is
available as mpeg2w11.zip. A DOS version of mpeg2encode and mpeg2decode is
available as mpeg2d11.zip.

Best regards,

Stefan Eckart, MPEG Software Simulation Group.

---------------------------------------------------------------------------

~Subject: layr_100

Look above in the DOS-section for a description.

---------------------------------------------------------------------------

~Subject: mpegaudio

[ You can find this under the name MPEGAUDI or ftp it from the IUMA-   ]
[ server

URL=ftp://sunsite.unc.edu/pub/electronic-publications/IUMA

[ For a further description of IUMA look into the WHERE-INFOS section. ]

Last updated 1/5/94

The good news is that source is now available. Look in /IUMA/mpeg_players
for the file mpegaudio.tar.Z 

We will continue to gather source and executables and hope that some
enterprising shareware authors or academics will provide various platforms
with real-time players. According to Jared V Boone below, the Xing
real-time player for Windows plays only the lower half of each subband of
only one of the two channels. By my ears, that's pretty good.

Another worthy undertaking would be porting the source to the DSPs
increasingly being found on motherboards and add-in cards, such as the Mac
AV series' AT&T 3210 or the Turtle Beach MultiSound's Motorola 56001, for
real-time full-quality encoding and playback.

That would be cool. =)

-IUMA staff

Here's the latest word on other non-commercial MPEG audio players for Unix
workstations.

I found this in a zip file, the test suite missing, as well as the Makefile.

I hacked together a quick makefile, and altered the musicout code so that if
the destination filename is "stdout" it writes the song to stdout so you can
pipeline it into sox then into /dev/audio or your equivilant.  (Handling
30 meg files takes mucho diskspace I dont have :)

Basically, all you need to do is run it in a pipeline:

decode snd.mp2 stdout | sox [your favorite opts] > /dev/audio (or equiv)

>Some of those favorite opts:
>sox -t .raw -r 44100 -s -w -c 2 file.mp2.dec -t .au -r 8000 file1.au 
>sox -t .au -c 2 -w -s file1.au -t .au -c 1 -b -u file2.au avg

I have both encoded and decoded with this.  I decoded a song off the IUMA 
archives, and encoded a topgun soundtrack I digitzed myself.  One thing to 
note, at the default encoding bitrate of 384 bits, things dont compress hardly
at all, you'll want to input something like 128 bits, which does on average
8-10:x1 compression.

Encoding takes a *LONG* time... :)

-Crh
    Charles Henrich Michigan State University henrich@crh.cl.msu.edu
                     http://rs560.msu.edu/~henrich/

---------------------------------------------------------------------------

~Subject: maplay

From: "Tobias 'Doping' Bading" <bading@cs.tu-berlin.de>

This announcement has been posted to the following newsgroups:
  alt.comp.compression, comp.compression, alt.binaries.multimedia,
  comp.multimedia, alt.binaries.sounds.misc, de.alt.binaries.sounds
last edit: 6/23/94 14:36:07

Hi MPEG audio fans,

I'd like to announce the second release of my free, software-only MPEG
audio player maplay. Those of you who are already familiar with maplay 1.1
may take a look at the list of changes in version 1.2:
  - required CPU time reduced by 50%
  - support of 16 bit soundcarts under Linux
    Implemented by Louis P. Kruger (lpkruger@phoenix.princeton.edu)
  - 8 kHz u-law realtime playback on amd devices (SPARC 2/IPX/...)
    or conversion to 8 kHz u-law to stdout
    Based on an implementation by Jim Boucher (jboucher@flash.bu.edu)
  - some bug-fixes (-u options, Solaris 2.3 problem, problems with older
    GNU C++ releases, makedepend usage removed)

All in all version 1.2 is now capable of
  - playing MPEG audio layer I or II streams on SPARC 10 (SunOS 4.1.3 or
    Solaris 2.x), Silicon Graphics Indigo (IRIX 4.0.x or IRIX 5.x) and Linux
    machines in nearly CD-quality. On a SPARC 10/40, maplay needs about
    46% CPU time for realtime stereo playback and 26% for mono playback.
    (maplay can't be compiled under IRIX 5.x because of the missing audio
     library, but an IRIX 4.0.5F binary works under IRIX 5.x, too)
  - playing these streams in 8 kHz u-law format on SPARC 2/IPX/...
    (SunOS 4.1.x) machines using the amd device. On a SPARCstation IPX,
    maplay needs about 43% CPU time for realtime mono playback.
  - decoding streams to raw 16 bit pcm format at the frequency of the stream
    (32, 44.1 or 48 kHz) or to 8 bit u-law format downsampled to 8 kHz.

The C++ sourcecode of maplay 1.2 and a short layer II MPEG audio stream
for testing purposes has been posted to alt.binaries.multimedia on 6/23/94.

The sources and some binaries are available via the ftp server

URL=ftp://ftp.cs.tu-berlin.de/incoming/maplay1.2/

It contains:
-rw-r--r--   1 bading   doping      4290 Jun 23 14:20 ANNOUNCEMENT
-rw-r--r--   1 bading   doping     95691 Jun 23 14:19 maplay1_2.tar.Z
-rwxr-xr-x   1 bading   doping     96497 Jun 22 12:30 maplay_indigo.Z*
-rwxr-xr-x   1 bading   doping     81469 Jun 22 12:12 maplay_sol2.Z*
-rwxr-xr-x   1 bading   doping     88881 Jun 22 12:17 maplay_sunos4_1_3.Z*
-rwxr-xr-x   1 bading   doping     93125 Jun 22 12:35 maplay_ulaw_sunos4_1_3.Z*
-rw-r--r--   1 bading   doping    372821 Jun 23 12:16 things.mp2

Due to slow Internet connections to this site, please use the mail server
mail-server@cs.tu-berlin.de. Send an email to this address with the contents
SEND incoming/maplay1.2/maplay1_2.tar.Z
and you will receive a mail with an uuencoded copy of the requested file.
Sending a mail containing "SEND help" returns a mail with more infos about
this mail server.

The available precompiled binaries are (in compressed format)
  - maplay_sunos4_1_3.Z
    for SPARCstations with a dbri device (e.g. SPARC 10, CD-quality)
    under SunOS 4.1.x (created under SunOS 4.1.3)
  - maplay_ulaw_sunos4_1_3.Z
    for SPARCstations with an amd device (e.g. SPARC 2 or IPX, telephone
    quality) under SunOS 4.1.x using 8 kHz u-law output
    (created under SunOS 4.1.3)
  - maplay_sol2.Z
    for SPARCstations with a dbri device (e.g. SPARC 10, CD-quality)
    under Solaris 2.x (created under Solaris 2.3 [= SunOS 5.3])
  - maplay_indigo.Z
    for Silicon Graphic Indigo machines (CD-quality)
    under IRIX 4.0.x or IRIX 5.x (created under IRIX 4.0.5F)

To extract the source code, you may use "zcat maplay1_2.tar.Z | tar xvf -"
or "uncompress maplay1_2.tar.Z ; tar xvf maplay1_2.tar". Please take a look
at the README file next.
For a binary, you may use "uncompress maplay_sunos4_1_3.Z".

You may also take a look at the Internet Underground Music Archive (IUMA)
ftp server sunsite.unc.edu (152.2.22.81) in the directory
/pub/electronic-publications/IUMA/audio_utils/mpeg_players/Workstations

If you are also looking for an encoder, please take a look at the file
/pub/electronic-publications/IUMA/audio_utils/converters/source/mpegaudio.tar.Z
on the IUMA ftp server. It contains sources for an encoder and a decoder.

That's all for now,
                    Tobias Bading   (bading@cs.tu-berlin.de)

---------------------------------------------------------------------------

~Subject: Scanning MPEG's ...

STC Version 1.0

A simple program that prints and plots 
the bits-per-picture of a MPEG-1 or MPEG-2 bitstream file.  The program is
called "stc" (since it only checks for picture_start_code's and thus runs
very quickly).  stc can be conveniently run in conjunction with an MPEG 
encoder, since stc can wait on the bitstream file and plot new points as
they become available (or produce a new graph if the bitstream file becomes
shorter, presumably because the MPEG encoder was restarted).

stc is only about 500 lines of C code, but it uses gnuplot for plotting.
stc was developed for an x-windows display and postscript printer, but it
can be very easily modified to use any of the many other displays and printers
that gnuplot supports.

Simply compile stc.c with your favorite ANSI-C compiler, and that's all there 
is to it.  For graphing functions, you must have gnuplot in your $PATH.

 * Copyright (c) 1993 by The Trustees of Columbia University in 
 * the City of New York.
 * All rights reserved.

---------------------------------------------------------------------------

~Subject: MPEG decoder...

Date: Sun, 2 Jan 1994 22:57:48 -0800
From: Jared V Boone <jboone@patriot.wtfd.orst.edu>

I have an MPEG decoder that I can make available.  It is in C and I have
succeeded in compiling it under Windows NT Visual C++ and NetBSD 0.9 with GNU
 V2.4.  The code is rather rough, only decodes Layer II, and is rather
slow.  However, I figure if I release the code to the public, some rocket
scientist can make it ran fast...  My only conditions are that I am acknowleged
and notified when someone uses the code in a freeware/shareware/commercial
product.  Let me know if you're interested.

	- Jared Boone, Oregon State University
	  (jboone@instruction.cs.orst.edu)

P.S.  I'm also working on an encoder.  It appears that Xing's encoder is not
all that great (sound quality), and also does not conform to the MPEG-I spec.
If you'd like, I can keep you posted on this as well...

---------------------------------------------------------------------------

~Subject: MPEGTool

MPEGTool is an application which combines  MPEGTool  encoder  and
MPEGTool statistics with X11/Motif based Graphical User Interface
(GUI). MPEGTool encoder is an MPEG-1 encoder for RGB and CCIR-601
format  input video sequences. MPEGTool statistics is a graphical
statistics tool which can be used to analyze the statistical pro-
perties of the encoding process. MPEGTool allows a user to speci-
fy several of the MPEG parameters such as the intraframe  to  in-
terframe ratio, and the quantizer scale through its GUI.

MPEGTool has been tested on Sun SparcStation and HP9000  current-
ly.   To  compile  under  these  machines,  see  instructions  in
Makefile.

GUI of MPEGTool is based on Motif toolkit from the Open  Software
Foundation  (OSF),  so  Motif (Xm) libraries as well as X Toolkit
(Xt)  libraries  and  Xlib  are  required  to  compile  MPEGTool.
Although  MPEGTool can be executed under several window managers,
Motif window manager (mwm) is recommended. We've tested mwm, Open
look  window  manager  (olwm), Tab window manager (twm). With the
twm, we recommend to  put  'DecorateTransients'  in  your  .twmrc
file.

MPEGTool supports disk and tape device for video data  input  and
MPEG  code  output. Also, MPEGTool creates statistics data on the
disk. Statistics data requires around 1/350  to  1/250  of  video
data  size  and  MPEG  code requires 1/10 to 1/5 depending on the
parameter.

MPEGTool encoder encodes RGB/CCIR-601  format  video  input  data
from  tape  or  disk device by MPEG-1 specification and write the
encoded data into tape or disk. In addition, the statistics  data
can be stored into disk device for MPEGTool statistics analysis.

We can set several encoding parameters from MPEGTool Encoder win-
dow.  For setting device related parameters, click Configure but-
ton and modifying parameters in  MPEGTool  Encoder  Configuration
window. To start Encoding, click Start and MPEGTool begins encode
if there is no parameter error or device related error.

MPEGTool statistics creates types of graphs to analyze  statisti-
cal properties of MPEG encoded video stream. Four types of graphs
can be selected, Distribution, Generation Record, Autocorrelation
and  Interarrival Time. First three of these plot each statistics
of   MPEG   code   in   five   levels,   Bit/Frame,    Bit/Slice,
Bit/MacroBlock,  ATM/Frame and ATM/Slice. Interarrival Time plots
the time elapsed between arrivals of ATM packets within a  frame.
The interarrival times are calculated from the bits generated per
macroblock within a frame.  This interarrival time is  normalized
to units of X seconds (where X will depend on the hardware imple-
mentation of the coder).

"MPEGTool: An X windows  based  MPEG   encoder   and   statistics
tool", Proceedings of ACM Multimedia '93, Anaheim, CA

This paper contains  more  details  and  several  examples  about
MPEGTool.   PostScript  file of this paper is placed on anonymous
ftp on atum.ee.upenn.edu.

---------------------------------------------------------------------------

~Subject: What is "SECMPEG" ?

  SECMPEG is first a newly defined stream, that ensures the service
  of confidentiality and integrity for a MPEG-I-video-stream. 'Cause
  of the amount of multimedia-data it is NOT possible to use the same
  crypto- or checking-techniques for multimedia-data then for normal
  files or streams.

<IMG SRC="secmpegf.gif">

  Therefore we defined a new stream, containing additional security
  information. We tested and filtered the MPEG-I-stream to ensure that
  only important and relevant data is encrypted or checked. The newly
  desinged methods are not proofed but quite good tested. We can't be
  sure so far, if these method really do what they are designed for.

<IMG SRC="secmpegm.gif">

  It is second a tool, that can insert and delete the confidentiality
  and integrity data into/from a MPEG-I-stream.

  If you get any results to proof our methods, we hope to here from you !

  More information is available from te authors, like some PostScript-
  files, pictures and graphs.


  Where is it ?

  It will stored on our ftp-server in the next days (probably there):

        URL= ftp://ftp.cs.tu-berlin.de/pub/msdos/dos/graphics/secmpeg.zip
             (the DOS-Version)

  or probably in the unix-directory somewhere.


  How does it compile ?

  The program already compiles under

  - SunOS 4.1.x            using cc or gcc
  - SunOS 5.0              using cc or gcc
  - Solaris 2.1            using cc or gcc
  - INTERACTIVE Unix 2.2.1 using cc or gcc
  - Linux                  using gcc
  - MS-DOS                 using gcc or Borland C 2.0 (tcc),
                           the dos-port shoulb be included as
                           executable in the archive

  You need a compiler, that understands ANSI-C so far, but the rest is
  straight forward C, so it should compile nearly everywhere.


  What can you do ?

  Permission to use, copy, modify, and distribute this software and
  its documentation for any purpose and without fee is hereby granted,
  provided that the archive remains complete, that this author notice
  will appear in all copies and as long as you don't try to make money
  off it, or pretend that you wrote it.


  Authors

  Juergen Meyer                Frank Gadegast
  Sonnenallee 50               Leibnizstr. 30
  12045 Berlin GERMANY         10625 Berlin GERMANY

  Access: jm@cs.tu-berlin.de
  Access: phade@cs.tu-berlin.de 

---------------------------------------------------------------------------

~Subject: PVRG-MPEG Codec

From: msimmons@ecel.uwa.edu.au (Michael Simmons - mgmt_staff)
Subject: Standford MPEG codec
Date: Thu, 25 Feb 1993 16:07:18 +0800 (WST)

MPEG  Image and Image sequence compression/decompression C software engines

The Portable Video Research Group at Stanford have developed
image/image sequence compression and decompression engines (codecs)
for MPEG, CCITT H.261, and JPEG. The primary goal of these codecs is
to provide the functionality - these codecs are not optimized for
speed, rather completeness, and some of the code is kludgey.

Development of MPEG, P64, and JPEG engines is not the primary goal of
the Portable Video Research Group.  Our research is focused on
software and hardware for portable wireless digital video
communication.  For more information about current research, please
send e-mail to Professor Teresa Meng at meng@tilden.stanford.edu.

COMMENTS/DISCLAIMERS:

This code has been compiled on the Sun Sparc and DECstation UNIX
machines; some code has been further checked on the HP workstations.

For comments, bugs, and other mail relating to the source code, we
appreciate any comments. The code author can be reached at Andy C.
Hung at achung@cs.stanford.edu.  The standard public domain disclaimer
applies: Caveat Emptor - no guarantee on accuracy or software support.

References related to these codecs should NOT use any author's name,
or refer to Stanford University.  Rather the Portable Video Research
Group or the acronym (PVRG) should be used, such as PVRG-MPEG,
PVRG-P64, PVRG-JPEG.

               PVRG-MPEG CODEC: (MPEGv1.1.tar.Z) [ is now MPEGv1.2.tar.gz ]

This public domain video encoder and decoder was generated according
to the Santa Clara August 1991 format.  It has been tested
successfully with decoders using the Paris December 1991 format. The
codec is capable of encoding all MPEG types of frames. The algorithms
for rate control, buffer-constrained encoding, and quantization
decisions are similar, but not identical, to that of the (simulation
model 1-3) MPEG document.  The rate control used is a simple
proportional Q-stepsize/Buffer loop that works though not very well -
better rate-control is the essence for good quality buffer-constrained
MPEG encoding.  Verification of the buffering is possible so as to
provide streams for real-time decoders.

The MPEG codec performs compression and decompression on raw raster
scanned YUV files. The companion display program for the X window
system is described in section IV) below.  A manual of approximately
50 pages describes the program's use.

There are also MPEG compressed files from the table tennis sequence in
tennis.mpg and the flower garden sequence in flowg.mpg.

This codec was recently tested with the MPEG decoder of the Berkeley
Plateau Research group. If what you want is decoding and X display,
then you might want to look into their faster public domain MPEG
decoder/viewer. The Berkeley player is available via anonymous ftp
from

URL=ftp://mm-ftp.cs.berkeley.edu//pub/multimedia/mpeg/mpeg-2.0.tar.Z
    [128.32.149.157]


ACKNOWLEDGEMENTS:

Funded by the Defense Advanced Research Projects Agency.

I am especially grateful to Hewlett Packard and Storm Technology for
their financial support during the earlier stages of codec
development.  Any errors in the code and documentation are my own.
The following people are acknowledged for their advice and assistance.
Thanks, one and all.

        The Portable Video Research Group at Stanford: Teresa Meng,
        Peter Black, Ben Gordon, Sheila Hemami, Wee-Chiew Tan, Eli Tsern.

        Adriaan Ligtenberg of Storm Technology.
        Jeanne Wiseman, Andrew Fitzhugh, Gregory Yovanof and
        Chuck Rosenberg of Hewlett Packard.
        Eric Hamilton and Jean-Georges Fritsch of C-Cube Microsystems.

        Lawrence Rowe of the Berkeley Plateau Research Group.
        Tom Lane of the Independent JPEG Group.
        Katsumi Tahara from Sony.
        Ciaran Mc Goldrick.
        Karl Lillevold

---------------------------------------------------------------------------

~Subject: wdgt

[ Jim Frost was putting the Berkeley-Code into a Motif and/or Xt-Widget. ]
[ Its called WDGT, Version 2.0b is up-todate, but no description         ]
[ was included. This is from the man-page:]

Mpeg  is  a  version  of the MPEG player from the Berkeley
Plateau Research Group group as a widget.  It can be  used
either as a Motif widget subclassed from XmPrimitive or as
a toolkit-independant widget subclassed from Core.

Mpeg inherits from Core. The Motif version  also  inherits from XmPrimitive.
The class pointer is xmpegWidgetClass. The class name is Xmpeg.
END ---------------------- CUT HERE --------------------- 6/8
