File: MPEG-FAQ

package info (click to toggle)
ucbmpeg 1r2-6
links: PTS
area: non-free
in suites: hamm, potato, slink
size: 9,504 kB
ctags: 7,643
sloc: ansic: 79,920; tcl: 2,985; perl: 313; asm: 284; makefile: 269; csh: 13
file content (6081 lines) | stat: -rw-r--r-- 255,181 bytes

Archive-name: mpeg-faq/part0
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly



        ====================================================
        THE MPEG-FAQ            [Version 3.2 - 22. Aug 1994]
        ====================================================
        PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY
        Inh. Frank Gadegast          Fon/Fax: +49 30 3128103

        phade@cs.tu-berlin.de


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

This is my summary about MPEG.

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

This fifth addition is not really different to the previous one.

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

You should receive seven files called:

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


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

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


 INDEX-files
=============

The INDEX-files are excluded in this release of the MPEG-FAQ.
You can ftp it from the same place you got this file from.
My home-site is:

        host: ftp.cs.tu-berlin.de (130.149.17.7) or
              quepasa.cs.tu-berlin.de
        file: /pub/msdos/dos/graphics/mpegfa11.zip
        file: /pub/msdos/dos/graphics/mpegfa20.zip
        file: /pub/msdos/dos/graphics/mpegfa30.zip
        file: /pub/msdos/dos/graphics/mpegfa31.zip

and the current FAQ lies right now under (but will be moved to
/pub/msdos/dos/graphics soon):

		file: /pub/msdos/dos/graphics or
		file: /pub/msdos/incoming

It should be usally called MPGIDX31.ZIP ! It includes the
INDEX-file (first picture of all known MPEG-movies), the AINDEX-file
(about 2 seconds of know MPEG-AUDIO-streams in one MPEG-stream) and
text-indexes for movies and audio-files.

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



 SYSADM
========

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


 NEWS
======

The FAQ itself will be posted as txt-file and the index-mpg-file will be
posted to alt.binaries.multimedia


 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.contrib.de/~phade




Archive-name: mpeg-faq/part1
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly


BEGIN -------------------- CUT HERE --------------------- 1/6

        ====================================================
        THE MPEG-FAQ            [Version 3.2 - 22. Aug 1994]
        ====================================================
        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 fourth publication of this file. Lots of information has been
added (which has surely brought errors with it, see Murphy's Law).

This fourth addition is different to the previous ones.

First:  Some old sections have been removed, because they are old or there was
        nothing changing. So for a starter you can read the last MPEG-FAQ's
        (Version 1.1, 2.0, or 3.0) Get them via ftp from

        host: ftp.cs.tu-berlin.de (130.149.17.7) or
              quepasa.cs.tu-berlin.de
        file: /pub/msdos/dos/graphics/mpegfa11.zip
        file: /pub/msdos/dos/graphics/mpegfa20.zip
        file: /pub/msdos/dos/graphics/mpegfa30.zip

        This new FAQ will be there soon too, as 'mpegfa31.zip'.
        My MPEG-related software and my DOS-ports of several
        programs can be found there too.

Second: The people where more interested to get the complete archives.
        Therefore the TRAIL-PACK-Service is still running. I'm still
        collecting EVERY info, video, sound or program.
        Get the Trail-Pack !

Third:  MPEG-audio is coming ! There is source-code ! There is a brand-new
        written audio-section in this FAQ written by Harald Popp and
        Morton Hjerde, thnx to both. And even MPEG-2 things are coming !

Fourth: MPEG-interleaving (audio and video together you know !) is about
        to be the next step. The pretty first things are there, incl.
        interleaved streams.

Fifth:  The INDEX-files are excluded in this release of the MPEG-FAQ.
        You can ftp it from the same place you got this file from.
        It should be usally called MPGIDX31.ZIP ! It includes the
        INDEX-file (first picture of all known MPEG-movies) and the
        AINDEX-file (about 2 seconds of know MPEG-AUDIO-streams in
        one MPEG-stream) and text-indexes for movies and audio-files.

Sixth:  The MPEG Trailpack CD-Rom is there ! Get it ! More than
        430 MB of movies, songs, documentation and utilities !
        Read below, about how to Order !


Seventh:The newest FAQ can always be loaded using Mosaic from:
            http://www.cs.tu-berlin.de/~phade
        And surely, there are more interesting things to find ;o)

Eigths: AND I HEARBY PROCLAIM, that: MPEG is getting SO important, that
        in about 5 years, you go to your HiFi-Dealer and you ask him
        if the TV or Stereo is capable of MPEG to make your descision,
        not if it works with CD's or HDTV !!!

You should read carefully through this FAQ this time, cause lots of new
information is hidden in all the sections. F.e. news about Dos, Amiga-,
Atari-, OS/2-, Windows-, Windows-NT, VMS-, NeXT, Unix- and Mac-Players
and coders !!! Read about the future of MPEG ...
        

This summary is devided in 12 parts:

 I    |  WHAT IS MPEG-VIDEO/AUDIO ?
 II   |  PROFESSIONAL SOFTWARE
 III  |  PUBLIC-DOMAIN SOFTWARE OR SHAREWARE
 IV   |  MPEG-RELATED HARDWARE
 V    |  MAILBOX-ACCESS
 VI   |  FTP-ACCESS (PD)
 VII  |  MAIL-ORDER
 VIII |  RETRIEVED MAIL OR ARTICLES
 IX   |  ADDITIONAL INFORMATION
 X    |  WHERE TO FIND MORE INFOS
 XI   |  NEWS
 XII  |  QUESTIONS

I add my comments in brackets [], lines (---- or ====) seperate the
chapters.
 
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.

    Phade (Frank Gadegast)


DISCLAIMER: I HAVE NOTHING TO DO WITH THE NAMED COMPANIES, NO BUSINESS,
            IT'S JUST MY PERSONAL INTERESTED. THESE 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.


===========================================================================
 I.1 | WHAT IS MPEG-VIDEO/VIDEO
===============================

-------------------------------------------------------------------------------
 I.1 | MPEG-Video
-----------------

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.                  ]

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

Subject: [71] Introduction to MPEG (long)


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.

   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

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

From: billd@cray.com (Bill Davidson)
Subject: MPEG standards documents.
Date: 21 Apr 94 02:16:32 MET

I just connected to the Document Center WAIS server at wais.service.com
to find out what MPEG documents cost.  This is what I found:

Title							Pages	Price(US$)
-------------------------------------------------------	-----	----------
ISO/IEC-11172-1 - PART 1: SYSTEMS, INFORMATION		60	158.75
	TECHNOLOGY - CODING OF MOVING PICTURES &
	ASSOCIATED AUDIO FOR

ISO/IEC-11172-2 - PART 2: VIDEO, INFORMATION TECHNOLOGY	122	204.00
	- CODING MOVING PICTURES & ASSOCIATED AUDIO FOR
	DIGI

ISO/IEC-11172-3 - PART 3: AUDIO, INFORMATION TECHNOLOGY	157	214.25
	- CODING OF MOVING PICTURES & ASSOCIATED AUDIO
	FOR D

ISO/IEC-CD-11172 - INFORMATION TECHNOLOGY - CODING OF	0	207.00
	OF MOVING PICTURES & ASSOCIATED AUDIO - FOR
	DIGITAL STORAGE

Is this a mistake or are standards documents really rediculously
priced?  Since these would be for my own personal use, I have to pay
for them out of my own personal pocket.  Just one of these eats my book
budget for quite a while.

I realize that they have to make money but this has got to be about a
1000% markup over printing costs; even assuming low volumes.

Bill Davidson


-------------------------------------------------------------------------------
 I.2 | MPEG-Audio
-----------------

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

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

-------------------------------------------------------------------------------
 I.3 | MPEG-2
-------------

From: Chad Fogg <cfogg@ole.cdac.com>
Date: Tue, 12 Oct 1993 06:23:40 -0700
Subject: installment 2 (posted version)

OK: slapped together for your entertainment, it's the second draft 
installment of the long promised MPEG-2 FAQ.   This draft is about 
50% complete.  Typos or spelling errors have not been checked yet.  
Many details need to be flushed out.

If you have any additional questions or information you would like
added, please E-mail to:  cfogg@cdac.com

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

[ A short insert ... maybe important for some ... ]

From: Tom Pfeifer <pfeifer@fokus.gmd.de>
Date: Fri, 29 Apr 1994 16:26:01 +0200
Subject: mpeg2

Heres the number of the MPEG-2 commission draft:

Workgroup ISO/IEC JTC 1 SC29N 660

Standard ISO-CD 13818 - {1,2,3} (like usual {system, video, audio})

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

[ And thats from Chad Fogg again ... ]

Table of questions:
[near 64KB limit... to big to include in installment 2]


Herein is not the official opionions of the MPEG "committee" members.
(MPEG opinions are self-cancelling---linear superposition theory).

Q. What are the important themes of MPEG video?
A. [Other than those introduced by Mark Adler...]
   
    1. Application specific. MPEG does not solve everybody's application
    needs, but offers a syntax that is a good solution for most. MPEG 
    does not, for example, decorrelate energies situated 1/256th 
    of a pixel between a non-linear combination of 1000 frames.
    The syntax was designed to occupy an optimum between cost and quality
    ... in other words, between computational complexity (VLSI area, memory 
    size and bandwidth) and compaction (compression) efficiency. 
   
    2. The DCT and Huffman algorithms are some of the least significant 
    aspects of the standard, and yet somehow receive the most press 
    coverage. MPEG-2 made its greatest improvements through enhancement 
    of prediction.

    3. In the encoding algorithm, you can do what you want as long as the 
    bistreams produced are compliant.  There is a huge difference in 
    picture quality between, for example, the test model and real-world 
    propriety implementions of encoding. 
    
Q. 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 actually a kind of subset known as Constrained 
   Parameters Bitstream (CPB).

Q. What are Constrained Parameters Bitstreams?

A. CPB are a limited set of sampling and bitrate parameters designed
   to normalize computational complexity, buffer size, and memory bandwidth
   while still addressing the widest possible range of applications.
   CPB limits video to 396 macroblocks (101,376 pixels) per frame if the
   frame rate is less than or equal to 25 fps (frames per second), and 330 
   macroblocks (84,480 pixels) per frame if the frame rate is less or 
   equal to 30 fps.  Therefore, MPEG video is typically coded at SIF
   dimensions (352 x 240 x 30fps  or 352 x 288 x 25 fps).

   The total maximum sampling rate is 3.8 Ms/s (million samples/sec) 
   including chroma.  The coded video rate is limited to 1.862 Mbit/sec. 
   In industrial practice, the bitrate is the most often waived parameter 
   of CPB, with rates as high as 6 Mbit/sec in use.

Q. 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 encoders.  MPEG
   devices which are not capable of meeting SIF rates are not canonically
   considered to be true MPEG.

Q. Are there ways of getting around constrained parameters bitstreams
   for SIF class applications and decoders ?
A. Yes, some.  Remember that CPB limits frames to 396 macroblocks
   (as in 352 x 288 SIF frames). 416 x 240 x 24 Hz sampling rates are 
   still within the constraints, but this only aids NTSC (240 lines/field)
   displays.  Deviating from 352 samples/line could throw off many decoder 
   implementations that have limited horizontal sample rate conversion
   modes. Due to chip die size constraints (most chips barely pack in the
   neccessary features), many decoders use simple doubling, e.g. 352 to 704 
   samples/line via binary taps which are simple shift-and-add operations. 
   Future MPEG decoders will have arbitrary sample rate convertors on-chip.
   Also remember that the 1.86 Mbit/sec limit is often ignored in real life.


Q. What is MPEG-2 Video Main Profile and Main Level?

A. MPEG-2 Video Main Level is analogous to MPEG-1's CPB, with sampling limits 
   at CCIR 601 parameters (720 x 480 x 30 Hz).  Profiles limit syntax 
   (i.e. algorithms), whereas Levels limit 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 application users.  
     

  Level      Max. sampling     Pixels/  Max.     Significance
             dimensions   fps  sec      bitrate           
  ---------  ----------------  -------  -------  --------------------------
  Low         352 x  240 x 30   3.05 M   4 Mb/s  CIF, consumer tape equiv.
  Main        720 x  480 x 30  10.40 M  15 Mb/s  CCIR 601, studio TV
  High 1440  1440 x 1152 x 30  47.00 M  60 Mb/s  4x 601, consumer HDTV
  High       1920 x 1080 x 30  62.70 M  80 Mb/s  production SMPTE 240M std

Note 1: pixel rate and luminance (Y) sample rate are equivalent.
     2: Low Level is similar MPEG-1's Constrained Parameters Bitstreams.
           
  Profile  Comments
  -------  -----------------------------------------------------------
  Simple   Same as Main, only without B-pictures.  Intended for software 
           applications, perhaps CATV.
  Main     Most decoder chips, CATV, satellite. 95% of users.
  Main+    Main with Spatial and SNR scalability       
  Next     Main+ with 4:2:2 marcoblocks
                                

                                Profile

  Level         Simple          Main            Main+           Next
  ------------  --------------  --------------  --------------  ------------
  High          illegal                         illegal         4:2:2 chroma
  High-1440     illegal                         With spatial    4:2:2 chroma
                                                Scalablity
  Main                          90% of users    Main with SNR   4:2:2 chroma
                                                scalability
  Low           illegal                         Main with SNR   illegal
                                                scalabiliy                                                                        
   [Subject to change at whim of MPEG Requirements sub-group]

Q. How do you tell a MPEG-1 bitstream from a MPEG-2 bistream?
A. All MPEG-2 bistreams must have certain extension headers that
   *immediately* follow MPEG-1 headers.  At the highest layer,
END ---------------------- CUT HERE --------------------- 1/6



Archive-name: mpeg-faq/part2
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly


BEGIN -------------------- CUT HERE --------------------- 2/6
   for example, the MPEG-1 style sequence_header() is followed by
   sequence_extension() which is exclusive to MPEG-2. Some extension 
   headers are specific to MPEG-2 profiles. For example, 
   sequence_scalable_extension() is not allowed in Main Profile.

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

Q. What is the precision of MPEG samples?
A. 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, levels 
   0 through 14 and 236 through 255 are reserved for blanking signal 
   excursions. MPEG currently has no such clipped excursion restrictions.

Q. Is it MPEG-2 (arabic numbers) or MPEG-II (roman)?

A. Committee insiders most often use the arabic notation with the
   hyphen, e.g. MPEG-2.  Only the most retentive use the official 
   designation: Phase 2.   In fact, M.P.E.G. itself is a nickname.  The
   official name is: ISO/IEC JTC1 SC29 WG11.  The militaristic lingo has 
   so far managed to keep the enemy (DVI) confused and out of the picture.

   ISO:  International Organization for Standardization
   IEC:  Interntional Electrotechnical Commission
   JTC1: Joint Technical Committee 1
   SC29: Sub-committee 29
   WG11: Work Group 11  (moving pictures with... uh, audio)

Q. Why MPEG-2?  Wasn't MPEG-1 enough?

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 
   co-operation had executed so well 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.

Q. How do MPEG and JPEG differ?

A. The most fundamental difference is MPEG's use of block-based motion 
   compensated prediction (MCP)---a general method falling into the 
   temporal DPCM category.  
    
   The second most fundamental difference is in the target application. 
   JPEG adopts a general purpose philosophy: independence from color space 
   (up to 255 components per frame) and quantization tables for each 
   component.  Extended modes in JPEG include two sample precisions (8 and 
   12 bit sample accuracy), combinations of frequency progessive, spatially 
   progressive, and amplitude progressive scanning modes. Color independence 
   is made possible thanks to downloadable Huffman tables.

   Since MPEG is targeted for a set of specific applications, there is 
   only one color space (4:2:0 YCbCr), one sample precision (8 bits), and
   one scanning mode (sequential). Luminance and chrominance share 
   quantization tables. The range of sampling dimensions are more limited
   as well.  MPEG adds adaptive quantization at the macroblock (16 x 16 pixel 
   area) layer.  This permits both smoother bit rate control 
   and more perceptually uniform quantization throughout the picture and 
   image sequence.   Adaptive quantization is part of the JPEG-2 charter.
   MPEG variable length coding tables are non-downloadable, and are 
   therefore optimized for a limited range of compression ratios 
   appropriate for the target applications.

   The local spatial decorrelation methods in MPEG and JPEG are very similar. 
   Picture data is block transform coded with the two-dimensional orthanormal 
   8x8 DCT. The resulting 63 AC transform coefficients are mapped in a 
   zig-zag pattern to statistically increase the runs of zeros. Coefficients 
   of the vector are then uniformily scalar quantized, run-length coded, and 
   finally the run-length symbols are variable length coded using a 
   cannonical (JPEG) or modified Huffman (MPEG) scheme.  Global frame 
   redundancy is reduced by 1-D DPCM of the block DC coefficients, followed
   by quantization and variable length entropy coding.

            MCP                   DCT                    ZZ               Q
       Frame -> 8x8 spatial block -> 8x8 frequency block -> Zig-zag scan -> 
                    
                    RLC                  VLC
       quanitzation -> run-length coding -> variable length coding.

   The similarities have made it possible for the development of hard-wired 
   silicon that can code both standards.  Even microcoded architectures can 
   better optimize through hardwired instruction primitives or functional 
   blocks. There are many additional minor differences. They include:
   
     1. DCT and quantization precision in MPEG is 9-bits since the macroblock 
        difference operation expands the 8-bit signal precision by one bit.

     2. Quantization in MPEG-1 forces quantized coefficients to become
        odd values (oddification).

     3. JPEG run-length coding produces run-size tokens (run of zeros,
        non-zero coefficient magnitude) whereas MPEG produces fully
        concatenated run-level tokens that do not require magnitude 
        differential bits.

     4. DC values in MPEG-1 are limited to 8-bit precision (a constant
        stepsize of 8), whereas JPEG DC precision can occupy all possible
        11-bits.  MPEG-2, however, re-introduced extra DC precison.
 

Q. What happened to MPEG-3?

A. 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 (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).   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, and with the exception of motion artificats (due to 
   limited search range in the encoder), was deemed to have the best picture
   quality of all three digital proponents.
   
   HDTV is now part of the MPEG-2 High-1440 Level and High Level toolkit.
   
Q. What is MPEG-4?
A. MPEG-4 targets the Very Low Bitrate applications defined loosly
   as having sampling dimensions up to 176 x 144 x 10 Hz and coded 
   bit rates between 4800 and 64,000 bits/sec.   This new standard would 
   be used, for example, in low bit rate videophones over analog 
   telephone lines.  
  
   This effort is in the very early stages.  Morphology, fractals, model
   based, and anal retentive block transform coding are all in the offering. 
   MPEG-4 is now in the application identification phase.

Q. Where can I get a copy of the latest MPEG-2 draft?
A. Contact your national standards body (e.g. ANSI Sales in NYC for the U.S.)

Q. What is the latest working drafts of MPEG-2 ?
A. The latest versions of video (version 4), and systems were produced at 
   the Brusells meeting (September 10, 1993).  The latest audio working 
   draft was produced in New York (July 1993).

   MPEG-2 Video, Audio, and Systems will reach CD at the November 1994
   Seoul, Korea meeting.

Q. What is the latest version of the MPEG-1 documents?
A. Systems (ISO/IEC IS 11172-1), Video (ISO/IEC IS 11172-2), and Audio
   (ISO/IEC IS 11172-3) have reached the final document stage.  Part 4,
   Conformance Testing, is currently a CD.
   
Q. What is the evolution of standard documents?
A. In chronological order:

   New Proposal (NP)
   Working Draft (WD)
   Committee Draft (CD)
   Draft International Standard (DIS)
   International Standard (IS)


Q. When will an MPEG-2 decoder chip be available?
A. Several chips will be sampling in late 1993.  For reasons of economy
   and scale in the cable TV application, all are single-chip (not including 
   DRAM and host CPU/controller) implementations. 
   They are:
 
  SGS-Thomson STi-3500
        first MPEG-2 chip on market
        multi-tap binary horizontal sample rate convertor.
        pan & scanning support for 16:9
        requires external, dedicated microcontroller (8 bit)
        8-bit data bus, no serial data bus.

  LSI Logic L64112 successor (pin compatible)
        serial bus, 15 Mbit coded throughput.
        smaller pin-count version due soon.

  C-Cube CL-950 successor (?)

  In 1994, we can look forward to:
  
  Pioneer single-chip MPEG-2 successor to CD-1100 MPEG-1 chip set.
  IBM single-chip decoder.

Q. Are there single chip MPEG encoders?

A. Yes, the C-Cube CL-4000 is the only single-chip, real-time encoder
   that can process true MPEG-1 SIF rate video.
   
   Single chip for +/- 15 pel motion estimation at SIF rates (352x240x30 Hz)
   Two chips for +/- 32 pel at SIF rates (hierarchical)
   5 or 6 chips for MPEG-2 at CCIR 601 rates (704 x 480 x 30 Hz)
   Highly microcoded architecture.
   Can code both H.261 and JPEG.
   Implements high picture quality microcode programs.
   [more details from CICC'93 and HotChips '93 conference to be included]
   
   IBM and SGS-Thomson plan to introduce more hard-wired, multichip 
   solutions in 1994.
   
Q. What about MPEG-1 decoder chips?

A. By implication of MPEG-2 Conformace requirements, all MPEG-2 decoders are 
   required to decode MPEG-1 bitstreams as well. These chips, however, are 
   strictly MPEG-1:

   
        C-Cube CL-450           SIF rates. Single-chip.  Has on-board CPU.
                                                                                                
        SGS-Thomson 3400        SIF rates. Single-chip.  Hardwired.

        Motorola MCD250         SIF rates. Single-chip.  

        LSI 641172              CCIR 601 rates. Single-chip.  Systems
                                packet decoder on-chip.

Q. What about audio chips?
A. To date, only Layer I and Layer II have been implemented in dedicated
   (ASIC) silicon:
               
  Motorola MCD260
                
  Texas Instruments TI 320AV110 
        hardwired with systems parsing)                      
        operates in free format (arbitrary sample rate)
        120 pin PQFP package
        Serial data port
        Part of technology exchange with C-Cube

  LSI Logic L64111 
        hardwired w/CPU with on-chip systems parsing.
        Serial data port                        
        100-pin PQFP              
        
  GCA/ASCII ?
  
  Crystal Semiconductor CS4920
        on-chip, 2 channel 16-bit digital-to-analog convertor (DAC)
        16 MIPS, 24-bit DSP 
        programmable clock manager
        44-pin PLCC package
        Programmable architecture.  For example, can download Layer II 
          MPEG-1 audio or Dolby AC-2
        $38 each in large quantities


Dolby AC-3
        MPEG NY disclosure
        claimed to be less computationally intensive
        Zoran, GI working on own DSP-like dedicated chips.

Q. Will there be an MPEG video tape format?

A. There is a consortium of companies (Philips, JVC, Sony, Matushista,
   et al) developing a metal particle based 6 milimeter consumer digital 
   video tape format. It will initially use more JPEG-like independent 
   frame compression for cheap encoding of source analog (NTSC, PAL) 
   video.  The consequence of course is less efficient use of bandwidth (
   25 Mbit/sec for the same quality acheived at 6 Mbit/sec with MPEG). 
   Pre-compressed video from broadcast sources will be directly recorded 
   to tape and "passed-through" as a coded bitstream to the video 
   decompression "box" upon playback.

               
             
Q. What do B-frames buy you?
A. Since bi-directional marcoblock predictions are an average of two maroblocks blocks, 
   noise is reduced at low bit rates.  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.


Q. Why do some people hate B-frames?
A. Computational complexity, bandwidth, delay, and picture buffer size are 
   the four B-frame Pet Peeves. Computational complexity is increased since
   a some macroblock modes require averaging between two macroblocks.  
   Worst case, memory bandwidth is increased an extra 16 MByte/s (601 
   rate) for this extra prediction. An extra picture buffer is needed to 
   store the future prediction reference (bi-directionality).  Finally, 
   extra delay is introduced in encoding since the frame used for backwards
   prediction needs to be transmitted to the decoder before the intermediate 
   B-pictures can be decoded and displayed.
   
   Cable television (e.g. General Instruments) have been particularly 
   adverse to B-frames since the extra picture buffer pushes the decoder
   DRAM memory requirements past the magic 8-Mbit (1 Mbyte) threshold into the 
   realm of 16 Mbits (2 MByte) for CCIR 601 frames (704 x 480), yet not for 
   lowly 352 x 480. However, cable does not realize that DRAM does not come 
   in convenient high-volume (low cost) 8-Mbit packages as 16-Mbit does.  In 
   a few years, the cost differences between 16 Mbit and 8 Mbit will become 
   insignificant compared to the gain in compression.  For the time being, 
   cable boxes will start with 8-Mbit and allow future drop-in upgrades to 
   16-Mbit.  The early market success of B-frames seem to have been 
   determined by a fire at a Japanese chemical plant.

Q. How do MPEG and H.261 differ?
A. H.261 was targeted for teleconferencing applications where motion
   is naturally more limited. Motion vectors are restricted to a range of
   +/- 15 pixels.  Accuracy is reduced since H.261 motion vectors are 
   restricted to integer-pel accuracy.  Other syntactic differences 
   include: no B-pictures, different quantization method. 

   H.261 is also known as P*64. "P" is an integer number meant to 
   represent multiples of 64kbit/sec.  In the end, this nomenclature 
   probably won't be used as many services other than video will adopt the 
   philosophy of arbitrary B channel (64kbit) bitrate scalability.

Q. Is H.261 the de facto teleconferencing standard?

A. Not exactly.  To date, about seventy percent of the industrial  
   teleconferencing hardware market is controlled by PictureTel of Mass.  
   The second largest market controller is Compression Labs of Silicon 
   Valley.  PictureTel hardware includes compatibility with H.261 as a 
   lowest common denominator, but when in comminication with other 
   PictureTel hardware, it can switch to a mode superior at low bit rates 
   (less than 300kbits/sec). In fact, over 2/3 of all teleconfercing is done 
   at two-times switched 56 channel (~P = 2) bandwidth.  Long distance ISDN 
   ain't cheap.  In each direction, video and audio are coded at an 
   aggregate of 112 kbits/sec (2*56 kbits/sec).
   
   The PictureTel proprietary compression algorithm is acknowledged to 
   be a combination of spatial pyramid, lattice vector quanitzer, and an 
   unidentified entropy coding method.  Motion compensation is considerably
   more refined and sophisticated than the 16x16 integer-pel block method
   specified in H.261.

   The Compression Labs proprietary algorithm also offers significant 
   improvement over H.261 when linked to other CLI hardware. 

   Currently, ITU-TS (International Telecommunications Union--Teleconferencing
   Sector), formerly CCITT, is quietly defining an improvement to H.261 with 
   the participation of industry vendors.
   
Q. Where will be see MPEG in everyday life?
A. Just about wherever you see video today.
   
   DBS (Direct Broadcast Satellite)
     The Hughes/USSB DBS service will use MPEG-2 video and audio.  Thomson 
     has exclusive rights to manufacture the decoding boxes for the first 
     18 months of operation.  No doubt Thomson's STi-3500 MPEG-2 video 
     decoder chip will be featured.

     Hughes/USSB DBS will begin service in North America in April 1994.
     Two satellites at 101 degrees West will share the power requirements   
     of 120 Watts per 27 MHz transponder. Multi-source channel rate 
     control methods will be employed to optimally allocate bits between 
     several programs on one data carrier. An average of 150 channels are  
     planned.
   

   CATV (Cable Television)
     Despite conflicting options, the the cable industry has more or less 
     settled on MPEG-2 video.  Audio is less than settled. For example, 
     General Instruments (the largest U.S. consumer cable set-top box 
     manufacturer) have announced the planned use of the Dolby AC-3 
     audio algorithm.

     The General Instruments DigiCipher I video syntax is similar to MPEG-2
     syntax but uses smaller macroblock predictions and no B-frames.  The
     DigiCipher II specification will include modes to support both the GI 
     and full MPEG-2 Video Main Profile syntax.  Services such as HBO will
     upgrade to DigiCipher II in 1994. 

   HDTV
     The U.S. Grand Alliance, a consortium of companies that formely competed
     for the U.S. terrestrial HDTV standard,  have already agreed to use
     the MPEG-2 Video and Systems syntax---including B-pictures. Both interlaced
     (1440 x 960 x 30 Hz) and progressive (1280 x 720 x 60 Hz) modes will 
     be supported. The Alliance must then settle upon a modulation (QAM, 
     VSB, OFDM), convolution (MS or Viterbi), and error correction (RSPC, RSFC) 
     specification.

     In September 1993, the consortium of 85 European companies signed an 
     agreement to fund a project known Digital Video Broacasting (DVB) which 
     will develop a standard for cable and terrestrial transmission by the 
     end of 1994. The scheme will use MPEG-2.  This consortium has put the 
     final nail in the coffin of the D-MAC scheme for gradual migration 
     towards an all-digital, HDTV consumer transmission standard. The only 
     remaining analog or digital-analog hybrid system left in the world is 
     NHK's MUSE (which will probably be axed in a few years).
     
Q. What did MPEG-2 add to MPEG-1 in terms of syntax/algorithms ?
A. Here is a brief summary:

  Sequence layer:
  More aspect ratios.  A minor, yet neccessary part of the syntax.

  Horizontal and vertical dimensions are now required to be a multiple of
  16 in frame coded pictures, and the vertical dimension must be a multiple 
  of 32 in field coded pictures.

  4:2:2 and 4:4:4 macroblocks were added in the Next profiles.

  Syntax can now signal frame sizes as large as 16383 x 16383.

  Syntax signals source video type (NTSC, PAL, SECAM, MAC, component) to 
  help post-processing and display.

  Source video color primaries (609, 170M, 240M, D65, etc.) and opto-
  electronic transfer characteristics (709, 624-4M, 170M etc.) can be 
  indicated.

  Four scalable modes [see scalable section below]

  Picture layer:
  All MPEG-2 motion vectors are half-pel accuracy.

  DC precision can be user-selected as 8, 9, 10, or 11 bits.

  Concealment motion vectors were added to I-pictures in order to 
  increase robustness from bit errors since I pictures are the most
  critical and sensitive in a group of pictures.

  A non-linear macroblock quantization factor that results in a more
  dynamic step size range, from 0.5 to  56, than in MPEG-1 (1 to 32).
  
  New Intra-VLC table for dct_next_coefficient (AC run-level events) 
  that is more geared towards I-frame probability distribution.  EOB
  is 4 bits.  The old tables are still included.

  Alternate scanning pattern that (supposedly) improves entropy coding
  performance over the original Zig-Zag scan used in H.261, JPEG, and
  MPEG-1.  The extra scanning pattern is geared towards interlaced
  video.

  Syntax to signal 3:2 pulldown process (repeat_field_first flag)

  Syntax flag to signal chrominance post processing type (4:2:0 to 
  4:2:2 upsampling conversion)

  Progressive and interlaced frame coding

  Syntax to signal source composite video characteristics useful in 
  post-processing operations. (v-axis, field sequence, sub_carrier, 
  phase, burst_amplitude, etc.)

  Pan & scanning syntax that tells decoder how to, for example, window a 
  4:3 image within a wider 16:9 aspect ratio image.  Vertical pan offset
  has 1/16th pixel accuracy.

  Macroblock layer:
  Macroblock stuffing is now illegal in MPEG-2 (hurray!!)

  Two line modes (interlaced and progressive) for DCT operation.   
  
  Now only one run-level escape code code (24-bits) instead of 
  the single (20-bits) and double escape (28-bits) in MPEG-1.

  Improved mismatch control in quantization over the original oddification
  method in MPEG-1.  Now specifies adding or subtracting one to the
  63rd AC coefficient depending on parity of summed quantized coefficients.
  
  Many additional prediction modes (16x8 MC, field MC, Dual Prime)
  and, correspondingly, macroblock modes.
  
  Overall, MPEG-2's greatest compression improvements over MPEG-1 are:  
  prediction modes, Intra VLC table, DC precision, non-linear macroblock 
  quant.  Implementation improvements, well,.. uh... macroblock stuffing
  was eliminated.
 
Q. What are the scalable modes of MPEG-2?
A. Scalable video is permitted only in the Main+ and Next profiles. 
   Currently, there are four scalable modes in the MPEG-2 toolkit.
   These modes break MPEG-2 video into different layers (base, middle,
   and high layers) mostly for purposes of prioritizing video data.  For 
   example, the high priority channel (bitstream) can be coded with a 
   combination of extra error correction information and decreased bit 
   error (i.e. higher Carrier-to-Noise ratio or signal strength) than 
   the lower priority channel.  
   
   Another purpose of scalablity is complexity division.  For example,
   in HDTV, the high priority bitstream (720 x 480) can be decoded 
   under noise conditions were the lower priority (1440 x 960) cannot. 
   This is "graceful" degradation. By the same division however, a 
   standard TV set need only decode the 720 x 480 channel, thus requiring 
   a less expensive decoder than a TV set wishing to display 1440 x 960.
   This is simulcasting.
   
   A brief summary of the MPEG-2 video scalability modes:
   [better descriptions in installment 3]   
   
   Spatial Scalablity-- Useful in simulcasting, and for feasible software 
    decoding of the lower resoultion, base layer.  This spatial domain 
    method codes a base layer at lower sampling dimensions (i.e. "resolution") 
    than the upper layers.  The upsampled reconstructed lower (base) layers 
    are then used as prediction for the higher layers.  
        
   Data Partitioning-- Similar to JPEG's frequency progressive mode, only 
    the slice layer indicates the maximum number of block transform 
    coefficients contained in the particular bitstream (known as the
    "priority break point").  Data partitioning is a frequency domain method
    that breaks the block of 64 quantized transform coefficients into two 
    bitstreams.  The first, higher priority bitstream contains the more 
    critical lower frequency coefficients and side informations (such as DC 
    values, motion vectors). The second, lower priority bitstream carries 
    higher frequency AC data.
        
   SNR Scalability-- Similar to the point transform in JPEG, SNR scalability 
    is a spatial domain method where channels are coded at identical sample 
    rates, but with differing picture quality (through quantization step sizes).  
    The higher priority bitstream contains base layer data that can be added 
    to a lower priority refinement layer to construct a higher quality picture.

   Temporal Scalability--- A temporal domain method useful in, e.g., 
    stereoscopic video.  The first, higher priority bitstreams codes video 
    at a lower frame rate, and the intermediate frames can be coded in a 
    second bitstream using the first bitstream reconstruction as prediction.  
    In sterescopic vision, for example, the left video channel can be 
    prediction from the right channel.

   Other scalability modes were experimented with in MPEG-2 video (such as
   Frequency Scalability), but were eventually dropped in favor of methods 
   that demonstrated similar quality and greater simplicity.

Q. What is all the fuss with cositing of chroma components?
A. It is important to properly co-site chroma samples, otherwise chroma 
   shifting may result.  
   [insert more details in installment 3]

Q. What is the reasoning behind MPEG syntax symbols?
A. Here are some of the Whys and Wherefores of MPEG symbols: 

  Start codes
  These 32-bit byte-aligned codes provide a mechanism for cheaply searching
  coded bitstreams for commencment of various layers of video without having
  to actually parse or decode.  Start codes also provide a mechanism for 
  resynchronization in the presense of bit errors.

  Coded block pattern (CBP --not to be confused with Constrained Parameters!)
  When the frame prediction is particularly good, the displaced 
  frame differencene (DFD, or 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.
  
  DCT_coefficient_first
  Each intra coded block has a DC coefficient.  Inter coded blocks 
  (prediction error or DFD) naturally do not since the prediction error 
  is the first derivative of the video signal. With coded block patterns
  signalling all possible non-coded block patterns, the dct_coef_first 
  mechanism assigns a different meaning to the VLC codeword that would
  otherwise represent EOB as the first coefficient.
  
  End of Block 
  Saves unecessary 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, this number is between 9 and 16 coefficients.
  Since EOB is required for all coded blocks, its absense can signal that a 
  syntax error has occurred in the bitstream.
  
  Macroblock stuffing
  A genuine pain for VLSI implementations, macroblock stuffing was introduced 
  to maintain smoother, constant bitrate control in MPEG-1. However, with 
  normalized complexity measures and buffer management performed on a 
  a priori (pre-frame, pre-slice, and pre-macroblock) basis in the MPEG-2 
  encoder test model, the need for such localized smoothing evaportated.  
  Stuffing can be acheived through virtually unlimited slice start code 
  padding if required. A good rule of thumb: if you find yourself often 
  using stuffing more than once per slice, you probably don't have a very 
  good rate control algorithm.  Anyway, marcoblock stuffing is now illegal in 
  MPEG-2.


  MPEG's 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).  With the acception of 
  a few codewords, the larger tables were carried over from the H.261 
  standard of 1990.  MPEG-2 added an "Intra table".  Note that the 
  dct_coefficient tables assume positive/negative coefficient pmf symmetry.


Q. What is the TM rate control and adaptive quantization technique ?
A. Test model was not by any strech of the imagination meant to
   be the show-stopping, best set of algorithm.  It was designed to
   excersize the syntax, verify proposals, and test the *relative* 
   performance of proposals in a way that could be duplicated
   by co-experimentors in a timely fashion.  Otherwise there would
   be more endless debates about model interpretation than actual
   time spent in verification.

  [MPEG-2 Test model is frozen as v5b]
  
  The MPEG-2 Test Model (TM) rate control method offers a dramatic 
  improvement to the Simulation Model (SM) method used for MPEG-1.  TM's 
  improvements are due to more sophistication pre-analysis and post-analysis 
  routines.

  Rate control and adaptive quantization are divided into three steps:

  Step One:       Bit Allocation 
    
    In Complexity Estimation, the global complexity measures assign relative 
    weights to each picture type.  These weights (Xi, Xp, Xb) are reflected 
    by the typical coded frame size of I, P, and B pictures (see typical frame 
    size section). I pictures are assigned the largest weight since they have 
    the greatst stability factor in an image sequence.  B pictures are assigned 
    the smallest weight since B data does not propogate into other frames 
    through the prediction process.

    Picture Target Setting allocates target bits for a frame based on 
    the frame type and the remaining number of frames of that same
    type in the Group of Pictures (GOP). 

 
Step Two:       Rate Control

        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.

        [more detail in installment 3]

Step Three:     Adaptive Quantization

        Recomputes macroblock quantization factor according to 
        activity of block against the normalized activity of the
        frame.
        
        The effect of this step is to roughly assign a constant number 
        of bits per macroblock (this results in more perceptually uniform 
        picture quality).

        [more detail in installment 3]
        

Q. How would you explain MPEG to the data compression expert?
A. MPEG video is a block-based video scheme 
   Local decorrelations via DCT-Q-VLC hybrid
   Dead-zone quanitizer
   DFD: quantized prediction error
   [etc.  More in installment 3]

Q. What are the implementation requirements?
A. MPEG pushes the limit of economical VLSI technology (but you get
   what you pay for in terms of picture quality or compaction efficiency) 

   Video                Typical decoder     Total    DRAM bus width 
   Profile              transistor count    DRAM     @ speed
   ------------         ----------------    -------  -------------------
   MPEG-1 CPB           0.4 to .75 million   4 Mbit  16 bits @ 80 ns
   MPEG-1 601           0.8 to 1.1 million  16 Mbit  64 bits @ 80 ns
   MPEG-2 MP@ML         0.9 to 1.5 million  16 Mbit  64 bits @ 80 ns
   MPEG-2 MP@High1440     2 to   3 million  64 Mbit  N/A

   70 or 80ns DRAM speed is a measure of the shortest period in which
   words can be transfered across the bus.  In the case of MPEG-1 SIF,
   80ns implies (1/80ns)(16bits) or about 25 MBytes/sec of bandwidth.
   Lack of cheap memory (DRAM) utilization is where the original DVI 
   algorithm made a costly mistake.  DVI required expensive VRAM/SRAM 
   chips (a static RAM transistor requires 6 transistors compared to 
   1 transistor for DRAM).    Fast page mode DRAM (which has slower 
   throughput than SRAM and requires near-contiguous address mapping) 
   is viable for MPEG due almost exclusively to the block nature of 
   the algorithm and syntax (DRAM memory locations are broken into 
   rows and columns).
        
Q. Is exhuastive search "optimal" ?
A. Definately not in the context of block-based MCP.   Since one motion
   vector represents the prediction of 256 pixels, divergent pixels within 
   the macroblock are misrepresented by the "global" vector.  This leads 
   back to the general philosophy of block-based coding as an approximation 
   technique.  Exhuastive search may find blocks with the least distortion 
   (displaced frame difference) but will not produce motion vectors with 
   the least entropy. [more details later]
   
Q. What is a good motion estimation method, then? 
   When shopping for motion vectors, the three basic characteristics are: 
   Search range, search pattern, and matching criteria.  Search pattern
   has the greatest impact on finding the best vector.   Hierarchical
   search patterns first find the best match between downsampled images of 
   the reference and target pictures and then refine the vector through
   progressively higher resolutions.  Hierarchical patterns are less
   likely to be confused by extremely local distortion minimums as being
   a best match.
   
   [Accuracy vs. Ambiguity]
   
   [Some ways of solving problem (Gary Sullivan--ICASSP '93), but not
   syntacitally compatible].

   [motion vector pre-frame search, motion vector refinement, etc.
    in installment 3]

Q. What is MPEG 1.5 and MPEG++ ? 
A. MPEG-1.5 was not exactly a  proprietary twist in terms of syntax,
   but operating parameters.  Again, people (erronously) consider MPEG-1 
   to be limited to SIF rates (352 x 240 x 30 Hz). After interrogation, 
   most MPEG 1.5 proponents will confess that MPEG 1.5 is simply MPEG-1 at 
   CCIR 601 rates (704 x 480 x 30 Hz) and that it may or may not include 
   B-frames.   It was meant to be an interrum solution for cable TV until
   MPEG-2 chips became available.

   MPEG++ is/was proprietary only at the transport layer (compatible syntax
   at the video layer).  This name was coined by the Sarnoff/Philips/
   RCA/Thomson HDTV consortium.  

   Both MPEG 1.5 and MPEG++ are now moot since MPEG-2 Simple profile and
   MPEG-2 Systems layer fill these potentials, respectively.


Q. What about MPEG-2 audio?
A. MPEG-2 audio attempts to maintain as much compatibility with        
   MPEG-1 audio syntax as possible, while adding discrete surround-sound
   channels to the orignal MPEG-1 limit of 2 channels (Left, Right or
   matrix center and difference).  The main channels (Left, Right) in 
   MPEG-2 audio will remain backwards compatible, whereas new coding
   methods and syntax will be used for the surround channels.

   A total of 5.1 channels are included that consist of the two main 
   channels (L,R), two side/rear, center, and a 100 Hz special effects 
   channel (hence the ".1" in "5.1").

   At this time, non-backwards compatible (NBC) schemes are being
   considered as an ammedment to the MPEG-2 audio standard. One
   such popular system is Dolby AC-3.

   [installment 3: detail on Layers, AC-3, etc., optimal bitrates.]

Q. What about MPEG-2 systems?
A. [to be filled out in installment 3]
        Transport stream
        Program stream
        ATM
        PES
        Timing Recovery

Q. How many bitstreams can MPEG-2 systems represent?
A. [installment 3]


Q. What are the typical MPEG-2 bitrates and picture quality?
[examples of typical frame sizes in bits]

                                        Picture type
                        I               P               B          Average
MPEG-1 SIF
@ 1.15 Mbit/sec         150,000         50,000          20,000      38,000

MPEG-2 601              400,000         200,000         80,000     130,000
@ 4.00 Mbit/sec

Note: parameters assume Test Model for encoding, I frame distance of 15 
(N = 15), and a P frame distance of 3 (M = 3).

Of course with scene changes and more advanced encoder models found
in any real-world implementation, these numbers can be very different.

Q. At what bitrates is MPEG-2 video optimal? 
A. The Test subgroup has defined a few examples:

"Sweet spot" sampling dimensions and bit rates for MPEG-2:

Dimensions      Coded rate      Comments
-------------   ----------      -------------------------------------------
352x480x24 Hz   2 Mbit/sec      Half horizontal 601.  Looks almost NTSC
(progressive)                   broadcast quality, and is a good (better) 
                                substitute for VHS.  Intended for film src.

544x480x30 Hz   4 Mbit/sec      PAL broadcast quality (nearly full capture 
(interlaced)                    of 5.4 MHz luminance carrier).  Also 
                                4:3 image dimensions windowed within 720
                                sample/line 16:9 aspect ratio via pan&scan.

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

[these numbers subject to change at whim of MPEG Test subgroup]


Q. How does MPEG video really compare to TV, VHS, laserdisc ?
A. VHS picture quality can be acheived for source film video at about
   1 million bits per second (with proprietary encoding methods).  It is 
   very difficult to objectively compare  MPEG to VHS.  The response curve 
   of VHS places -3 dB at around 2 MHz of analog luminance bandwidth 
   (equivalent to 200 samples/line). VHS chroma is considerably less dense 
   in the horizontal direction than MPEG source video (compare 80 samples/
   line to 176!).  From a sampling density perspective, VHS is superior only 
   in the vertical direction (480 lines compared to 240)... but when taking 
   into account interfield magnetic tape crosstalk and the TV monitor Kell 
   factor, not by all that much.  VHS is prone to timing errors (which can be 
   improved with time base correctors), whereas digital video is fully 
   discretized. Pre-recorded VHS is typically recorded at very high 
   duplication speeds (5 to 15 times real time playback), which leads to 
   further shortfalls for the format that has been with us since 1977.
   
   Broadcast NTSC quality can be approximated at about 3 Mbit/sec, and PAL 
   quality at about 4 Mbit/sec.  Of course, sports sequences with complex 
   spatial-temporal activity need more like 5 and 6 Mbit/sec, respectively.
   
   Laserdisc is a tough one to compare.  Disc is composite video (NTSC 
   or PAL) with up to 425 TVL (or 567 samples/line) response.  Thus it 
   could be said laserdisc has 567 x 480 x 30 Hz "resolution". The 
   carrier-to-noise ratio is typically better than 48 dB.  Timing is 
   excellent. Yet some of the clean characteristics of laserdisc can be 
   acheived at 1.15 Mbit/sec (SIF rates), especially for those areas of 
   medium detail (low spatial activity) in the presense of uniform motion.
   This is why some people say MPEG-1 video at 1.15 Mbit/sec looks almost
   as good as Laserdisc or Super VHS.

   Regardless of the above figures, those clever proprietary encoding
   algorithms can push these bitrates even lower.


Q. Why film does so well with MPEG ?
A. Several reasons, really:

   1) The frame rate is 24 Hz (instead of 30 Hz) which is a savings of
      some 20%.  
   2) the film source video is inherently progressive.  Hence no fussy 
      interlaced spectral frequencies.
   3) the pre-digital source was severly oversampled (compare 352 x 240 
      SIF to 35 milimeter 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 ameniable to 
      the transform and quantization methods of MPEG.

Q. What is the best compression ratio for MPEG ?
A. The MPEG sweet spot is about 1.2 bits/pel Intra and .35 bits/pel inter.
   Experimentation has shown that intra frame coding with the familiar 
   DCT-Quantization-Entropy hybrid algorithm acheives optimal performance
   at about an average of 1.2 bits/sample or about 6:1 compression ratio.  
   Below this point, artifacts become noticable.


Q. What are some pre-processing enhancements ?

  Adaptive de-interlacing:
  This method maps interlaced video from a higher sampling rate (e.g
  720 x 480) into a lower rate, progressive format (352 x 240).   The 
  most basic algorithm measures the variance between two fields, and if 
  the variance is small enough, uses an average of both fields to form a 
  frame macroblock.  Otherwise, a field area from one field (of the same
  parity) is selected.  More clever algorithms are much more complex 
  than this, and may involve median filtering, and multirate/
  multidimensional tools.

  Pre-anti-aliasing and Pre-blockiness reduction:
  A common method in still image coding is to pre-smooth the image
  before compression encoding.  For example, if pre-analysis of a
  frame indicates that serious artifacts will arise if the picture
  were to be coded in the current condition, a pre-anti-aliasing 
  filter can be applied.  This can be as simple as having a smoothing 
  severity proportional to the image activity.  The pre-filter can be 
  global (same smoothing factor for whole image) or locally adaptive.
  More complex methods will use multirate/multidimensional tools again.

  The basic idea of multidimensional/multirate pre-processing is to 
  apply source video whose resolution (sampling density) is greater 
  than the target source and reconstruction sample rates. This follows 
  the basic principles of oversampling, as found in A/D converters.

  Most detail is contained in the lower harmonics anyway.  Sharp-cut off
  filters are not widely practiced, so the "320 x 480 potential" of VHS
  is never truly realized.

Q. Why use these "advanced" pre-filtering techniques?

A. Think of the DCT and quantizer as an A/D convertor.  Think of the
   pre-filter as the required anti-alias prefilter found before every
   A/D.  The big difference of course is that the DCT quantizer assigns
   a varying number of bits per sample (transform coefficient).
   
   Judging on the normalized activity measured in the pre-analysis 
   stage of video encoding, and the target buffer size status, you have
   a fairly good idea of how many bits can be spared for the target
   macroblock, for instance. 

   Other pre-filtering techniques mostly take into account: texture 
   patterns, masking, edges, and motion activity.  Many additional 
   advanced techniques can be applied at different immediate layers
   of video encoding (picture, slice, macroblock, block, etc.).
   
 
Q. What are some advanced encoding methods?

  Quantizer feedback
  [Thomson patent: installment 3]
  
  Horizontal variance [installment 3]
  
  motion vector cost:  this is true for any syntax elements, really.  
  Signalling a macroblock quantization factor or a large motion vector 
  differential can cost more than making up the difference with extra 
  quantized DFD (prediction error) bits.   The optimum can be found
  with, for example, a Lagrangian process.  In summary, any compression 
  system with side information, there is a optimum point between signalling 
  overhead (e.g. prediction) and prediction error. 
        
  Liberal Interpretations of the Forward DCT        
  Borrowing from the concept that the DCT is simply a filter bank, a 
  technique that seems to be gaining popularity is basis vector shaping.  
  Usually this is combined with the quantization stage since the two are 
  tied closely together in a rate-distortion sense. The idea is to use 
  the basis vector shaping as a cheap alternative to pre-filtering by 
  combining the more diserable data adaptive properties of pre-filtering/
  pre-processing into the transformation process... yet still reconstruct 
  a picture in the decoder using the standard IDCT that looks reasonably 
  like the source. Some more clever schemes will apply windowing.  
  [Warning: watch out for eigenimage/basis vector orthoganality. ]

  Frequency-domain enhancements:
  Enhancements are applied after the DCT (and possibly quantization)
  stage to the transform coefficients.  This borrows from the concept:  
  if you don't like the (quantized) transformed results, simply reshape 
  them into something you do like.
  
  Temporal spreading of quantization error:
  This method is similar to the orignal intent behind color subcarrier 
  phase alternation by field in the NTSC analog TV standard: for stationary 
  areas, noise does not hang" in one location, but dances about the image 
  over time to give a more uniform effect.  Distribution makes it more 
  difficult for the eye to "catch on" to trouble spots (due to the latent 
  temporal response curve of human vision). Simple encoder models tend 
  to do this naturally but will not solve all situations.


  Look-ahead and adaptive frame cycle structures:
        Scene changes
        [installment 3]        

  It is easy to spot encoders that do not employ any advanced 
  encoding techniques:  reconstruced video usally contains
  ringing around edges, color bleeding, and lots of noise.

 
Post-processing 

 (non-linear) Interpolation methods (Wu-Gersho)
 Convex hull projections
 Some ICASSP '93 papers, etc.

 Conformance vs. post-processing:   Post-processing makes judging 
 decoder output for conformace testing near impossible.
 [installment 3]

Q. Why bother to research compressed video when there is a standard?        
A. Despite the worldwide standard, many areas remain open for
   research:  advanced encoding and pre-processing, motion estimation,
   macroblock decision models, rate control and buffer management, etc.  
   There's practically no end to it.


Q. Is so-and-so really MPEG compliant ? 

A. At the very least, there are two areas of conformance/compliance in
   MPEG:  1. Compliant bitstreams  2. compliant decoders.  Technically 
   speaking, video bitstreams consisting entirely of I-frames (such as 
   those generated by Xing software) are syntactically compliant with 
   the MPEG specification.  The I-frame sequence is simply a subset of 
   the full syntax.  Compliant bitstreams must obey the range limits 
   (e.g. motion vectors limited to +/-128, frame sizes, frame rates, etc.) 
   and syntax rules (e.g. all slices must commence and terminate with a 
   non-skipped macroblock, no gaps between slices, etc.). 

   Decoders, however, cannot escape true comformance. For example, a  
   decoder that cannot decode P or B frames are *not* legal MPEG.  
   Likewise, full arithmetic precision must be obeyed before any 
   decoder can be called "MPEG compliant."   The IDCT, inverse quantizer, 
   and motion compensated predictior must meet the specification 
   requirements... which are fairly rigid (e.g. no more than 1 least 
   significant bit of error between reference and test decoders).  
   Real-time conformance is more complicated to measure than arithmetic 
   precision, but it is reasonable to expect that decoders that skip 
   frames on reasonable bitstreams are not likely to be considered 
   compliant.

      

Q. What are some journals on related MPEG topics ?
A. 

  IEEE Multimedia [first edition Spring 1994]
  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 Pictrures and Television Engineers (SMPTE)
  SPIE conference on Visual Comminications and Image Processing
END ---------------------- CUT HERE --------------------- 2/6



Archive-name: mpeg-faq/part3
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly


BEGIN -------------------- CUT HERE --------------------- 3/6
  SPIE conference on Video Compression for Personal Computers
   (to be held Feb 1994 in San Jose)


Q. Is there a book on MPEG video?
A. Yes, there will be a book published in Spring 1994 by the same
   authors who wrote the JPEG book (Bill Pennebaker, Joan Mitchell)
   with Didier Le Gall as an additional co-author.


Q. Can motion vectors be used to measure object velocity?

A. Motion vector information cannot be relaibly 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 form vectors 
   that typically minimze prediction error and, consequentally, the vectors 
   often do not represent true object translation.  Standards convertors that 
   resample one frame rate to another (as in NTSC to PAL) use different 
   methods (field coding, edge detection, et al) that are not concerned with 
   optimizing SNR vs bitrate. Secondly, motion vectors are not transmitted 
   for all macroblocks anyway. 
    
 

Q. How do you 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 efficient of course.  On the other hand, if the 
   orignal 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 superior performance through 
   greater DC block precision, non-linear mquant, intra VLC, etc.)
   Reconstructed frames are re-interlaced in the decoder Display process.

   The second syntactically compatible method codes fields separately.
   Picture types are keyed to motion activity to aid efficiency of
   prediction. 
   
Q. How many cable box alliances are there?
A. Many.  To start with:

  Scientific Atlanta (SA), Kaledia, and Motorola:
  SA will build the box, Motorola the chips, and Kaleida the
  O/S and user interface (using ScriptX of course).
    
  Silicon Graphics (SGI), Scientific Atlanta, and Toshiba 
  For the Time Warner's Orlando trial, SGI will provide the 
  RISC (MIPS R4000) and software, SA will do the box again,
  and Toshiba will provide the chips.

  General Instruments (GI) and Microsoft:
  GI will make the box and Intel will supply the special low-cost
  386SL processor on which a 1MB flash EPROM executable core 
  of  Microsoft windows and DOS will run.  Microsoft will develop the 
  user interface.

  Hewlett Packard (HP):
  HP will manufacture and/or design low cost, open architecture set-top
  decoder boxes (not a part of the Eon wireless deal).  The CPU will
  explicitly not use a 80x68 based processor.

	[more details in installment 3]

  CLI and Philips:
  Compression Labs will provide the encoder technology and Philips 
  will provide the decoder techology for an ADSL system whose
  transport structure will be put together by Broadband Technologies.

  ["These alliances subject to change at the whim of PR departments 
     and market forces."]
  [Thanks to Steve Krause for assistance on box alliances].


Q. What is the rundown on public domain MPEG source software?
A. There are two public domain source codes available:
  
  Berkeley encoder (v1.1) by Kevin Gong, Dan Wallace, Ketan Patel, 
        Brian Smith, and Larry Rowe.                
        Log, telescopic, and exhastive search
        variable rate operation
        designed for parallel machine operation
             
        Loeffler, Lightenberg, Moschytz "Practical fast 1-D
        DCT algorithms with 11 multipications" from ICCASP-89.

        Optimized for speed.

  Stanford encoder (v1.2) by Andy C. Hung
        Telescopic search
        SM-3 coding strategy and rate control
        Chen, Smith, Fralick algorithm or floating point direct matrix 
        multiply.
        Optimized for flexibility.

        Stanford decoder does not include display functions.
  [more details in installment 3]

Q. Is MPEG patented?
A. Yes and no.  Many encoding methods are patented.  Blocking patents,
   that is, patents that are general enough to be unavoidable in any
   implementation have been recently identified.
   
   [installment 3]
        patent pool
        blocking patents
        method-specific patents (proprietary algorithms, architectures)


Q. What are the tell-tale MPEG artifacts?
A. If the encoder did its job properly, and the user specified a 
   proper balance between sample rate and bitrate, there shouldn't be 
   any visible artifacts.  However, in sub-optimal systems, you can
   look for:
     
     Gibbs phenomenon/Ringing/Aliasing (too few AC bits, not enough
     pre-filtering)

     Blockiness (not considering your neighbors before quantizing)
     Posterization (too few DC bits)
     Checkerboards (DCT eigenimages as a result of too few AC coefficients)
     Colorbleeding (not considering color in encoder cost model)

Q. Where are the weak points of MPEG video ?
A. 

        Texture patterns (rapidly alternating lines)
        sharp edges (especially text)
        [installment 3]

Q. What are some myths about MPEG?
A. There are two major myths that I am aware of:

   Block displacements:  macroblock predictions are formed out of
   arbitrary 16x16 (or 16x8 in MPEG-2) areas from previously reconstructed 
   pictures. Many people believe that the prediction macroblocks have 
   boundaries that fall on interchange boundaries (pixel 0, 15, 31, 53... 
   line 0, 15, 31, 53... etc.).  In fact, motion vectors represent relative
   translations with respect to the target reconstruction macroblock
   co-ordinates. The motion vectors can point to half pixel co-ordinates 
   which requires that the prediction macroblock to be formed via 
   interpolation of pixels.

   Displaced frame (macroblock) difference construction: the prediction 
   error formed as the difference between the prediction macroblock and 
   source macroblock is coded much like an Intra macroblock (only without
   a DC value).  The prediction may come from different locations 
   (B-macroblocks) or fields (MPEG-2), but the DFD is always coded 
   progressively as if it were a I-frame energy.

   ..and worst of all...
   Compression ratios:  

   [installment 3]
   [real compression ratios are in the range of 16:1 to 30:1]
--------
Subjects in future installments of the FAQ:

Who are the people and companies behind MPEG?
Frame formats and their significance
4:2:2, 4:4:4, 4:2:0
[many, many more]

End of MPEG-2 FAQ Installment No. 2 (October 8, 1993)
-----
Copyright (need to re-use the information)   Chad Fogg.
cfogg@cdac.com


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

From: cfogg@ole.cdac.com (Chad Fogg)
Subject: MPEG Press Release -- NY meeting
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

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.


===========================================================================
 II | PROFESSIONAL SOFTWARE
===========================

The named tools are:

  MPEG Encode
  XingSound
  XingCD
  PC-Hurricane
  NVR-Toolkit

-------------------------------------------------------------------------------
 II.1 | DOS
-----------

Ingenieurbuero Gatz & Hartmann,

Fehrbelliner Str. 32, 13585 Berlin, GERMANY

Tel: 030- 344 23 66 or 030-375 55 68
FAX: 030- 344 92 79 or 030-375 56 55

email to: harti@mikro.ee.tu-berlin.de


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(             ]

---------------------------------------------------------------------------
 II.2 | WINDOWS
---------------

[ 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 !


This package is available from:
-------------------------------

Gatz & Hartmann
Ingenieurbuero fuer Multimedia-Anwendungen
Berlin, Germany

Tel: ++ 49 30 344 23 66
FAX: ++ 49 30 344 92 79

email:
harti@mikro.ee.tu-berlin.de

The bundle is 999.-DM incl. 15 % VAT in Germany. If you order from outside 
Germany, you will be charged 15 % less, plus airmail shipping and c.o.d charges.

Please call for shipment details. Orders please via FAX. Thanks !

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

XingCD is here !

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 !

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

Gatz and Hartmann proudly presents:  PC-Hurricane Win3.x Winhurri Version 1.5

This is our new control program for the moviegrabber board
		
		PC-Hurricane
		============

This version 1.5 only runs in Hicolor modes 32K or 64K colors !
So use these Windows Hicolor drivers to use this piece of software.

Functions:
----------

1. You can digitize video movies in realtime (up to 25 frames/second) into 
Extendend Memmory and play them also back in realtime with this Winhurri
program.  Now you can also do Harddisk-Video-Recording in realtime up to
384x288 screen size (full field resolution ) !

2. You can save every single frame or the whole movie in one shot to the 
harddrive.

3. Due to the DIB or BMP output you can load the DIB sequence directly into
the VideoEditor of Microsoft's Video for Windows(tm) program and generate
an compressed AVI movie. The BMP output is for the Xing Technology MPEG encoder,
so you can choose to make AVI or MPEG movies from the digitized raw data.

4. You can watch television with this card by connecting a tuner and clicking
the VIEW button. At 160x120 screen size it gives you realtime video display
without the need of an feature connector cable to your VGA card or the hassle 
to be unable to use the highest Hicolor windows driver.
So you can watch TV while working in a windows resolution of e.g. 1024x768x64K 
colors and still doing word-processing or picture editing in Hicolor.

Normal Overlay boards only support up to 256 colors windows drivers or only
640x480x32K colors, but not 1024x768x64K colors Noninterlaced! (like with the
new Genoa VideoBlitz card with the Weitek P9000 chipset) 

Future versions:
----------------

We are already working on integrating WAV sound digitizing in realtime together
with the video grabbing by using any installed soundcard under windows.

This will allow synchroneous digitizing of sound and video in one shot.
You can then save the DIB sequence and a WAV file and do an AVI movie with
sound in one shot !

email to: harti@mikro.ee.tu-berlin.de

PC-Hurricane in this moment sells for 499.-DM incl. 15 % VAT in Germany.
Together with the Xing Technology MPEG Encoder and player it is 699.- DM 
incl. 15 % VAT in Germany.

Foreign customers could get it by VISA card payment.
It is 299.-US$ including airmail delivery to you.
Together with the Xing MPEG Encoder and Player software for Windows it sells
for 449.- US$ incl. shipping and handling.


---------------------------------------------------------------------------
 II.3 | UNIX
------------

[ 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>
Subject: Re: THE MPEG-FAQ - Version 2.0 
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

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

From: Todd Brunhoff <toddb@nvr.com>
Subject: Re: NVR-Software 
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 nvr.com (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
nvr.com (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


===========================================================================
 III | PUBLIC-DOMAIN-SOFTWARE OR SHAREWARE
==========================================

The named tools are:

  LAYR_099
  MPEG2PPM
  VMPEG
  CMPEG
  DMPEG
  SECMPEG (Dos)
  MPEGSTAT
  ENC11DOS
  XingIt (MPEGPLAY)
  PVRGMPEG (MPGCODEC)
  MPEGW32E
  XMPLAY
  MPEGAUDI
  MAPLAY
  MPEGTOOL
  SECMPEG (Unix)
  MPEGSTAT (Unix)
  MPEG_ENCODE
  MPEGv1.2 (PVRG)
  WDGT
  MPEG_PLAY-20-DECW
  SPARCLE
  QT2MPEG
  MP (OS/2)
  MPPLAY
  MPEGNEXT

---------------------------------------------------------------------------
 III.1 | DOS
------------

[ First, the new AUDIO-Tool, juhuu ;o) usally called LAYR_099.EXE ]

From: "Harald Popp" <POPP@iis.fhg.de>
Organization:  Fraunhofer Gesellschaft, IIS
Date:          Tue, 10 May 1994 15:03:04 +0200
Subject:       Re: mpegfa31.txt-[3/7]

ISO-MPEG Audio Layer 3 software only Encoder and Decoder
Version 0.99a.

copyright Fraunhofer - IIS 1994

- 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 III 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 
  Layer III are available. Contact one of the companies listed 
  in the file info.txt.

The package consists of the following files
   
   L3ENC.EXE      encoder program (8088)
   L3ENC_FP.EXE   encoder program (80486)
   L3DEC.EXE      decoder program (8088)
   L3DEC_FP.EXE   decoder programm (80486)
   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).

This package is distributed as shareware. You may work with the package for
30 days for evaluation purposes. If you want to use this package after the
evaluation period, you are required to register the package (see information
in the file REGISTER.TXT). You may give copies of this package to other 
people as long as no file is changed and no file is omitted.

The programms are written for IBM-PCs or Compatibles with MS-Dos. While
L3ENC.EXE and L3DEC.EXE should work on practically any PC, the other
programms require a 386 type CPU plus hardware floating point support.
Especially for the encoder, a 486DX33 or better is recommended.

On a 486DX2/66 the performance of the software-only decoder is about
33% of the performance necessary for real time audio processing. The 
encoder needs about 30 minutes to encode a 1 minute audio data file. 
These figures assume coding/decoding of stereo audio material 
at 44.1 kHz/sec.

If you need further information on Layer 3 products or if you have
any questions concerning this shareware product, please send email to

	layer3@iis.fhg.de. 

You can also fax or mail your questions to

   Layer 3 support
   Fraunhofer - IIS
   Am Weichselgarten 3
   D-91058 Erlangen
   Germany

Fax: + 49 9131 / 776 399

We would also like to hear from you, if you are interested in a 
version of this shareware for SUN workstations.


Disclaimer:

Don't forget that there are no warranties associated with this software.
While we believe that our software is reasonably bug free and well behaved,
we are in no way responsible if our software does not work the way you
would expect it to work. No matter if it locks up your computer, garbles
your floppy disks or does any other harmful things to your computer - it
is entirely your problem. 

Fraunhofer - IIS is not liable for any infringments or damages of 
third parties' rights in consequencs of your use of this shareware 
product. Fraunhofer - IIS is in no event liable for, respectively does 
not warrant the trustworthiness, quality, industrial exploitability, 
serviceability of this shareware product for the supposed purpose 
or any other purposes.

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

How you may get the shareware:

a) via anonymous ftp from fhginfo.fhg.de (153.96.1.4)

You may download our Layer-3 audio software package from the 
directory /pub/layer3. You will find the following files:
  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 

b) 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.

c) 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")

d) 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...


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


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

MPEG2P11.ZIP (c) 1993 by PHADE Software
=======================================

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

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

[ This is VMPEG 1.1, the best MPEG-player for DOS AT ALL ! ]

From: stefan@lis.e-technik.tu-muenchen.de (Stefan Eckart)
Subject: vmpeg11.zip (fast DOS 386+ MPEG player) posted
Date: 23 Nov 93 17:54:51 GMT

                              VMPEG V1.1
                            DOS MPEG player
                           by Stefan Eckart

The archive also contains MPGSPLIT (no '386 req.), a utility to split
multiplexed MPEG system layer files (e.g. from a CD) into seperate video
and audio streams.


Changes from VMPEG 1.0 to VMPEG 1.1:

 - 20% speed gain (code streamlining)
 - improved image quality (higher IDCT accuracy)
 - True Color display
 - support of system layer MPEG streams
 - more drivers included


Features:

 - full MPEG-1 video standard (ISO 11172-2): I,P,B frames of arbitrary size;
   no restriction to 160x120 or I-frame-only sequences
 - also plays system layer (ISO 11172-1) files
 - "high" speed: e.g. 16 frames/s on a 386DX/33 for a 160x120 I frame
                 sequence (mjackson.mpg); about the speed of mpeg_play
                 running on a Sparcstation1+
 - supports VGA and a variety of SVGAs
 - '386 or '486 processor required (i.e. no '286); based on the
   DOS extender GO32.EXE by DJ Delorie
END ---------------------- CUT HERE --------------------- 3/6



Archive-name: mpeg-faq/part4
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly


BEGIN -------------------- CUT HERE --------------------- 4/6

 - dithering options: 4x4 ordered dither normal size
                      4x4 ordered dither double size
                      grayscale


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

VMPEG complements the programs CMPEG (MPEG encoder) and DMPEG (MPEG
decoder and off-line player). It decodes MPEG encoded sequences directly
to the screen at (hopefully) reasonable speed. It is about eight times
faster than DMPEG, up to nearly 50% faster than the latest Xing MPEG player
(mjackson.mpg: XingIt V2.1: 10 frames/s, VMPEG: 14.5 frames/s) and, timed
on a 386DX/33, about 1/3 to 1/2 the speed of the Berkeley MPEG player
(mpeg_play) running on a Sparc10.

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. VMPEG cannot be run from Windows or under OS/2.

The eightfold speed improvement over DMPEG was obtained by changing the
C compiler, by using algorithms which take advantage of the 32 bit
architecture of the '386 and by rewriting a few key routines in '386
assembler.

VMPEG is, however, not meant to replace DMPEG (at least not presently),
since it is lacking several of the features of DMPEG (like decoding
to a file, TrueColor display, Floyd-Steinberg dithering etc.) and the
quality of the decoded sequences is a bit lower (about 7 bit accuracy
instead of 8 bit, which is however completely masked by the dithering
noise and the 6 bit color register resolution of VGAs and SVGAs).

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


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

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:

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

DMPEG V1.1  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.

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

[ 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) 1993 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 Gnu's DOS-port of their 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 Gnu-environment-executable 'GO32.EXE' has to be somewhere
in the PATH. If running on a 386, the GNU-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

       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.

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

[ 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) 1993 by PHADE Software
=======================================

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

It was compiled with Gnu's DOS-port of their 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):

        host: ftp.cs.tu-berlin.de (130.149.17.7)
        file: /pub/msdos/dos/graphics/mpegstat.zip



NEEDS and INSTALL
-----------------

The Gnu-environment-executable 'GO32.EXE' has to be somewhere
in the PATH. If running on a 386, the GNU-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, Phade (phade@cs.tu-berlin.de)
 
---------------------------------------------------------------------------

[ 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 Gnu's DOS-port of their 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):

        host: ftp.cs.tu-berlin.de (130.149.17.7)
        file: /pub/msdos/dos/graphics/enc11dos.zip


NEEDS and INSTALL
-----------------

The Gnu-environment-executable 'GO32.EXE' has to be somewhere
in the PATH. If running on a 386, the GNU-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, Phade (phade@cs.tu-berlin.de)

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

[ 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".

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

[ 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: mitgml@dct.ac.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
mitgml@dct.ac.uk


---------------------------------------------------------------------------
 III.2 | WINDOWS
----------------

[ Usally called MPGAUDIO.ZIP ]

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. ]


---------------------------------------------------------------------------
 III.3 | WINDOWS-NT
-------------------

[ This new version of it, is running now extremly nice, the subsystem ]
[ is no harm at all. The file should be known as MPEGW32E.ZIP.        ]

From: michael@ecel.uwa.edu.au (Michael Simmons  - division)
Subject: MPEGPLAY for WINDOWS and NT Now has VCR like Controls
Date: 8 Dec 1993 01:37:36 GMT

It is also available via ftp from decel.ecel.uwa.edu.au as
/users/michael/mpegw32e.zip

MPEGPLAY V1.50 (c) 1993 Michael Simmons

This is Release Version 1.50 of my port of the Berkeley mpeg player.

I have redesigned the interface.

Some of the new features are:
(1) Push button VCR like controls.
(2) A Seperate Video Window.
(3) Automaticaly 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 Player window positions correctly when exiting.

Please Email me with any suggestions you may have on improving the player!

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 color (for Hicolor graphic cards).

This program is SHAREWARE Please read the About box and Help file for 
information on registering your copy. The registered version does not 
display the About box at startup. It also handles files bigger than 1MB.

To install the player under Windows 3.1(tm), Unzip the file disk1.zip
to a floppy disk. Then run the setup.exe file via the Progman File-Run Menu
Item. Note: You will need to install the Win32s extensions to Windows 3.1
inorder to run this player. Should you wish to remove these extensions
please refer to the section near the end of this Readme.txt file.
Then follow the instructions for running the player under windows NT.

To install the player under Windows NT(tm) copy the files mpegplay.exe and
mpegplay.hlp to a common directory. Then create a new program item for the
mpegplay.exe file via the File New option of the Program Manager.

Read the Disclaimer in the online Help before loading any mpeg movie files.


The lastest version of this software can be found first on decel.ecel.uwa.edu.au
in the users/michael directory


DISTRIBUTION:

This File must not be separated from the rest of this archive.

Due to licensing conditions of the WIN32s(tm) System this archive can only be
Redistributed in the following ways:
(1) Archive site to End user.
(2) Archive site to Archive site.
The following means of redistribution are not permitted:
(1) End user to End user.
(2) End user to Archive site.

Redistribution from Archive site to Archive site may only be performed by
the operators of those sites.
An Archive site is taken to be any large collection of software which is
operated by a person or group of persons for the primary purpose of 
redistributing that software.
An End user is taken to be the person or group of persons who use this
software.

Known Bugs:
(1) The Mono Dither is not working properly.
(2) The 2x2 Colour Dither has patches of incorrect colour.
(3) Bug/feature The Player runs slow when ever the mouse is moving.
(4) Will still give Exception errors but this is much rarer.

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 
    (I have only received one registration!!)

Changes V1.2 -> 1.25
(1) Major rewrite of source code to cleanup 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 Seperate Video Window.
(3) Automaticaly 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 transfering images to the screen.


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).
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 help full suggestions.

HOW TO REMOVE THE WIN32s EXTENSIONS to WINDOWS

(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

Windows NT, Win32s, Windows 3.1 are trademarks of the Microsoft Corporation.

Michael Simmons B.E.E.               The Department of Management
Computer Officer                   University of Western Australia
Phone: (w)+61-9-380 2985          Stirling Highway Nedlands WA 6009
Phone: (h)+61-9-390 4534                      Australia
Fax:      +61-9-380 1004           Email: msimmons@ecel.uwa.edu.au

---------------------------------------------------------------------------
 III.4 | OS/2
-------------

[ Read the RETRIEVED-MAIL-section for more infos ! ]

mp.lha               gfx/show    45K  83 MPEG player for EHB display.


---------------------------------------------------------------------------
 III.5 | X-WINDOWS and UNIX
---------------------------

[ Here it is !! The first, fully-featured MPEG-player with X11-interface. ]
[ XPLAY 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:

        host: ftp.cs.tu-berlin.de (130.149.17.7) or
              quepasa.cs.tu-berlin.de
        file: /pub/incoming/xmplay-1.0.tar.gz
        file: /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]

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.

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]
===================

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.


You can ftp XMPLAYe 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
	

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

[ And here the otehr BIG sensation: We have MPEG-I-audio-source-code. ]
[ From the ISO somebody organized the example encoder/decoder-source. ]
[ And from the TU-Berlin, there is Tobias "Doping" Badings' free      ]
[ implementation of an C++ decoder. Thats a BIG step forward, yeh ?   ]
[ And theres even more ...                                            ]

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

[ You can find this under the name MPEGAUDI or ftp it from the IUMA-  ]
[ server sunsite.unc.edu in 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/

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

From: "Tobias 'Doping' Bading" <bading@cs.tu-berlin.de>
Subject: Re: MPEGFAQ31: call for papers
Date: Wed, 4 May 1994 17:49:12 +0200 (MET DST)

MPEG Audio Player maplay
------------------------

Features of the actual version 1.1:
 - realtime playing of layer I/II MPEG audio streams on SPARC 10 machines with
   the dbri device and on Indigo audio ports with 16 bit and 32, 44.1 or 48 kHz
 - support of all modes (single channel, stereo, joint stereo and dual channel)
   and bitrates (except free mode currently)
 - decoding of streams to stdout into a raw pcm format for further format
   conversions to .au, .wav etc
 - free-ware
 - written in C++ using the GNU C++ compiler version >= 2.5.1
 - already tested on
     Sun SPARCs with SunOS 4.1.3 or Solaris 2.3,
     Silicon Graphics Indigos with IRIX IRIX 4.0.5F,
     DECstations with ULTRIX 4.2

Promised enhancements for the next version:
 - increased decoding efficiency
 - support for /dev/dsp under Linux
 - 8 kHz u-law support for SPARC 1 and 2 (but without CD-quality ;-)
 - ???

You can find the sources of the actual version on the Internet Underground
Music Archive (IUMA) ftp server sunsite.unc.edu (198.86.40.81) in
/pub/electronic-publications/IUMA/audio_utils/mpeg_players/Workstations

New versions, patches etc will be posted to alt.binaries.multimedia and will
find their way to the IUMA.
Announcements will be made in alt.binaries.multimedia, comp.multimedia,
alt.comp.compression, comp.compression, alt.binaries.sounds.misc and
de.alt.binaries.sounds.d. Persons who already contacted me with new ideas,
comments, adjustments, problems etc will be informed via email, too.

Enjoy the sound,
                 Tobias Bading   (bading@cs.tu-berlin.de)

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

Date: Sun, 2 Jan 1994 22:57:48 -0800
From: Jared V Boone <jboone@patriot.wtfd.orst.edu>
Subject: MPEG decoder...

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...

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

[ Well, have a look with archie to find 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.

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

  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.

  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.

  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 be posted the alt.binaries.pictures.utilities and the security-
  relevant groups these days. Reposts come as requested.

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

        host: ftp.cs.tu-berlin.de (130.149.17.7)
        file: /pub/msdos/dos/graphics/secmpeg.zip

  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

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

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                                 ]

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

/*
 *
 * Copyright (c) 1993 Technical University of Berlin, Germany
 *
 * for the parts of the Berkeley player used:
 *
 * Copyright (c) 1992 The Regents of the University of California.
 * All rights reserved.
 *
 */

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

[ This brand-new encoder is really nice. Supports parralell computation ! ]
[ There is also a really nice TKTCL-X11-Interface included !!!            ]

[ I already ported this to DOS (surely without the parallel stuff.        ]

From: Larry Rowe <larry@postgres.Berkeley.EDU>
Date: Fri, 30 Jul 1993 17:15:56 -0700
Subject: MPEG Video Encoder Release


The Berkeley Plateau Research Group is happy to announce the
release of Version 1.0 of its MPEG video encoder.
The encoder is available via anonymous ftp from mm-ftp.cs.berkeley.edu
(128.32.149.157) in /pub/multimedia/mpeg/mpeg_encode-1.0.tar.Z.
That directory includes a sample uncompressed video sequence
(flower.tar), our software MPEG video player, and some MPEG movies.
	Larry and Kevin

Below is a copy of the README file:
------------------------------------------

                 MPEG-1 Video Software Encoder
                 (Version 1.0; July 30, 1993)

     Lawrence A. Rowe, Kevin Gong, Ketan Patel, and Dan Wallach
    Computer Science Division-EECS, Univ. of Calif. at Berkeley

This directory contains the freely distributed Berkeley MPEG-1 Video 
Encoder.  The decoder implements the standard described in the ISO/IEC
International Standard 11172-2.  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)
 DECstation 5000 and Alpha

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/INSTALL.  A man 
page is given in the file doc/mpeg_encode.1. 

The encoder will accept any input file format as long as you provide 
a script to convert the images to PPM or YUV 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.

We have also provided a Tcl/Tk script, named encode.tcl, that can 
be used to set parameters interactively (see the misc/ directory).
The misc/ directory contains utility you might find useful including:
programs to do PPM/YUV conversion and programs to convert Parallax
XVideo JPEG files into PPM or YUV 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 doc/TIPS.

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 EXTENSIONS.  If you succeed in 
implementing any of them, please let us know! We have established 
several mailing lists for messages about the Berkeley MPEG work:

mpeg-list-dist@CS.Berkeley.EDU
   General information on the MPEG-1 decoder and encoder for 
   everyone interested should be sent to this list.

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.

Our future plans include porting the encoder to run on other
platforms and completing a portable parallel version of the code
that will run on a network of workstations.  Vendors or other 
END ---------------------- CUT HERE --------------------- 4/6



Archive-name: mpeg-faq/part5
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly


BEGIN -------------------- CUT HERE --------------------- 5/6
organizations interested in supporting this research or discussing 
other aspects of this project should contact Larry Rowe at 
Rowe@CS.Berkeley.EDU (+1 510-642-5117).

ACKNOWLEDGEMENTS:

We gratefully thank Hewlett-Packard and Fujitsu who provided financial
support for this work.  We also want to thank the following people for 
their help:

    Jef Poskanzer who developed the pbmplus package.

[ He added the very nice patch that allows mpeg_play to decode ]
[ a MPEG-stream to produce a series of pbm-files. The DOS-port ]
[ of this utility is called MPEG2P11.ZIP                       ]

    ---------
    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.

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

[ You can find this in the /pub/multimedia/mpeg-directory of Berkeley's ]
[ ftp-server. Belongs to there codec.                                   ]

This directory includes 150 raw YUV frames suitable for use with the MPEG
encoder.

The YUV frames are the files flower.*.tar.z.  To uncompress, use the GNU
'gunzip' program.  You should uncompress all of these files inside a
directory named 'flowg'.

To run the test, simply do 'mpeg_encode flower.param'

To make sure the test worked, do 'diff flowgard.mpg result.mpg'
  (there shouldn't be any difference; if there is, let us know)

Please see the file 'times,' which includes time results for various machines
and compilers.

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

[ A Public-Domain-Encoder-Kit for Unix ! Now in Version 1.2 ]

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 mm-ftp.cs.berkeley.edu [128.32.149.157] in
/pub/multimedia/mpeg/mpeg-2.0.tar.Z.


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

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

[ 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.

This widget was implemented by making minimal  changes  to
the mpeg2.0 source code. Because of this, there are a num-
ber of global variables, functions and constants  that  do
not follow normal widget conventions.  Many of the mpeg2.0
options are not supported yet. Shared memory may not  work
-  it  has  not been tested.  On stepping through a movie,
the number of frames shown per step is indeterminate.


---------------------------------------------------------------------------
 III.6 | VMS
------------

The VMS MPEG viewer is built by acquiring the regular Unix-specific mpeg
source, then getting the VMS specific code.  Using this mesh of code, you
build your own VMS-compatible MPEG player.

First, get the regular UNIX Mpeg viewer per the instructions in part "c"
above.  Then get the following:

Site:  mm-ftp.cs.berkeley.edu [128.32.149.157]
Dir :  /pub/multimedia/mpeg/vms
File:  Browse entire subdir, snag what you need

Thanks to Terry Maton for this information.  Here is some text from him
which may be of help to VMS users:

First go to mm-ftp.cs.berkeley.edu in /pub/multimedia/mpeg and get the main
mpeg file mpeg_play.2.00.tar.Z, then cd to vms and get the file 
MPEG_PLAY-20-DECW.TAR_Z.  Now you have to decompress and tar the main file
first and then the vms file.  This means that the latest version of some
of the .c files are the correct ones for vms.
 
---------------------------------------------------------------------------
 III.7 | MAC
------------

[ If it really does what it says, it looks like the best MPEG-software ]
[ that you can get. Current is version 2.0.1                           ]


From: Maynard James Handley <maynard@elwing.otago.ac.nz>
Date: Wed, 16 Feb 1994 00:01:24 -0700
Subject: Mac MPEG player


You can download Sparkle from sumex-aim.stanford.edu or any of its mirrors
in info-mac/grf/util, or from any other fine mac ftp site like 
mac.archive.umich.edu. 

I right now have a VERY rough version of Sparkle that handles converting 
QT to MPEG. The MPEG encoding is essentially satisfactory but the user 
interface is largely non-existent. I hope to release it in usable form in 
about two months,


WHAT's NEW FROM VERSION 2.0?


WHAT's NEW FROM VERSION 1.7?
% Works around a bug in the QT VM extension. This should help those people 
  for whom Sparkle 1.7 crashed when a file was opened.
% The progress bar now updates itself better. Looks better in B/W.
% More of the default QT movie player keystrokes now work.
% Notification of extensive errors in an MPEG file.
% Fixed bug that displayed certain files as "slanted".
% Better memory management for ultra-low memory conditions.

WHAT's NEW FROM VERSION 1.6?
% Misc bug fixes and cleanups.
% Way cool progress bar for showing progress on slow machines.
% Opening files is much faster.
% Random access and stepping backwards are both available.
% Saving to QuickTime will now work much better in the background 
  (much less jerky).

See the New in 1.71 file for details.

Now requires QuickTime 1.6. If you don't have it, ftp it from ftp.apple.com.

WHAT IS IT?
Sparkle plays MPEGs and converts them to QuickTime movies. It uses the 
standard QuickTime movie controller as its interface. It is multifinder 
friendly and, with enough memory, will open multiple documents at once.
It is free. I ask only that you read the enclosed README file and if you 
can help with any of the issues I raise there, you mail me.

REQUIRES: 
System 7 or greater.
QuickTime 1.6 or greater.
An 020 based mac or greater.

Maynard Handley
maynard@elwing.otago.ac.nz 
January 18 1994

[ And now some things he currently does ... ]

I don't do any interleaving yet, but I have code for audio and 
interleaving so my next major task will be adding those. But before
I start that, I'll be taking a few weeks to clean up the code I have. 
Parts of the MPEG encoding use up much more memory and are much slower 
than they need to be, so I'll be working my way through the Berkeley code 
changing things.

I don't know how well it'll run under Mac emulation, because it 
requires some pretty low level parts of the Mac system. Will the emulator 
offer System 7, 32 bit color QuickDraw, QuickTime and the Thread Manager?
The old mac emulators for UNIX offered none of these, but the new 
emulators using the Apple supplied services for emulation might do a 
better job.

BTW I have fixed all bugs I know of in 2.0 and afetr two or three days of 
testing 2.01 will release it, so you should refer to 2.01 in the FAQ.

At present I am using the Berkeley 1.2 encoder source. 
I have already made some changes to the way it handles MPEG sizing
(the Berkeley source chopped off the edges and bottoms of movies.) 
Also changes to the way B frames are handled (the Berkeley source would 
sometimes skip frames at the end of a movie.)
Also changes to support threading and object encapsulation.
Byt the basic core is the Berkeley code. What I'll do as time goes by
is successlively alter it to get it smaller (in many ways it uses four times
as much memory as really necessary) and faster. And I'd like to add some 
of the ideas from the Stanford code, in particular the bit-rate 
limiting. The P/B search algorithms are the pure Berkeley ones, but I'll
probably iddle with those as well as soon as I have time.

I keep wanting to post source, but at any given stage large parts of it are
so chaotic I'd be ashamed to do so. Now I mostly have the version 1.x core
source cleaned up, but all the new 2.0 features are a mess.
However you might want to say in the FAQ that I have, in the past, given
the source out to people who want it, on the condition that they accept that
it is work in progress and has very messy parts. Also note that the source
assumes you know
1) the mac OS
2) The Think Class Library
3) QuickTime
4) MPEG 
all very well. If you don't understand any of this, the source won't be much
use to you. (And now that I have based it on threads, it's even more complex!)
(BTW not many people know Macs have threads--- it's not just OS/2)

Good to keep up friendly competition!

Maynard

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

From: Rainer Menes <menes@statistik.tu-muenchen.de>
Subject: Re: LAST REPOST: THE MPEG-FAQ Version 2.0 - Part 2
Date: 	Wed, 6 Oct 1993 13:20:08 +0100

Dear qt2mpeg users,

I like to announce a new version of my qt2mpeg util. This version is a 
beta  version but should be very stable I hope.

The best news about the new version is that it supports Quicktime to MPEG
conversation of any length. The last version, as some of you have 
reported, had a very seriuos bug which crash your mac very badly. Now 
this shouldn't happend any more.

I putted the stuff on my ftp site suniams1.statistik.tu-muenchen.de in the
dir incoming/qt2mpeg.

What will you need? It depends if you are a firsttime user or you are 
using the older version right now.

1. Firsttime user should get qt2mpeg1.1b.sit.bin. This includes all you 
   need to do the qt to MPEG conversation.
   
2. To update your older version get only qt2mpeg_update.sit.bin. This 
   will save bandwidth on internet (Thank you),and replace the old files 
   with the new once.
   
Some fun stuff is also in this dir. To test my new qt2mpeg I made a mpeg 
movie with a realtime length of 1 min. The size is 192x144 with 25 fps.
The movie was produced from some videos I made 1992 in Italy while 
skiing there. The cut was done with Adobe Premiere 3.0 and than converted
with qt2mpeg 1.1b to a mpeg movie. The first scenes show myself and the 
last two show me and Claudia a good friend of mine (Thanks Claudia). Hope 
you find this movie fun to watch. (I will try a second one next year in 
382x288 with 25fps) The file is called SkiRainer.mpg and is about 1.2 
MByte in size. The compression rate is 1:102 and the quality is still 
very good I think.


This is beta version qt2mpeg 1.1!

If you find my utils usefull please send me nice postcard!!!!! You will 
find address below at the end of this readme file.

This is my second beta version of Quicktime to MPEG, so you will find bugs.

Changes from the version 0.1

- The qt2yuv converter now runs even when used on non truecolor screens.
  Sorry for this former bug. I allway run my Quadra in truecolor and never
  tested it in an other mode.
- The MPEG encoder now is version 1.2 and not 1.0 alpha. (mpeg)
- The MacMiNT version is updaten to the lastest status. The background
  feature now work great.
- The old version only runs on a 68040 with FPU so all users without a
  full blow Quadra where not able to run the software. Now you can run
  this software on an 68030 with 68882. Hopefully with softfpu the
  Centris machines with a 68LC040 will be able to run this converter too. 
  Please let me know if not.
- added a new MPEG converter to the software. After alot of pproblems
  I got the mpeg encoder from Berkeley running (mpeg_encode).
- added a new program called qt2yuvBerkeley. This will generate the 
  different yuv files and an other shell script to make conversation
  as easy as possible.

Changes from the version 0.5b

- removed the stanford encoder from the distribution. Only takes space
  and isn't as fast the berkeley encoder. (Also it produces three times
  as mutch files as the berkeley once. For big movies this might get a 
  problem).
- change berekeley encoder to the new version 1.2. It works now with alot 
  better quality. (Now all feature of the UNIX version). Thanks to Larry
  Rowe and his team.
- dropped the qt2yuv program, because it only produces stanford encoder 
  files.

- qt2yuvBerkeley got some bug fixes. Main changes:
  1. For some reasons the display window does show the movie centered.
     This bug is fixed now. All movies should work without problems.
     I also tested it with Adobe Premiere 3.0 which produce multiple
     segment files with differned compressor and it worked.
  2. The bug which cause a unrecoverble crash when reaching the heaplimit 
     is fixed. The converter stops when the heapspace get below 100 KByte. 
 
  3. Added support for YUV conversation of qt movies of any length.
     First the converter will count all frames in the qt movie and inform
     you in its statuswindow about it. Now you have to enter the startframe
     on which the converter starts with it conversation. Next you will be 
     asked if you want continuemode or not. 
     
     Yes = if you convert multiple segment keep the overall startframe 
           in the parameter file allways 0.
     No = The overall startframe is set to the actual startframe!!! Might
          be usefull when converting only a special part of the movie.
     
     y or n is ok to select on of this options!!!
     
     After you have reached the end of the conversation you will be 
     informated how many frames the converter could convert in this 
     session. If you didn't reach the end write down the number of the 
     continue startframe and quit the converter. Now restart it and use the
     same parameters and set the new startframe to the number the last 
     run told you.

- removed sources of the encoder because it took alot of space. All of 
  you with ftp access are able to get the source from toe.cs.berkeley.edu.
       
Software you will need too: You could use either mpeg player 0.3 (no 
suppport for it anymore. Stop because Sarkle is far better and Apple will 
bring MPEG playing support next year for Quicktime) or Sparkle 1.6. If you 
love a good Mac interface Sparkle is the way to go.
  
Because this is a beta version I like to get your feedback. So if you find
something you don't like, problems or what ever, sende me a mail and tell
me about. Thank you.

Here first some short intro to my approche to convert Quicktime movies to
MPEG's. First the Quicktime to YUV converter is a FutureBasic program which
reads in any Quicktime movie and converts it to a three seperate Y,U,V 
files. YUV is color model used in video technics as for example MPEG. This
program should be really mac like to use. Sadly I couldn't make this
program
ran in background. I contacted the developers of FutureBasic, but they
still
don't know why my code wont run in background. I hope I could fix this in
a future version. The YUV to MPEG conversation is handled under MacMiNT,
a multitasking UNIX like development enviroment. I prefer to use MacMiNT 
because the MPEG converter which might run for hours, could run easy in 
background with out modifing the source code. This version of MacMiNT now 
has a stable background feature. I hope you will love MacMiNT as much as 
I do. I have also a version of the MPEG encoder which runs under MPW shell,
but without the background feature. (If you are interested in this code
send mail to me). 

The MPEG converter is based on the Berkeley mpeg 1.2 encoder you will find
on
toe.cs.berkeley.edu. The YUV converter was done by me as said befor in 
FutureBasic to speedup development time alot. As you see this software is 
first approche to help you using MPEG. I hope a friend of mine who has 
writen Sparkle will continue to work on a MPEG encoder integrated into 
Sparkle.

You will find this software on:

suniams1.statistik.tu-muenchen.de:/pub/mac/MPEG/encoder/...
(131.159.64.1)

---------------------------------------------------------------------------
 III.8 | ATARI
--------------

[ Bainstorm is not continuing to develop their MPEG-Player for ]
[ the Atari, really sad :o( Maybe somebody can help them ?     ]


From: laurent@brasil.frmug.fr.net (Laurent Chemla)
Subject: MPEG-FAQ - next version
Date: Fri, 10 Sep 1993 14:39:39 +0000 (GMT)

  Frank,

  Of course you're right. Raphael Lemoine replied quickly, directly online
on Compuserve, and as the author of our MPEG software he's quite disapointed
by the little interest there is about.

  As a commercial entity, Brainstorm is trying to sell his work. But this
kind of work is not an easy thing to sell. A few developpers asked us about
our software, but could'nt pay for it. An easy solution would be to sell it
to Atari Corp directly, and then developpers could get it from Atari at low
price. But Atari licensed Cinepak for this usage, and they aren't interested
in buying our MPEG. So we decided to forget it for a while.

  Our MPEG runs at the same (or so) rate, not depending on the resolution.
It uses some of our 'real time' dithering algorithms on Atari. Added to the
work on the DSP coding, you can see it's a good piece of software Raphael
did. But it's not enough for selling it as a Shareware library, because it
does'nt handle P and B frames nor the sound, and we wont work on it if we
cant expect to be paid for this work. I have personnally written a few news
about this software in the Atari's Usenet conferences, but only got 3 mails
in return, and nothing really exciting.

  Anyway, be sure we will tell you if anything new occurs about that.

Laurent Chemla @ Brainstorm

--
Laurent Chemla : chemla@cnam.cnam.fr or laurent@brasil.frmug.fr.net
Brasil BBS  - +33 1 44 67 08 44 -  Atari France developpers support

---------------------------------------------------------------------------
 III.9 | AMIGA
--------------

[ There are lots of other MPEG-ports for the AMIGA ]

mpeg2_0amiga.lha     gfx/show    50K  40 Berkeley MPEG player 2.0
mpegplay201_bin.lha  gfx/show   147K  43+MPEG player V2.01 executable
mpegplay201_src.lha  gfx/show   170K  43+MPEG player V2.01 sources
mpeg_player122.lha   gfx/show   206K 104+MPEG Player 1.22 (for all Amigas)

---------------------------------------------------------------------------
 III.10 | NEXT
--------------

[ This piece of software is now available in Version 2.5. Its usally ]
[ called MPPLAY.                                                     ]

This is a new release of MPEG_Play.app, a threaded program for displaying multiple MPEG videos with capability for visual cueing ("scrubbing").  Release 3.0 is required to run the application, so it should probably be archived with other 3.0 binaries.

MPEG Play is in the process of evolving from a bare-bones MPEG animation
viewer into a full-fledged NeXT application.  The current version is multi-
threaded and supports the simultaneous loading and playback of multiple
"mini-videos" at different rates as high as 28 frames per second.  There
is a group of "live controls" in the Window Settings panel which can be
manipulated even while the video is playing.  There is also a Transport
panel with tape deck buttons.  Both can be found in the Tools submenu.

MPEG Play will keep track of different settings for each window, reflecting
the current values in the various information panels whenever you select a
new main window.  When playback is complete, a few interesting performance
statistics are shown in the Playback Statistics panel.  This panel, as well
as a File Info Panel, can be found in the Info submenu.

Notes:

You may have to wait some time after opening a new file before it will be
shown.  The MPEG file must be decoded into memory to allow rewind and random
access.  The frames will be counted as they are loaded.

Playback is slightly slower when the Transport panel is visible, simply
because it takes some CPU time to update the frame indicators.  For maximum
speed, close the Transport panel and use the menu options for Stop, Pause,
and Play.

This version is not recommended for NeXT systems without substantial system
RAM and swap space.  I have not personally used this software on anything
other than a NeXTdimension with 88 MB of RAM, but future versions of MPEG
Play will be adjusted for any problems with other systems.

I have updated to version 2.0 of the mpeg_play code from Berkeley.
B&W support is temporarily disabled.

You can reach me as brianw@sounds.wa.com


    Brian Willoughby	Software Design Engineer, BSEE NCSU
NeXTmail welcome here	Sound Consulting: Software Design and Development
BrianW@SoundS.WA.com	Bellevue, WA

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

[ This archive is usally called MPEGNEXT. ]

This is a hack of Version 2.0 of the MPEG decoder from the Berkeley
Plateau Research Group.  (Please read their README.)  Basically, I
replaced all the X-Windows stuff with NeXTstep windows and discarded
all of the dithering stuff.  Don't need it since the NeXT is true color.
This version is specifically optimized for a 16bit color NeXTstation.
I did have to sacrifice some image quality to get the speed up.  I don't
know what its performance is because I use a NeXTdimension.  In fact I
would very much appreciated if some one would mail me the performance of
this decoder.  I am hoping for 6 frames/second.  The NeXTdimension gets
5.5 frames/second.

To get other MPEG movies please read the notes from the Berkeley
Plateau Research Group.

gary@isr.recruit.co.jp
Media Design Center
Recruit Co.
Tokyo, JAPAN


===========================================================================
 IV | MPEG-RELATED HARDWARE
===========================

[ We even have MPEG-AUDIO-solutions now, but still not a lot of ]
[ information about them :o( who knows more ?                   ]

From: popp@iis.fhg.de (Harald Popp)
Subject: MPEG audio Layer-3 at AES Amsterdam
Date: Wed, 16 Feb 1994 11:12:33

MPEG- Audio Layer-3: Best Music Quality at Lowest Bitrates!

Audio Export: PC board with realtime Layer-3 audio codec
Philips PKI: MAGIC codec for telecommunication networks
Telos Systems: ZEPHYR codec for ISDN, Switch 56 and other networks
Dialog 4: MUSICTAXI TYPE 3 for telecommunication networks and various PC 
          solutions
Fraunhofer-IIS: Objective Quality Assessment with the NMR meter 
                (Noise-to-Mask Ratio)

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

[ The first real MPEG-cards arrived ! ]

From: jmm73@frmug.fr.mugnet.org (Jean-Michel Mercier)
Subject: Info for the MPEG FAQ
Date: Tue, 22 Jun 93 22:07:34 MET DST

VITEC VIDEO-MAKER
=================

Since December 92, there is a french MPEG PC-plugin. It's called
VIDEO MAKER and it's manufactured by :
 VITEC
 3 bis rue P. Baudry
 92140 CLAMART
 FRANCE
 tel (33) 1.46.29.03.00
 fax (33) 1.46.29.03.04

Features :
Claims to be the world 1st MPEG board.
2 selectable video inputs NTSC/PAL/SECAM/S-VHS
Picture up to 768x576 (by step of 16)
Colors  : 256/32K/16M
Frame : 1 to 25 Fr/s
No need for VESA Features connector
16 bit short card, no dip nor jumper, no DMA nor IRQ
Windows software :
IMAGER : record & compress moving or still picts.
MPEG PLAYER : full software MPEG decoder/player, doesn't need the board
(it seems that you can freely give this soft with your MPEG seqs.)
MULTIMEDIA MANAGER VM : well known software from Multimedia Telecom to
build your scripts with icons, sync. with sounds, etc...
DLL for MCI & AVI availables

What it's not said in the commercial :
The card doesn't sample sound today but a daughter board should become
available (you can still sample sound separ and the resync with M. MANAGER)
You can't use the full specs at the same time (ie 768x576, 16M colors,
25 fr/s) even with a 486 as the compression is made by software
In fact, the sequence is 1st stored in memory using a proprietary
compression scheme and saved to disk as .VSF files. Then the offline
compression could be achived. It seems that a PC with 8Mbytes of RAM
should be able to record about 10 to 30 secondes of video.

What's on the board :
The board use Philips Digital Desktop video chipset (TDA8708+TDA8709+
SAA7191+SAA7197) witch provides 4:2:2 YUV video @ 14.75 Msmp/s
It doesn't use the SAA7192 color space converter to get RVB so this
should be done by software.
There is also an XC3042-100 FPLA from Xilinx and 1Mx8bits of dynamic
ram (70ns). Probably used for pre-compression.

The public price is 3500FF ($625) but Surcouf (Paris' computer store)
sells it about 2300FF ($410).
There was an ad in march issue of BYTE (p127) @ $695. For US & canada
the ad said to phone to 404-921-6167 or fax to 404-921-9243.

There is an test of this card (9 other ones) in june issue of the french
magazine "Multimedia Solutions".


     NOTE : I have nothing to do with VITEC. This is not an ad. It is
     my personnal understanding of VITEC's ads, magazines reports and
     phone calls to VITEC. Please contact VITEC for any contractual
     informations.


MPEG CHIPS
==========

Some new chips are about to be available from SGS-Thomson :
STI3223 : motion estimator controller, intended to be used with
previously released STI3220
STI3230 : MPEG coder
STI3400 : MPEG coder (STI3240 coder + DCT processor)
STI3500 : MPEG 2 coder
Do you want me to get some more details fast ?

TI introduce the TMS320AV110 MPEG audio decoder based on TI's 16 bits
DSPs (about $14).

Some other boards
=================

OPTIBASE's MPEG2000 (Herzliya - Israel, Canoga Park - Calif.)
It use an CCUBE (witch?), DSP56001 ant DCT chips from LSI.

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

[ And there it is, just real magic ;o) ]

ReelMagic MPEG-Video-decoder-card from Sigma Design

Video-Decoder-Specification
- MPEG-Video-Standard ISO 11172-Paris
- 32.768 colors
- Resolution 1024x768
- 30 frames/s
- Video Overlay

Audio-Specification
- MPEG-Audio Level I/II
- 8/16-bit PCM, 44 kHz sampling-rate
- Synthesizer Yamaha OPL2 compliant
- Audio Mixer PCM with FM or MPEG
- Frequence 20 Hz - 20 kHz
- Audio-Out Stereo-Headphone
            2x75mW with 32 Ohm
            2 V rms with 100 Ohm

System-Specification
- Standard ISA PBM PC 16 bit card
- VESA compliant Feature Connector 15 Pin
- DMA and IRQ-selection via Software (no Jumpers)
- SCSI-I, CD-ROM-driver (MSCDEX 2.2)
- Driver for Windows 3.1 and DOS 5.0 and higher
- Support of Windows OLE 2.0
- MPEG-compatible with VideoCD (CD-I coded movies !!!)
- Audio-compatible with DOS games and MPC sound standard


Price at Cebit'94:
- Reel Magic Lite (just the card) DM 679.-
- Real Magic with SCSI-interface  DM 899.-
- Real Magic Kit with Sony CD-ROM DM 1299.-

Contact:

SIGMA Designs, Inc.
Leopoldstrasse 28a/II
80802 Muenchen/GERMANY
Fon: ++49 89 336443
Fax: ++49 89 335967

or

SIGMA DESIGNS, Inc.
47900 Bayside Parkway
Fremont, CA 94538 USA
Fon: (510) 770-0100
Fax: (510) 770-2640
COMPUSERVE: GO DTPVEN
Sigma BBS: (510) 770-0111 (9600-8-1-N)

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

[ Do you want to watch Cinama-Movies on your PC's ? I do ... ]

From: Yasser.El.Chemaytilly@aedi.insa-lyon.fr (Yasser.El.Chemaytilly)
Subject: Re: CD-i, and the MPEG format
Date: 4 Mar 1994 16:00:03 GMT
Organization: INSA Lyon - Computer Science Dept / France

 At this time, there are 3 ways of playing a Video-CD-I:

 - the Phillips CD-i with the Full Motion Video Card (approx $950 in Europe)
 - the Amiga CD^32 with its Full Motion Video Card (approx $670 in Europe) 
 - a PC, 486 DX or DX2 with the Reel Magic MPEG card and a Sony 
		  CD-ROM player (for the moment, it only works with the Sony
		  player) (the card costs approx $650 in Europe without 
			   CD-ROM player)

  The quality of the playback is identical and very good with either the CD-i or
   the CD^32 (same manufacturer) but is a little bit lossy with the PC card.

   Anyway, the Reel Magic card is practically as expensive as a full
   CD^32 system, CD-i (+FMV cartidge) being only a little more expensive. 

   There may be software for playing Video-CDs on PCs, but I haven't heard 
   of them yet.

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

[ Well and there's the XingIt!-card now, I try and translate the ]
[ German description.                                           ]

Features:

- realtime MPEG-Video-card for 386/486 and Pentium
- Framegrabber for Xing-Format I-frame only movies from
  Video-In in 24-bit/pixel QSIF resolution
- PAL/SECAM and NTSC
- Xing-MPEG-to-real-MPEG compression software
- different playing modes up to 320x240/30frames
- selectable Refreshrate
- Windows-Applications, incl. Window for Windows MCI and Media Player

Price: DM 1499.- (so about $900)

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

[ Ha, a game-console with MPEG-support, a bit crazy, but the best things ]
[ get pushed by nig-nag <grin>                                           ]

From: George Sanderson <G.Sanderson@ais.gu.edu.au>
Date: Thu, 3 Feb 94 12:28:31 +1000
Subject: Re: THE MPEG-FAQ [Version 3.0]

You may want to add to your MPEG FAQ that the Amiga CD32 game console is
able to play both standard MPEG VideoCDs and the CD-I specific VideoCDs,
with the addition of the MPEG card which is available now.

As far as I know, the recommended retail price just for the CD32 in the USA
is US$399 but it is selling below that now (US$376).  In Australia, it is
selling for AUS$594.  It has been released in Europe in late 1993 and
is selling very well (120,000+ units sold as of Jan'94).  The major release
date for the US market is sometime in March.  There are at least
20 CD32 specific titles available (and it can play CDTV titles as well)
and over 100 CD32 titles will be released in 1994.  The price of the MPEG
module is (guessing) US$299.  Commodore is selling the units directly
to wholesalers.

here is some info about the Amiga CD32 (made by Commodore) with
info about its MPEG module mixed in (i'll mail you more info about
the MPEG module when I get it):

                     AmigaCD32         

       CPU/Speed: 68EC020 @ 14MHz
    Architecture: 32 bit
      Throughput: 3.5 MIPS      
        Chip RAM: 2 Megs of DRAM
        Fast RAM: None
Non-Volatile RAM: 1 KB

    Custom Chips: I/O ports, Audio and Interrupt controller,
                  DMA Controller, Video data controller (AGA chipset)
                  CD-ROM controller

  Animation CELS: 8 Sprites per scanline (64-bit)
                  & Unlimited Bobs (blitter objects)

     Video Modes: can display upto 1280 x 512 in 15 kHz
         Colours: 256,000/16.7 Million   

           Sound: Stereo 8 bit         
                  Stereo 18 bit CD-DA  
                  DSP planned          

          CD-ROM: Double Speed         
                  Top Loading          
Software Video
          Player: Partial Screen using 4096 Colours (CDXL)

            MPEG: Available now (see below)
         PhotoCD: Available as third party software

 Game Controller: 11 Buttons           

Supported CD Standards
----------------------
AMIGA CD32
Audio CD
CD+G (Graphics)
Most CDTV including CDXL
VideoCD (MPEG1) - see below

Connectors + Switches
---------------------
2 x Games Controller/Joystick/Mouse ports
High Speed auxiliary connector for keyboard and virtual reality gloves, etc.
Local slot expansion connector
Power Switch and Indicator LED
Reset Switch (momentary)
Headphone jack and Volume slider


MPEG Module (optional)
----------------------
Full screen, Full Motion Video and Stereo Audio replay direct from disc;
total running time 74 minutes
352 x 288 at 25 Frames per Second (PAL mode - different for NTSC)
Able to play most CD-I MPEG specific titles (they demonstrated that
at the World of Commodore shows playing Star Trek 6, Top Gun, etc.)

The Amiga CD32 hardware is able to genlock its graphics and sound on top of
the MPEG output.  Additionally, while the MPEG module is playing, the CD32
has about 80% of CPU left to use - this could mean some interesting games
with video backdrops.

The MPEG module comes with a MPEG disk that has a few rock video clips.

Audio Output
------------
2 channel, 4 voice stereo using 8 bit digital/analogue converters
18 bit audio CD stereo at 44kHz

Video Outputs
-------------
S-Video, Composite and RF (UHF) for TV

Included
--------
11 Button Game Controller
"Welcome" Disc
Consumer Information Manual
CD32 Users Guide
RF video and Stereo audio cables
+ usually packed with 2 games

Physical
--------
212 mm x 311 mm x 81 mm
CPU 1.44 kg
Power Supply 1.53 kg

Warranty
--------
1 Year, return to regional service centre

Power Supply
------------
External, 22 Watts

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

Please refer here to the section in the MPEG-FAQ Version 1.1,
because I did not get a lot of new infos. There is a big list
of MPEG-related chips, including vendor adresses.


===========================================================================
 V | MAILBOX-ACCESS
===================

---------------------------------------------------------------------------
 V.1 |
------

GENOA has right now a new BBS in Germany (Stefan Hartmann will put new
MPEG-software there too), phone:

  ++ 49 211 686756    (16.8Kb/sec with US Robotics Dual Standard)

---------------------------------------------------------------------------
 V.2 |
------

This is the phone number of Xing Technologies' BBS:

  805-473-2680 (2400b) (USA)

Bryan Woodworth <bryanw@rahul.net> wrote:

Would you also please add, that the Xing BBS now supports v.32bis and HST !
I am not sure on HST, but I am sure it supports v.32bis.  However, I have a
v.32bis modem, and could only connect at 9600. I think they do not have the
modem configured properly.


===========================================================================
 VI.1 |  FTP-ACCESS (PD)
========================

Please contact these ftp-sites for files before e-mailing to me !!!

Site: busop.cit.wayne.edu
Dir : /sys/pub/simpsons/incoming/mpeg
      /sys/pub/simpsons/incoming/mpeg1

Site: amiga.physik.unizh.ch [130.60.80.80]
Dir : pub/aminet/

Site: ftp.cica.indiana.edu [129.79.20.17]

Site: ftp.cs.tu-berlin.de [130.149.17.7] or
      quepasa.cs.tu-berlin.de
Dir : /pub/msdos/incoming, /pub/msdos/dos/graphics,
      /pub/msdos/windows3/graphics
      /pub/aminet/

Site: ftp.germany.eu.net [192.76.144.75]

Site: ftp.luth.se
Dir : /pub/graphics/animation/mpeg
 
Site: ftp.rahul.net [192.160.13.1]
Dir : /pub/bryanw/pc/mpeg

Site: ftp.uni-erlangen.de [131.188.1.43]
Dir : pub/aminet/

Site: ftp.uni-kl.de [131.246.9.95]
Dir : pub/aminet/

Site: ftp.wustl.edu [128.252.135.4]

Site: isfs.kuis.kyoto-u.ac.jp

Site: litamiga.epfl.ch [128.178.151.32]
Dir : pub/aminet/

END ---------------------- CUT HERE --------------------- 5/6



Archive-name: mpeg-faq/part6
Last-modified: 1994/08/22
Version: v 3.2 94/08/22
Posting-Frequency: bimonthly


BEGIN -------------------- CUT HERE --------------------- 6/6
Site: merlin.etsu.edu [192.43.199.20]

Site: mm-ftp.cs.berkeley.edu [128.32.149.157]
Dir : /pub/multimedia/mpeg

Site: nic.funet.fi [128.214.6.100]

Site: oak.oakland.edu

Site: phoenix.oulu.fi [130.231.240.17]

Site: pinus.slu.se (130.238.98.11)
Dir : /pub/graphics/mpeg
 
Site: sumex-aim.stanford.edu
Dir : /info-mac/app

Site: suniams1.statistik.tu-muenchen.de [131.159.64.1]
Dir : /pub/mac/MPEG/encoder/...

Site: sunsite.unc.edu
Dir : pub/electronic-publications/IUMA

Site: wuarchive.wustl.edu [128.252.135.4]


---------------------------------------------------------------------------
 VI.2 |
-------

Bryan Woodworth <bryanw@rahul.net> invites you to the ftp-server:

    ftp.rahul.net (192.160.13.1) in /pub/bryanw/pc/mpeg

Login as "anonymous," any time of the day or night.

[ Several MPEG-Information is located in the directory /pub/bryanw   ]
ear Bryan was the first one, that downloaded the brand new mpeg-player ]
[ from Xing's BBS and posted it to a.b.p.u, thnx to Bryan !          ]

He wrote:

If the people have problems connecting, they should send a capture of the
session to "support@rahul.net," so that the problem can be corrected.

and wrote:
 
If people want to know where they can find the Microsoft Windows MPEG 
player(s), DOS players, Amiga players, X Windows, VMS, and 
Macintosh players, they could cd to:
 
/pub/bryanw/information
 
and retrieve:
 
WHERE.TO.GET.MPEG.PLAYERS
 
This file is posted biweekly to alt.binaries.pictures.*

The information subdirectory also contains an ABPE faq, this MPEG 
faq :-), JPEG information, information on X-windows on PCs, and I
suppose that is all.. If I ever find good stuff, I put it here.


---------------------------------------------------------------------------
 VI.3 | ACCESSING AMINET
------------------------
 
There are many other ways than FTP to access AmiNet:
 
- ADT. This is a front end for FTP that allows easy access to AmiNet.
  Get it from comm/misc/ and compile it on your UNIX box.
- FSP. AmiNet Files can be downloaded from the FSP site disun3.epfl.ch
  port 9999. Uploads are accepted and forwarded.
- NFS. The only AmiNet site that allows NFS mounting of the archives is
  wuarchive.wust.edu. FTP there and read the details in the /README.NFS
- IRC. On Internet Relay Chat, you can talk to various server robots
  like AmiBot, MerBot or Mama, to do queries and retrievals.
- Gopher. There is a gopher server for AmiNet at merlin.etsu.edu. To
  connect, use the command 'gopher merlin.etsu.edu'.
- Modem. In Germany, you can download the AmiNet files from the Incubus
  BBS, telephone number 0931 781464. The login is 'ftp', password 'ftp'.
- Usenet. A list of recent uploads is posted every week to the newsgroups
  comp.sys.amiga.misc and de.comp.sys.amiga.misc. Useful for mail servers.
- Mailserver. Sorry, no specialized e-mail server for AmiNet yet. But you
  can use ftpmail@decwrl.dec.com. Send a mail with HELP in the body.
- CD-ROM. AmiNet is available on CD-ROM. Talk to info@cdrom.com, or write
  to Walnut Creek CDROM, 1547 Palos Verdes Mall, Walnut Creek CA 94596, USA
  or phone 1 800 786 9907, +1 510 674 0783 or +1 510 674 0821 (FAX)
 

===========================================================================
 VII |  MAIL-ORDER
==================

---------------------------------------------------------------------------
 VII.1 | TRAIL-PACK
-------------------


        ====================================================
        THE MPEG-TRAILPACK-CD   Fri Jul  8 01:44:55 EDT 1994
        ====================================================
        PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY
        Inh. Frank Gadegast          Fon/Fax: +49 30 3128103

        phade@contrib.de


== INFO ===================================================================

You can purchase a complete archive named the "TRAILPACK-CD" including the
FAQ and all named programs, source-code, movies and information-files.
Just everything about MPEG-I and now even MPEG-II.

This "TRAILPACK-CD" is still sold on streamer-tapes, but NOW it's
available as ISO-9660 conform CD-Rom ! Readable on DOS, Windows,
Windows-NT, OS/2, Ultrix, SunOS, Solaris, Linux, Mac's ....

This archive includes (in addition to the ftp-access) all versions of the
programs and source-code, additional movies (including the audio-files)
and lots of additional informations.

Additional to any ftp-servers it contains special things, you can't find
anywhere but here. Like a DOS-port of the Berkeley-Encoder, other DOS-ports,
a security-filter for MPEG-I-stream called secmpeg, some selfmade movies.

The whole archive itself is organized as one big hypertext-document.
It includes a complete Wide-World-Webster (WWW) document, the tools to
use this document on Windows/Windows-NT-machines are included, most
UNIX-hosts can include the "TRAILPACK-CD" into their hyptertext-
services with a single link !!!


           THE HOST THE ARCHIVE IS ON IS NOT ON THE INTERNET !
                                         ===

Today the "TRAILPACK-CD" contains at least the following sections:

      9,115,890 G:\AUDIO
      5,615,273 G:\CDHELP
      1,519,167 G:\DEMO\PCHDEMO
      2,164,203 G:\DEMO
     11,672,774 G:\DOC
      2,409,841 G:\FAQ
    151,715,898 G:\IUMA
    129,613,395 G:\MOVIES
     10,299,484 G:\MPEG1
        250,441 G:\MPEG2
      8,610,993 G:\NVR
        581,273 G:\PHADESW
     53,380,969 G:\UTIL
     41,715,267 G:\VIDEOS
      2,454,664 G:\WWW
Total = 430,843,247 bytes

Please be sure, to get always the most-up-to-date description
of the Trail-Pack before requesting it ! Mail to phade@contrib.de
or find the MPEGFAQ (current Version 3.1). Look at the date of
this info file, something older than 3 month cant be up-to-date !

To obtain the "TRAILPACK-CD" fill the ORDER.FRM below and send it
(from overseas via air-mail !), with the big-written keyword
"TRAILPACK-CD" on the envelope to:

      PHADE SOFTWARE
      Inh. Frank Gadegast

      Leibnizstr. 30
      10625 Berlin 

      G E R M A N Y

====================== cut here  cut here  cut here =======================

      ORDER-FORM for TRAILPACK-CD [Version 1.0]
      =========================================
             Fri Jul  8 01:44:55 EDT 1994

Please fill this form carefully to order the TRAILPACK-
CD-Rom Version 1.0. Then send it via letter to:

  PHADE Software
  Inh. Frank Gadegast

  Leibnizstr. 30
  10625 Berlin
  GERMANY

and put the money in the envelope, too. Please only send
GERMAN MONEY (DM), no checks, no post-depostits, no coins !!!

The price of the TRAILPACK-CD-Rom is DM 120.- plus

  o  DM 20 for shipping inside Germany and Europe
  o  DM 30 for shipping outside Europe.

If you order several CD-Rom's, you only have to add the
shipping fee ones !

Thats what you will have to change at your bank and to put
in the envelope (get somebody that watched you putting the
money in or insure the letter via post or do a moneyletter
or whatever to be sure, the money is not getting lost).

Exchange rate today is: 1 $ = 1.60 DM

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

Name         : _____________________________________
First Name   : _____________________________________
Title        : _____________________________________
Company      : _____________________________________

Adress       : _____________________________________
Town         : _____________________________________
Post code    : _____________________________________
Country      : _____________________________________

Fon          : _____________________________________
Fax          : _____________________________________
E-mail       : _____________________________________

Enter here the number of CD-Rom's you want (defaults
to 1):

(  ) number of CD-Rom's

I received information about the TRAILPACK-CD from:

( ) the Usenet
( ) Compuserve
( ) a Ftp-site, host-name : __________________________
( ) a Mail-Box, name      : __________________________
                Fon       : __________________________
( ) a friend
( ) a college

I intend to use the TRAILPACK-CD for commercial purpose
with the following description:

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

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

AGREEMENT: By signing this paragraph you agree, that you will not copy
           the complete TRAILPACK-CD or bigger parts of it to more
           than ONE computer nor publish it or bigger parts of it to
           any network or other public service, mailbox or other storage
           medias, like floppy-disk, CD's, MO-disks or tapes for
           redistributing purpose.

           You agree, that if you use the TRAILPACK-CD for commercial
           or any public use, the archives or a copy of the CD-Rom will
           remain complete, including all Copyright- and Readme-notices
           and if you make this CD-Rom available to the public, that ALL
           files will be accessable by the public.

           The use of single files or small parts to whatever purpose
           is hereby granted. The commercial use of this package is only
           allowed, if the kind of commercial use is reported to PHADE
           Software.

           This agreement does not touch any other regulations by the
           authors of the programs in this archive.


           =============       ======================================
             (date)                     ^-- sign here

====================== cut here  cut here  cut here =======================


---------------------------------------------------------------------------
 VII.2 | CONVERSION
-------------------

PHADE Software is offering a video-conversion-service !

A conversion of 1 MB video (GL,DL,MPEG,AVI,DIB-seq, e.g.)
to one or the other format cost currently 30DM (20$).
Over 10 MB gets then really cheap only 15DM (10$).
Audio conversion is possible too (AVI, WAV, AU) and costs
the half of the video-price (but is included if there is
a video-conversion).

Please send any jobs or commercial mail to

    'phade@contrib.de'


---------------------------------------------------------------------------
 VII.3 | FTP-MAIL
-----------------

FTPMAIL, obtaining files from a server via email which does the ftping for
you, is not the best way to obtain files via ftp, but for some it is the
only way.  To get more information, send email to one of the servers below
with the word HELP in the message body.

In North America:   Internet:  ftpmail@decwrl.dec.com
                    BITNET  :  bitftp@pucc.princeton.edu or BITFTP@PUCC

In Europe:  ftpmail@grasp.insa-lyon.fr


===========================================================================
 VIII |  RETRIEVED MAIL
=======================

[ About what Xing is messing up again ... ]

Date: Mon, 3 Jan 1994 12:20:33 -0800 (PST)
From: Jared V Boone <jboone@patriot.wtfd.orst.edu>
Subject: Re: MPEG decoder...

Unfortunately, my program DOES NOT decode in real time.  But then, Xing's
program cheats.  It does not decode the entire file, but plays the lower
half of the subbands and only one channel of a stereo pair.  My program
will decode the whole thing, but there's a price to be paid.  Decoding
'together.mp2' takes approximately 797 seconds on a Intel 486DX2-66
Windows NT/Visual C++ PC, and 1152 seconds on a Intel 486DX2-66 NetBSD/GCC
V2.4 UNIX system.  So I guess that's about 3-5 times slower than necessary
for real-time playback.  I've got some tricks I want to try, but they'll
involve a lot of code modification.  I also don't think they'll make THAT
much difference.  We may be asking these processors to do more than they can.

I'll keep you posted...

Jared Boone (jboone@patriot.wtfd.orst.edu)

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

[ As of 1/1/94, a little bird told me... ]

Aware Inc. is considering making demo versions of their high quality MPEG
audio players/converters for Macs and SGIs available on the IUMA.

-IUMA staff

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

[ And another little bird... ]

From: mwilliam@envy.Reed.Edu (Son of Sam)
Subject: Quicktime WITH MPEG
Date: 24 Mar 1994 09:07:39 GMT

I read a press release for Quicktime 2.3 (due to developers this month :)  
and Apple claims that with this new version of their extension one can
get 15 fps at 640 x 480 on an LC 475! and Full motion (30 fps) at the next  
screen size down.... 

	That's decent for a low horsepower machine.  Whether or not this  
proves itself in practice, we'll see...

	But the real point of this post revolves around apple's  
announcement that QT2.3 incorporates MPEG technology... That's right, now,  
instead of needing to convert MPEG to QT, Macs will be MPEG savvy.  It  
also mentions that you'll be able to encode MPEG's (with sound) with your  
Mac...

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

[ And here the biggest bird, gulp ... ]

From: cfogg@netcom.com (Chad Fogg)
Date: Wed, 20 Apr 1994 18:05:04 -0700
Message-Id: <199404210105.SAA14372@mail.netcom.com>
Subject: Re:  MPEGFAQ31: call for papers

The MPEG Software Simulation Group, a development effort comprised 
of MPEG committee participants, will soon release both an encoder 
and decoder for MPEG-1 and MPEG-2 video.  Principle contributors 
of the MPEG-2 S/W are: Stefan Eckart (Univ. Munich), Chad Fogg (Xenon
Microsystems), and Cheung Auyeung (Motorola). Systems software will be 
included at a later date.  

Also, the Committee Draft of ISO/IEC 11172-5 (Part 5) containing 
software of MPEG-1 Systems, Video, and Audio will be presented
in May 1994.

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

From: optimg!james@uunet.UU.NET (James W. Shoemaker)

[ He, that's Optibase' e-mail adress ! ]

Date: Mon, 22 Nov 93 09:59:37 CST
Subject: Re: MPEG realtime Encoder card shippin

We have a Real-Time full SIF MPEG encoding board from Optivision.
The board can only do I and P frames now, but B frames will be supplied
once new Microcode is available from C-Cube.

How much is the Encoder board ? Probably very expensive.. ?

The streams from this board have a few artifacts, but over-all look
quite good.

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

From: "Cave Newt" <roe2@midway.uchicago.edu>
Date: Sat, 15 May 93 23:15:51 CDT
Subject: Re: THE MPEG-FAQ - Version 2.0 - Part [2/3]

>mpegplay.zip      97028  Full-screen 320x200 MPEG animation player
>in pub/os2/2.x/graphics.
>
>[ Would be nice, if somebody could test this, and post some results. ]

I did so; I've never seen/used any other MPEG viewer, however, so
I have nothing with which to compare it.  Nevertheless...

On a 25MHz 386 running OS/2 2.0 GA+SP, and an ATI GUP with the 
16-bit (slow) beta drivers, it displays roughly two frames per 
second in default mode on an actual movie posted to a.b.p.misc
("fan_bulb.mpg").  On the index20.mpg, it managed two to three
frames per second; processing the whole file took exactly 15
seconds, of which about 2 seconds was initialization (before
any display).  The "-dither gray" option speeds things up by
perhaps 50%.

It's a port of "the Unix MPEG player," by which I assume the author
is referring to the Berkeley software-only decoder.  It gets the
job done, I guess...I have yet to try any of the "standard" mpegs
in the Berkeley collection.

Greg Roelofs

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

From: Morten Hjerde <100034.663@compuserve.com>
Date: 17 Sep 93 13:08:21 EDT
Subject: Re: MPEG-FAQ Audio-part ?

The people I know is working on MPEG is Philips/Compression Labs for their
"digital video" CD-I's. Digigram in France is producing some nice MPEG cards
for the PC. You would want to avoid their older PCX3 cards because their
MPEG implementation were a little odd. Their new PCX5 and PCX3 should be
fine. Cardinal are introducing an MPEG driver for their new PC card. The driver
has not been released. It's developed by Xing. I've played around with
earlier Xing MPEG Audio stuff and it looked and sounded nice. C-Cube also
have written an MPEG codec (for the AD2015 I believe). I don't know if they
are doing anything with it. For broadcast
industry use there are several others, also a couple of German vendors that
makes stand-alone units. I don't have their names here. Here in Norway Tandberg
are making a logger w. MPEG compression.
(I have no connection to any of the above)
 
Source code? I was hoping you could tell me that <g>.
 
---------------------------------------------------------------------------

From: kothary@mprgate.mpr.ca
Subject: Optibase
Date: Wed, 06 Oct 93 16:12:22 PDT

I recently bought the Optibase PCMotion Player.  This is the real 
time MPEG 1 decompressor.  I have only tested it with a couple of 
clips so far but it seems to work very well.  The decoded picture is 
the best I have seen so far.  There are very few artifacts. The two 
clips I have tested to date are tigers.mps ( a system level stream 
they included with the board) and starwars.mpg (an older video level 
clip I had sitting around.) The tigers clip was very good while the 
Star Wars was not nearly as good.  I don't know if this reflects 
advances in encoder technology or that Optibase does some funny 
stuff with their files.  

The board was very easy to install and ran pretty much the first 
time.  The only problems I had with the company are that they are 
very difficult to contact and seem to be understaffed.  I constantly 
hear the excuse that Mr X has not been able to contact me because he 
is very busy since he is on N different projects.  Also they seem to 
be a funny company in that their employees seem to continually shift 
between their Isreal and two US offices.  As you can imagine, it is 
very difficult to contact people who constantly change continents!

The other big problem with the board is that it can only take data 
in through the ISA bus.  It is not clear how to use this sort of 
card in a network unless one is willing to dedicate the entire PC to 
just one application.  The bus on my PC seems quite full when I use 
this card.  I think using either a T1, MVIP, SCSI, etc interface 
might make a more usuable card.  

Overall, for the kind of money they want, it seems to be a 
worthwhile board except the utility is limited to evaluation of MPEG 
and some composing rather than watching actual movies since 
networking is weak.


===========================================================================
 IX | ADDITIONAL INFORMATION
============================

[ Well, there are lots of MPEG-related papers at Berkeley's ftp-server. ]

From: Larry Rowe <larry@plateau.cs.Berkeley.EDU>
Subject: mpeg to ppm
Date: Thu, 24 Mar 1994 17:39:36 -0800

o papers/94MMComputing.ps.Z - copies of slides from a highlight talk at
  the UC Berkeley Industrial Liason Program on multimedia computing.  Main
  topics: importance of mosaic/www, video-on-demand architectures and problems,
  and desktop video conferencing.

o papers/CMMPEG-SPIE94.ps.Z - A paper describing the heuristics we used
  to implement synchronized mpeg video and sparc audio playback in the
  CMPlayer system.

o papers/VodsArch-SPIE94.ps.Z - A paper describing the architecture of the
  the Berkeley Distributed VOD System that is designed to store thousands
  of hours of video material on tertiary storage devices that can be staged
  to video file servers.

o papers/VodsDB-SPIE94.ps.Z - A paper that describes the metadata database
  in the Berkeley Distributed VOD System.  The database contains a variety
  of indexes to the video material which a user can query to locate material
  of interest.

o papers/VideoCompression-Usenix94.*.ps.Z - Copies of slides from an invited
  talk on Video Compression given at Usenix '94 by L. Rowe.  The BW file has
  a black and white version of the slides with 2 to a page, and the Color file
  a color version with 1 slide to a page.

o papers/dv-at-ucb.txt -- A survey of digital video research in the EECS
  Department at U.C. Berkeley.  This article will appear in the 1994 EECS/ERL
  Research Summary.

o papers/compressed.ps.Z

o papers/VodsProp93.ps.Z - a revised version of the Berkeley VOD Server
  proposal first released on August 20, 1993.

o papers/VODProp-Rowe.ps.Z -- a rough draft of a proposal to be submitted
  to NSF to build a video-on-demand system.  Novel feature of the system
  is that it includes a large tertiary storage archive and a metadata
  database with an ad hoc query browser to search for particular videos.
  The archive server talks to several video file servers so that an
  organization can share file servers.

o papers/MM93Talk.ps.Z is a copy of the slides used for the talk at the ACM
  Multimedia 93 conference for the previous paper. The performance
  numbers comparing the mpeg player on different platforms were updated 
  the week before the conference so they reflect the most recent results.

o papers/{Mpeg94.txt,VODarch94.txt,VODdb94.txt} -- abstracts submitted
  to SPIE '94 that describe recent work on integrating our mpeg video 
  decoder into the CMPlayer and the design of the UCB video-on-demand system.

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

From: gandhi@trix18.genie.uottawa.ca (rakeshkumar gandhi )
Date: Tue, 24 Nov 92 13:14:03 -0500
Subject: IEEE

There is MPEG Hardware review in IEEE computer graphics and application
magazine.

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

From: Chad Fogg <cfogg@ole.cdac.com>
Date: Mon, 4 Oct 1993 02:02:58 -0700
Subject: Re: MPEG-2 FAQ -- first installment (draft)

Q. Is there a book on MPEG compression?
A. Yes, there will be a book published in Spring 1994 by the same
   authors who wrote the JPEG book (Bill Pennebaker, Joan Mitchell)
   with Didier Le Gall as an additional co-author.

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

[ Only for Germans... ]

Ihr koennt den MPEG-draft-I beim Beuth Verlag bekommem.


===========================================================================
 X | WHERE TO FIND MORE INFOS
=============================

Well, first you can check the related news-groups:

  comp.graphics, comp.graphics.animation, comp.compression, comp.multimedia,
  comp.sys.amiga.multimedia, comp.mail.multi-media,
  alt.binaries.pictures.utilities

The first part of this FAQ about MPEG came from Mark Adler, published in
in FAQ for the newsgroup 'comp.compression'.

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

Then you can ask 'archie' to find all NEW mpeg-releated software
by sending the following mail (with no title):

  set search sub
  prog mpeg mpg
  quit

to one of the following archie-mail-servers:

  archie@archie.ans.net
  archie@archie.rutgers.edu
  archie@archie.sura.net
  archie@archie.mcgill.ca
  archie@archie.funet.fi
  archie@archie.au
  archie@archie.doc.ic.ac.uk


Or look for it with archie on the Internet like this:

telnet 128.214.6.102
archie
set search sub
prog mpeg mpg

quit

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

Then you could look for a newer version of the first part of this FAQ via
ftp at:

    garbo.uwasa.fi (128.214.87.1), in /pub/doc-net

    The current version is named FAQC9301.ZIP

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

Then get the newest version of this document

File: WHERE.TO.GET.MPEG.PLAYERS
Site: ftp.rahul.net [192.160.13.1]
Dir : /pub/bryanw/pc/mpeg
 
This file is posted biweekly to alt.binaries.pictures.*

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

[ Then you can order information from C-CUBE ]

Subject: Announcing C-Cube product information request via E-Mail

All requests for general C-Cube product literature should be forwarded to:

    literature@c-cube.com

Requests for specific JPEG or MPEG product information should be forwarded to:

    jpeg@c-cube.com
    mpeg@c-cube.com

Please include your complete name, address, phone and fax numbers in your
request. Thank you. C-Cube Microsystems

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

[ For audio-related stuff look into the IUMA archive. ]

.___ ____ ___ _____    _____   
|   |    |   \     \  /  _  \       the net's first hi-fi music archive
|   |    |   /  Y   \/  /_\  \     .:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
|   |    |  /   |    \   |    \    The Internet Underground Music Archive 
|___|______/____|__  /___|__  /      bands/music/labels/images/bubbles
===================\/=======\/============================================
                         How to Use IUMA
Last edited 2/2/94

Here are a few pointers about how to make the most efficient use of
IUMA and the music on it. You may also wish to peruse the
Frequent Asked Questions (FAQ), although it's currently undergoing a 
complete revision. 8)

The first and most important thing to note is that IUMA is best explored 
and used via World-Wide Web (WWW) clients such as Lynx and NCSA Mosaic. 
The WWW is a hypertext-based method of purusing the net that is 
both more intuitive than FTP and Gopher, yet downwards compatible with FTP
and Gopher.

NCSA Mosaic requires a direct network connection or SLIP to the Internet 
and versions are available for Xwindows boxes, Macintoshs and Windows PCs.
FTP to "ftp.ncsa.uiuc.edu" and look in the dir "/Mosiac" for all current 
versions.

Lynx is a very good text-mode WWW browser available as UNIX program that 
one runs from their UNIX account. As long as "tar" and "uncompress" are 
not foreign to you, you should have no problems making it work.
You can FTP lynx from ftp.wustl.edu in the /packages/www dir.

---

The next most important thing to first realize is that all of the music on 
IUMA comes a few forms:

MPEG
  This is the format of the best stereo copies of the music online. You need
  a special player to decode the MPEG compression and play the music on your
  system once it's downloaded. IUMA has a few freely distributable
  MPEG audio players already available for you to download:

    XingSound Player for Windows as mpgaudio.zip
    Tobias Bading's MPEG audio player source as maplay.tar.Z
       People using this on UNIX workstations (particularly Suns), 
       should take a look at the accompanying textfiles.

    Aware Corporation has graciously produced a shareware MPEG audio player 
    for the Macintosh which will be availble for distribution in the 
    next few weeks.

ADPCM
  The ADPCM format is probably going to be phased out of being included
  in IUMA since the quality is not as good as MPEG II. In any case,
  the files have the extension .WAV and are in the MS-ADPCM format.
  The program Cool Edit (cool131.zip) can decode and play them on 
  Windows PCs.

AU
  Some (eventually all) bands will have a Sun Audio (au) sample file which
  is available to download a small 15 second sample of the band before  
  deciding that you wish to download the entire MPEG song. When listening 
  to these note that the Sun Au files are 8bit mono for that full-on 
  compressed midrange AM Radio sound and therefore will sound nothing 
  remotely like the awesome stereo MPEG file. Most machines can 
  understand this format so nothing special should be needed beyond normal 
  audio tools to download and play these files. Player for Macintoshes 
  and Windows PCs can be found on the Internet.

If you have any questions please mail ianc@sunsite.unc.edu.

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

[ And the first WWW-server for Fractals, probably coded with MPEG ! ]

From: rousself@univ-rennes1.fr ( Frank ROUSSEL )
Subject: * FRACTAL MOVIE ARCHIVE *
Date: 21 Mar 1994 21:39:27 GMT
Organization: CRI/CICB Universite' de Rennes 1 - FR

I'm proud to announce you that a Fractal Movie Archive
has been opened at the CNAM of Paris.
URL = http://www.cnam.fr/fractals/anim.html

You may also have a look at the Fractal Art Gallery too.
URL = http://www.cnam.fr/fractals.html

NOTE: You can also accede via ftp.cnam.fr:/pub/Fractals

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

From: rousself@univ-rennes1.fr ( Frank ROUSSEL )
Subject: * SPACE MOVIE ARCHIVE *
Date: 21 Mar 1994 21:39:52 GMT
Organization: CRI/CICB Universite' de Rennes 1 - FR

I'm proud to announce you that a Space Movie Archive
has been opened at the CRI-CICB of Rennes.
It consists of about 90 anims, the biggest archive i know.

English URL = http://www.univ-rennes1.fr/ASTRO/anim-e.html
French  URL = http://www.univ-rennes1.fr/ASTRO/anim-f.html

Some new clickable cards (mainly on planets & shuttles)
have been added to the astronomy page (images, animations)
English URL = http://www.univ-rennes1.fr/ASTRO/astro.english.html
French  URL = http://www.univ-rennes1.fr/ASTRO/astro.french.html

NOTE: You can also accede via ftp.univ-rennes1.fr:/pub/Images/ASTRO,
                       or via gopher.univ-rennes1.fr:/Astro Gopher

The IP address is 129.20.254.1 for all.


===========================================================================
 XI | NEWS
==========

News from the CeBit '94 in Hannover:

The real sensation is the ReelMagic-Card ! Look above.

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

New MPEG VideoCD and CD-I service available !
=============================================

Get your own VideoCD or CD-I done via the service bureau !

We offer you the full service to produce an MPEG VideoCD or a CD-I disk with
MPEG full-motion video on it for you.

Just provide the video tapes (S-VHS / Hi-8) and get your own VideoCD back,
playable on Sigma Design's Reel Magic MPEG card, Amiga CD-32 and
Phillips CD-I player. (soon coming out: GOLDSTAR- and JVC- and SAMSUNG-VideoCD 
players for around 350 US$ enduser price)

(In this moment we only offer PAL standard VideoCDs and CD-Is, which also could
be played with NTSC players; call for NTSC version)

Please call for current rates:
------------------------------

Hartmann Electronics
Mr. Dipl. Ing. Stefan Hartmann
Berlin, Germany

Tel: ++ 49 30 344 23 66

email:
harti@mikro.ee.tu-berlin.de

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

Leadtek was showing there DOS-full-screen-MPEG-player. They double
the pixel in a tricky way, so they get 640x400 and the quality is
really good. They told me, the player (with lots of additional
software) is to buy for about $900. The contact address is:

  Mr. Terry Yeu          at

  Leadtek Research Inc.
  Computer Graphics, Multimedia Design & Manufacture

  5F, NO. 4, Alley 11, Lane 327, Sec. 2, Chung-Shan Rd.,
  Chung-Ho, Taipei Shien,
  TAIWAN R.O.C.

  Tel: 886-2-2484101 Ext 113
  Fax: 886-2-2484103

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

Sun has a new version of there 'Multimedia Solutions for Workgroup'
out. And (but this is not official), they will support MPEG, but this
was not to be seen.


===========================================================================
 XII | QUESTIONS
================

These are some questions, ideas or whatever problems, where still no
solutions is found or nobody knows an answer. Please contact me via e-mail
if YOU find a solution for:

1) Interleaving should be the next step in MPEG-development.
   There free audio- and video-code now. Now we have to
   synchronize it. Stefan Eckhardt and Simmons bith can split
   a full-MPEG-stream, but there's no code !
   So, who's working on it ?

2) Are there multimedia-specialized mailboxes out there ? Please send
   a filelisting of your mpeg-archive, a description of how to obtain
   the files, costs, connection times, telefon-numbers etc.

3) Who can send me informations about MPEG-I-Videos stored on CD-I CD's ?
   Are there driver or programs that read CD-I CD's with a coumputer
   CD-ROM-drive to explucde the MPEG-parts ?

4) I'm still looking for some programs, that I cant find anymore.
   One is called "MPEGVU", the other one "SPRAW", a program to
   convert real MPEG-stream into Xing-format (well we would
   really need one, thats doing the other way around).
   Whos has them ? Who knows more ?

5) I still look for the following streams. I know they exist, but
   they are NOT online. Who are the authors, where can I ftp them ?

   dcx-flare.mpg dcx-launch.mpg ferris-sif.mpg
   football.3mbit.mpg football1-qsif.mpg football1-sif.mpg
   football2-qsif.mpg football2-sif.mpg football3-qsif.mpg football3-sif.mpg
   gmsearth.mpg goats.mpg kathy.mpg laputa.mpg mclyte.mpg nlm.mpg
   pingpong-qsif.mpg pingpong-sif.mpg pingpong-varq2.mpg pingpong-varq3.mpg
   simulation.mpg tearsforfears.mpg tm-op.mpg tue.world.mpg
   windmill-qsif.mpg windmill-sif.mpg

6) Who likes to buy the TRAILPACK on CD ? I need about 15 customers
   buying it, so the production cost come back in. The calculated
   price will be DM 100.- (or $ 70). Please see below the TRAILPACK-
   INFO ...


Please mail to:

  phade@cs.tu-berlin.de

if you have more information, than I have.

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

The end of ...

        THE MPEG-FAQ
        ====================================================
        PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY
        Inh. Frank Gadegast          Fon/Fax: +49 30 3128103

        phade@cs.tu-berlin.de

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

END ---------------------- CUT HERE --------------------- 6/6