Newsgroups: comp.graphics,comp.graphics.animation,comp.compression,comp.multimedia,alt.binaries.multimedia,alt.binaries.pictures.utilities,alt.binaries.pictures,alt.binaries.pictures.d,alt.answers,comp.answers,news.answers Subject: MPEG-FAQ: multimedia compression [ /9] Followup-To: alt.binaries.multimedia Reply-To: mpegfaq@powerweb.de Keywords: MPEG, FAQ, Compression Expires: 31 Dec 1996 12:00:00 GMT Summary: This is the summary about the ISO video and audioformats MPEG 1, 2 and 4 Approved: news-answers-request@MIT.EDU Archive-name: mpeg-faq/part0 Last-modified: 1996/06/02 Version: v 4.1 96/06/02 Posting-Frequency: bimonthly =========================================================================== ~Subject: SECTION 0. - INTRO ==================================================== THE MPEG-FAQ [Version 4.1 - 1. June 1996] ==================================================== PHADE Software Inh. Dipl-Inform. Frank Gadegast Leibnizstr. 30 10625 Berlin, GERMANY Fon/Fax ++ 49 30 3128103 E-mail phade@powerweb.de Web site http://www.powerweb.de/mpeg It's the eights publication of this file. Lots of information has been changed (which has surely brought errors with it, see Murphy's Law). This eights compilation is very different to the previous one, Version 4.0. First: The location of this file is: Text-Version : URL: ftp://ftp.powerweb.de/mpeg/faq/mpegfa41.zip [194.77.15.46] HTML-Version : URL: http://www.powerweb.de/mpeg/faq/ My MPEG-related software and my DOS-ports of several programs can be found there too. Second: "The Internet MPEG Audio Archive" is there ! Our brilliant collecting of everything that belongs to MPEG audio. For only DM 49,- ! Get it ! More than 400 MB of songs, documentation and utilities ! Read below, about how to Order ! Third: "The Internet MPEG CD-Rom" is still available ! The uniq collecting of everything that belongs to MPEG. For only DM 49,90 ! Get it ! More than 600 MB of movies, songs, documentation and utilities ! Read below, about how to Order ! Another CD-Rom containing material for MPEG-2 is about to get released ! It will be called the "MPEG-2 Movie Toolbox". Fourth: This FAQ has and the famous MPEG Archive has a complete new home now on the PowerWeb site ! The newest FAQ and other MPEG-related information and utilities for all platforms can always be loaded using WWW from: URL=http://www.powerweb.de/mpeg And surely, there are more interesting things to find ;o) I add my comments in brackets [], lines (---- or ====) seperate the chapters and questions. Please try and find out more information yourself. I had enough to do by getting and preparing this information. And only bother me with file- request if its not possible for you to get it somewhere else !!! If you want to contribute to this FAQ in any way, please email directly too (probably by replying to this posting): mpegfaq@powerweb.de If you want to contribute to the MPEG Archive, please upload via ftp to ftp://ftp.powerweb.de/incoming/mpeg and notity mpeg@powerweb.de via e-mail about your contribution. Other usefull information related to MPEG can be e-mailed to mpeg@powerweb.de Or send any additional information via fax or e-mail. Enjoy MPEG, KeyJ "MPEG" Phade (Frank Gadegast) ------------------------------------------------------------------------------- ~Subject: Disclaimer I HAVE NOTHING TO DO WITH THE NAMED COMPANIES, NO BUSINESS, IT'S JUST MY PERSONAL INTERESTED. COMPANIES ARE NAMED, BECAUSE THEY ARE THE FIRST, BRINGING REAL MULTIMEDIA TO THE WORLD. SURE I MAKE ADVERTS FOR THEM WITH THIS FAQ, BUT HOPE- FULLY YOU, AS A READER OF THIS FAQ, WILL FORCE THEM TO PRODUCE MORE AND BETTER PRODUCTS. MOST ADDITIONAL INFORMATION IS WRITTEN AS PERSONAL COMMENT, AND SHOULD NOT BE TAKEN AS PROOFEN FACTS. INFORMATION IS PRESENTED "AS IS", COULD BE OUT OF DATE AND CANNOT BE GARANTIED TO BE THE TRUTH. THIS INFOMATION COMES WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION OF WARRANTIES OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE AND NON-INFRINGEMENT. UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY, TORT, CONTRACT, OR OTHERWISE, SHALL THE AUTHOR BE LIABLE TO YOU OR ANY OTHER PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF GOODWILL, WORK STOPPAGE, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER COMMERCIAL DAMAGES OR LOSSES. Frank Gadegast ------------------------------------------------------------------------------- ~Subject: Copyright information THIS COMPILATION OF INFORMATION IS COPYRIGHTED BY THE AUTHOR AND MAINTAINER, CURRENTLY FRANK GADEGAST. ANY NON-COMMERCIAL USE OF IT, OR PARTS OF IT IS ALLOWED, UNTIL THE USE OF IT IS REPORTED TO THE AUTHOR AND THE COMPILATION IS KEPT UNCHANGED. ADDITONAL, IF PARTS OF IT ARE USED, INFORMATION HAS TO BE ADDED WITH THAT PART, WHO THE AUTHOR OF THAT PARTS IS, THAT IT BELONGS TO THE COMPLETE COMPILATION AND WHERE TO FIND THE COMPLETE COMPILATION. COMMERCIAL USE CAN BE GRANTED IN SPECIAL CIRCUMSTANCES, FEEL FREE TO ASK AND SEND A DESCRIPTION OF THE INTENDED USE, TO RECEIVE A CERTIFICATION. ANY NON-REPORTED OR NON-CERTIFIED COMMERCIAL USE OF THIS COMPILATION IS A VIOLATION OF GERMAN COPYRIGHT LAW ! ANY RE-PUBLICATION OF THE INFORMATION IN THIS COMPILATION SHOULD BE REPORTED TO THE AUTHOR AND SHOULD BE QUOTED IN THE NEW PUBLICATION. ANY RE-DISTRIBUTION OF THE COMPLETE FILE ON NON-COMMERCIAL ARCHIVES, LIKE FTP- OR FAQ-MIRRORS IS ALLOWED. ------------------------------------------------------------------------------- ~Subject: Digest format It should be possible to read this FAQ with a threaded newsreader or emacs in FAQ-mode to enable you, to jump from one question to another, because this FAQ is organized as a digest. You can move to the next question with the digest commands in gnus, rn or other newsreaders, or with a regex search for ^~Subject or ^--. ------------------------------------------------------------------------------- ~Subject: Recommendations Well, to stop some of the most enoying question, from those that do not read this FAQ at all, I recommend the following player/decoder and encoder. Search the FAQ for these words and download them BEFORE e-mailing to me ! DOS: VMPEG, MAPLAYPC and CMPEG, ENC11BIN Windows: VMPEG, SoftPeg, COOL 1.5.3 and Maplay 1.2 for Win32 Unix: XMPLAY and VCR CD-I's and Video-CDs are currently only supported by VMPEG and SoftPeg ! ------------------------------------------------------------------------------- ~Subject: What questions are getting answered in this FAQ ? SECTION 0. - INTRO Disclaimer Copyright information Digest format What questions are getting answered in this FAQ ? SECTION 1. - WHAT IS MPEG-VIDEO/VIDEO What is MPEG ? What is MPEG-Audio then ? What is the Audio Layer 3 then ? What is MPEG-1+ ? What is MPEG-2 ? What happened at the MPEG - NY meeting ? What's about Video-CD and CD-I ? SECTION 2. - PROFESSIONAL SOFTWARE SUBSECTION - DOS MPEG Encoder by Xing SUBSECTION - WINDOWS MPEG ARCADETM XingSound XingCD SUBSECTION - UNIX Xing Distributed Media Architecture NVR Research Kit Demo of NVR Digital Media Development Kit How will I get the NVR-Software ? SECTION 3. - FREE AVAILABLE SOFTWARE SUBSECTION - DOS layr_100 mpeg2ppm vmpeg cmpeg dmpeg secmpeg mpegstat enc11dos pvrg MPEG SUBSECTION - Windows XingIt mpgaudio SUBSECTION - WINDOWS-NT mpeg2ply mpegplay SUBSECTION - OS/2 mp SUBSECTION - X-WINDOWS and UNIX Berkeley's MPEG Tools MPEG-1 Video Software Encoder MPEG Video Software Decoder MPEG Video Software Analyzer MPEG Blocks Analyzer MPEG Video Software Statistics Gatherer xmg mpegstat mplex xmplay xplayer xmpeg.tk mpeg2encode / mpeg2decode mpegaudio maplay Scanning MPEG's ... MPEG decoder... MPEGTool What is "SECMPEG" ? PVRG-MPEG Codec wdgt SUBSECTION - VMS vms MPEG SUBSECTION - MacIntosh Sparcle Qt2MPEG Audio on Macintosh ?! SUBSECTION - Atari SUBSECTION - Amiga MPEG2DCTV SUBSECTION - NeXT MPEG_Play.app mpegnext SUBSECTION - SGI SECTION 4. - MPEG-RELATED HARDWARE MPEG audio Layer-3 Video-Maker Some MPEG chips Optibase ReelMagic Cinerama XingIt!-card MPEG-decompression hardware list Amiga CD32 SECTION 5. - MAILBOX-ACCESS Genoabox Xing Technologies BBS and fax SECTION 6. - FTP-ACCESS FTP-ACCESS - Overview MPEG-2 validation bitstreams Audio streams and utils Accessing Aminet Where will I find test-material for MPEG-encoders ? SECTION 7. - WWW-ACCESS Where is the WWW-home of this FAQ ? An Interactive Explanation on the Web ? Where is the WWW-demo of "The Internet MPEG CD-Rom" ? Which archive is mostly related to MPEG-Audio ? What's with Bryan Woodworth ftp-area ? Rock'n'Roll stored in MPEG on the Web ? Where can I find space movies coded in MPEG ? Movies on Web-site Where can I find fractal movies coded in MPEG ? Is qt2mpeg on the Web ? What are other good URL's ? SECTION 8. - MAIL ORDER The Internet MPEG CD-Rom Conversion, WWW and CD-Rom production service How can I order information from C-CUBE ? SECTION 9. - ADDITIONAL INFORMATION What are the MPEG standard documents ? So, the Xing decoder is cheating, right ? What is Aware Inc. doing ? Will MPEG be included in QuickTime ? What's about MPEG-2 software ? What about good MPEG Hardware encoders (Optivision) ? What's about CD-I ? What is the PCMotion Player ? What is the MPEG-2 ISO number ? Some papers about MPEG-audio Where can I find more documents about what Berkeley is doing ? Is there a book about MPEG ? Who are CD-I producers ? Where can I get VideoCD and CD-I coding ? Where can I do MPEG encoding ? What the problem with all these file extensions for MPEG-files ? How can I do RTP encapsulation of MPEG1/MPEG2 ? Wo kann ich den MPEG-standard bestellen ? SECTION 10. - WHERE TO FIND MORE INFOS What newsgroups discuss MPEG ? How can 'archie' help me ? SECTION 11. - QUESTIONS =========================================================================== ~Subject: SECTION 1. - WHAT IS MPEG-VIDEO/VIDEO ------------------------------------------------------------------------------- ~Subject: What is MPEG ? From comp.compression Mon Oct 19 15:38:38 1992 Sender: news@chorus.chorus.fr Author: Mark Adler [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 standard? [ There is no newer version of this part so far. Whoever wants to update ] [ this description, should do the job and send it over. ] Written by Mark Adler . 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 1996), they have completed the "Standard of MPEG phase I, colloquially called MPEG I. This 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 standard 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 standard ? A. MPEG is a ISO standard. It's exact name is ISO CD 11172. The standard 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 Or from 'ISO Online' at http://www.iso.ch/welcome.html ------------------------------------------------------------------------------- ~Subject: What is MPEG-Audio then ? From: "Harald Popp" From: mortenh@oslonett.no Date: Fri, 25 Mar 1994 19:09:06 +0100 Q. What is MPEG? A. MPEG is an ISO committee that proposes standards for compression of Audio and Video. MPEG deals with 3 issues: Video, Audio, and System (the combination of the two into one stream). You can find more info on the MPEG committee in other parts of this document. Q. I've heard about MPEG Video. So this is the same compression applied to audio? A. Definitely no. The eye and the ear... even if they are only a few centimeters apart, works very differently... The ear has a much higher dynamic range and resolution. It can pick out more details but it is "slower" than the eye. The MPEG committee chose to recommend 3 compression methods and named them Audio Layer-1, Layer-2, and Layer-3. Q. What does it mean exactly? A. MPEG-1, IS 11172-3, describes the compression of audio signals using high performance perceptual coding schemes. It specifies a family of three audio coding schemes, simply called Layer-1,-2,-3, with increasing encoder complexity and performance (sound quality per bitrate). The three codecs are compatible in a hierarchical way, i.e. a Layer-N decoder is able to decode bitstream data encoded in Layer-N and all Layers below N (e.g., a Layer-3 decoder may accept Layer-1,-2 and -3, whereas a Layer-2 decoder may accept only Layer-1 and -2.) Q. So we have a family of three audio coding schemes. What does the MPEG standard define, exactly? A. For each Layer, the standard specifies the bitstream format and the decoder. It does *not* specify the encoder to allow for future improvements, but an informative chapter gives an example for an encoder for each Layer. Q. What have the three audio Layers in common? A. All Layers use the same basic structure. The coding scheme can be described as "perceptual noise shaping" or "perceptual subband / transform coding". The encoder analyzes the spectral components of the audio signal by calculating a filterbank or transform and applies a psychoacoustic model to estimate the just noticeable noise-level. In its quantization and coding stage, the encoder tries to allocate the available number of data bits in a way to meet both the bitrate and masking requirements. The decoder is much less complex. Its only task is to synthesize an audio signal out of the coded spectral components. All Layers use the same analysis filterbank (polyphase with 32 subbands). Layer-3 adds a MDCT transform to increase the frequency resolution. All Layers use the same "header information" in their bitstream, to support the hierarchical structure of the standard. All Layers use a bitstream structure that contains parts that are more sensitive to biterrors ("header", "bit allocation", "scalefactors", "side information") and parts that are less sensitive ("data of spectral components"). All Layers may use 32, 44.1 or 48 kHz sampling frequency. All Layers are allowed to work with similar bitrates: Layer-1: from 32 kbps to 448 kbps Layer-2: from 32 kbps to 384 kbps Layer-3: from 32 kbps to 320 kbps Q. What are the main differences between the three Layers, from a global view? A. From Layer-1 to Layer-3, complexity increases (mainly true for the encoder), overall codec delay increases, and performance increases (sound quality per bitrate). Q. Which Layer should I use for my application? A. Good Question. Of course, it depends on all your requirements. But as a first approach, you should consider the available bitrate of your application as the Layers have been designed to support certain areas of bitrates most efficiently, i.e. with a minimum drop of sound quality. Let us look a little closer at the strong domains of each Layer. Layer-1: Its ISO target bitrate is 192 kbps per audio channel. Layer-1 is a simplified version of Layer-2. It is most useful for bitrates around the "high" bitrates around or above 192 kbps. A version of Layer-1 is used as "PASC" with the DCC recorder. Layer-2: Its ISO target bitrate is 128 kbps per audio channel. Layer-2 is identical with MUSICAM. It has been designed as trade-off between sound quality per bitrate and encoder complexity. It is most useful for bitrates around the "medium" bitrates of 128 or even 96 kbps per audio channel. The DAB (EU 147) proponents have decided to use Layer-2 in the future Digital Audio Broadcasting network. Layer-3: Its ISO target bitrate is 64 kbps per audio channel. Layer-3 merges the best ideas of MUSICAM and ASPEC. It has been designed for best performance at "low" bitrates around 64 kbps or even below. The Layer-3 format specifies a set of advanced features that all address one goal: to preserve as much sound quality as possible even at rather low bitrates. Today, Layer-3 is already in use in various telecommunication networks (ISDN, satellite links, and so on) and speech announcement systems. Q. So how does MPEG audio work? A. Well, first you need to know how sound is stored in a computer. Sound is pressure differences in air. When picked up by a microphone and fed through an amplifier this becomes voltage levels. The voltage is sampled by the computer a number of times per second. For CD audio quality you need to sample 44100 times per second and each sample has a resolution of 16 bits. In stereo this gives you 1,4Mbit per second and you can probably see the need for compression. To compress audio MPEG tries to remove the irrelevant parts of the signal and the redundant parts of the signal. Parts of the sound that we do not hear can be thrown away. To do this MPEG Audio uses psychoacoustic principles. Q. Tell me more about sound quality. How good is MPEG audio compression? And how do you assess that? A. Today, there is no alternative to expensive listening tests. During the ISO-MPEG-1 process, 3 international listening tests have been performed, with a lot of trained listeners, supervised by Swedish Radio. They took place in 7.90, 3.91 and 11.91. Another international listening test was performed by CCIR, now ITU-R, in 92. All these tests used the "triple stimulus, hidden reference" method and the so-called CCIR impairment scale to assess the audio quality. The listening sequence is "ABC", with A = original, BC = pair of original / coded signal with random sequence, and the listener has to evaluate both B and C with a number between 1.0 and 5.0. The meaning of these values is: 5.0 = transparent (this should be the original signal) 4.0 = perceptible, but not annoying (first differences noticable) 3.0 = slightly annoying 2.0 = annoying 1.0 = very annoying With perceptual codecs (like MPEG audio), all traditional parameters (like SNR, THD+N, bandwidth) are especially useless. Fraunhofer-IIS (among others) works on objective quality assessment tools, like the NMR meter (Noise-to-Mask-Ratio), too. If you need more informations about NMR, please contact nmr@iis.fhg.de Q. Now that I know how to assess quality, come on, tell me the results of these tests. A. Well, for details you should study one of those AES papers listed below. One main result is that for low bitrates (60 or 64 kbps per channel, i.e. a compression ratio of around 12:1), Layer-2 scored between 2.1 and 2.6, whereas Layer-3 scored between 3.6 and 3.8. This is a significant increase in sound quality, indeed! Furthermore, the selection process for critical sound material showed that it was rather difficult to find worst-case material for Layer-3 whereas it was not so hard to find such items for Layer-2. For medium and high bitrates (120 kbps or more per channel), Layer-2 and Layer-3 scored rather similar, i.e. even trained listeners found it difficult to detect differences between original and reconstructed signal. Q. So how does MPEG achieve this compression ratio? A. Well, with audio you basically have two alternatives. Either you sample less often or you sample with less resolution (less than 16 bit per sample). If you want quality you can't do much with the sample frequency. Humans can hear sounds with frequencies from about 20Hz to 20kHz. According to the Nyquist theorem you must sample at least two times the highest frequency you want to reproduce. Allowing for imperfect filters, a 44,1kHz sampling rate is a fair minimum. So you either set out to prove the Nyquist theorem is wrong or go to work on reducing the resolution. The MPEG committee chose the latter. Now, the real reason for using 16 bits is to get a good signal-to-noise (s/n) ratio. The noise we're talking about here is quantization noise from the digitizing process. For each bit you add, you get 6dB better s/n. (To the ear, 6dBu corresponds to a doubling of the sound level.) CD-audio achieves about 90dB s/n. This matches the dynamic range of the ear fairly well. That is, you will not hear any noise coming from the system itself (well, there is still some people arguing about that, but lets not worry about them for the moment). So what happens when you sample to 8 bit resolution? You get a very noticeable noise floor in your recording. You can easily hear this in silent moments in the music or between words or sentences if your recording is a human voice. Waitaminnit. You don't notice any noise in loud passages, right? This is the masking effect and is the key to MPEG Audio coding. Stuff like the masking effect belongs to a science called psycho-acoustics that deals with the way the human brain perceives sound. And MPEG uses psychoacoustic principles when it does its thing. Q. Explain this masking effect. A. OK, say you have a strong tone with a frequency of 1000Hz. You also have a tone nearby of say 1100Hz. This second tone is 18 dB lower. You are not going to hear this second tone. It is completely masked by the first 1000Hz tone. As a matter of fact, any relatively weak sounds near a strong sound is masked. If you introduce another tone at 2000Hz also 18 dB below the first 1000Hz tone, you will hear this. You will have to turn down the 2000Hz tone to something like 45 dB below the 1000Hz tone before it will be masked by the first tone. So the further you get from a sound the less masking effect it has. The masking effect means that you can raise the noise floor around a strong sound because the noise will be masked anyway. And raising the noise floor is the same as using less bits and using less bits is the same as compression. Do you get it? Q. I don't get it. A. Well, let me try to explain how the MPEG Audio Layer-2 encoder goes about its thing. It divides the frequency spectrum (20Hz to 20kHz) into 32 subbands. Each subband holds a little slice of the audio spectrum. Say, in the upper region of subband 8, a 6500Hz tone with a level of 60dB is present. OK, the coder calculates the masking effect of this sound and finds that there is a masking threshold for the entire 8th subband (all sounds w. a frequency...) 35dB below this tone. The acceptable s/n ratio is thus 60 - 35 = 25 dB. The equals 4 bit resolution. In addition there are masking effects on band 9-13 and on band 5-7, the effect decreasing with the distance from band 8. In a real-life situation you have sounds in most bands and the masking effects are additive. In addition the coder considers the sensitivity of the ear for various frequencies. The ear is a lot less sensitive in the high and low frequencies. Peak sensivity is around 2 - 4kHz, the same region that the human voice occupies. The subbands should match the ear, that is each subband should consist of frequencies that have the same psychoacoustic properties. In MPEG Layer 2, each subband is 750Hz wide (with 48 kHz sampling frequency). It would have been better if the subbands were narrower in the low frequency range and wider in the high frequency range. That is the trade-off Layer-2 took in favour of a simpler approach. Layer-3 has a much higher frequency resolution (18 times more) - and that is one of the reasons why Layer-3 has a much better low bitrate performance than Layer-2. But there is more to it. I have explained concurrent masking, but the masking effect also occurs before and after a strong sound (pre- and postmasking). Q. Before? A. Yes, if there is a significant (30 - 40dB ) shift in level. The reason is believed to be that the brain needs some processing time. Premasking is only about 2 to 5 ms. The postmasking can be up till 100ms. Other bit-reduction techniques involve considering tonal and non-tonal components of the sound. For a stereo signal you may have a lot of redundancy between channels. All MPEG Layers may exploit these stereo effects by using a "joint- stereo" mode, with a most flexible approach for Layer-3. Furthermore, only Layer-3 further reduces the redundancy by applying huffmann coding. Q. What are the downside? A. The coder calculates masking effects by an iterative process until it runs out of time. It is up to the implementor to spend bits in the least obtrusive fashion. For Layer 2 and Layer 3, the encoder works on 24 ms of sound (with 1152 sample, and fs = 48 kHz) at a time. For some material, the time-window can be a problem. This is normally in a situation with transients where there are large differences in sound level over the 24 ms. The masking is calculated on the strongest sound and the weak parts will drown in quantization noise. This is perceived as a "noise- echo" by the ear. Layer 3 addresses this problem specifically by using a smaller analysis window (4 ms), if the encoder encounters an "attack" situation. Q. Tell me about the complexity. What are the hardware demands? A. Alright. First, we have to separate between decoder and encoder. Remember: the MPEG coding is done asymmetrical, with a much larger workload on the encoder than on the decoder. For a stereo decoder, variuos real-time implementations exist for Layer-2 and Layer-3. They are either based on single-DSP solutions or on dedicated MPEG audio decoder chips. So you need not worry about decoder complexity. For a stereo Layer-2-encoder, various DSP based solutions with one or more DSPs exist (with different quality, also). For a stereo Layer-3-encoder achieving ISO reference quality, the current real-time implementations use two DSP32C and two DSP56002. Q. How many audio channels? A. MPEG-1 allows for two audio channels. These can be either single (mono), dual (two mono channels), stereo or joint stereo (intensity stereo (Layer-2 and Layer-3) or m/s- stereo (Layer-3 only)). In normal (l/r) stereo one channel carries the left audio signal and one channel carries the right audio signal. In m/s stereo one channel carries the sum signal (l+r) and the other the difference (l-r) signal. In intensity stereo the high frequency part of the signal (above 2kHz) is combined. The stereo image is preserved but only the temporal envelope is transmitted. In addition MPEG allows for pre-emphasis, copyright marks and original/copy marks. MPEG-2 allows for several channels in the same stream. Q. What about the audio codec delay? A. Well, the standard gives some figures of the theoretical minimum delay: Layer-1: 19 ms (<50 ms) Layer-2: 35 ms (100 ms) Layer-3: 59 ms (150 ms) The practical values are significantly above that. As they depend on the implementation, exact figures are hard to give. So the figures in brackets are just rough thumb values. Yes, for some applications, a very short delay is of critical importance. E.g. in a feedback link, a reporter can only talk intelligibly if the overall delay is below around 10 ms. If broadcasters want to apply MPEG audio coding, they have to use "N-1" switches in the studio to overcome this problem (or appropriate echo-cancellers) - or they have to forget about MPEG at all. But with most applications, these figures are small enough to present no extra problem. At least, if one can accept a Layer- 2 delay, one can most likely also accept the higher Layer-3 delay. Q. OK, I am hooked on! Where can I find more technical informations about MPEG audio coding, especially about Layer- 3? A. Well, there is a variety of AES papers, e.g. K. Brandenburg, G. Stoll, ...: "The ISO/MPEG-Audio Codec: A Generic Standard for Coding of High Quality Digital Audio", 92nd AES, Vienna 1992, pp.3336 E. Eberlein, H. Popp, ...: "Layer-3, a Flexible Coding Standard", 94th AES, Berlin 93, pp.3493 K. Brandenburg, G. Zimmer, ...: "Variable Data-Rate Recording on a PC Using MPEG-Audio Layer-3", 95th AES, New York 93 B. Grill, J. Herre,... : "Improved MPEG-2 Audio Multi-Channel Encoding", 96th AES, Amsterdam 94 And for further informations, please contact layer3@iis.fhg.de Q. Where can I get more details about MPEG audio? A. Still more details? No shit. You can get the full ISO spec from Omnicom. The specs do a fairly good job of obscuring exactly how these things are supposed to work... Jokes aside, there are no description of the coder in the specs. The specs describes in great detail the bitstream and suggests psychoacoustic models. Originally written by Morten Hjerde <100034,663@compuserve.com>, modified and updated by Harald Popp (layer3@iis.fhg.de). Harald Popp Audio & Multimedia ("Music is the *BEST*" - F. Zappa) Fraunhofer-IIS-A, Weichselgarten 3, D-91058 Erlangen, Germany Phone: +49-9131-776-340 Fax: +49-9131-776-399 email: popp@iis.fhg.de ------------------------------------------------------------------------------- ~Subject: What is the Audio Layer 3 then ? Informations about MPEG Audio Layer-3 Version 1.51 - 1. 95 This text is organized as a kind of Mini-FAQ (Frequently Asked Questions). It covers several topics: 1. ISO-MPEG Standard 2. MPEG Audio Codec Family ("Layer 1, 2, 3") 3. Applications 4. Products 5. Support by Fraunhofer-IIS 6. Shareware Information For further comments and questions regarding Layer-3, please contact: - layer3@iis.fhg.de For further informations about MPEG, you may also like to contact: - phade@powerweb.de 1. ISO-MPEG Standard Q: What is MPEG, exactly? A: MPEG is the "Moving Picture Experts Group", working under the joint direction of the International Standards Organization (ISO) and the International Electro-Technical Commission (IEC). This group works on standards for the coding of moving pictures and associated audio. Q: What is the status of MPEG's work, then? What about MPEG-1, -2, and so on? A: MPEG approaches the growing need for multimedia standards step-by- step. Today, three "phases" are defined: MPEG-1:"Coding of Moving Pictures and Associated Audio for Digital Storage Media at up to about 1.5 MBit/s" Status: International Standard IS-11172, completed in 10.92 MPEG-2:"Generic Coding of Moving Pictures and Associated Audio" Status: International Standard IS-13818, completed in 11.94 MPEG-3: does no longer exist (has been merged into MPEG-2) MPEG-4: "Very Low Bitrate Audio-Visual Coding" Status: Call for Proposals first deadline 1. 10. 95 Q: MPEG-1 and MPEG-2 are ready-for-use. How do the standards look like? A: Both standards consist of 4 main parts. The structure is the same for MPEG-1 and MPEG-2. -1: System describes synchronization and multiplexing of video and audio -2: Video describes compression of video signals -3: Audio describes compression of audio signals -4: Compliance Testing describes procedures for determining the characteristics of coded bitstreams and the decoding process and for testing compliance with the requirements stated in the other parts. Q: How do I get the MPEG documents? A: You order it from your national standards body. E.g., in Germany, please contact: DIN-Beuth Verlag, Auslandsnormen Mrs. Niehoff, Burggrafenstr. 6, D-10772 Berlin, Germany Phone: +49-30-2601-2757, Fax: +49-30-2601-1231 2. MPEG Audio Codec Family ("Layer 1, 2, 3") Q: Talking about MPEG audio coding, I heard a lot about "Layer 1, 2 and 3". What does it mean, exactly? A: MPEG describes the compression of audio signals using high performance perceptual coding schemes. It specifies a family of three audio coding schemes, simply called Layer-1,-2,-3, with increasing encoder complexity and performance (sound quality per bitrate) from 1 to 3. The three codecs are compatible in a hierarchical way, i.e. a Layer-N decoder is able to decode bitstream data encoded in Layer-N and all Layers below N (e.g., a Layer-3 decoder may accept Layer-1,-2 and -3, whereas a Layer-2 decoder may accept only Layer-1 and -2.) Q: So we have a family of three audio coding schemes. What does the MPEG standard define, exactly? A: For each Layer, the standard specifies the bitstream format and the decoder. To allow for future improvements, it does *not* specify the encoder, but an informative chapter gives an example for an encoder for each Layer. Q: What have the three audio Layers in common? A: All Layers use the same basic structure. The coding scheme can be described as "perceptual noise shaping" or "perceptual subband / transform coding". The encoder analyzes the spectral components of the audio signal by calculating a filterbank or transform and applies a psychoacoustic model to estimate the just noticeable noise-level. In its quantization and coding stage, the encoder tries to allocate the available number of data bits in a way to meet both the bitrate and masking requirements. The decoder is much less complex. Its only task is to synthesize an audio signal out of the coded spectral components. All Layers use the same analysis filterbank (polyphase with 32 subbands). Layer-3 adds a MDCT transform to increase the frequency resolution. All Layers use the same "header information" in their bitstream, to support the hierarchical structure of the standard. All Layers have a similar sensitivity to biterrors. They use a bitstream structure that contains parts that are more sensitive to biterrors ("header", "bit allocation", "scalefactors", "side information") and parts that are less sensitive ("data of spectral components"). All Layers support the insertion of programm-associated information ("ancillary data") into their audio data bitstream. All Layers may use 32, 44.1 or 48 kHz sampling frequency. All Layers are allowed to work with similar bitrates: Layer-1: from 32 kbps to 448 kbps Layer-2: from 32 kbps to 384 kbps Layer-3: from 32 kbps to 320 kbps The last two statements refer to MPEG-1; with MPEG-2, there is an extension for the sampling frequencies and bitrates (see below). Q: What are the main differences between the three Layers, from a global view? A: From Layer-1 to Layer-3, complexity increases (mainly true for the encoder), overall codec delay increases, and performance increases (sound quality per bitrate). Q: What are the main differences between MPEG-1 and MPEG-2 in the audio part? A: MPEG-1 and MPEG-2 use the same family of audio codecs, Layer-1, -2 and -3. The new audio features of MPEG-2 are: "low sample rate extension" to address very low bitrate applications with limited bandwidth requirements (the new sampling frequencies are 16, 22.05 or 24 kHz, the bitrates extend down to 8 kbps), "multichannel extension" to address surround sound applications with up to 5 main audio channels (left, center, right, left surround, right surround) and optionally 1 extra "low frequency enhancement (LFE)" channel for subwoofer signals; in addition, a "multilingual extension" allows the inclusion of up to 7 more audio channels. Q: A lot of new stuff! Is this all compatible to each other? A: Well, more or less, yes - with the execption of the low sample rate extension. Obviously, a pure MPEG-1 decoder is not able to handle the new "half" sample rates. Q: You mean: compatible!? With all these extra audio channels? Please explain! A: Compatibility has been a major topic during the MPEG-2 definition phase. The main idea is to use the same basic bitstream format as defined in MPEG-1, with the main data field carrying two audio signals (called L0 and R0) as before, and the ancillary data field carrying the multichannel extension information. Without going further into details, three terms can be explained here: "forwards compatible": the MPEG-2 decoder has to accept any MPEG-1 audio bitstream (that represents one or two audio channels) "backwards compatible": the MPEG-1 decoder should be able to decode the audio signals in the main data field (L0 and R0) of the MPEG-2 bitstream "Matrixing" may be used to get the surround information into L0 and R0: L0 = left signal + a * center signal + b * left surround signal R0 = right signal + a * center signal + b * right surround signal Therefore, a MPEG-1 decoder can reproduce a comprehensive downmix of the full 5-channel information. A MPEG-2 decoder uses the multichannel extension information (3 more audio signals) to reconstruct the five surround channels. Q: I heard something about a new NBC mode for MPEG-2 audio? What does it mean? A: "NBC" stands for "non-backwards compatible". During the development of the backwards compatible MPEG-2 standard, the experts encountered some trouble with the compatibility matrix. The introduced quantisation noise may become audible after dematrixing. Although some clever strategies have been devised to overcome this problem, the question remained how much better a non-compatible multichannel codec might perform. So ISO-MPEG decided to address that issue in a "NBC" working group - among the proponents are AT&T, Dolby, Fraunhofer, IRT, Philips, and Sony. Their work will lead to an addendum to the MPEG-2 standard (13818-8). Q: O.K., that should do for a first overview. Are there some papers for a more detailed information? A: Sure! You'll find more technical informations about MPEG audio coding in a variety of AES papers (AES = Audio Engineering Society). The AES organizes two conventions per year, and perceptual audio coding has been a topic since the middle of the 80s. Some interesting papers might be: K. Brandenburg, G. Stoll, et al.: "The ISO/MPEG-Audio Codec: A Generic Standard for Coding of High Quality Digital Audio", 92nd AES, Vienna Mar. 92, pp. 3336; revised version ("ISO-MPEG-1 Audio: A Generic Standard...") published in the Journal of AES, Vol.42, No. 10, Oct. 94 S. Church, B. Grill, et al.: "ISDN and ISO/MPEG Layer-3 Audio Coding: Powerful New tools for Broadcast and Audio Production", 95th AES, New York Oct. 93, pp. 3743 E. Eberlein, H. Popp, et al.: "Layer-3, a Flexible Coding Standard", 94th AES, Berlin Mar. 93, pp. 3493 B. Grill, J. Herre, et al.: "Improved MPEG-2 Audio Multi-Channel Encoding", 96th AES, Amsterdam Feb. 94, pp. 3865 J. Herre, K. Brandenburg, et al.: "Second Generation ISO/MPEG Audio Layer-3 Coding", 98th AES, Paris Feb. 95 F.-O. Witte, M. Dietz, et al.: "'Single Chip Implementation of an ISO/MPEG Layer-3 Decoder", 96th AES, Amsterdam Feb. 94, pp. 3805 For ordering informations, contact: AES 60 East 42nd Street, Suite 2520 New York, NY 10165-2520, USA phone: (212) 661-8528, fax: (212) 682-0477 Another interesting publication: the "Proceedings of the Sixth Tirrenia International Workshop on Digital Communications", Tirrenia Sep. 93, Elsevier Science B.V. Amsterdam 94 (ISBN 0 444 81580 5). An excellent tutorial about MPEG-2 has recently been published in a German technical journal (Fernseh- und Kino-Technik); part 4, by E. F. Schroeder and J. Spille, talks about the audio part (7/8 94, p. 364 ff). And for further informations, please feel free to contact layer3@iis.fhg.de. 3. Applications Q: O.K., let us concentrate on one or two audio channels. Which Layer shall I use for my application? A: Good Question. Of course, it depends on all your requirements. But as a first approach, you should consider the available bitrate of your application as the Layers have been designed to support certain areas of bitrates most effectively. Roughly, today you can achieve a data reduction of around 1:4 with Layer-1 (or 192 kbps per audio channel), 1:6..8 with Layer-2 (or 128..96 kbps per audio channel), and 1:10..12 with Layer-3, (or 64..56 kbps per audio channel), and still the reconstructed audio signal will maintain a "CD-like" sound quality. This may be used as a first "thumb rule" - let's talk about details later on. Q: Why does the performance increase with the number of the Layer? Why does the standard define a family of audio codecs instead of one single powerful algorithm? A: Well, the MPEG standard has forged together two main coding schemes that offered advantages either in complexity (MUSICAM) or in performance (ASPEC). Layer-2 is identical with the MUSICAM format. It has been designed as a trade-off between sound quality per bitrate and encoder complexity. So it is most useful for the "medium" range of bitrates (96..128 kbps per channel). For higher bitrates, even a simplified version, the Layer-1, performs well enough. Layer-1 has originally been developed for a target bitrate of 192 kbps per channel. It is used as "PASC" within the DCC recorder. For lower bitrates (64 kbps per channel or even less), the Layer-2 format suffers from its build-in limitations, and with decreasing bitrate, artefacts become audible more and more. Here is the strong domain of the most powerful MPEG audio format, Layer-3. It specifies a set of unique features that all address one goal: to preserve as much sound quality as possible even at very low bitrates. Q: Wait a second! I understand that Layer-3 has been an important asset to the MPEG-1 standard, to address the high-quality low bitrate applications. With the advent of the "low sample rate extension (LSF)" in MPEG-2, is it still necessary to rely on Layer-3 to achieve a high-quality sound at low bitrates? A: Yes, for sure! Please, don't mix up MPEG-1 and MPEG-2 LSF. MPEG-2 LSF is useful only for applications with limited bandwidth (11.25 kHz, at best). For applications with full bandwidth, MPEG-1 Layer-3 at 64 or 56 kbps per channel achieves the best sound quality of all ISO codecs. For applications with limited bandwidth, MPEG-2 LSF Layer-3 provides an excellent sound quality at 56 kbps for monophonic speech signals and still a good sound quality at only 64 kbps total bitrate for stereo music signals (with around 10 kHz bandwidth). The latest MPEG ISO listening test (in September 94 at NTT Japan, doc. MPEG 94/437) proved the superior performance of Layer-3 in MPEG-1 and MPEG-2 LSF. Q: Tell me more about sound quality. How do you assess that? A: Today, there is no alternative to expensive listening tests. During the ISO- MPEG process, a number of international listening tests have been performed, with a lot of trained listeners. All these tests used the "triple stimulus, hidden reference" method and the "CCIR impairment scale" to assess the sound quality. The listening sequence is "ABC", with A = original, BC = pair of original / coded signal with random sequence, and the listener has to evaluate both B and C with a number between 1.0 and 5.0. The meaning of these values is: 5.0 = transparent (this should be the original signal) 4.0 = perceptible, but not annoying (first differences noticable) 3.0 = slightly annoying 2.0 = annoying 1.0 = very annoying Q: Is there really no alternative to listening tests? A: No, there is not. With perceptual codecs, all traditional "quality" parameters (like SNR, THD+N, bandwidth) are rather useless, as any codec may introduce noise and distortions as long as it does not affect the perceived sound quality. So, listening tests are necessary, and, if carefully prepared and performed, lead to rather reliable results. Nevertheless, Fraunhofer-IIS works on objective sound quality assessment tools, too. There is already a first product available, the NMR meter, a real-time DSP-based measurement tool that nicely supports the analysis of perceptual audio codecs. If you need more informations about the Noise-to- Mask-Ratio (NMR) technology, feel free to contact nmr@iis.fhg.de. Q: O.K., back to these listening tests. Come on, tell me some results. A: Well, for details you should study one of those AES papers or MPEG documents listed above. The main result is that for low bitrates (64 kbps per channel or below), Layer-3 always scored significantly better than Layer-2. Another important conclusion is the draft recommendation of the task group TG 10/2 within the ITU-R. It recommends the use of low bit- rate audio coding schemes for digital sound-broadcasting applications (doc. BS.1115). Q: Very interesting! Tell me more about this recommendation! A: The task group TG 10/2 concluded its work in October 93. The draft recommendation defines three fields of broadcast applications: - distribution and contribution links (20 kHz bandwidth, no audible impairments with up to 5 cascaded codecs) Recommendation: Layer-2 with 180 kbps per channel - emission (20 kHz bandwidth) Recommendation: Layer-2 with 128 kbps per channel - commentary links (15 kHz bandwidth) Recommendation: Layer-3 with 60 kbps for monophonic and 120 kbps for stereophonic signals Q: I see. Medium bitrates - Layer-2, low bitrates - Layer-3. What's about a bitrate of 96 kbps per channel that seems to be "somewhere in between" Layer-2 and Layer-3 domains? A: Interesting question. In fact, a total bitrate of 192 kbps for stereo music is useful for real applications, e.g. emission via satellite channels. The ITU-R required that emission codecs should score at least 4.0 on the CCIR impairment scale, even for the most critical material. At 128 kbps per channel, Dolby's AC-2, Layer-2 and Layer-3 fulfilled this requirement. Finally, Layer-2 got the recommendation mainly because of its "commonality with the distribution and contribution application". Further tests for emission were performed at 192 kbps joint-stereo coding. Layer-3 clearly met the requirements, Layer-2 fulfilled them only marginally, with doubts remaining during further tests with cascaded codecs in 1993. In the end, the task group decided to pronounce no recommendation for emission at 192 kbps. Q: Someone told me that in the ITU-R tests, there was some trouble with Layer-3, specifically on male voice in the German language. Still, Layer-3 got the recommendation for "commentary links". Can you explain that? A: Yes. For commentary links, the quality requirements for speech were to be equivalent to 14-bit linear PCM, and for music, some perceptible impairments were to be tolerated. In the test in 1992, Layer-3 was by far the only codec that fulfilled these requirements (e.g. overall monophonic, Layer-3 scored 3.6 in contrast to Layer-2 at 2.05 - and for male German speech, Layer-3 scored 4.4 in contrast to Layer-2 at 2.4). Further tests were performed in 1993 using headphones. They showed that MPEG-1 Layer-3 with monophonic speech (the test item is German male voice) at 60 kbps did not fully meet the quality requirements. The ITU decided to recommend Layer-3 and to include a temporary footnote that will be removed as soon as an improved Layer-3 codec fulfills the requirements completely, i.e. even with that well-known critical male German speech item (for many other speech items, Layer-3 has no trouble at all). Q: O.K., a Layer-2 codec at low bitrates may sound poor today, but couldn't that be improved in the future? I guess you just told me before that the encoder is not fixed in the standard. A: Good thinking! As the sound quality mainly depends on the encoder implementation, it is true that there is no such thing as a "Layer-N"- quality. So we definitely only know the performance of the reference codecs used during the international tests. Who knows what will happen in the future? What we do know now, is: Today, in MPEG-1 and MPEG-2, Layer-3 provides the best sound quality at low bitrates, by far better than Layer-2. Tomorrow, both Layers may improve. Layer-2 has been designed as a trade-off between quality and complexity, so the bitstream format allows only limited innovations. In contrast, even the current reference Layer-3- codec does not exploit all of the powerful mechanisms inside the Layer-3 bitstream format. Q: What other topics do I have to keep in mind? Tell me about the complexity of Layer-3. A: O.K. First, we have to separate between decoder and encoder, as the workload is distributed asymmetrically between them, i.e. the encoder needs much more computation power than the decoder. For a stereo Layer-3-decoder, you may either use a DSP (e.g. one DSP56002 from Motorola) or an "ASIC", like the masc-programmed DSP chip MAS 3503 C from Intermetall, ITT. Some rough requirements are: computation power around 12 MIPs Data ROM 2.5 Kwords Data RAM 4.5 Kwords Programm ROM 2 to 4 Kwords word length at least 20 bit Intermetall (ITT) estimated an overhead of around 30 % chip area for adding the necessary Layer-3 modules to a Layer-2-decoder. So you need not worry too much about decoder complexity. For a stereo Layer-3-encoder achieving reference quality, our current real- time implementations use two DSP32C (AT&T) and one DSP56002. With the advent of the 21060 (Analog Devices), even a single-chip stereo encoder comes into view. Q: Quality, complexity - what about the codec delay? A: Well, the standard gives some figures of the theoretical minimum delay: Layer-1: 19 ms (<50 ms) Layer-2: 35 ms (100 ms) Layer-3: 59 ms (150 ms) The practical values are significantly above that. As they depend on the implementation, exact figures are hard to give. So the figures in brackets are just rough thumb values - real codecs may show significant higher values. Q: For some applications, a very short delay is of critical importance: e.g. in a feedback link, a reporter can only talk intelligibly if the overall delay is below around 10 ms. Here, do I have to forget about MPEG audio at all? A: Not necessarily. In this application, broadcasters may use "N-1" switches in the studio to overcome this problem - or they may use equipment with appropriate echo-cancellers. But with many applications, these delay figures are small enough to present no extra problem. At least, if one can accept a Layer-2 delay, one can most likely also accept the higher Layer-3 delay. Q: Someone told me that, with Layer-3, the codec delay would depend on the actual audio signal, varying over the time. Is this really true? A: No. The codec delay does not depend on the audio signal.With all Layers, the delay depends on the actual implementation used in a specific codec, so different codecs may have different delays. Furthermore, the delay depends on the actual sample rate and bitrate of your codec. Q: All in all, you sound as if anybody should use Layer-3 for low bitrates. Why on earth do some vendors still offer only Layer-2 equipment for these applications? A: Well, maybe because they started to design and develop their systems rather early, e.g. in 1990. As Layer-2 is identical with MUSICAM, it has been available since summer of 1990, at latest. In that year, Layer-3 development started and could be successfully finished at the end of 1991. So, for a certain time, vendors could only exploit the already existing part of the new MPEG standard. Now the situation has changed. All Layers are available, the standard is completed, and new systems may capitalize on the full features of MPEG audio. 4. Products Q: What are the main fields of application for Layer-3? A: Simply put: all applications that need high-quality sound at very low bitrates to store or transmit music signals. Some examples are: - high-quality music links via ISDN phone lines (basic rate) - sound broadcasting via low bitrate satellite channels - music distribution in computer networks with low demands for channel bandwidth and memory capacity - music memories for solid state recorders based on ROM chips Q: What kind of Layer-3 products are already available? A: An increasing number of applications benefit from the advanced features of MPEG audio Layer-3. Here is a list of companies that currently sell Layer-3 products. For further informations, please contact these companies directly. Layer-3 Codecs for Telecommunication: - AETA, 361 Avenue du Gal de Gaulle (*) F-92140 Clamart, France Fax: +33-1-4136-1213 (Mr. Fric) (*) products announced for 1995 - Dialog 4 System Engineering GmbH, Monreposstr. 57 D-71634 Ludwigsburg, Germany Fax: +49-7141-22667 (Mr. Burkhardtsmaier) - PKI Philips Kommunikations Industrie, Thurn-und-Taxis-Str. 14 D-90411 Nuernberg, Germany Fax: +49-911-526-3795 (Mr. Konrad) - Telos Systems, 2101 Superior Avenue Cleveland, OH 44114, USA Fax: +1-216-241-4103 (Mr. Church) Speech Announcement Systems: - Meister Electronic GmbH, Koelner Str. 37 D-51149 Koeln, Germany Fax: +49-2203-1701-30 (Mr. Seifert) PC Cards (Hardware and/or Software): - Dialog 4 System Engineering GmbH, Monreposstr. 57 D-71634 Ludwigsburg, Germany Fax: +49-7141-22667 (Mr. Burkhardtsmaier) - Proton Data, Marrensdamm 12 b D-24944 Flensburg, Germany Fax: +49-461-38169 (Mr. Nissen) Layer-3-Decoder-Chips: - ITT Intermetall GmbH, Hans-Bunte-Str. 19 D-79108 Freiburg, Germany Fax: +49-761-517-2395 (Mrs. Mayer) Layer-3 Shareware Encoder/Decoder: - Mailbox System Nuernberg (MSN), Innerer Kleinreuther Weg 21 D-90408 Nuernberg, Germany Fax: +49-911-9933661 (Mr. Hanft) Shareware (version 1.50) is available for: - IBM-PCs or Compatibles with MS-DOS: L3ENC.EXE and L3DEC.EXE should work on practically any PC with 386 type CPU or better. For the encoder, a 486DX33 or better is recommended. On a 486DX2/66 the current shareware decoder performs in 1:3 real-time, and the shareware encoder in 1:14 real-time (with stereo signals sampled with 44.1 kHz). - Sun workstations: On a SPARC station 10, the decoder works in real time, the encoder performs in 1:5 real-time. For more information, refer to chapter 6. 5. Support by Fraunhofer-IIS Q: I understand that Fraunhofer-IIS has been the main developer of MPEG audio Layer-3. What can they do for me? A: The Fraunhofer-IIS focusses on applied research. Its engineers have profound expertise in real-time implementations of signal-processing algorithms, especially of Layer-3. The IIS may support a specific Layer-3 application in various ways: - detailed informations - technical consulting - advanced C sources for encoder and decoder - training-on-the-job - research and development projects on contract basis. For more informations, feel free to contact: - Fraunhofer-IIS, Weichselgarten 3 D-91058 Erlangen, Germany Fax: +49-9131-776-399 (Mr. Popp) Q: What are the latest audio demonstrations disclosed by Fraunhofer-IIS? A: At the Tonmeistertagung 11.94 in Karlsruhe, Germany, the IIS demonstrated: - real-time Layer-3 decoder software (mono, 32 kHz fs) including sound output on ProAudioSpectrum running on a 486DX2/66 - playback of Layer-3 stereo files from a CD-ROM that has been produced by Intermetall and contains Layer-3 data of up to 15 h of stereo music (among others, all Beethoven symphonies); the decoder is a small board that is connected to the parallel printer port. It mainly carries 3 chips: a PLD as data interface, the MAS 3503 C stereo decoder chip, and the ASCO Digital-Analog-Converter. The board has two cinch adapters that allow a very simple connection to the usual stereo amplifier. - music-from-silicon demonstration by using the standard 1 Mbyte EPROMs to store 1.5 minutes of CD-like quality stereo music - music link (with around 6 kHz bandwidth) via V.34 modem at 28.8 kbps and one analog phone line 6. Shareware Information The Layer 3 Shareware is copyright Fraunhofer - IIS 1994,1995. The shareware packages are available: - via anonymous ftp from 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: For IBM PCs: l3v150d1.txt a short description of the files found in l3v150.zip l3v150d1.zip encoder, decoder and documentation l3v150d2.txt a short description of the files found in l3v150n.zip l3v150d2.zip sample bitstreams For SUN workstations: l3v150.sun.txt short description of the files found in l3v100.sun.tar.gz l3v150.sun.tar.gz encoder, decoder and documentation l3v150bit.sun.txt short description of the files found in l3v150bit.sun.tar.gz l3v150bit.sun.tar.gz sample bitstreams - via direct modem download (up to 14.400 bps) Modem telephone number : +49 911 9933662 Name: FHG Packet switching network: (0) 262 45 9110 10290 Name: FHG (For the telephone number, replace "+" with your appropriate international dial prefix, e.g. "011" for the USA.) Follow the menus as desired. - via shipment of diskettes (only including registration) You may order a diskette directly from: Mailbox System Nuernberg (MSN) Hanft & Hartmann Innerer Kleinreuther Weg 21 D-90408 Nuernberg, Germany Please note: MSN will only ship a diskette if they get paid for the registration fee before. The registration fee is 85 Deutsche Mark (about 50 US$) (plus sales tax, if applicable) for one copy of the package. The preferred method of payment is via credit card. Currently, MSN accepts VISA, Master Card / Eurocard / Access credit cards. For details see the file REGISTER.TXT found in the shareware package. You may reach MSN also via Internet: msn@iis.fhg.de or via Fax: +49 911 9933661 or via BBS: +49 911 9933662 Name: FHG or via X25: 0262 45 9110 10290 Name: FHG (e.g. in USA, please replace "+" with "011" - via email You may get our shareware also by a direct request to msn@iis.fhg.de. In this case, the shareware is split into about 30 small uuencoded parts... SOFTWARE: MPEG Audio Layer 3 Shareware Codec and Windows Realtime Player ---------------------------------------------------------------- MPEG Audio Codec and Windows REALTIME Player from Fraunhofer IIS ---------------------------------------------------------------- Fraunhofer IIS announces l3enc/l3dec V2.00 and WinPlay3 V1.00. For high quality audio compression, the shareware l3enc/l3dec V2.00 package is available for Linux, SUN, NeXT and DOS on Versions for SGI and HP will follow soon. The shareware package for DOS includes a demo version of WinPlay3, a Windows MPEG Audio Layer 3 realtime-player. With MPEG Audio Layer 3 you can get a 12:1 compression with a CD like quality. Instead of 12 MByte / minute (stereo 44.1 kHz) you only need about 1 Mbyte / minute! More information can be found on or contact - via direct modem download (up to 14.400 bps) Modem telephone number : +49 911 9933662 Name: FHG Packet switching network: (0) 262 45 9110 10290 Name: FHG (For the telephone number, replace "+" with your appropriate international dial prefix, e.g. "011" for the USA.) Follow the menus as desired. - via shipment of diskettes (only including registration) You may order a diskette directly from: Mailbox System Nuernberg (MSN) Hanft & Hartmann Innerer Kleinreuther Weg 21 D-90408 Nuernberg, Germany Please note: MSN will only ship a diskette if they get paid for the registration fee before. The registration fee is 85 Deutsche Mark (about 50 US$) (plus sales tax, if applicable) for one copy of the package. The preferred method of payment is via credit card. Currently, MSN accepts VISA, Master Card / Eurocard / Access credit cards. For details see the file REGISTER.TXT found in the shareware package. You may reach MSN also via Internet: msn@iis.fhg.de or via Fax: +49 911 9933661 or via BBS: +49 911 9933662 Name: FHG or via X25: 0262 45 9110 10290 Name: FHG (e.g. in USA, please replace "+" with "011" - via email You may get our shareware also by a direct request to msn@iis.fhg.de. In this case, the shareware is split into about 30 small uuencoded parts... Harald Popp Audio & Multimedia ("Music is the *BEST*" - F. Zappa) Fraunhofer-IIS-A, Weichselgarten 3, D-91058 Erlangen, Germany Phone: +49-9131-776-340 Fax: +49-9131-776-399 email: popp@iis.fhg.de P.S.: Look out for planetoid #3834! ------------------------------------------------------------------------------- ~Subject: What is MPEG-1+ ? This was a little mail-talk between harti@harti.de (Stefan Hartmann) and hgordon@system.xingtech.com. Q: What is MPEG-1+ ? It's MPEG-1 at MPEG-2 (CCIR) resolution. It will maybe be used fir TV-on-top-boxes for broadcasting or video-on-demand projects to enhance the picture quality. Q: I see. Is this a new standard ? No. MPEG-1 allows the definition of frames until 4000x4000 pixel, but that is usally not used. Q; So what's different ? I understand that the effective resolution is approximately 550 x 480. Typical datarates are 3.5Mbps - 5.5Mbps (sports programming and perhaps movies are higher). Q: Is the video quality lower than with real MPEG-2 movies ? The quality is better than cable TV, and in my area, we don't have cable. They de-interlace and compress the full frames. My understanding is that this is about 5%-10% less efficient than taking advantage of MPEG-2 interfield motion vectors. Q: If the fields are deinterlaced, do you see the interlace artifacts, so that a moving object in one field is already more into one direction, than in the other field ? Probably the TV-receiver also gives it out interlaced again to the TV- set, so this does not produce this interlace artifact like on PCs with live video windows displaing both fields.... Q: Can you record this anyhow on a VCR ? Does the SAT-Receiver have a video- output, so you can record movies to tape ? You should be able to record to tape, though they may have some record blocking hardware which has to be overcome with video stabilizing hardware. Q: What kind of realtime encoders do they use at the broadcast station ? CLI (Compression Labs) is the manufacturer, using C-Cube chipsets (10 CL-4000's per MPEG-1+ encoder). Q: Is there any written info about this MPEG-1 Plus technology available on the net ? Not that I'm aware. Maybe C-Cube has a Web site. [So it's up to you, dear reader, to find more and to tell me where it is ;o) ] Frank Gadegast, phade@powerweb.de ------------------------------------------------------------------------------- ~Subject: What is MPEG-2? MPEG-2 FAQ version 3.7 (May 11, 1995) by Chad Fogg (cfogg@chromatic.com) The MPEG (Moving Pictures Experts Group) committee began its life in late 1988 by the hand of Leonardo Chairiglione and Hiroshi Yasuda with the immediate goal of standardizing video and audio for compact discs. Over the next few years, participation amassed from international technical experts in the areas of Video, Audio, and Systems, reaching over 200 participants by 1992. By the end of the third year (1990), a syntax emerged, which when applied to code SIF video and compact disc audio samples rates at a combined coded bitrate of 1.5 Mbit/sec, approximated the perceptual quality of consumer video tape (VHS). After demonstrations proved that the syntax was generic enough to be applied to bit rates and sample rates far higher than the original primary target application, a second phase (MPEG-2) was initiated within the committee to define a syntax for efficient representation of broadcast video. Efficient representation of interlaced (broadcast) video signals was more challenging than the progressive (non-interlaced) signals coded by MPEG-1. Similarly, MPEG-1 audio was capable of only directly representing two channels of sound. MPEG-2 would introduce a scheme to decorrelate mutlichannel discrete surround sound audio. Need for a third phase (MPEG-3) was anticipated in 1991 for High Definition Television, although it was later discovered by late 1992 and 1993 that the MPEG-2 syntax simply scaled with the bit rate, obviating the third phase. MPEG-4 was launched in late 1992 to explore the requirements of a more diverse set of applications, while finding a more efficient means of coding low bit rate/low sample rate video and audio signals. Today, MPEG (video and systems) is exclusive syntax of the United States Grand Alliance HDTV specification, the European Digital Video Broadcasting Group, and the high density compact disc (lead by rivals Sony/Philips and Toshiba). What is MPEG video syntax ? MPEG video syntax provides an efficient way to represent image sequences in the form of more compact coded data. The language of the coded bits is the syntax. For example, a few tokens can represent an entire block of 64 samples. MPEG also describes a decoding (reconstruction) process where the coded bits are mapped from the compact representation into the original, raw format of the image sequence. For example, a flag in the coded bitstream signals whether the following bits are to be decoded with a DCT algorithm or with a prediction algorithm. The algorithms comprising the decoding process are regulated by the semantics defined by MPEG. This syntax can be applied to exploit common video characteristics such as spatial redundancy, temporal redundancy, uniform motion, spatial masking, etc. MPEG Myths A brief summary myths. 1. Compression Ratios over 100:1 Articles in the press and marketing literature will often make the claim that MPEG can achieve high quality video with compression ratios over 100:1. These figures often include the oversampling factors in the source video. In reality, the coded sample rate specified in an MPEG image sequence is usually not much larger than 30 times the specified bit rate. Pre-compression through subsampling is chiefly responsible for 3 digit ratios for all video coding methods, including those of the non-MPEG variety. 2. MPEG-1 is 352x240 Both MPEG-1 and MPEG-2 video syntax can be applied at a wide range of bitrates and sample rates. The MPEG-1 that most people are familiar with has parameters of 30 SIF pictures (352 pixels x 240 lines) per second and a bitrate less than 1.86 megabits/sec----a combination known as "Constrained Parameters Bitstreams". This popular interoperability point is promoted by Compact Disc Video (White Book). In fact, it is syntactically possible to encode picture dimensions as high as 4095 x 4095 and a bitrates up to 100 Mbit/sec. With the advent of the MPEG-2 specification, the most popular combinations have coagulated into Levels, which are described later in this text. The two most common are affectionately known as SIF (e.g. 352 pixels x 240 lines x 30 frames/sec), or Low Level, and CCIR 601 (e.g. 720 pixels/line x 480 lines x 30 frames/sec), or Main Level. 3. Motion Compensation displaces macroblocks from previous pictures Macroblock predictions are formed out of arbitrary 16x16 pixel (or 16x8 in MPEG-2) areas from previously reconstructed pictures. There are no boundaries which limit the location of a macroblock prediction within the previous picture, other than the edges of the picture. 4. Display picture size is the same as the coded picture size In MPEG, the display picture size and frame rate may differ from the size (resolution) and frame rate encoded into the bitstream. For example, a regular pattern of pictures in a source image sequence may be dropped (decimated), and then each picture may itself be filtered and subsampled prior to encoding. Upon reconstruction, the picture may be interpolated and upsampled back to the source size and frame rate. In fact, the three fundamental phases (Source Rate, Coded Rate, and Display Rate) may differ by several parameters. The MPEG syntax can separately describe Coded and Display Rates through sequence_headers, but the Source Rate is known only by the encoder. 5. Picture coding types (I, P, B) all consist of the same macroblocks types. All macroblocks within an I picture must be coded Intra (like a baseline JPEG picture). However, macroblocks within a P picture may either be coded as Intra or Non-intra (temporally predicted from a previously reconstructed picture). Finally, macroblocks within the B picture can be independently selected as either Intra, Forward predicted, Backward predicted, or both forward and backward (Interpolated) predicted. The macroblock header contains an element, called macroblock_type, which can flip these modes on and off like switches. macroblock_type is possibly the single most powerful element in the whole of video syntax. Picture types (I, P, and B) merely enable macroblock modes by widening the scope of the semantics. The component switches are: 1. Intra or Non-intra 2. Forward temporally predicted (motion_forward) 3. Backward temporally predicted (motion_backward) (2+3 in combination represent “Interpolated”) 4. conditional replenishment (macroblock_pattern). 5. adaptation in quantization (macroblock_quantizer). 6. temporally predicted without motion compensation The first 5 switches are mostly orthogonal (the 6th is derived from the 1st and 2nd in P pictures, and does not exist in B pictures). Some switches are non-applicable in the presence of others. For example, in an Intra macroblock, all 6 blocks by definition contain DCT data, therefore there is no need to signal either the macroblock_pattern or any of the temporal prediction switches. Likewise, when there is no coded prediction error information in a Non-intra macroblock, the macroblock_quantizer signal would have no meaning. 6. Sequence structure is fixed to a specific I,P,B frame pattern. A sequence may consist of almost any pattern of I, P, and B pictures (there are a few minor semantic restrictions on their placement). It is common in industrial practice to have a fixed pattern (e.g. IBBPBBPBBPBBPBB), however, more advanced encoders will attempt to optimize the placement of the three picture types according to local sequence characteristics in the context of more global characteristics. Each picture type carries a penalty when coupled with the statistics of a particular picture (temporal masking, occlusion, motion activity, etc.). The variable length codes of the macroblock_type switch provide a direct clue, but it is the full scope of semantics of each picture type spell out the costs-benefits. For example, if the image sequence changes little from frame-to-frame, it is sensible to code more B pictures than P. Since B pictures by definition are never fed back into the prediction loop (i.e. not used as prediction for future pictures), bits spent on the picture are wasted in a sense (B pictures are like temporal spackle). Application requirements also govern picture type placement: random access points, mismatch/drift reduction, channel hopping, program indexing, and error recovery & concealment. The 6 Steps to Claiming Bogously High Compression Ratios: MPEG video is often quoted as achieving compression ratios over 100:1, when in reality the sweet spot rests between 8:1 and 30:1. Heres how the fabled greater than 100:1 reduction ratio is derived for the popular Compact Disc Video (White Book) bitrate of 1.15 Mbit/sec. Step 1. Start with the oversampled rate Most MPEG video sources originate at a higher sample rate than the "target sample rate encoded into the final MPEG bitstream. The most popular studio signal, known canonically as D-1 or CCIR 601 digital video, is coded at 270 Mbit/sec. The constant, 270 Mbit/sec, can be derived as follows: Luminance (Y): 858 samples/line x 525 lines/frame x 30 frames/sec x 10 bits/sample ~= 135 Mbit/sec R-Y (Cb): 429 samples/line x 525 lines/frame x 30 frames/sec x 10 bits/sample ~= 68 Mbit/sec B-Y (Cb): 429 samples/line x 525 lines/frame x 30 frames/sec x 10 bits/sample ~= 68 Mbit/sec Total: 27 million samples/sec x 10 bits/sample = 270 Mbit/sec. So, our compression ratio is: 270/1.15... an amazing 235:1 !! Step 2. Include blanking intervals Only 720 out of the 858 luminance samples per line contain active picture information. In fact, the debate over the true number of active samples is the cause of many hair-pulling cat-fights at TV engineering seminars and conventions, so it is safer to say that the number lies somewhere between 704 and 720. Likewise, only 480 lines out of the 525 lines contain active picture information. Again, the actual number is somewhere between 480 and 496. For the purposes of MPEG-1s and MPEG-2s famous conformance points (Constrained Parameters Bitstreams and Main Level, respectively), the number shall be 704 samples x 480 lines for luminance, and 352 samples x 480 lines for each of the two chrominance pictures. Recomputing the source rate, we arrive at: (luminance) 704 samples/line x 480 lines x 30 fps x 10 bits/sample ~= 104 Mbit/sec (chrominance) 2 components x 352 samples/line x 480 lines x 30 fps x 10 bits/sample ~= 104 Mbit/sec Total: ~ 207 Mbit/sec The ratio (207/1.15) is now only 180:1 Step 3. Include higher bits/sample The MPEG sample precision is 8 bits. Studio equipment often quantize samples with 10 bits of accuracy. The 2-bit improvement to the dynamic range is considered useful for suppressing noise in multi-generation video. The ratio is now only 180 * (8/10 ), or 144:1 Step 4. Include higher chroma ratio The famous CCIR-601studio signal represents the chroma signals (Cb, Cr) with half the horizontal sample density as the luminance signal, but with full vertical resolution. This particular ratio of subsampled components is known as 4:2:2. However, MPEG-1 and MPEG-2 Main Profile specify the exclusive use of the 4:2:0 format, deemed sufficient for consumer applications, where both chrominance signals have exactly half the horizontal and vertical resolution as luminance (the MPEG Studio Profile, however, centers around the 4:2:2 macroblock structure). Seen from the perspective of pixels being comprised of samples from multiple components, the 4:2:2 signal can be expressed as having an average of 2 samples per pixel (1 for Y, 0.5 for Cb, and 0.5 for Cr). Thanks to the reduction in the vertical direction (resulting in a 352 x 240 chrominance frame), the 4:2:0 signal would, in effect, have an average of 1.5 samples per pixel (1 for Y, and 0.25 for Cb and Cr each). Our source video bit rate may now be recomputed as: 720 pixels x 480 lines x 30 fps x 8 bits/sample x 1.5 samples/pixel = 124 Mbit/sec ... and the ratio is now 108:1. Step 5. Include pre-subsampled image size As a final act of pre-compression, the CCIR 601 frame is converted to the SIF frame by a subsampling of 2:1 in both the horizontal and vertical directions.... or 4:1 overall. Quality horizontal subsampling can be achieved by the application of a simple FIR filter (7 or 4 taps, for example), and vertical subsampling by either dropping every other field (in effect, dropping every other line) or again by an FIR filter (regulated by an interfield motion detection algorithm). Our ratio now becomes: 352 pixels x 240 lines x 30 fps x 8 bits/sample x 1.5 samples/pixel ~= 30 Mbit/sec !! .. and the ratio is now only 26:1 Thus, the true A/B comparison should be between the source sequence at the 30 Mbit/sec stage, the actual specified sample rate in the MPEG bitstream, and the reconstructed sequence produced from the 1.15 Mbit/sec coded bitstream. Step 6. Don’t forget the 3:2 pulldown A majority of high-end programs originates from film. Most of the movies encoded onto Compact Disc Video were in captured and reproduced at 24 frames/sec. So, in such an image sequence, 6 out of the 30 frames every second are in fact redundant and need not be coded into the MPEG bitstream, leading to the shocking discovery that the actual soure bit rate has really been 24 Mbit/sec all along, and the compression ratio a mere 21:1 !!! Even at the seemingly modest 20:1 ratio, discrepancies will appear between the 24 Mbit/sec source sequence and the reconstructed sequence. Only conservative ratios in the neighborhood of 8:1 have demonstrated true transparency for sequences with complex spatial-temporal characteristics (i.e. rapid, divergent motion and sharp edges, textures, etc.). However, if the video is carefully encoded by means of pre-processing and intelligent distribution of bits, higher ratios can be made to appear at least artifact-free. What are the parts of the MPEG document? The MPEG-1 specification (official title: ISO/IEC 11172 Information technology Coding of moving pictures and associated audio for digital storage media at up to about 1.5 Mbit/s, Copyright 1993.) consists of five parts. Each document is a part of the ISO/IEC number 11172. The first three parts reached International Standard in 1993. Part 4 reached IS in 1994. In mid 1995, Part 5 will go IS. Part 1---Systems: The first part of the MPEG standard has two primary purposes: 1). a syntax for transporting packets of audio and video bitstreams over digital channels and storage mediums (DSM), 2). a syntax for synchronizing video and audio streams. Part 2---Video: describes syntax (header and bitstream elements) and semantics (algorithms telling what to do with the bits). Video breaks the image sequence into a series of nested layers, each containing a finer granularity of sample clusters (sequence, picture, slice, macroblock, block, sample/coefficient). At each layer, algorithms are made available which can be used in combination to achieve efficient compression. The syntax also provides a number of different means for assisting decoders in synchronization, random access, buffer regulation, and error recovery. The highest layer, sequence, defines the frame rate and picture pixel dimensions for the encoded image sequence. Part 3---Audio: describes syntax and semantics for three classes of compression methods. Known as Layers I, II, and III, the classes trade increased syntax and coding complexity for improved coding efficiency at lower bitrates. The Layer II is the industrial favorite, applied almost exclusively in satellite broadcasting (Hughes DSS) and compact disc video (White Book). Layer I has similarities in terms of complexity, efficiency, and syntax to the Sony MiniDisc and the Philips Digitial Compact Cassette (DCC). Layer III has found a home in ISDN, satellite, and Internet audio applications. The sweet spots for the three layers are 384 kbit/sec (DCC), 224 kbit/sec (CD Video, DSS), and 128 Kbits/sec (ISDN/Internet), respectively. Part 4---Conformance: (circa 1992) defines the meaning of MPEG conformance for all three parts (Systems, Video, and Audio), and provides two sets of test guidelines for determining compliance in bitstreams and decoders. MPEG does not directly address encoder compliance. Part 5---Software Simulation: Contains an example ANSI C language software encoder and compliant decoder for video and audio. An example systems codec is also provided which can multiplex and demultiplex separate video and audio elementary streams contained in computer data files. As of March 1995, the MPEG-2 volume consists of a total of 9 parts under ISO/IEC 13818. Part 2 was jointly developed with the ITU-T, where it is known as recommendation H.262. The full title is: Information Technology--Generic Coding of Moving Pictures and Associated Audio. ISO/IEC 13818. The first five parts are organized in the same fashion as MPEG-1(System, Video, Audio, Conformance, and Software). The four additional parts are listed below: Part 6 Digital Storage Medium Command and Control (DSM-CC): provides a syntax for controlling VCR- style playback and random-access of bitstreams encoded onto digital storage mediums such as compact disc. Playback commands include Still frame, Fast Forward, Advance, Goto. Part 7 Non-Backwards Compatible Audio (NBC): addresses the need for a new syntax to efficiently de- correlate discrete mutlichannel surround sound audio. By contrast, MPEG-2 audio (13818-3) attempts to code the surround channels as an ancillary data to the MPEG-1 backwards-compatible Left and Right channels. This allows existing MPEG-1 decoders to parse and decode only the two primary channels while ignoring the side channels (parse to /dev/null). This is analogous to the Base Layer concept in MPEG-2 Scalable video. NBC candidates include non-compatible syntaxs such as Dolby AC-3. Final document is not expected until 1996. Part 8 10-bit video extension. Introduced in late 1994, this extension to the video part (13818-2) describes the syntax and semantics to coded representation of video with 10-bits of sample precision. The primary application is studio video (distribution, editing, archiving). Methods have been investigated by Kodak and Tektronix which employ Spatial scalablity, where the 8-bit signal becomes the Base Layer, and the 2-bit differential signal is coded as an Enhancement Layer. Final document is not expected until 1997 or 1998. [Part 8 will be withdrawn] Part 9 Real-time Interface (RTI): defines a syntax for video on demand control signals between set-top boxes and head-end servers. What is the evolution of an MPEG/ISO document? In chronological order: Abbr. ISO/Committee notation Author's notation ----- ------------------------------- ----------------------------- - Problem (unofficial first stage) barroom witticism or dare NI New work Item Napkin Item NP New Proposal Need Permission WD Working Draft We’re Drunk CD Committee Draft Calendar Deadlock DIS Draft International Standard Doesn't Include Substance IS International Standard Induced patent Statements Introductory paper to MPEG? Didier Le Gall, "MPEG: A Video Compression Standard for Multimedia Applications," Communications of the ACM, April 1991, Vol.34, No.4, pp. 47-58 MPEG in periodicals? The following journals and conferences have been known to contain information relating to MPEG: IEEE Transactions on Consumer Electronics IEEE Transactions on Broadcasting IEEE Transactions on Circuits and Systems for Video Technology Advanced Electronic Imaging Electronic Engineering Times (EE Times) IEEE Int'l Conference on Acoustics, Speech, and Signal Processing (ICASSP) International Broadcasting Convention (IBC) Society of Motion Pictures and Television Engineers Journal (SMPTE) SPIE conference on Visual Communications and Image Processing MPEG Book? Several MPEG books are under development. An MPEG book will be produced by the same team behind the JPEG book: Joan Mitchell and Bill Pennebaker.... along with Didier Le Gall. It is expected to be a tutorial on MPEG-1 video and some MPEG-2 video. Van Nostran Reinhold in 1995. A book, in the Japanese language, has already been published (ISBN: 4-7561-0247-6). The title is called MPEG by ASCII publishing. Keith Jack's second edition of Video Demystified, to be published in August 1995, will feature a large chapter on MPEG video. Information: ftp://ftp.pub.netcom/pub/kj/kjack/ MPEG is a DCT based scheme? The DCT and Huffman algorithms receive the most press coverage (e.g. "MPEG is a DCT based scheme with Huffman coding"), but are in fact less significant when compared to the variety of coding modes signaled to the decoder as context-dependent side information. The MPEG-1 and MPEG-2 IDCT has the same definition as H.261, H.263, JPEG. What are constant and variable bitrate streams? Constant bitrate streams are buffer regulated to allow continuos transfer of coded data across a constant rate channel without causing an overflow or underflow to a buffer on the receiving end. It is the responsibility of the Encoders Rate Control stage to generate bitstreams which prevent buffer overflow and underflow. The constant bit rate encoding can be modeled as a reservoir: variable sized coded pictures flow into the bit reservoir, but the reservoir is drained at a constant rate into the communications channel. The most challenging aspect of a constant rate encoder is, yes, to maintain constant channel rate (without overflowing or underflow a buffer of a fixed depth) while maintaining constant perceptual picture quality. In the simplest form, variable rate bitstreams do not obey any buffer rules, but will maintain constant picture quality. Constant picture quality is easiest to achieve by holding the macroblock quantizer step size constant (e.g. level 16 of 31). In its most advanced form, a variable bitrate stream may be more difficult to generate than constant bitrate streams. In advanced variable bitrate streams, the instantaneous bit rate (piece-wise bit rate) may be controlled by factors such as: 1. local activity measured against activity over large time intervals (e.g. the full span of a movie), or 2. instantaneous bandwidth availability of a communications channel. Summary of bitstream types Bitrate type Applications constant-rate fixed-rate communications channels like the original Compact Disc, digital video tape, single channel-per-carrier broadcast signal, hard disk storage simple variable-rate software decoders where the bitstream buffer (VBV) is the storage medium itself (very large). macroblock quantization scale is typically held constant over large number of macroblocks. complex variable-rate Statistical muliplexing (multiple-channel-per-carrier broadcast signals), compact discs and hard disks where the servo mechanisms can be controlled to increase or decrease the channel delivery rate, networked video where overall channel rate is constant but demand is variably share by multiple users, bitstreams which achieve average rates over very long time averages What is statistical multiplexing ? Progressive explanation: In the simplest coded bitstream, a PCM (Pulse Coded Modulated) digital signal, all samples have an equal number of bits. Bit distribution in a PCM image sequence is therefore not only uniform within a picture, (bits distributed along zero dimensions), but is also uniform across the full sequence of pictures. Audio coding algorithms such as MPEG-1s Layer I and II are capable of distributing bits over a one dimensional space, spanned by a frame. In layer II, for example, an audio channel coded at a bitrate of 128 bits/sec and sample rate of 44.1 Khz will have frames (which consist of 1152 subband coefficients each) coded with approximately 334 bits. Some subbands will receive more bits than others. In block-based still image compression methods which employ 2-D transform coding methods, bits are distributed over a 2 dimensional space (horizontal and vertical) within the block. Further, blocks throughout the picture may contain a varying number of bits as a result, for example, of adaptive quantization. For example, background sky may contain an average of only 50 bits per block, whereas complex areas containing flowers or text may contain more than 200 bits per block. In the typical adaptive quantization scheme, more bits are allocated to perceptually more complex areas in the picture. The quantization stepsizes can be selected against an overall picture normalization constant, to achieve a target bit rate for the whole picture. An encoder which generates coded image sequences comprised of independently coded still pictures, such as JPEG Motion video or MPEG Intra picture sequences, will typically generate coded pictures of equal bit size. MPEG non-intra coding introduces the concept of the distribution of bits across multiple pictures, augmenting the distribution space to 3 dimensions. Bits are now allocated to more complex pictures in the image sequence, normalized by the target bit size of the group of pictures, while at a lower layer, bits within a picture are still distributed according to more complex areas within the picture. Yet in most applications, especially those of the Constant Bitrate class, a restriction is placed in the encoder which guarantees that after a period of time, e.g. 0.25 seconds, the coded bitstream achieves a constant rate (in MPEG, the Video Buffer Verifier regulates the variable-to-constant rate mapping). The mapping of an inherently variable bitrate coded signal to a constant rate allows consistent delivery of the program over a fixed-rate communications channel. Statistical multiplexing takes the bit distribution model to 4 dimensions: horizontal, vertical, temporal, and program axis. The 4th dimension is enabled by the practice of mulitplexing multiple programs (each, for example, with respective video and audio bitstreams) on a common data carrier. In the Hughes' DSS system, a single data carrier is modulated with a payload capacity of 23 Mbits/sec, but a typical program will be transported at average bit rate of 6 Mbit/sec each. In the 4-D model, bits may be distributed according the relative complexity of each program against the complexities of the other programs of the common data carrier. For example, a program undergoing a rapid scene change will be assigned the highest bit allocation priority, whereas the program with a near-motionless scene will receive the lowest priority, or fewest bits. How does MPEG achieve compression? Here are some typical statistical conditions addressed by specific syntax and semantic tools: 1. Spatial correlation: transform coding with 8x8 DCT. 2. Human Visual Response---less acuity for higher spatial frequencies: lossy scalar quantization of the DCT coefficients. 3. Correlation across wide areas of the picture: prediction of the DC coefficient in the 8x8 DCT block. 4. Statistically more likely coded bitstream elements/tokens: variable length coding of macroblock_address_increment, macroblock_type, coded_block_pattern, motion vector prediction error magnitude, DC coefficient prediction error magnitude. 5. Quantized blocks with sparse quantized matrix of DCT coefficients: end_of_block token (variable length symbol). 6. Spatial masking: macroblock quantization scale factor. 7. Local coding adapted to overall picture perception (content dependent coding): macroblock quantization scale factor. 8. Adaptation to local picture characteristics: block based coding, macroblock_type, adaptive quantization. 9. Constant stepsizes in adaptive quantization: new quantization scale factor signaled only by special macroblock_type codes. (adaptive quantization scale not transmitted by default). 10. Temporal redundancy: forward, backwards macroblock_type and motion vectors at macroblock (16x16) granularity. 11. Perceptual coding of macroblock temporal prediction error: adaptive quantization and quantization of DCT transform coefficients (same mechanism as Intra blocks). 12. Low quantized macroblock prediction error: No prediction error for the macroblock may be signaled within macroblock_type. This is the macroblock_pattern switch. 13. Finer granularity coding of macroblock prediction error: Each of the blocks within a macroblock may be coded or not coded. Selective on/off coding of each block is achieved with the separate coded_block_pattern variable-length symbol, which is present in the macroblock only of the macroblock_pattern switch has been set. 14. Uniform motion vector fields (smooth optical flow fields): prediction of motion vectors. 15. Occlusion: forwards or backwards temporal prediction in B pictures. Example: an object becomes temporarily obscured by another object within an image sequence. As a result, there may be an area of samples in a previous picture (forward reference/prediction picture) which has similar energy to a macroblock in the current picture (thus it is a good prediction), but no areas within a future picture (backward reference) are similar enough. Therefore only forwards prediction would be selected by macroblock type of the current macroblock. Likewise, a good prediction may only be found in a future picture, but not in the past. In most cases, the object, or correlation area, will be present in both forward and backward references. macroblock_type can select the best of the three combinations. 16. Sub-sample temporal prediction accuracy: bi-linearly interpolated (filtered) "half-pel" block predictions. Real world motion displacements of objects (correlation areas) from picture-to-picture do not fall on integer pel boundaries, but on irrational . Half-pel interpolation attempts to extract the true object to within one order of approximation, often improving compression efficiency by at least 1 dB. 17. Limited motion activity in P pictures: skipped macroblocks. When the motion vector is zero for both the horizontal and vertical vector components, and no quantized prediction error for the current macroblock is present. Skipped macroblocks are the most desirable element in the bitstream since they consume no bits, except for a slight increase in the bits of the next non-skipped macroblock. 18. Co-planar motion within B pictures: skipped macroblocks. When the motion vector is the same as the previous macroblocks, and no quantized prediction error for the current macroblock is present. What is the difference between MPEG-1 and MPEG-2 syntax? Section D.9 of ISO/IEC 13818-2 is an informative piece of text describing the differences between MPEG-1 and MPEG-2 video syntax. The following is a little more informal. Sequence layer: MPEG-2 can represent interlaced or progressive video sequences, whereas MPEG-1 is strictly meant for progressive sequences since the target application was Compact Disc video coded at 1.2 Mbit/sec. MPEG-2 changed the meaning behind the aspect_ratio_information variable, while significantly reducing the number of defined aspect ratios in the table. In MPEG-2, aspect_ratio_information refers to the overall display aspect ratio (e.g. 4:3, 16:9), whereas in MPEG-2, the ratio refers to the particular pixel. The reduction in the entries of the aspect ratio table also helps interoperability by limiting the number of possible modes to a practical set, much like frame_rate_code limits the number of display frame rates that can be represented. Optional picture header variables called display_horizontal_size and display_vertical_size can be used to code unusual display sizes. frame_rate_code in MPEG-2 refers to the intended display rate, whereas in MPEG-1 it referred to the coded frame rate. In film source video, there are often 24 coded frames per second. Prior to bitstream coding, a good encoder will eliminate the redundant 6 frames or 12 fields from a 30 frame/sec video signal which encapsulates an inherently 24 frame/sec video source. The MPEG decoder or display device will then repeat frames or fields to recreate or synthesize the 30 frame/sec display rate. In MPEG-1, the decoder could only infer the intended frame rate, or derive it based on the Systems layer time stamps. MPEG-2 provides specific picture header variables called repeat_first_field and top_field_first which explicitly signal which frames or fields are to be repeated, and how many times. To address the concern of software decoders which may operate at rates lower or different than the common television rates, two new variables in MPEG-2 called frame_rate_extension_d and frame_rate_extension_n can be combined with frame_rate_code to specify a much wider variety of display frame rates. However, in the current set of define profiles and levels, these two variables are not allowed to change the value specified by frame_rate_code. Future extensions or Profiles of MPEG may enable them. In interlaced sequences, the coded macroblock height (mb_height) of a picture must be a multiple of 32 pixels, while the width, like MPEG-1, is a coded multiple of 16 pixels. A discrepancy between the coded width and height of a picture and the variables horizontal_size and vertical_size, respectively, occurs when either variable is not an integer multiple of macroblocks. All pixels must be coded within macroblocks, since there cannot be such a thing as fractional macroblocks. Never intended for display, these overhang pixels or lines exist along the left and bottom edges of the coded picture. The sample values within these trims can be arbitrary, but they can affect the values of samples within the current picture, and especially future coded pictures. In the current pictures, pixels which reside within the same 8x8 block as the overhang pixels are affect by the ripples of DCT quantization error. In future coded pictures, their energy can propagate anywhere within an image sequence as a result of motion compensated prediction. An encoder should fill in values which are easy to code, and should probably avoid creating motion vectors which would cause the Motion Compensated Prediction stage to extract samples from these areas. The application should probably select horizontal_size and vertical_size that are already multiples of 16 (or 32 in the vertical case of interlaced sequences) to begin with. Group of Pictures: The concept of the Group of Pictures layer does not exist in MPEG-2. It is an optional header useful only for establishing a SMPTE time code or for indicating that certain B pictures at the beginning of an edited sequence comprise a broken_link. This occurs when the current B picture requires prediction from a forward reference frame (previous in time to the current picture) has been removed from the bitstream by an editing process. In MPEG-1, the Group of Pictures header is mandatory, and must follow a sequence header. Picture layer: In MPEG-2, a frame may be coded progressively or interlaced, signaled by the progressive_frame variable. In interlaced frames (progressive_frame==0), frames may then be coded as either a frame picture (picture_structure==frame) or as two separately coded field pictures (picture_structure==top_field or picture_structure==bottom_field). Progressive frames are a logic choice for video material which originated from film, where all pixels are integrated or captured at the same time instant. Most electronic cameras today capture pictures in two separate stages: a top field consisting of all odd lines of the picture are nearly captured in the time instant, followed by a bottom field of all even lines. Frame pictures provide the option of coding each macroblock locally as either field or frame. An encoder may choose field pictures to save memory storage or reduce the end-to-end encoder-decoder delay by one field period. There is no longer such a thing called D pictures in MPEG-2 syntax. However, Main Profile @ Main Level MPEG-2 decoders, for example, are still required to decode D pictures at Main Level (e.g. 720x480x30 Hz). The usefulness of D pictures, a concept from the year 1990, had evaporated by the time MPEG-2 solidified in 1993. repeat_first_field was introduced in MPEG-2 to signal that a field or frame from the current frame is to be repeated for purposes of frame rate conversion (as in the 30 Hz display vs. 24 Hz coded example above). On average in a 24 frame/sec coded sequence, every other coded frame would signal the repeat_first_field flag. Thus the 24 frame/sec (or 48 field/sec) coded sequence would become a 30 frame/sec (60 field/sec) display sequence. This processes has been known for decades as 3:2 Pulldown. Most movies seen on NTSC displays since the advent of television have been displayed this way. Only within the past decade has it become possible to interpolate motion to create 30 truly unique frames from the original 24. Since the repeat_first_field flag is independently determined in every frame structured picture, the actual pattern can be irregular (it doesnt have to be every other frame literally). An irregularity would occur during a scene cut, for example. Slice: To aid implementations which break the decoding process into parallel operations along horizontal strips within the same picture, MPEG-2 introduced a general semantic mandatory requirement that all macroblock rows must start and end with at least one slice. Since a slice commences with a start code, it can be identified by inexpensively parsing through the bitstream along byte boundaries. Before, an implementation might have had to parse all the variable length tokens between each slice (thereby completing a significant stage of decoding process in advance) to know the exact position of each macroblock within the bitstream. In MPEG-1, it was possible to code a picture with only a single slice. Naturally, the mandatory slice per macroblock row restriction also facilitates error recovery. MPEG-2 also added the concept of the slice_id. This optional 6-bit element signals which picture a particular slice belongs to. In badly mangled bitstreams, the location of the picture headers could become garbled. slice_id allows a decoder to place a slice in the proper location within a sequence. Other elements in the slice header, such as slice_vertical_position, and the macroblock_address_increment of the first macroblock in the slice uniquely identify the exact macroblock position of the slice within the picture. Thus within a window of 64 pictures, a lost slice can find its way. Macroblock: motion vectors are now always represented along a half-pel grid. The usefulness of an integer-pel grid (option in MPEG-1) diminished with practice. A intrinsic half-pel accuracy can encourage use by encoders for the significant coding gain which half-pel interpolation offers. In both MPEG-1 and MPEG-2, the dynamic range of motion vectors is specified on a picture basis. A set of pictures corresponding to a rapid motion scene may need a motion vector range of up to +/- 64 integer pixels. A slower moving interval of pictures may need only a +/- 16 range. Due to the syntax by which motion vectors are signaled in a bitstream, pictures with little motion would suffer unnecessary bit overhead in describing motion vectors in a coordinate system established for a much wider range. MPEG-1s f_code picture header element prescribed a radius shared by horizontal and vertical motion vector components alike. It later became practice in industry to have a greater horizontal search range (motion vector radius) than vertical, since motion tends to be more prominent across the screen than up or down (vertical). Secondly, a decoder has a limited frame buffer size in which to store both the current picture under decoding and the set of pictures (forward, backward) used for prediction (reference) by subsequent pictures. A decoder can write over the pixels of the oldest reference picture as soon as it no longer is needed by subsequent pictures for prediction. A restricted vertical motion vector range creates a sliding window, which starts at the top of the reference picture and moves down as the macroblocks in the current picture are decoded in raster order. The moment a strip of pixels passes outside this window, they have ended their life in the MPEG decoding loop. As a result of all this, MPEG-2 created separate into horizontal and vertical range specifiers (f_code[][0] for horizontal, and f_code[][1] for vertical), and placed greater restrictions on the maximum vertical range than on the horizontal range. In Main Level frame pictures, this is range is [- 128,+127.5] vertically, and [-1024,+1023.5] horizontally. In field pictures, the vertical range is restricted to [- 64,+63.5]. Macroblock stuffing is now illegal in MPEG-2. The original intent behind stuffing in MPEG-1 was to provide a means for finer rate control adjustment at the macroblock layer. Since no self-respecting encoder would waste bits on such an element (it does not contribute to the refinement of the reconstructed video signal), and since this unlimited loop of stuffing variable length codes represent a significant headache for hardware implementations which have a fixed window of time in which to parse and decode a macroblock in a pipeline, the element was eliminated in January 1993 from the MPEG-2 syntax. Some feel that macroblock stuffing was beneficial since it permitted macroblocks to be coded along byte boundaries. A good compromise could have been a limited number of stuffs per macroblock. If stuffing is needed for purposes of rate control, an encoder can pad extra zero bytes before the start code of the next slice. If stuffing is required in the last row of macroblocks of the picture, the picture start code of the next picture can be padded with an arbitrary number of bytes. If the picture happens to be the last in the sequence, the sequence_end_code can be stuffed with zero bytes. The dct_type flag in both Intra and non-Intra coded macroblocks of frame structured pictures signals that the reconstructed samples output by the IDCT stage shall be organized in field or frame order. This flag provides an encoder with a sort of poor mans motion_type by adapting to the interparity (i.e. interfield) characteristics of the macroblock without signaling a need for motion vectors via the macroblock_type variable. dct_type plays an essential role in Intra frame pictures by organizing lines of a common parity together when there is significant interfield motion within the macroblock. This increases the decorrelation efficiency of the DCT stage. For non-intra macroblocks, dct_type organizes the 16 lines (... luminance, 8 lines chrominance) of the macroblock prediction error. In combination with motion_type, the meaning.... dct_type motion_format interpretation frame Intra coded block data is frame correlated field Intra coded block data is more strongly correlated along lines of opposite parity frame Field predicted 1. a low-cost encoder which only possesses frame motion estimation may use dct_type to decorrelate the prediction error of a prediction which is inherently field by characteristic 2. an intelligent encoder realizes that it is more bit efficient to signal frame prediction with field dct_type for the prediction error, than it is to signal a field prediction. field Field predicted A typical scenario. A field prediction tends to form a field-correlated prediction error. frame Frame predicted A typical scenario. A frame prediction tends to form a frame-correlated prediction error. field Frame predicted Makes little sense. If the encoder went through the trouble of finding a field prediction in the first place, why select frame organization for the prediction error? prediction modes now include field, frame, Dual Prime, and 16x8 MC. The combinations for Main Profile and Simple Profile are shown below. Frame pictures motion_type motion vectors per MB fundamental prediction block size (after half- pel) interpretation Frame 1 16x16 same as MPEG-1, with possibly different treatment of prediction error via dct_type Field 2 16x8 Two independently coded predictions are made: one for the 8 lines which correspond to the top field, another for the 8 bottom field lines. Dual Prime 1 16x8 Two independently coded predictions are made: one for the 8 lines which correspond to the top field, another for the 8 bottom field lines. Uses averaging of two 16x8 prediction blocks from fields of opposite parity to form a prediction for the top and bottom 8 lines. A second vector is derived from the first vector coded in the bitstream. Field pictures motion_type motion vectors per MB fundamental prediction block size (after half- pel) interpretation Field 1 16x16 same as MPEG-1, with possibly different treatment of prediction error via dct_type 16x8 2 16x8 Two independently coded predictions are made: one for the 8 lines which correspond to the top field, another for the 8 bottom field lines. Dual Prime 1 16x16 A single prediction is constructed from the average of two 16x16 predictions taken from fields of opposite parity. concealment motion vectors can be transmitted in the headers of intra macroblocks to help error recovery. When the macroblock data that the concealment motion vectors are intended for becomes corrupt, these vectors can be used to specify a concealment 16x16 area to be extracted from the previous picture. These vectors do not affect the normal decoding process, except for motion vector predictions. Additional chroma_format for 4:2:2 and 4:4:4 pictures. Like MPEG-1, Main Profile syntax is strictly limited to 4:2:0 format, however, the 4:2:2 format is the basis of the 4:2:2 Profile (aka Studio Profile). In 4:2:2 mode, all syntax essentially remains the same except where matters of block count are concerned. A coded_block_pattern extension was added to handle signaling of the extra two prediction error blocks. The 4:4:4 format is currently undefined in any Profile. chroma_format multiplex order within Macroblock Application 4:2:0 (6 blocks) YYYYCbCr main stream television, consumer entertainment. 4:2:2 (8 blocks) YYYYCbCrCbCr studio production environments, professional editing equipment, distribution and servers 4:4:4 (12 blocks) YYYYCbCrCbCrCbCrCbCr computer graphics Non-linear macroblock quantization was introduced in MPEG-2 to increase the precision of quantization at high bit rates, while increasing the dynamic range for low bit rate use where larger step size is needed. The quantization_scale_code may be selected between a linear (MPEG-1 style) or non-linear scale on a picture (frame or field) basis. The new non-linear range corresponds to a dynamic range of 0.5 to 54 with respect to the linear (MPEG-1 style) range of 1 to 31. Block: alternate scan introduced a new run-length entropy scanning pattern generally more efficient for the statistics of interlaced video signals. Zig-zag scan is the appropriate choice for progressive pictures. intra_dc_precision: the MPEG-1 DC value is mandatory quantized to a precision of 8 bits. MPEG-2 introduced 9, 10, and 11 bit precision set on a picture basis to increase the accuracy of the DC component, which by very nature, has the most significant contribution towards picture quality. Particularly useful at high bit rates to reduce posterization. Main and Simple Profiles are limited to 8, 9, or 10 bits of precision. The 4:2:2 High Profile, which is geared towards higher bitrate applications (up to 50 Mbits/sec), permits all values (up to 11 bits). separate quantization matrices for Y and C: luminance (Y) and chrominance (Cb,Cr) share a common intra and non-intra DCT coefficient quantization 8x8 matrix in MPEG-1 and MPEG-2 Main and Simple Profiles. The 4:2:2 Profile permits separate quantization matrices to be downloaded for the luminance and chrominance blocks. Cb and Cr still share a common matrix. intra_vlc_format: one of two tables may now be selected at the picture layer for variable length codes (VLCs) of AC run-length symbols in Intra blocks. The first table is identical to that specified for MPEG-1 (dc_coef_next). The newer second table is more suited to the statistics of Intra coded blocks, especially in I- frames. The best illustration between Table 0 and Table 1is the length of the symbol which represents End of Block (EOB). In Table zero, EOB is 2 bits. In Table one, it is 4 bits. The implication is that the EOB symbol is 2^-n probable within the block, or from an alternative perspective, there are an average of 3 to 4 non-zero AC coefficients in Non-intra blocks, and 9 to 16 coefficients in Intra blocks. The VLC tree of Table 1 was intended to be a subset of Table 0, to aid hardware implementations. Both tables have 113 VLC entries (or events). escape: When no entry in the VLC exists for a AC Run-Level symbol, an escape code can be used to represent the symbol. Since there are only 63 positions within an 8x8 block following the first coefficient, and the dynamic range of the quantized DCT coefficients is [-2047,+2048], there are (63*2047), or 128,961 possible combinations of Run and Level (the sign bit of the Level follows the VLC). Only the 113 most common Run-Level symbols are represented in Table 0 or Table 1. The length of the escape symbol (which is always 6 bits) plus the Run and Level values in MPEG-1 could be 20 or 28 bits in length. The 20 bit escape describes levels in the range [-127,+127]. The 28 bit double escape has a range of [-255, +255]. MPEG-2 increased the span to the full dynamic range of quantized IDCT coefficients, [-2047, +2047] and simplified the escape mechanism with a single representation for this event. The total length of the MPEG-2 escape codeword is 24 bits (6 bit VLC followed by a 6-bit Run value, and 12 bit Level value). It was an assumption by MPEG-1 designers that no quantized DCT coefficient would need greater representation than 10 bits [-255,+255]. Note: MPEG-2 escape mechanism does not permit the value -2048 to be represented. mismatch control: The arithmetic results of all stages are defined exactly by the normative MPEG decoding process, with the single exception of the Inverse Discrete Cosine Transform (IDCT). This stage can be implemented with a wide variety of IDCT implementations. Some are more suited for software, others for programmable hardware, and others still for hardwired hardware designs. The IDCT reference formula in the MPEG specification would, if directly implemented, consume at least 1024 multiply and 1024 addition operations for every block. A wide variety of fast algorithms exist which can reduce the count to less than 200 multiplies and 500 adds per block by exploiting the innate symmetry of the cosine basis functions. A typical fast IDCT algorithm would be dwarfed by the cost of the other decoder stages combined. Each fast IDCT algorithm has different quantization error statistics (fingerprint), although subtle when the precision of the arithmetic is, for example, at least 16-bits for the transform coefficients and 24-bits for intermediate dot product values. Therefore, MPEG cannot standardize a single fast IDCT algorithm. The accuracy can be defined only statistically. The IEEE 1180 recommendation (December 1990) defines the error tolerance between an ideal direct-matrix floating point implementation (a direct implementation of the MPEG reference formula) and the test IDCT. Mismatch control attempts to reduce the drift between different IDCT algorithms by eliminating bit patterns which statistically have the greatest contribution towards mismatches between the variety of methods. The reconstructions of two decoders will begin to diverge over time since their respective IDCT designs will reconstruct occasional, slightly different 8x8 blocks. MPEG-1s mismatch control method is known canonicially as Oddification, since it forces all quantized DCT coefficients to negative values. It is a slight improvement over its predecessor in H.261. MPEG-2 adopted a different method called, again canonically, LSB Toggling, further reducing the likelihood of mismatch. Toggling affects only the Least Significant Bit (LSB) of the 63rd AC DCT coefficient (the highest frequency in the DCT matrix). Another significant difference between MPEG-1 and MPEG-2 mismatch control is, in MPEG-1, oddification is performed on the quantized DCT coefficients, whereas in MPEG-2, toggling is performed on the DCT coefficients after inverse quantization. MPEG-1s mismatch control method favors programmable implementation since a block of DCT coefficients when quantized. Sample: The two chrominace pictures (Cb, Cr) possess only half the resolution in both the horizontal and vertical direction as the luminance picture (Y). This is the definition of the 4:2:0 chroma format. Most television displays require that at least the vertical chrominance resolution matches the luminance (4:2:2 chroma format). Computer displays may further still demand that the horizontal resolution also be equivalent (4:4:4 chroma format). There are a variety of filtering methods for interpolating the chrominance samples to match the sample density of luminance. However, the official location or center of the lower resolution chrominance sample should influence the filter design (relative taps weights), otherwise the chrominance plane can appear to be shifted by a fractional sample in the wrong direction. The subsampled MPEG-1 chroma position has a center exactly half way between the four nearest neighboring luminance samples. To be consistent with the subsampled chrominance positions of 4:2:2 television signals, MPEG-2 moved the center of the chrominance samples to be co-located horizontally with the luminance samples. Misc.: copyright_id extension can identify whether a sequence or subset of frames within the sequence is copyrighted, and provides a unique 64-bit copyright_id_number registered with the ISO/IEC. Syntax can now signal frame sizes as large as 16383 x 16383. Since MPEG-1 employed a meager 12-bits to describe horizontal_size and vertical_size , the range was limited to 4095x4095. However, MPEGs Levels prescribe important interoperability points for practical decoders. Constrained Parameters MPEG-1 and MPEG-2 Low Level limit the sample rate to 352x240x30 Hz. MPEG-2s Main Level defines the limit at 720x480x30 Hz. Of course, this is simply the restriction of the dot product of horizontal_size, vertical_size, and frame_rate. The Level also places separate restrictions on each of the these three variables. Reflecting the more television oriented manner of MPEG-2, the optional sequence_display_extension() header can specify the chromaticy of the source video signal as it was prior to representation by MPEG syntax. This information includes: whether the original video_format was composite or component, the opto-electronic transfer_characteristics, and RGB->YCbCr matrix_coefficients. The picture_display_extension() provides more localized source composite video characteristics on a frame by frame basis (not field-by-field), with the syntax elements: field_sequence, sub_carrier_phase, and burst_amplitude. This information can be used by the displays post-processing stage to reproduce a more refined display sequence. Optional pan & scan syntax was introduced which tells a decoder on a frame-by-frame basis how to, for example, window a 4:3 image within the wider 16:9 aspect ratio of the coded frame. The vertical pan offset can be specified to within 1/16th pixel accuracy. How does MPEG syntax facilitate parallelism ? For MPEG-1, slices may consist of an arbitrary number of macroblocks. They can be independently decoded once the picture header side information is known. For parallelism below the slice level, the coded bitstream must first be mapped into fixed-length elements. Further, since macroblocks have coding dependencies on previous macroblocks within the same slice, the data hierarchy must be pre-processed down to the layer of DC DCT coefficients. After this, blocks may be independently inverse transformed and quantized, temporally predicted, and reconstructed to buffer memory. Parallelism is usually more of a concern for encoders. In many encoders today, block matching (motion estimation) and some rate control stages (such as activity and/or complexity measures) are processed for macroblocks independently. Finally, with the exception that all macroblock rows in Main Profile MPEG-2 bitstreams must contain at least one slice, an encoder has the freedom to choose the slice structure. What is the MPEG color space and sample precision? MPEG strictly specifies the YCbCr color space, not YUV or YIQ or YPbPr or YDrDb or any other many fine varieties of color difference spaces. Regardless of any bitstream parameters, MPEG-1 and MPEG-2 Video Main Profile specify the 4:2:0 chroma_format, where the color difference channels (Cb, Cr) have half the "resolution" or sample grid density in both the horizontal and vertical direction with respect to luminance. MPEG-2 High Profile includes an option for 4:2:2 chroma_format, as does the MPEG 4:2:2 Profile (a.k.a. Studio Profile) naturally. Applications for the 4:2:2 format can be found in professional broadcasting, editing, and contribution-quality distribution environments. The drawback of the 4:2:2 format is simply that it increases the size of the macroblock from six 8x8 blocks (4:2:0) to eight, while increasing the frame buffer size and decoding bandwidth by the same amount (33 %). This increase places the buffering memories well past the magic 16-Mbit limit for semiconductor DRAM devices, assuming the pictures are stored with a maximum of 414,720 pixels (720 pixels/line x 576 lines/frame). The maximum allowable pixel resolution could be reduced by 1/3 to compensate (e.g. 544 x 576). However, if a hardware decoders operate on a macroblock basis in the pipeline, on-chip static memories (SRAM) will increase by 1/3. The benefits offered by 1/3 more pixels generally outweighs full vertical chrominance resolution. Other arguments favoring 4:2:0 over 4:2:2 include: Vertical decimation increases compression efficiency by reducing syntax overhead posed in an 8 block (4:2:2) macroblock structure. You're compressing the hell out of the video signal, so what possible difference can the 0:0:2 chromiance high-pass make? Is 4:2:0 the same as 4:1:1 ? No, no, definitely no. The following table illustrates the nuances between the different chroma formats for a frame with pixel dimensions of 720 pixels/line x 480 lines/frame. CCIR 601 (60 Hz) image Chroma sub-sampling factors format Y Cb, Cr Vertical Horizontal chroma format pixels/ line Y lines/ frame Y pixels/ line Cb, Cr lines/ frame Cb, Cr horizontal subsampling factor vertical subsampling factor 4:4:4 720 480 720 480 none none 4:2:2 720 480 360 480 2:1 none 4:2:0 720 480 360 240 2:1 2:1 4:1:1 720 480 180 480 4:1 none 4:1:0 720 480 180 120 4:1 4:1 3:2:2, 3:1:1, and 3:1:0 are less common variations, but have been documented. As shocking as it may seem, the 4:1:0 ratio was used by Intels DVI for several years. The 130 microsecond gap between successive 4:2:0 lines in progressive frames, and 260 microsecond gap in interlaced frames, can introduce some difficult vertical frequencies, but most can be alleviated through pre- processing. What is the sample precision of MPEG ? How many colors can MPEG represent ? By definition, MPEG samples have no more and no less than 8-bits uniform sample precision (256 quantization levels). For luminance (which is unsigned) data, black corresponds to level 0, white is level 255. However, in CCIR recommendation 601 chromaticy, luminance (Y) levels 0 through 14 and 236 through 255 are reserved for blanking signal excursions. MPEG currently has no such clipped excursion restrictions, although decoder might take care to insure active samples do not exceed these limits. With three color components per pixel, the total combination is roughly 16.8 million colors (i.e. 24-bits). How are the subsampled chroma samples cited ? It is moderately important to properly co-site chroma samples, otherwise a sort of chroma shifting effect (exhibited as a halo) may result when the reconstructed video is displayed. In MPEG-1 video, the chroma samples are exactly centered between the 4 luminance samples (Fig 1.) To maintain compatibility with the CCIR 601 horizontal chroma locations and simplify implementation (eliminate need for phase shift), MPEG-2 chroma samples are arranged as per Fig.2. Y Y Y Y Y Y Y Y YC Y YC Y C C C C Y Y X Y Y Y Y Y YC Y YC Y Y Y Y Y Y Y Y Y YC Y YC Y C C C C Y Y Y Y Y Y Y Y YC Y YC Y Fig.1 MPEG-1 Fig.2 MPEG-2 Fig.3 MPEG-2 and 4:2:0 organization 4:2:0 organization CCIR Rec. 601 4:2:2 organization How do you tell an MPEG-1 bitstream from an MPEG-2 bitstream ? A. All MPEG-2 bitstreams must contain specific extension headers that immediately follow MPEG-1 headers. At the highest layer, for example, the MPEG-1 style sequence_header() is followed by sequence_extension(). Some extension headers are specific to MPEG-2 profiles. For example, sequence_scalable_extension() is not allowed in Main Profile bitstreams. A simple program need only scan the coded bitstream for byte-aligned start codes to determine whether the stream is MPEG-1 or MPEG-2. What are start codes? These 32-bit byte-aligned codes provide a mechanism for cheaply searching coded bitstreams for commencement of various layers of video without having to actually parse variable-length codes or perform any decoder arithmetic. Start codes also provide a mechanism for resynchronization in the presence of bit errors. A start code may be preceded by an arbitrary number of zero bytes. The zero bytes can be use to guarantee that a start code occurs within a certain location, or by rate control to increase the bitrate of a coded bitstream. Coded block pattern Coded block pattern: (CBP --not to be confused with Constrained Parameters!) When the frame prediction is particularly good, the displaced frame difference(DFD, or temporal macroblock prediction error) tends to be small, often with entire block energy being reduced to zero after quantization. This usually happens only at low bit rates. Coded block patterns prevent the need for transmitting EOB symbols in those zero coded blocks. Coded block patterns are transmitted in the macroblock header only if the macrobock_type flag indicates so. Why is the DC value always divided by 8 ? Clarification point: The DC value of Intra coded blocks is quantized by a constant stepsize of 8 only in MPEG-1, rendering the 11-bit dynamic range of the IDCT DC coefficient to 8-bits of accuracy. MPEG-2 allows for DC precision of 8, 9, 10, or 11 bits. The quantization stepsize is fixed for the duration of the picture, set by the intra_dc_precision flag in the picture_extension_header(). Why is there a special VLC for DCT_coefficient_first:? Since the coded_block_pattern in NON-INTRA macroblocks signals every possible combination of all-zero valued and non-zero blocks, the dct_coef_first mechanism assigns a different meaning to the VLC codeword (run = 0, level =+/- 1) that would otherwise represent EOB (10) as the first coefficient in the zig-zag ordered Run-Level token list. What’s the deal with End of Block ? Saves unnecessary run-length codes. At optimal bitrates, there tends to be few AC coefficients concentrated in the early stages of the zig-zag vector. In MPEG-1, the 2-bit length of EOB implies that there is an average of only 3 or 4 non-zero AC coefficients per block. In MPEG-2 Intra (I) pictures, with a 4-bit EOB code in Table 1, this estimate is between 9 and 16 coefficients. Since EOB is required for all coded blocks, its absence can signal that a syntax error has occurred in the bitstream. What’s this “Macroblock stuffing,” dammit ?: A genuine pain for VLSI implementations, macroblock stuffing was included in MPEG-1 to maintain smoother, constant bitrate control for encoders. However, with normalized complexity/activity measures and buffer management performed a priori (before coding of the macroblock, for example) and local monitoring of coded data buffer levels now a common operation in encoders, (e.g. MPEG-2 encoder Test Model), the need for such localized bitrate smoothing evaporated. Stuffing can be achieved through slice start code padding if required. A good rule of thumb is: if you find often yourself wishing for stuffing more than once per slice, you probably don't have a very good rate control algorithm. Nonetheless, to avoid any temptation, macroblock stuffing is now illegal in MPEG-2 (A general syntax restriction brought to you by the Implementation Studies Subgroup!) What’s the deal with slice_vertical_position and macroblock_address_increment? The absolute position of the first macroblock within a slice is known by the combination of slice_vertical_position and the macroblock_address_increment. Therefore, the proper place of a lost slice found in a highly corrupt bitstream can be located exactly within the picture. These two syntax elements are also the only known means of detecting slice gaps----areas of the picture which are not represented with any information (including skipped macroblocks). A slice gap occurs when the current macroblock address of the first macroblock in a slice is greater than the previous macroblock address by more than 1 macroblock unit. A slice overlap occurs when the current macroblock address is less than or equal to the previous macroblocks address. The previous macroblock in both instances is the last known macroblock within the previous slice. Because of the semantic interpretation of slice gaps and overlaps, and because of the syntactic restrictions for slice_vertical_position and macroblock_address_increment, it is not syntactically possible for a skipped macroblock to be represented in the first and last positions of a slice. In the past, some (bad) encoders would attempt to signal a run of skipped macroblocks to the end of the slice. These evil skipped macroblocks should be interpreted by a compliant decoder as a gap, not as a string of skipped macroblocks. What is meant by modified Huffman VLC tables: The VLC tables in MPEG are not Huffman tables in the true sense of Huffman coding, but are more like the tables used in Group 3 fax. They are entropy constrained, that is, non-downloadable and optimized for a limited range of bit rates (sweet spots). A better way would be to say that the tables are optimized for a range of ratios of bit rate to sample rate (e.g. 0.25 bits/pixel to 1.0 bits/pixel). With the exception of a few codewords, the larger tables were carried over from the H.261 standard drafted in the year 1990. This includes the AC run-level symbols, coded_block_pattern, and macroblock_address_increment. MPEG-2 added an "Intra table," also called "Table 1". Note that the dct_coefficient tables assume positive/negative coefficient PMF symmetry. How does MPEG handle 3:2 pulldown? MPEG-1 video decoders had to decide for themselves when to perform 3:2 pulldown if it was not indicated in the presentation time stamps (PTS) of the Systems layer bitstream. MPEG-2 provides two flags (repeat_first_field, and top_field_first) which explicitly describe whether a frame or field is to be repeated. In progressive sequences, frames can be repeated 2 or 3 times. Simple and Main Profile limit are limited to repeated fields only. It is a general syntactic restriction that repeat_first_field can only be signaled (value ==1) in a frame structured picture. It makes little sense to repeat field pictures in an interlaced video signal since the whole process of 3:2 pulldown conversion was meant to convert progressive, film sequences to the display frame rate of interlaced television. In the most common scenario, a film sequence will contain 24 frames every second. The bit_rate element in the sequence header will indicate 30 frames/sec, however. On average, every other coded frame will signal a repeat field (repeat_first_field==1) to pad the frame rate from 24 Hz to 30 Hz: (24 coded frames/sec)*(2 fields/coded frame)*(5 display fields/4 coded fields) = 30 display frames/sec After all this standardization, what’s left for research? A . Despite the fact that a comprehensive worldwide standard now exists for digital video, many areas remain wide open for research: advanced encoding and pre-processing, motion estimation, macroblock decision models, rate control and buffer management in editing environments, implementation complexity reduction, etc. Many areas have yet to be solved ... (and discovered).. Are some encoders better than others ? A. Definitely. For example, the motion estimation search range of a has great influence over final picture quality. At a certain point a very large range can actually become detrimental (it may encourage large differential motion vectors). Practical ranges are usually between +/- 15 and +/- 32. As the range doubles, for instance, the search area quadruples. (like the classic relationship between in increase in linear vs. area). Rate control marks a second tell-tale area where some encoders perform significantly better than others. And finally, the degree of "pre-processing" (now a popular buzzword in the business) signals that the encoder belongs to an elite marketing class. Is the encoder standardized ? A. The encoder rests just outside the normative scope of the standard, as long as the bitstreams it produces are compliant. The decoder, however, is almost deterministic: a given bitstream should reconstruct to a unique set of pictures. However, since the IDCT function is the ONLY non-normative stage in the decoder, an occasional error of a Least Significant Bit per prediction iteration is permitted. The designer is free to choose among many DCT algorithms and implementations. The IEEE 1180 test referenced in Annex A of the MPEG-1 (ISO/IEC 11172-2) and MPEG-2 (ISO/IEC 13818-2) Video specifications spells out the statistical mismatch tolerance between the Reference IDCT, which is a separable 8x1 "Direct Matrix" DCT implemented with 64-bit floating point accuracy, and the IDCT you are testing for compliance. What is the TM (Test Model) ? What is the TM rate control and adaptive quantization technique ? A. The Test model (MPEG-2) and Simulation Model (MPEG-1) were not, by any stretch of the imagination, meant to epitomize state-of-the art encoding quality. They were, however, designed to exercise the syntax, verify proposals, and test the relative compression performance of proposals in a timely manner that could be duplicated by co-experimenters. Without simplicity, there would have been no doubt endless debates over model interpretation. Regardless of all else, more advanced techniques would probably trespass into proprietary territory. The final test model for MPEG-2 is TM version 5b, a.k.a. TM version 6, produced in March 1993 (the time when the MPEG-2 video syntax was frozen). The final MPEG-1 simulation model is version 3 (SM-3). The MPEG-2 TM rate control method offers a dramatic improvement over the SM method. TM adds more accurate estimation of macroblock complexity through use of limited a priori information. Macroblock quantization adjustments are computed on a macroblock basis, instead of once-per-macroblock row (which in the SM-3 case consisted of an entire slice). How does the TM work? Rate control and adaptive quantization are divided into three steps: Step One: Target Bit Allocation In Complexity Estimation, the global complexity measures assign relative weights to each picture type (I,P,B). These weights (Xi, Xp, Xb) are reflected by the typical coded frame size of I, P, and B pictures (see typical frame size discussion). I pictures are usually assigned the largest weight since they have the greatest stability factor in an image sequence and contain the most new information in a sequence. B pictures are assigned the smallest weight since B energy do not propagate into other pictures and are usually more highly correlated with neighboring P and I pictures than P pictures are. The bit target for a frame is based on the frame type, the remaining number of bits left in the Group of Pictures (GOP) allocation, and the immediate statistical history of previously coded pictures (sort of a moving average global rate control, if you will). Step Two: Rate Control via Buffer Monitoring Rate control attempts to adjust bit allocation if there is significant difference between the target bits (anticipated bits) and actual coded bits for a block of data. If the virtual buffer begins to overflow, the macroblock quantization step size is increased, resulting in a smaller yield of coded bits in subsequent macroblocks. Likewise, if underflow begins, the step size is decreased. The Test Model approximates that the target picture has spatially uniform distribution of bits. This is a safe approximation since spatial activity and perceived quantization noise are almost inversely proportional. Of course, the user is free to design a custom distribution, perhaps targeting more bits in areas that contain more complex yet highly perceptible data such as text. Step Three: Adaptive Quantization The final step modulates the macroblock quantization step size obtained in Step 2 by a local activity measure. The activity measure itself is normalized against the most recently coded picture of the same type (I, P, or B). The activity for a macroblock is chosen as the minimum among the four 8x8 block luminance variances. Choosing the minimum block is part of the concept that a macroblock is no better than the block of highest visible distortion (weakest link in the chain). Decision: [deferred to later date] Can motion vectors be used to determine object velocity? Motion vector information cannot be reliably used as a means of determining object velocity unless the encoder model specifically set out to do so. First, encoder models that optimize picture quality generate vectors that typically minimize prediction error and, consequently, the vectors often do not represent true object translation from picture-to-picture. Standards converters that resample one frame rate to another (as in NTSC to PAL) use different methods (motion vector field estimation, edge detection, et al) that are not concerned with Rate-Distortion theory. Second, motion vectors are not transmitted for all macroblocks anyway. Is it possible to code interlaced video with MPEG-1 syntax? A. Two methods can be applied to interlaced video that maintain syntactic compatibility with MPEG-1 (which was originally designed for progressive frames only). In the field concatenation method, the encoder model can carefully construct predictions and prediction errors that realize good compression but maintain field integrity (distinction between adjacent fields of opposite parity). Some pre-processing techniques can also be applied to the interlaced source video that would, e.g., lessen sharp vertical frequencies. This technique is not terribly efficient of course. On the other hand, if the original source was progressive (e.g. film), then it is more trivial to convert the interlaced source to a progressive format before encoding. (MPEG-2 would then only offer slightly superior performance through such MPEG-2 enhancements as greater DC coefficient precision, non-linear mquant, intra VLC, etc.) Reconstructed frames are usually re- interlaced in the Display process following the decoding stages. The second syntactically compatible method codes fields as separate pictures. Rumors have spread that this approach does not quiet work nearly as well as the pretend its really a frame method. Can MPEG be used to code still frames ? Yes. MPEG Intra pictures are similar to baseline sequential JPEG pictures. There are, of course, advantages and disadvantages to using MPEG over JPEG to represent still pictures. Disadvantages: 1. MPEG has only one color space (YCbCr) 2. MPEG-1 and MPEG-2 Main Profile luma and chroma share quanitzation and VLC tables (4:2:0 chroma_format) 3. MPEG-1 is syntactically limited to 4k x 4k images, and 16k x 16k for MPEG-2. Advantages: 1. MPEG possesses adaptive quantization which permits better rate control and spatial masking. 2. With its limited still image syntax, MPEG averts any temptation to use unnecessary, expensive, and academic encoding methods that have little impact on the overall picture quality (you know who you are). 3. Philips' CD-I spec. has a requirement for a MPEG still frame mode, with double SIF image resolution. This is technically feasible mostly thanks to the fact that only one picture buffer is needed to decode a still image instead of the 2.5 to 3 buffers needed for IPB sequences. Why was the 8x8 DCT size chosen? A. Experiments showed little compaction gains could be achieved with larger transform sizes, especially in light of the increased implementation complexity. A fast DCT algorithm will require roughly double the number of arithmetic operations per sample when the linear transform point size is doubled. Naturally, the best compaction efficiency has been demonstrated using locally adaptive block sizes (e.g. 16x16, 16x8, 8x8, 8x4, and 4x4) [See Gary Sullivan and Rich Baker "Efficient Quadtree Coding of Images and Video," ICASSP 91, pp 2661-2664.]. Inevitably, adaptive block transformation sizes introduce additional side information overhead while forcing the decoder to implement programmable or hardwired recursive DCT algorithms. If the DCT size becomes too large, then more edges (local discontinuities) and the like become absorbed into the transform block, resulting in wider propagation of Gibbs (ringing) and other unpleasant phenomena. Finally, with larger transform sizes, the DC term is even more critically sensitive to quantization noise. Why was the 16x16 prediction size chosen? The 16x16 area corresponds to the Least Common Multiple (LCM) of 8x8 blocks, given the normative 4:2:0 chroma ratio. Starting with medium size images, the 16x16 area provides a good balance between side information overhead & complexity and motion compensated prediction accuracy. In gist, experiments showed that the 16x16 was a good trade-off between complexity and coding efficiency. What do B-pictures buy you? A. Since bi-directional macroblock predictions are an average of two macroblock areas, noise is reduced at low bit rates (like a 3-D filter, if you will). At nominal MPEG-1 video (352 x 240 x 30, 1.15 Mbit/sec) rates, it is said that B-frames improves SNR by as much as 2 dB. (0.5 dB gain is usually considered worth-while in MPEG). However, at higher bit rates, B- frames become less useful since they inherently do not contribute to the progressive refinement of an image sequence (i.e. not used as prediction by subsequent coded frames). Regardless, B-frames are still politically controversial. B pictures are interpolative in two ways: 1. predictions in the bi-directional macroblocks are an average from block areas of two pictures 2. B pictures "fill in" like a digital spackle the immediate 3-D video signal without contributing to the overall signal quality beyond that immediate point in time. In other words, a B picture, regardless of its internal make-up of macroblock types, has a life limited only to itself. As mentioned before, B picture energy does not propagate into other frames. In a sense, bits spent on B pictures are wasted. Why do some people hate B-frames? A. Computational complexity, bandwidth, end-to-end delay, and picture buffer size are the four B-frame Pet Peeves. Computational complexity in the decoder is increased since some macroblock modes require averaging between two block predictions (macroblock_motion_forward==1 && macroblock_motion_backward==1). Worst case, memory bandwidth is increased an extra 15.2 MByte/s (assuming 4:2:0 chroma_format at Main Level), not including any half pel or page-mode overhead) for this extra directional prediction. To really rub it in, an extra picture buffer is needed to store the future reference picture (backwards prediction frame). Finally, an extra picture delay is introduced in the decoder since the frame used for backwards prediction needs to be transmitted to the decoder and reconstructed before the intermediate B-pictures in display order can be decoded. Cable television have been particularly adverse to B-frames since, for CCIR 601 rate video, the extra picture buffer pushes the decoder DRAM memory requirements past the magic 8- Mbit (1 Mbyte) threshold into the evil realm of 16 Mbits (2 Mbyte).---- although 8-Mbits is fine for 352 x 480 B picture sequence. However, cable often forgets that DRAM does not come in convenient high-volume (low cost) 8- Mbit packages as does friendly 4-Mbit and 16-Mbit packages. In a few years, the cost difference between 16 Mbit and 8 Mbit will become insignificant compared to the bandwidth savings gain through higher compression. For the time being, some cable boxes will start with 8-Mbit and allow future drop-in upgrades to the full 16-Mbit. How are interlaced and progressive pictures indicated in MPEG? The following tree may help illustrate the possible layers of progressive and interlaced coding modes: MPEG-2 sequence / \ progressive interlaced sequence sequence / \ Field picture Frame picture / \ / \ Frame or field prediction Frame MB prediction only / \ Field dct Frame dct What does it mean to be compliant with MPEG ? There are two areas of conformance/compliance in MPEG: 1. Compliant bitstreams 2. Compliant decoders Technically speaking, video bitstreams consisting entirely of I-frames are syntactically compliant with the MPEG specification. The I-frame sequence simply utilizes a rather limited subset of the full syntax. Compliant bitstreams must obey the range limits (e.g. motion vectors ranges, bit rates, frame rates, buffer sizes) and permitted syntax elements in the bitstream (e.g. chroma_format, B-pictures, etc). Decoders, however, must be able to decode all combinations of legal bitstreams.. For example, a decoder which is incapable of decoding P or B frames is definitely not a Main Profile or Constrained Parameters decoder! Likewise, full arithmetic precision must be obeyed before any decoder can be called "MPEG compliant." The IDCT, inverse quantizer, and motion compensated predictor must meet the accuracy requirements defined in the MPEG document. Real-time conformance is more complicated to measure than arithmetic precision, but it reasonable to expect that decoders that skip frames on reasonable bitstreams are not likely to be considered compliant. What are Profiles and Levels? A. MPEG-2 Video Main Profile and Main Level is analogous to MPEG-1's CPB, with sampling limits at CCIR 601 parameters (720x480x30 Hz or 720x576x24 Hz). "Profiles" limit syntax (i.e. algorithms), whereas "Levels" limit coding parameters (sample rates, frame dimensions, coded bitrates, etc.). Together, Video Main Profile and Main Level (abbreviated as MP@ML) normalize complexity within feasible limits of 1994 VLSI technology (0.5 micron), yet still meet the needs of the majority of applications. MP@ML is the conformance point for most cable and satellite TV systems. [insert a description of each Profiles and Levels here] Can MPEG-1 encode higher sample rates than 352 x 240 x 30 Hz ? A. Yes. The MPEG-1 syntax permits sampling dimensions as high as 4095 x 4095 x 60 frames per second. The MPEG most people think of as "MPEG-1" is really a kind of subset known as Constrained Parameters bitstream (CPB). What are Constrained Parameters Bitstreams? MPEG-1 CPB are a limited set of sampling and bitrate parameters designed to normalize decoder computational complexity, buffer size, and memory bandwidth while still addressing the widest possible range of applications. The parameter limits were intentionally designed to permit decoder implementations integrated with 4 Megabits (512 Kbytes) of DRAM. Bitstream Parameter Limit pixels/line 704 lines/frame 480 or 576 pixels/frame 101,376 pixels pixels/second 2,534,400 frames/sec 30 Hz bit rate 1.86 Mbit/sec buffer size 40 Kbytes The sampling limits of CPB are bounded at the ever popular SIF rate: 396 macroblocks (101,376 pixels) per picture if the picture rate is less than or equal to 25 Hz, and 330 macroblocks (84,480 pixels) per picture if the picture rate is 30 Hz. The MPEG nomenclature loosely defines a pixel or "pel" as a unit vector containing a complete luminance sample and one fractional (0.25 in 4:2:0 format) sample from each of the two chrominance (Cb and Cr) channels. Thus, the corresponding bandwidth figure can be computed as: 352 samples/line x 240 lines/picture x 30 pictures/sec x 1.5 samples/pixel or 3.8 Ms/s (million samples/sec) including chroma, but not including blanking intervals. Since most decoders are capable of sustaining VLC decoding at a faster rate than 1.8 Mbit/sec, the coded video bitrate has become the most often waived parameter of CPB. An encoder which intelligently employs the syntax tools should achieve SIF quality saturation at about 2 Mbit/sec, whereas an encoder producing streams containing only I (Intra) pictures might require as much as 8 Mbit/sec to achieve the same video quality. Why is Constrained Parameters so important? A. It is an optimum point that allows (just barely) cost effective VLSI implementations in 1992 technology (0.8 microns). It also implies a nominal guarantee of interoperability for decoders and a reasonable class of performance for encoders. Since CPB is the most popular canonical MPEG-1 conformance point, MPEG devices which are not capable of at least meeting SIF rates are usually not considered to be true MPEG by industry. Picture buffers (i.e. "frame stores") and coded data buffering requirements for MPEG-1 CPB fit just snugly into 4 Mbit of memory (DRAM). Who uses constrained parameters bitstreams? A. Principal CPB applications are Compact Disc video (White Book or CD-I) and desktop video. Set-top TV decoders fall into a higher sampling rate category known as "CCIR 601" or "Broadcast rate," which as a rule of thumb, has sampling dimensions and bandwidth 4 times that of SIF (Constrained Parameter sample rate limit). Are there ways of circumventing constrained parameters bitstreams for SIF class applications and decoders ? A. Yes, some. Remember that CPB limits pictures by macroblock count (or pixels/frame). 416 x 240 x 24 Hz sampling rates are still within these constraints. Deviating from 352 samples/line could throw off many decoder implementations which possess limited horizontal sample rate conversion abilities. Some decoders do in fact include a few rate conversion modes, with a filter usually implemented via binary taps (shifts and adds). Likewise, the target sample rates are usually limited or ratios (e.g. 640, 540, 480 pixels/line, etc.). Future MPEG decoders will likely include on-chip arbitrary sample rate converters, perhaps capable of operating in the vertical direction (although there is little need of this in applications using standard TV monitors where line count is constant, with the possible exception of windowing in cable box graphical user interfaces). Also, many CD videos are letterboxed at the 16:9 aspect ratio. The actual coded and display sampling dimensions are 384 x 216 (note 384/216 = 16/9). These programs are typically movies coded at the more manageable 24 frames/sec. Are there any other conformance points like CPB for MPEG-1? A. Undocumented ones, yes. A second generation of decoder chips emerged on the market about 1 year after the first wave of SIF-class decoders. Both LSI Logic and SGS-Thomson introduced CCIR 601 class MPEG-1 video decoders to fill in the gap between canonical MPEG-1 (SIF) and the emergence of Main Profile at Main Level (CCIR 601) MPEG-2 decoders. Under non-disclosure agreement, C-Cube had the CL- 950, although since Q2'94, the CL-9100 is now the full MPEG-2 successor in production. MPEG-1 decoders in the CCIR 601 class, or Main Level, were all too often called MPEG-1.5 or MPEG-1++ decoders. For the first year of operation, the Direct Broadcasting Satellite service in the United States (Hughes Direct TV and Hubbards USSB) called only upon MPEG-1 syntax to represent interlaced video before switching to full MPEG-2 syntax. What frame rates are permitted in MPEG? A limited set is available for the choosing in MPEG-1 and the currently defined set of Profiles and Levels of MPEG-2, although "tricks" could be played with Systems-layer Time Stamps to convey non-standard picture rates. The set is: 23.976 Hz (3-2 pulldown NTSC), 24 Hz (Film), 25 Hz (PAL/SECAM or 625/60 video), 29.97 (NTSC), 30 Hz (drop-frame NTSC or component 525/60), 50 Hz (double-rate PAL), 59.97 Hz (double rate NTSC), and 60 Hz (double-rate, drop-frame NTSC/component 525/60 video). Only 23.976, 24, 25, 29.97, and 30 Hz are within the conformance space of Constrained Parameter Bitstreams and Main Level. What areas can be improved upon to create a better syntax than MPEG? Several improvements can be made to the MPEG syntax while remaining within the framework of block based coding. As implementation technology improves with time, the ratio of computation to sample rate can be increased for the same implementation cost. With each evolutionary stage in the shrinking of the semiconductor lithography process (line width), more complex coding methods become economically realizable. Some of the well-known or well-anticipated areas for improvement are described below: Intra coding: For intra pictures, subband methods such as wavelets combined with improved quantization and entropy coders could gain as much as 2-4 dB over MPEG Intra pictures. The problem becomes more complex when considering the coding of Intra Macroblocks in mixed pictures, such as P or B, since the extend of a subband must, in the simplest of schemes, be limited to the dimensions of a macroblock. Prediction error coding One of the strongest gripes against MPEG is the use of the DCT for decorrelation of prediction error blocks. One explanation is that the DCT is suited for the statistical correlation of intra signals, but less suited for the statistics of prediction error (Non-Intra) signals. One common proposal is to replace the DCT with a Vector Quantizer. Prediction error (Non-intra) blocks typically contain far fewer bits than intra blocks. (The bits that comprise a Non-intra blocks can be thought of as having been previously distributed over previous blocks in previous pictures in the form of coefficients and side information...) Finer coding unit granularity’s: The size of the transform block could be made smaller, larger, or both (myriad of different sizes). Likewise, the size of the motion compensation block can be made larger or smaller. The cost is more complex semantics (more decoder complexity) and the overhead bits to select the block size. Instead of sharing the same side information, the blocks within the macroblock could be assigned their own motion vectors, macroblock quantization scale factors, etc. Many advanced techniques were in investigated by MPEG during the formative stages of the specification, but were eventually eliminated for falling below a threshold set for coding gain vs. implementation complexity. Often, proposals presented a significant departure from the main stream algorithms under consideration. Each bit added to the syntax, or rule added to the semantics represents several gates to a silicon implementation, or from a software perspective, an extra table, if-then or case statement at multiple points in the decoding program. What are the similarities and differences between MPEG and H.263 During its formative stages, H.263 was known as "H.26P" or "H.26X". It is an ITU-T standard for low-bitrate video and audio teleconferencing. It is designed to be more efficient (at least 2dB) than H.261 for bit rates below 64 kbits/sec (ISDN B channel). The primary target bit rate, approximately 27,000 bits/sec, is the payload rate of the V.34 (a.k.a "V.Fast" or "V.Last") modem standard. In a typical scenario, 20 kbit/sec would be allocated for the video portion, and 6.5 kbit/sec for the speech portion. Since the H.261 syntax was defined in 1990, techniques and implementation power have naturally improved. H.263 collects many of the advanced methods proposed during MPEGs formative stages into a syntax which shares a common basis more with MPEG-1 video than with H.261. The detailed differences and similarities are summarized below: Sample rate, precision, and color space: H.263 pictures are transmitted with QCIF dimensions. MPEG and JPEG allow nearly any picture size to be described in the headers. A fixed picture size promotes interoperability by forcing all implementors to operate at a common rate, rather than by allowing implementors to get away with whatever lowest sample rate the consumer can be tricked into buying. Another reason for a fixed sample rate is that, unlike MPEG which is generic, H.263 is geared towards a specific application (teleconferencing). Other MPEG applications such as CD Video and Cable TV define their own fixed parameters. Chromaticy is again YCbCr, 4:2:0 macroblock structure, and 8 bits of uniform sample precision. [details deferred] How would you describe MPEG to the Data Compression expert? A. MPEG video is a block-based coding scheme. How does MPEG video really compare to TV, VHS, laserdisc ? A. VHS picture quality can be achieved for film source video at about 1 million bits per second (with careful application of proprietary encoding methods). Objective comparison of MPEG to VHS is complex. The luminance response curve of VHS places -3 dB (50% response, the common definition of bandlimit) at around analog 2 MHz (digital equivalent to 200 samples/line). VHS chroma is considerably less dense in the horizontal direction than MPEG's 4:2:0 signal (compare 80 samples/line equivalent to 176 !!). From a sampling density perspective, VHS is superior only in the vertical direction (480 luminance lines compared to 240). When other analog factors are taken into account, such as interfield crosstalk and the TV monitor Kell factor, the perceptual vertical advantage becomes much less than 2:1. VHS is also prone to such inconveniences as timing errors (an annoyance addressed by time base correctors), whereas digital video is fully discretized. Duplication processes for pre-recorded VHS tapes at high speeds (5 to 15 times real time playback speed) introduces additional handicaps. In gist, MPEG-1 at its nominal parameters can match VHSs sexy low-pass-filtered look, but for critical sequences, is probably overall inferior to a well mastered, well duplicated VHS tape. With careful coding schemes, broadcast NTSC quality can be approximated at about 3 Mbit/sec, and PAL quality at about 4 Mbit/sec for film source video. Of course, sports sequences with complex spatial- temporal activity should be treated with higher bit rates, in the neighborhood of 5 and 6 Mbit/sec. Laserdisc is perhaps the most difficult medium to make comparisons with. First, the video signal encoded onto a laserdisc is composite, which lends the signal to the familiar set of artifacts (reduced color accuracy of YIQ, moirse patterns, crosstalk, etc). The medium's bandlimited signal is often defined by laserdisc player manufacturers and main stream publications as capable of rendering up to 425 TVL (or frequencies with Nyquist at 567 samples/line). An equivalent component digital representation would therefore have sampling dimensions of 567 x 480 x 30 Hz. The carrier-to-noise ratio of a laserdisc video signal is typically better than 48 dB. Timing accuracy is excellent, certainly better than VHS. Yet some of the clean characteristics of laserdisc can be simulated with MPEG-1 signals as low as 1.15 Mbit/sec (SIF rates), especially for those areas of medium detail (low spatial activity) in the presence of uniform motion (affine motion vector fields). The appearance of laserdisc or Super VHS quality can therefore be obtained for many video sequences with low bit rates, but for the more general class of images sequences, a bit rate ranging from 3 to 6 Mbit/sec is necessary. What are the typical coded sizes for the MPEG frames? Typical bit sizes for the three different picture types: Level I P B Average 30 Hz SIF @ 1.15 Mbit/sec 150,000 50,000 20,000 38,000 30 Hz CCIR 601 @ 4 Mbit/sec 400,000 200,000 80,000 130,000 Note: the above example is taken from a standard test sequence coded by the Test Model method, with an I frame distance of 15 (N = 15), and a P frame distance of 3 (M = 3). Of course, among differing source material, scene changes, and use of advanced encoder models these numbers can be significantly different. At what bitrates is MPEG-2 video optimal? The Test subgroup has defined a few example "Sweet spot" sampling dimensions and bit rates for MPEG-2: Dimensions Coded rate Application 352x480x24 Hz (progressive) 2 Mbit/sec Equivalent to VHS quality. Intended for film source video. Half horizontal 601(HHR). Looks almost broadcast NTSC quality 544x480x30 Hz (interlaced). 4 Mbit/sec PAL broadcast quality (nearly full capture of 5.4 MHz luminance signal). 544 samples matches the width of a 4:3 picture windowed within 720 sample/line 16:9 aspect ratio via pan&scan 704x480x30 Hz.(interlaced) 6 Mbit/sec Full CCIR 601 sampling dimensions These numbers may be too ambitious. Bit rates of 3, 6, and 8 Mbit/sec respectively provide transparent quality for the above application examples when generated by a reasonably sophisticated encoder. Why does film perform so well with MPEG ? 1. The frame rate is 24 Hz (instead of 30 Hz) which is a savings of some 20%. 2. Film source video is inherently progressive. Hence no fussy interlaced spectral frequencies. 3. The pre-digital source was severely oversampled (compare 352 x 240 SIF to 35 millimeter film at, say, 3000 x 2000 samples). This can result in a very high quality signal, whereas most video cameras do not oversample, especially in the vertical direction. 4. Finally, the spatial and temporal modulation transfer function (MTF) characteristics (motion blur, etc) of film are more amenable to the transform and quantization methods of MPEG. What is the best compression ratio for MPEG ? The MPEG sweet spot is about 1.2 bits/pel Intra and 0.35 bits/pixel inter. Experimentation has shown that intra frame coding with the familiar DCT-Quantization-Huffman hybrid algorithm achieves optimal performance at about an average of 1.2 bits/sample or about 6:1 compression ratio. Below this point, artifacts become non-transparent. Is there an MPEG file format? The traditional descriptors that file formats provide in headers, such image height, width, color space, etc., are already embedded within the MPEG bitstream in the sequence header. Directory file formats are described in the White Book and DVD specifications. What is the Digital Video Disc (DVD) ? In 1994, Toshiba united with Thomson Consumer Electronics, Pioneer, and a handful of Hollywood studios to define a new 12 cm diameter compact disc format for broadcast rate digital video. The new format basically increases the effective areal storage density over the 1982 Red Book format by some 6:1 (800 Mbytes vs 5 GBytes). This is achieved through a combination of shorter laser wavelength, finer track pitch, inter-pit pitch, and better optics. The thickness of the disc is reduced from the Red Book's 1.2 millimeters to 0.6 millimeters. However, the new format can be glue two 0.6 mm thick discs back-to-back, forming a double- size disc 1.2 mm thick with a total capacity of 10 Gbytes. A two hour movie, encoded onto only one side, would contain a video bistream average at 5 Mbit/sec. Or 10 Mbit/sec if distributed on both sides of a disc. Most of the 6:1 gain is achieved though more efficient encoding of bits onto the disc. Only a 2:1 factor comes purely from the reduction in wavelength. By comparison, today's double-sided analog video laserdiscs have a diameter of 30 cm (571 cm^2 of usable area), and a thickness of 2.4 millimeters. Storage capacity is a maximum of 65 minutes per side. A future potential format for HDTV may employ a blue wavelength laser (0.4 microns), offering another 2:1 increase in areal density, or 20 Gbytes total. Other alternatives include larger disc sizes. For example, if bit coding at DVD areal densities were applied to the familiar 30 cm disc, the average bitrate for the 65 minutes of video per side would be nearly 70 Mbit/sec !! What is the MPEG committee ? In fact, MPEG is a nickname. The official title is: ISO/IEC JTC1 SC29 WG11. ISO: International Organization for Standardization IEC: International Electrotechnical Commission JTC1: Joint Technical Committee 1 SC29: Sub-committee 29 WG11: Working Group 11 (moving pictures with... uh, audio) What ever happened to MPEG-3 ? MPEG-3 was to have targeted HDTV applications with sampling dimensions up to 1920 x 1080 x 30 Hz and coded bitrates between 20 and 40 Mbit/sec. It was later discovered that with some (syntax compatible) fine tuning, MPEG-2 and MPEG-1 syntax worked very well for HDTV rate video. The key is to maintain an optimal balance between sample rate and coded bit rate. Also, the standardization window for HDTV was rapidly closing. Europe and the United States were on the brink of committing to analog-digital subnyquist hybrid algorithms (D-MAC, MUSE, et al). By 1992, European all-digital projects such as HD-DIVINE and VADIS demonstrated better picture quality with respect to bandwidth using the MPEG syntax. In the United States, the Sarnoff/NBC/Philips/Thomson HDTV consortium had used MPEG-1 syntax from the beginning of its all-digital proposal, and with the exception of motion artifacts (due to limited search range in the encoder), was deemed to have the best picture quality of all three digital proponents in the early 1993 bake-off. HDTV is now part of the MPEG-2 High-1440 Level and High Level toolkit. Why bother having an MPEG-2 ? A. MPEG-1 was optimized for CD-ROM or applications at about 1.5 Mbit/sec. Video was strictly non- interlaced (i.e. progressive). The international cooperation executed well enough for MPEG-1, that the committee began to address applications at broadcast TV sample rates using the CCIR 601 recommendation (720 samples/line by 480 lines per frame by 30 frames per second or about 15.2 million samples/sec including chroma) as the reference. Unfortunately, today's TV scanning pattern is interlaced. This introduces a duality in block coding: do local redundancy areas (blocks) exist exclusively in a field or a frame.(or a particle or wave) ? The answer of course is that some blocks are one or the other at different times, depending on motion activity. The additional man years of experimentation and implementation between MPEG-1 and MPEG-2 improved the method of block-based transform coding. It is often remarked that MPEG-2 spent several hundred man years and 10s of millions of dollars yet only gained 20% coding efficiency over MPEG-1 for interlaced video signals. However, the collaborative process brought companies together, and from that came a standard well agreed upon. In many ways, the political achievement dwarfs the technical one. Also, MPEG-2 was exploratory. Coding of interlaced video was unknown territory. It took some considerable convincing to demonstrate that a simple syntax, akin to MPEG-1, was as efficient as other proposals. Left by themselves, each company would probably have produced a diverse scope of syntax. Is MPEG patented ? Many of the companies which participated in the MPEG committee have indicated that they hold patents to fundamental elements of the MPEG syntax and semantics. Already, the group known as the "IRT consortium" (CCETT, IRT, et al) have defined royalty fees and licensing agreements for OEMs of MPEG Layer I and II audio encoders and decoders. The fee is $1 USD per audio channel in small quantities, and $0.50 USD per channel in large quantities. A royalty and licensing agreement has yet to be reached among holders of Video and Systems patents, however the figure has already been agreed upon, ranging from $3 to $4 per implementation. Whether it is retroactively applicable or not to products already sold, or whether it is possible to avoid the patents via approximation techniques, is not known. The non-profit organization,CableLabs (Boulder, Colorado), is responsible for leading the MPEG Intellectual Property Rights effort (known canonically as the "MPEG Patent Pool."). An agreement is expected by mid 1995. In order to reach the IS (International Standard) document stage, all parties must have sent in a letter to ISO stating they agree to license their intellectual property on fair and reasonable terms, indiscriminately. For MPEG-1 and MPEG-2, this was accomplished in mid 1993. Companies which hold patents often cross-license each other. Each party does not have to pay royalties to one another. What is White Book The White Book specifies the file structure and indexing of multiplexed MPEG video and audio streams. White Book also specifies the Karaoke application's reference table which describes programs and their sector locations. At the lowest layer, White Book builds upon the CD-ROM XA spec.. Extension data includes screen pointing devices, address list of all Intra pictures within a program, CD version number, Closed Caption data, and information indexing of MPEG still pictures. The specific MPEG parameter definitions of White Book are: Audio coding method: MPEG-1 Layer II Sampling rate: 44.1 kHz Coded bit rate: 224 Kbits/sec Mode: stereo, dual channel, or intensity stereo Video coding method: MPEG-1 Permitted sample rates: 352 pixels/line x 240 lines/frame x 29.97 frames/sec (NTSC rate) 352 pixels/line x 240 lines/frame x 23.976 frames/sec (NTSC film rate) 352 pixels/line x 288 lines/frame x 25 frame/sec (PAL rate) Maximum bitrate: 1.1519291 bits/sec Recommendations include: pixel aspect ratios: 1.0950 (352x240) or 0.9157 (352 x 288) Intra pictures be placed at least once every 2 seconds. Still pictures: ("Intra" picture_coding_type only) Normal res: 352 x 240 or 352 x 288 (maximum 46 Kbytes coded size) Double res: 704 x 480 or 704 x 576 (maximum 224 Kbytes coded size) The other books are: Red Book: this is the original Compact Disc Audio specification (circa 1980). All other books (Yellow, Green, Orange, White) are identical at the low-level, sharing a common base with Red Book. This grandfather specification defines sectors, tracks, and channel coding (8/14 EFM outer forward error correction (FEC), 8-bit polynomial interleaved Reed-Soloman inner forward error correction, etc), and physical parameters (disc diameter 12 cm, laser wavelength 0.8 microns, track pitch, land-to-pit spacing, digital modulation, etc.). Yellow Book: first CD-ROM specification (circa 1986). Later appended by the CD-ROM XA spec. Green Book: CD-I (Compact Disc Interactive). Orange Book: Kodak Photo CD ISO 9660: (circa 1988) describes file structure for CD-ROM XA (circa 1988). Similar to MS-DOS, filenames are case insensitive and limited to 8 characters, and 3 extension characters (8.3 format). Many CD-ROMs containing MPEG are nothing more than Yellow Book CD which treat multiplexed video and audio bitstreams as an ordinary file. Further information can be retrieved from: Philips Consumer Electronics B.V. Coordination Office Optical & Magnetic Media Systems Building SWA-1 P.O. Box 80002 5600 JB Eindhoven The Netherlands Tel: +31 40 736409 Fax: +31 40 732113 What are some typical picture sizes and their associated applications ? 352 x 240 SIF. CD WhiteBook Movies, video games. 352 x 480 HHR. VHS equivalent 480 x 480 Bandlimited (4.2 Mhz) broadcast NTSC. 544 x 480 Laserdisc, D-2, Bandlimited PAL/SECAM. 640 x 480 Square pixel NTSC 720 x 480 CCIR 601. Studio D-1. Upper limit of Main Level. Future topics: How are MPEG video and audio streams synchronized? What is Digital Video Cassette (DVC) ? How does the D-VHS format encode MPEG signals? What is MPEG-4 ? The high level and low level differences between MPEG, JPEG, H.261, and H.263 MPEG in applications More on DVD. Details on DVB Implementations (semiconductor chips) Software Complexity and performance. Well known speedup methods. MPEG software on the Internet (audio, video, systems) Specific MPEG articles in literature. Current activities of MPEG-4 MPEG Compliance bitstreams ----- cfogg@chromatic.com ------------------------------------------------------------------------------- ~Subject: What happened at the MPEG - NY meeting ? From: cfogg@ole.cdac.com (Chad Fogg) Date: 22 Jul 93 05:31:41 GMT INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND ASSOCIATED AUDIO ISO/IEC JTC1/SC29/WG11 N0500 July 16, 1993 Source: ISO/IEC JTC1/SC29/WG11 ~Title: Press Release (Final) -- MPEG New York Meeting Status: For immediate release Summary This week in New York, at a meeting hosted by Columbia University, the Moving Picture Experts Group (MPEG) completed definition of MPEG-2 Video, MPEG-2 Audio, and MPEG-2 Systems. MPEG therefore confirmed that it is on schedule to produce, by November 1993, Committee Drafts of all three parts of the MPEG-2 Standard, for balloting by its member countries. To ensure that a harmonized solution to the widest range of applications is achieved, MPEG, an ISO/IEC working group designated ISO/IEC JTC1/SC29/WG11, is working jointly with the ITU-TS Study Group 15 "Experts Group for ATM Video Coding." MPEG also collaborates with representatives from other parts of ITU-TS, and from EBU, ITU-RS, SMPTE, and the North American HDTV community. MPEG-2 Video MPEG is developing the MPEG-2 Video Standard, which specifies the coded bit stream for high-quality digital video. As a compatible extension, MPEG-2 Video builds on the completed MPEG-1 Video Standard (ISO/IEC IS 11172-2), by supporting interlaced video formats and a number of other advanced features, including features to support HDTV. As a generic International Standard, MPEG-2 Video is being defined in terms of extensible profiles, each of which will support the features needed by an important class of applications. At the March MPEG meeting in Sydney, the MPEG-2 Main Profile was defined to support digital video transmission in the range of about 2 to 15 Mbits/sec over cable, satellite, and other broadcast channels, as well as for Digital Storage Media (DSM) and other communications applications. Building on this success at this week's New York meeting, MPEG experts from participating countries in Asia, Australia, Europe, and North America further defined parameters of the Main Profile and Simple Profile suitable for supporting HDTV formats. This week the MPEG experts also extended the features of the Main Profile by defining a hierarchical/scalable profile. This profile aims to support applications such as compatible terrestrial TV/HDTV, packet-network video systems, backward-compatibility with existing standards (MPEG-1 and H.261), and other applications for which multi-level coding is required. For example, such a system could give the consumer the option of using either a small portable receiver to decode standard definition TV, or a larger fixed receiver to decode HDTV from the same broadcast signal. This week's accomplishments in New York mean that the technical definition of MPEG-2 Video has been completed. This was a critical milestone, and shows that MPEG-2 Video is on schedule for a Committee Draft in November. MPEG-2 Audio MPEG is developing the MPEG-2 Audio Standard for low bitrate coding of multichannel audio. MPEG-2 Audio coding will supply up to five full bandwidth channels (left, right, center, and two surround channels), plus an additional low frequency enhancement channel, and/or up to seven commentary/multilingual channels. The MPEG-2 Audio Standard will also extend the stereo and mono coding of the MPEG-1 Audio Standard (ISO/IEC IS 11172-3) to half sampling-rates (16 kHz, 22.05 kHz, and 24 kHz), for improved quality for bitrates at or below 64 kbits/s, per channel. This week in New York, MPEG produced an updated version of the MPEG-2 Audio Working Draft, and is on track for achieving a Committee Draft specification by the November MPEG meeting. The MPEG-2 Audio multichannel coding Standard will provide backward-compatibility with the existing MPEG-1 Audio Standard (ISO/IEC IS 11172-3). Together with ITU-RS, MPEG is organizing formal subjective testing of the proposed MPEG-2 multichannel audio codecs and up to three non-backward-compatible (NBC) codecs. The NBC codecs are included in order to determine whether an NBC mode should be introduced as an addendum to the standard. If the results show clear evidence that an NBC mode improves the performance, a formal call for NBC proposals will be issued by MPEG, with a view to incorporate these features in the audio syntax. MPEG-2 Systems 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. ------------------------------------------------------------------------------- ~Subject: Whats with MPEG-4 ? 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. From Leonardo.Chiariglione@CSELT.STET.IT Fri Aug 18 15:10:47 1995 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ORGANISATION INTERNATIONALE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND ASSOCIATED AUDIO INFORMATION ISO/IEC JTC1/SC29/WG11 N0997 MPEG 95/ July 1995 Source: Leonardo Chiariglione - Convenor Title: MPEG-4 Call for Proposals Status: Approved at 31st WG11 meeting MPEG (originally, Moving Pictures Experts Group) is a working group operating within ISO (International Standardisation Organisation) and IEC (International Electrotechnical Commission). Since starting its activity in 1988, MPEG has produced ISO/IEC 11172 (so-called MPEG-1) and ISO/IEC 13818 (so called MPEG-2) and among others, plans to finalise the so-called DSM-CC standard protocol for set-top to server and set-top to network dialogue in July 1996. While its standards are obtaining wide support from both the manufacturing industry and service providers and have actually been instrumental in triggering the digital revolution that is making possible the coming of interactive multimedia for widespread consumer applications, MPEG is turning its attention to more advanced forms of interactivity that technology will make possible in the next few years. This is the objective of the MPEG-4 project whose completion, planned to take place in November 1988, will give users the possibility to achieve various forms of interactivity with the audio-visual content of a scene and to mix synthetic and natural audio and video information in a seamless way. MPEG-4 technology will comprise two major parts: a set of coding tools for audiovisual objects, and a syntactic language to describe both the coding tools and the coded objects. From a technical viewpoint, the most notable departure from traditional coding standards will be the possibility for a receiver to download the description of the syntax used to represent the audio-visual information, a feature that VLSI technology will soon be able to support. It should be noted also that the audiovisual information will not be restricted to have the format of conventional video, i.e., it will not necessarily be frame-based. The additional degrees of freeedom that will result from not forcing the data structure of the coded representation of the data to be the same as the data structure of the presentation of the data are expected to produce significant improvements in both efficiency and functionality. Using the same approach as for the case of the MPEG-1 and MPEG-2 standards, MPEG is now requesting technical proposals in line with the general philosophy described in document WG11 N0998 "Proposal Package Description". A Call for Pre-registration has already produced more than 70 statements of intention to submit a proposal on Synthetic/Natural Audio/Speech or Video Coding. The companion document WG11 N0999 "MPEG-4 Test/Evaluation Procedures", finalized at 31st MPEG meeting, describes the details of the expected content of submissions and the methodology to be used in assessing their suitability for the intended scope of the MPEG-4 standard. Please note that two kinds of submission will be accepted for coding techniques: algorithms for certain functionalities will be subjected to formal testing, while algorithms for other functionalities, and coding tools that may constitute only part of a complete algorithm will be subjected to evaluation by a panel of experts. Also, submission of proposals for syntactic language will be evaluated by experts. This document (w0997.doc) and the two documents referred to above (w0998.doc and w0999.doc) can be obtained in electronic form (Word 6.0 for Windows) from: name: wuarchive.wustl.edu login: iso password: !more!less directory: uploads/ Those intending to submit a proposal should send the registration form contained in the WfW file w0997.doc duly filled in to: Dr. Leonardo Chiariglione CSELT Via G. Reiss Romoli, 274 10148 Torino ITALY Tel.: +39 11 228 6120 Fax: +39 11 228 6299 Email: leonardo.chiariglione@cselt.stet.it and Dr. Cliff Reader Samsung Semiconductor Inc. 3655 North 1st Street San Jose, CA 95134 USA Tel.: +1 408 954 7853 Fax: +1 408 434 5510 Email: cliff@reader.com by 15 September 1995. Registrations will be acknowledged by 30 September 1995. Please refer to document WG11 N0999 for a detailed calendar of deadlines to be met by prospective proposers. Video and audio tapes submitted for subjective testing will be assessed in the two weeks preceding the 32nd MPEG meeting. This meeting will be held in Dallas, TX, USA, on 6 to 10 November 1995. At this meeting both the results of subjective tests and the technical proposals with supporting information will be assessed by MPEG. Proposers are strongly encouraged to upload the textual and graphical parts of their proposals in Word 6.0 for Windows format by 27 October 1995 for early and better consideration of their proposals. Please note that a mandatory financial contribution to cover the cost of tape editing will be requested to submitters of proposals that include tapes for subjective tests. The exact amount of the contribution will be communicated in the letter of acknowledgment, as this depends on the number of tapes to be edited. The major steps in the MPEG-4 standard development following the Dallas meeting will be the attainment of "Working Draft" level in November 1996 and of "Committee Draft" level in November 1997. International Standard level will be reached in November 1998. ------------------------------------------------------------------------------- ~Subject: What's about Video-CD and CD-I ? FAQ ABOUT VIDEO CD and CD-i Copyright (c) 1996 Steve Perlman, Visible Light Revised: 15 Mar 96 Introduction The Different Formats of Video CD and CD-i Special Considerations To Play Green Book An Important Choice: Windows 3.1 or 95 Playback Software For Video CD and CD-i Using Software Decoders Introduction Every day, I'm contacted by an increasing number of PC owners who want to playback their CD-i and Video CDs on their PCs. The answer to the question "Can I play Video CDs and CD-i on my PC?" is absolutely and positively a "maybe!" Without question, you must have an MPEG decoder to playback a Video CD or CD-i. Software-only decoders, like CompCore SoftPEG, are inexpensive and work well with fast Pentium based PCs. The hardware decoders, like Sigma Designs' REALMagic, are more costly but will run well even on 486 PCs, since the processing is all done on the board. But, just having an MPEG decoder just isn't enough! So beware! There are hardware, software, driver and configuration issues that must be resolved to play Video CD or CD-i. The bright spot is that it generally can be done! This FAQ explains the factors involved in playback of Video CD and CD-i. Hopefully, you're somewhat knowledgeable of your PC hardware and configuration! The Different Formats of Video CD and CD-i Looking at the way Video CD and CD-i has evolved may arguably lead one to believe that it was created to confuse the world on purpose. Have you ever stopped to think about how many types of Video CD and CD-i there really are? There are at least four types! Each one has a different format! There is Green Book, White Book, CD-i Interactive and Video CD 2.0. Wow! Which one you have will affect your ability to playback the CD using Windows. So, let's start by unraveling the mystery behind the formats of Video CD and CD-i. Don't let the term "book" confuse you. It's just a cute name given to that particular format. It's not difficult to identify which type of CD you have! GREEN BOOK This is the earliest format created by Philips for CD-i movies. Most of the Philips CDs dated 1993 and earlier are Green Book. Look on the CD itself for the wording "Digital Video". You will also find that the directory is unreadable on a PC. WHITE BOOK (Video CD 1.1) This is the latest format used by Philips for CD-i movies. Most of the Philips CDs dated 1994 and later are White Book. Look on the CD itself for the wording "Video CD". You will find that this directory is readable, and there are files with the extension .DAT CD-i INTERACTIVE This is the Philips format for games and other interactive content. The CDs use wording like "CD-i Games" and "CD-i Interactive". These CDs are not playable on a PC unless you have a very expensive board which only Philips supplies. VIDEO CD 2.0 The world wants to develop interactive content. But, it doesn't want to pay high fees to Philips to develop CD-i Interactive disks, and wants to have wide distribution on PCs. Thus, the new Video CD 2.0 standard was created. It is an extension of Video CD 1.1, and has a readable directory with .DAT files. These CDs should begin to receive widespread distribution by the end of 1996. Special Considerations To Play Green Book Green Book is not entirely supported on PCs, because Green Book format cannot be read as a standard ISO-9660 CD (meaning no readable directory). Therefore, some CD drive manufacturers did not build Green Book format support into their CD drive hardware. These CD drives cannot read Green Book format. They must be replaced to play Green Book CDs. Panasonic and Matsushita drives typically do not support Green Book. Unfortunately, many of these drives were distributed by Creative Labs with their multimedia upgrade packages. When selecting a drive, make certain that it is "CD-i compatible". Most CD drives are. The error most attributable to the CD-ROM hardware problem is the now infamous MMSYSTEM001: External Error. This is a general catch-all error which means that the CD-ROM drive is not responding properly. The most likely reason is that the drive simply can't read the disk. That's not all! Windows 3.1 CD drivers, using the file MSCDEX.EXE, supported Green Book format. As long as the CD drive hardware could read Green Book, you can playback a Green Book CD without problems. Windows 3.1 was such a nice, friendly operating system. Then came Windows 95, touted to us as being 100% compatible with Win 3.1. Except for one thing! Microsoft didn't tell us that Green Book support was removed from the Windows 95 CD drivers! So, Green Book CDs are specifically not supported in Windows 95. That doesn't mean you won't be able to use Windows 95 to play Green Book in the future. But, Microsoft has to release a new driver or another fix must be found. It is believed that you may be able to use the Windows 3.1 MSCDEX drivers, and disable the Windows 95 CD drivers. This is all being tested now, so we will cover this point in a later revision to this FAQ. An Important Choice: Windows 3.1 or 95 We covered the requirement for playback of Green Book CDs, that the Windows 3.1 CD driver (MSCDEX) be used instead of the Windows 95 driver. But, there is also a special bug in Windows 95, for which Microsoft has not yet released a fix publically yet. An IDE CDROM may not reside on the primary channel with you Hard Drive. It must be on the secondary channel. If you have a 486 with no EIDE (no secondary channel) and want to use an IDE CDROM, tough luck. If you have a Pentium and an IDE CDROM, move it to the secondary channel. In general, you will find Windows 3.1 to be the preferable environment for playback of Video CD and CD-i. There are less things to go wrong, and configuration problems are easier to control. Windows 3.1 is a good test environment also. If you have problems with playback of Video CD and CD-i under Windows 95, you should test first under Windows 3.1 if possible. That will help you define whether or not the problem is hardware (the CD drive) or Windows 95 itself. Unless you have a hardware problem, you should always be able to play Video CD and CD-i under Windows 3.1! Direct Draw improves video considerably under Windows 95, and improves the frame rate. Direct Draw drivers write YUV information directly to a video card that supports it. Generally, these video drivers are not available yet, but some vendors have begun distribution of the beta versions of their Direct Draw drivers. Diamond has Direct Draw beta drivers available for its Video 2001 series. S3 reportedly has also released its beta version for public testing. A special warning though. These beta versions are generally untested, and may generate unwanted or unexpected results during playback! Playback Software For Video CD and CD-i Media Player, distributed with Windows, will playback .MPEG and .DAT files very nicely. But, you have to point to these files directly. With Video CD and CD-i, you want software that will read the CD header and begin automatic playback of the CD. Media Player does not support this, and most of the players for the PC will not either. Therefore, you must find a player that will support playback of Video CD and CD-i. CompCore's SoftPEG 2.0 is distributed with CD Vision, a player that supports Green Book, Video CD 1.1 and Video CD 2.0. So, if you want to playback Video CD or CD-i, you need more than just an MPEG decoder. You need one that has a driver and a player that will support the playback of these formats! Using Software Decoders Software decoders will run fine with Video CD and CD-i, although there are CPU constraints. Because these decoders use your CPU for processing, frame rate is dependent upon the speed of your processor. Generally, the decoder should be configured for maximum CPU usage (90%), and all other applications should be closed. Another factor is that Windows 3.1 is a bit faster than Windows 95 for software decoding. Windows 95 tends to use more system resources. This is a minor consideration, though, because the 32-bit decoder drivers talk nicely with the new graphics accelerator boards. In fact, the new Direct Draw drivers will greatly improve things further. Use of software decoders should be limited to Pentium platforms, for best frame rate and better compatibility. =========================================================================== ~Subject: SECTION 2. - PROFESSIONAL SOFTWARE This section describes commercial software, even when a free, but restricted demo version is available. SECTION 2. - PROFESSIONAL SOFTWARE SUBSECTION - DOS SUBSECTION - WINDOWS SUBSECTION - UNIX ------------------------------------------------------------------------------- ~Subject: SUBSECTION - DOS ------------------------------------------------------------------------------- ~Subject: MPEG Encoder by Xing The MPEG Encoder is available starting from 349.-DM incl. VAT. BTW, the encoder still sells for 349.-DM and the MCI-driver for 199.-DM [ The MCI-driver is nice, because it allows you to include movies in ] [ other documents. But it includes only the MPLAYER.EXE-icon in the ] [ document (not the first picture of the movie), the movie runs at ] [ whatever position (not where the icon is !), when you double-click it. ] [ Xing should have a close look at Microsoft's AVI-driver ;o) (but there ] [ movies are incredible slow and small, compared to MPEG :o( ] --------------------------------------------------------------------------- ~Subject: SUBSECTION - WINDOWS --------------------------------------------------------------------------- ~Subject: SoftPEG [ The current version 2.0 seems to be the quickest software decoder for ] [ for Windows, check there site under http://www.compcore.com/ ] CompCore SoftPEG MPEG Decoder SoftPEG MPEG-1 Decoder Engine Tecnical specification: MPEG: - MPEG-1 compatible System, Audio & Video streams. - Automatic rate control. - Full lip-sync from 30 fps (P90 + DCI graphics) to 8 fps (486 + GDI graphics). - User defined frame-rate support. Video: - Support for DCI, WinG, GDI. - 2X optimized scaling option. - User defined scaling through DCI, WinG or GDI. - Suports RGB8, RGB24, YUV12, YUY2, YVYU and UYVY color formats. Audio: - Automatic support fot 16/8 bit, stereo/mono sound. System requirements: - 486 DX or above (Pentium recommended). - Windows 3.x in enhanced mode. - 4 MBytes RAM. - Windows compatible Sound Card. Implementation: - Windows 3.x DLL. - API and MCI interface. - Virtualized stream input/ graphic output. - Low CPU usage (40-70%). - Low memory consumption (1.3 MB). - MCI driver for MediaPlayer integration. - SoftPEG player application. Product Background: CompCore Multimedia, Inc., the leader in low cost, high performance MPEG solutions, is proud to announce the availability of the SoftPEG tm MPEG decoder. SoftPEG is the highest performance MPEG software decoding solution in the industry. Using the same patented algorithms as CompCore's efficient hardware solutions, SoftPEG tm is able to generate unparalleled picture and sound quality with full audio/ video synchronization, without added hardware or assemble language programming. Performance: Achieves real-time performance at SIF resolution (352 x 240 @ 30 frames/sec or 352 x 288 @ 25 frames/sec) on 90 MHz Pentium systems with YUV color space conversion hardware assist. Delivers smooth motion quality and full audio/video synchronization on base level Pentium and 486DX2 systems. Decodes video frames faster than real-time on basic PowerPC, MIPS and Alpha systems. Features: Fully decodes and displays any MPEG-1 compliant bit stream. Uses CompCore's patented algorithms to efficiently decode, synchronize and present audio/video frames. Able to perform decode and presentation without full utilization of CPU. SoftPEG tm delivers exceptional audio/video synchronization quality regardless of platform (Pentium, 486, MIPS, PowerPC). Automatically configurable to either DCI or WinG interfaces. SoftPEG, tm designed with a 16 bit interface in mind, runs under the Window 3.1, as well as Windows NT, without the use of Win32S. Compliant to OpenMPEG standard. Written in high level C code making the design easily portable to other platforms. Licensing and Availability: SoftPEG is available for immediate distribution. For information on licensing please contact Tanya Sitterly at: CompCore Multimedia, Inc. 1270 Oakmead Parkway, Suite 214 Sunnyvale, CA 94086 Tel: (408) 773-8310 ext. 22 Fax: (408) 773-0432 --------------------------------------------------------------------------- ~Subject: MPEG ARCADETM Mediamatics Inc.'s MPEG ARCADETM Player is a software only, full implementation of the MPEG-I ISO 11172 standard. The entire MPEG-1 decompression, both video and audio is implemented in software (along with system stream parsing and video/audio synchronization). Finally, a MCI-DV Media Player interface is provided to control/playback MPEG-1 encoded system stream files. This media player is fully compliant with OPEN PC MPEG consortium's MpegVideo command set. This player will soon be available in the retail market from major manufacturers of graphics cards, who will be bundling our Arcade Player with their recently announced video-enabled graphics cards. Arcade Player is currently offered only to OEMs and has been licensed by Brooktree, Western Digital. Arcade Player - Key Features: * Performance benchmarks: 24-30 fps with synchronized audio on a Pentium PCI system with a video enabled graphics card. [Note: assumes graphics subsystem to contain a hardware color space converter] * Supports Windows 3.1, Windows95TM and Windows NT operating system. * Supports playback of CD-I/VideoCD/CD-Karaoke format encoded content. * Tested with major DCI-aware graphics devices from companies such as Brooktree, Western Digital, Trident, S3, Cirrus, Avance, Alliance etc. For More information: Mediamatics Inc. 4633 Old Ironsides Drive #328 Santa Clara, CA 95054 Ph: 408-496-6360 Fx: 408-496-6634 Email: info@mediamatics.com --------------------------------------------------------------------------- ~Subject: XingSound [ Well, the encoder costs, but the decoder is PD ! But, attention ] [ they say, they support full-MPEG-audio, but sure they are not. ] [ They do dirty tricks again, had a look at the streams, tststs ] [ Buts good stuff and its helping the MPEG-comunity. ] XingSound Realtime MPEG Audio Layer II Encoding on the PC ! Here it is: the first low cost REALTIME MPEG AUDIO Encoding on the PC via a high quality 16 Bits Stereo DSP based Audio-Soundcard and the famous Xing Technology XingSOUND(tm) MPEG Audio Encoder software. The XingSound MPEG audio encoder encoder supports the DSP on the Soundcard and enables realtime 15:1 compression of high quality Audio material without any audible loss in quality. REALTIME means REALTIME ! Wait no longer endless time (hours) to convert your WAV-files offline, like a few shareware encoders do. No just record your songs in realtime to MPEG Audio MP2 files. Compression factor can be set . Comfortable record software coming with the package and also an offline WAV to MP2 converter. All software runs under win3.x ! With the optinal MPEG Audio- MCI-driver you can paste your MPEG audio files directly via Media player into your applications and save huge disk space compared when using 16 bits Stereo WAV files ! Also , when the DSP Soundcard is installed, you get full CD-quality STEREO playback with 16 bits resolution ! (if other soundcard is installed, XingSound MPEG player will only play in Mono) Available only as a bundled package consisting of: 1. XingSound MPEG Audio Realtime software for Windows 3.x incl. free MPEG audio win3.x player program, WAV to MP2 offline converter, Realtime DSP supported Audio recorder program, Realtime DSP supported FULL Stereo CD-quality MPEG Audio playback 2. 16 bits Stereo CD-quality DSP Soundcard, with win3.x drivers (can be used as a normal Windows soundcard as well, Soundblaster and WSS compatible, jumperless design, options set via software, Sony CD-ROM I/O onbord) All manuals have english language ! --------------------------------------------------------------------------- ~Subject: XingCD It is the first AVI to MPEG Encoder, which allows you to make MPEG system streams from AVI movies. This means, you can directly use a Motion JPEG capture board at 352x288 resolution to capture Realtime video, edit it with Adobe Premiere for Windows and make a Video CD out of it, using the new XingCD Encoder. The XingCD Encoder is software only, so there is no further hardware required. It converts the AVI Video file to MPEG Video and the sound WAV file to MPEG Audio and interleaves (multiplexes) these 2 bitstreams into an MPEG system layer bitstream, so it could be played back via a REEL MAGIC card for instance or the new Inside Technology MPEG player card for the PC. The new MPEG Encoder supports full IBP format and is compatible with the ISO11172 MPEG system layer description. Price is 995.-US$, but this is still cheaper than a 20K US$ realtime MPEG capture board..... It can also encode from single TGA or BMP pics and it supports various output format of: 352x240, 352x288, 160x120 and custom output resolution. Rescales source to desired ouput resolution etc... Encode Process runs in the background. I hope, we will get soon many "fresh" MPEG Video CDs ! --------------------------------------------------------------------------- ~Subject: SUBSECTION - UNIX --------------------------------------------------------------------------- ~Subject: Xing Distributed Media Architecture {XDMA} Network Description The Xing Distributed Media Architecture ("XDMA"), developed by Xing Technology Corporation ("Xing") is the first commercially available low-cost solution for world-wide and local network delivery of live and on-demand video+audio. The National Broadcasting Company (NBC) has broadly deployed XDMA for broadcast delivery of financial news programming to subscribers in the U.S and Europe. New applications are being developed with XDMA for distance learning, corporate communications, news delivery and computer based training in corporate, educational, government and health care markets, employing wide area, local area and ISDN networks. How XDMA Differs from other Video Networks Existing "on-demand" multimedia (video) network architectures are based on tightly coupled point-to-point client-server communication, which result in 4 major limitations: 1. significant interaction is required between client and server for flow control, requiring complex server programming and signficant data overhead (on the order of 25% - 50%); 2. servers are not designed to deliver the same streams simultaneously to multiple users, making "live" delivery to multiple users impractical; 3. LAN-based server architectures are not designed to operate (and generally don't work well) over wide area networks; and 4. communication protocols employed are proprietary, and do not directly support the TCP/IP international standard XDMA represents a significantly different multimedia network architecture, based on the concept of "streaming media". This architecture supports both "on-demand" as well as "live" It video and audio delivery which does not require close coupling between the client and server. It easily supports "broadcasting" or "multicasting" of live or on-demand content to multiple simultaneous users over local as well as wide area networks. The benefits of XDMA are reduced network component complexity, significantly increased network flexibility, and significantly reduced network overhead. Moreover, Xing's approach is built around international standards-based components - Unix and (in 3rd quarter 1995) Windows NT servers, TCP-IP connections, MPEG video and audio compression, and HTTP-HTML client server communication. This allows better economies in implementation and easy integration into existing communication networks. Technical Description XDMA was developed as a client-server media distribution architecture which can operate independently or complement existing WWW (World Wide Web) HTTP / HTML architectures on local area networks, private data wide area networks and public data wide area networks (e.g. Internet). XDMA delivers *streaming* multimedia - pictures, video and sound - based on the MPEG international standards for video and audio compression from Unix and (in 3rd quarter 1995) Windows NT servers. When integrated with WWW, XDMA augments existing WWW architectures by providing a Common Gateway Interface (CGI) to existing Web (HTTP) servers, and viewer extensions to popular "Web HTML browsers" (i.e. Mosaic, Netscape, Winweb, Spyglass, etc). As such, XDMA can take advantage of user authentication procedures as supported by current Web browsers and HTTP servers. Streaming of multimedia data is a significantly different way of delivery, as the user can view / hear the data as it is being transmitted instead of waiting for file transfer completion, and there is no requirement for complex file systems such as Netware or NFS. In addition, XDMA uses standard TCP-IP network protocols, and takes advantage of new "multicast IP" protocols (RFC 1112) for data delivery, allowing multiple users to simultaneously view / hear the same data streams without duplication of data or use of intrusive broadcast protocols. A typical XDMA configuration will include some of the following components: * XDMA Network Encoders - video+audio - audio only - file transmitter / encoder emulator * XDMA Network Servers * XDMA Network Clients - for PC Windows - for X-Windows - Standalone * XDMA Network Routers * XDMA Network Editors * XDMA Network Manager as described below. XDMA Benefits * compatible with existing enterprise TCP/IP networks, including Ethernet, ATM, FDDI, ISDN, T1 and Frame Relay * adds live and on-demand video and audio services to private and public WAN's and LAN's without infrastructure changes * low overhead (3%) video and audio streams are fully routable * all network components are SNMP manageable (3rd quarter 1995) * network congestion is controlled by on-the-fly bitrate reduction of video and audio streams; streams are scalable from full rate down to ISDN BRI (56-128kbps) * SQL database management of XDMA streams (3rd quarter 1995) * servers may be distributed for load balancing and stream caching * software-only and hardware accelerated video and audio decode provided on client systems * user interface customizable through HTML / HTTP (Web / Mosaic) interface * compressed video and audio streams compliant with MPEG-1 and MPEG-2 (ISO/ICE 11172 and 13818) international standards XDMA Applications Applications requiring "media on-demand" benefit from XDMA's simplified approach. The advantage becomes most apparent in applications with a combination of "on-demand" and "live" media delivery requirements, especially when the clients are geographically dispersed. NBC is using XDMA to deliver multiple simultaneous live financial and news video broadcast channels to financial market subscribers (money managers, stock brokers, financial analysts) in cities throughout the US and Europe as part of their "NBC Desktop Video" service. Xing is developing similar delivery services for other commercial TV and radio programmers. Although commercial broadcast services provide very visible and compelling examples for Xing's capabilities, the largest volume applications for "streaming media" will be in corporate, educational, government and health-care networks with "on-demand" and "live" communication requirements, including training, presentations, status reporting, and occassionally, entertainment. Because of the rapid proliferation of TCP-IP / HTTP / HTML ( Internet + World Wide Web + Mosaic), the infrastructure for integration of Xing "streaming media" architectures is quickly developing. Representative XDMA applications include: * Commercial broadcast delivery systems; * Internet Service Provider delivery of radio and TV programming; * On-line marketing, sales, service and customer support; * Enterprise-wide training, corporate information systems and regulatory compliance; * Medical information systems, including live monitoring and on-demand multimedia information retrieval; * Educational systems for live and on-demand distance learning as well media production; * Government networks for live and on-demand delivery of news events and briefings to policy makers and dissemination of public information; * Media production and distribution; and * Information archives XDMA and ISDN XDMA is ideally suited for ISDN remote access server and regional server applications such as distance learning and news delivery, through its ability to provide on-the-fly MPEG stream bitrate reduction and service of large numbers of simultaneous users. Xing is currently developing a reference platform for ISDN regional servers which delivers both high resolution / low frame rate as well as low resolution / 30 frame per second video streams. Demonstration of this capability will be available via Xing's World Wide Web site - http://www.xingtech.com, as well as via direct ISDN dial-in - 805/473-7200. Xing Technology Corporation Xing is the world's leading producer of PC based software technologies and products for digital compression and decompression of video and audio in accordance with the MPEG (Moving Pictures Expert Group) international standards. Technology licensees include Microsoft, Intel, Pacific Bell, NTT Japan, Fujitsu, Hewlett Packard and IBM. In addition, Xing provided the key technologies to NBC for the development of the first wide area digital video broadcast delivery system ("NBC Desktop Video"). Glossary MPEG - Motion Picture Experts Group. The international standards for compression of video and audio. There are actually two standards - MPEG-1 (ISO/IEC 11172) and MPEG-2 (ISO/IEC 13818). MPEG-1 was originally designed for delivery of video to consumer devices at single speed CD-ROM data rates (150kbytes/sec), and is therefore lower resolution and lower quality than MPEG-2, which was designed for delivery of broadcast and HDTV quality video. Each MPEG specification actually has 3 parts which define the video stream, the audio stream and the video+audio encapsulating transport stream. TCP-IP - Transmission Control Protocol + Internet Protocol. A collection of communications protocols (including TCP, IP, UDP, ARP, IGMP, ICMP, RAP, RIP, SNMP) that are the basis of the Internet and all Unix networking. Because TCP-IP can support both local and wide area networking, while Novell's Netware protocols were designed only to support local area networking, TCP-IP is rapidly become the standard as well for PC Windows networking through an interface called "WINSOCK". HTML+HTTP - Hypertext Markup Language + Hypertext Transport Protocol. HTML is a page description language and HTTP is a communications protocol that runs on top of TCP-IP. Combined, HTML+HTTP define the basis for applications such as Mosaic and Netscape, which are the primary tools for navigating the Internet's "World Wide Web". HTML defines the contents of pages which are viewed on the "Web", and HTTP defines the way an HTML browser talks with an HTML server (refered to as an HTTPD or Web server). It is important to note that HTML+HTTP can be used on local area networks and private data networks, and are rapidly becoming the standard for in-house corporate information systems which are not necessarily Internet connected. URL=http://xingtech.com/ --------------------------------------------------------------------------- ~Subject: NVR Research Kit [ Its really nice software, but its expensive ! You find the infos and ] [ software on there ftp-server (see below !), don't forget to order a ] [ licence key. There are several nice and long MPEG-movies to ftp !!! ] [ If you require a demo version, please send mail to support@nvr.com ] From: Chris Jacobson Date: Thu, 13 May 93 10:31:32 -0700 North Valley Research Digital Media Systems North Valley Research is pleased to announce immediate availability of a family of products for working with video and other time-based media in a UNIX environment. These products are the first, affordable software products that enable the end user to take video and audio all the way from video camera or tape to an MPEG sequence that can be played back in real-time on most Sun SPARCstations. Starting now until May 5th, 1993, individual products can be purchased for $150 in quantities of 30 or more; or under $300 for quantity 1. These software products have well-designed Motif user interfaces and a robust architectural design. The first set of products is sold as a kit, and consists of three user interfaces: - The Player. This tool provides a viewing mechanism for working with + MPEG sequences + analog video (requires the Parallax XVideo board) + JPEG movies (requires the Parallax XVideo board with JPEG option) - The Recorder. This tool enables the user to peruse analog material with an interface very similar to the Player, but in addition, allows you to create JPEG movies using the JPEG hardware on the Parallax XVideo board. - The Compressor. This tool allows you to choose input files, specify the compression characteristics and finally, compress them with our software MPEG compression engine. The MPEG playback mechanism is purely software, requires no special framebuffer, and depending on the size of picture, the size of the window and bandwidth of the bitstream, can run at 6 - 30 fps with synchronized audio. The color is dithered from 19 bits down to 7 bits, gamma-corrected, with real-time adjustments for contrast and brightness. The displayed window can be one or four times the size of the MPEG sequence picture size. For example, a sequence compressed at 320x240 can be played back at 320x240 or 640x480 (depending on the performance of the host computer). Both the MPEG compression and playback mechanisms support: + variable I:P:B ratios + variable picture sizes from 64x48 to 320x240 + variable and fixed bit rate + three motion estimation algorithms (Jain & Jain and two Exhaustive methods) The MPEG compressor is relatively fast for compression that includes motion estimation, and depending on the input stream and the selected compression parameters, can compress a twenty second sequence in as little as an hour. The JPEG record and playback is accomplished with the aid of the Parallax XVideo board. Recording and playback of JPEG movies is controlled by a special software engine that always keeps the audio and video synchronized. Recorded sequences may be "running records" from a camera or broadcast, or assembled from a controllable video source with in and out points. Both the Player and Recorder support Sony's ViSCA/LANC, and Pioneer 4400 disc players (and other compatible models). VideoMedia's VLAN will be added in the future. Prices and Availability ----------------------- All prices below are retail, with a special, 40%-off, introductory price in parenthesis. These special prices are good until May 5, 1993. All products require: Operating System: Solaris 1.0.1 Computer: SPARCstation 1+, 2, IPC, IPX Availability: All products are available for immediate delivery Media: 8mm tape or Quarter-inch cartridge (QIC) Terms: P.O. prior to shipment, net 30 days with credit NVR Digital Media Player: Includes: Support for audio and viewing analog video, JPEG movies and software MPEG. Requirements: For analog video: Parallax XVideo board For JPEG movies: Parallax XVideo board with JPEG option For MPEG playback: most any 8-bit pseudo-color frame-buffer, including CG3, CG4, CG6 and Parallax XVideo. Black-and-white monochrome support available on request. Prices: 1 floating license $495 ($297 intro) 10 floating license $2,000 ($1,200 intro) 30 floating license $4,500 ($2,700 intro) NVR Digital Media Recorder Includes: Support for viewing analog video and creating JPEG movies Requirements: Parallax XVideo board Price: 1 floating license $1,595 ($960 intro) NVR Digital Media Compressor Includes: Support for compressing JPEG movies (both audio and video) into MPEG. Other input formats available on request. Requirements: No special display requirements Price: 1 floating license $2,495 ($1,495 intro) Development Kit: Includes: 5 Player licenses 1 Recorder license 1 Compressor license. Requirements: As above for each product Price: $3,995 ($2,395 intro) Support and Maintenance: Includes: software upgrades email support limited phone support Price: 15% of purchased product price (Free intro!) Further Information ------------------- You can reach us at: North Valley Research, Inc. 15262 NW Greenbrier Parkway Beaverton, OR 97006 Tel: (503) 531-5705 Fax: (503) 690-2320 email (sales and marketing): marketing@nvr.com email (technical questions): support@nvr.com This and other text-only versions of our product sheets are available via anonymous ftp to nvr.com (192.82.231.50). Look in /pub/NVR. We are happy to mail paper versions of our product sheets on request. If you require a demo version, please call or send mail to support@nvr.com. --------------- Todd Brunhoff Vice President, R&D North Valley Research --------------------------------------------------------------------------- ~Subject: Demo of NVR Digital Media Development Kit $Revision: 1.2 $ $Date: 1994/08/06 19:49:42 $ We are pleased to make available another release of NVR's digital media development kit, version 2.0.3. You should already have a license key. If you don't, please contact us at support@nvr.com. This version has several fixes for bugs and some important improvements over version 2.0.2. In particular: - Support added for Alias PIX files - Support added for playing XING sequences that have illegal syntax (extra picture info and non-increasing temporal references) - 400% speed improvement for RGB --> Y/Cr/Cb conversion in the compressor and imageop (you'll want this if you are compressing any rgb files, such as SGI rgb files). - the deinterlace operator (in imageop and the compressor) was broken in version 2.0.2. You would only notice this if you are compressing abekas or other interlaced files. The 2.0.x version is a significant improvement over our last major release, 1.0.4. Briefly, this software offers: - MPEG video compression - image processing and compatibility with many image file formats, including JPEG, TIFF, SGI RGB and others. - MPEG audio compression - compatibility with a variety of audio files, including AIFF, AIFC Sun Audio and Parallax movie files. - MPEG system multiplexing - real-time, synchronized playback of any combination of video and audio files. This means you can play back MPEG video files with AIFF, or you can play back MPEG system streams containing MPEG video and MPEG audio. And everything in between - a variety of tools for converting image file formats and audio file formats. - a real-time video/audio recording program (Sun and Parallax hardware required) The software package is available in several pieces via anonymous ftp to URL=ftp://nvr.com/pub/NVR-software/ [192.82.231.50] Look in /pub/NVR-software for the license agreement and README file. It also contains about 25 megabytes of data and software, so first fetch the README file and read it to decide what you need. If you only need the software, you should get one of SGI-Product-2.0.3.tar.Z Sun-Product-2.0.3.tar.Z depending on the kind of hardware you have. Turning on the software ----------------------- If you already have a demo key from us, simply install the software described above and copy the file $NVRHOME/adm/keys/demokeys from the previous version into the same place in the new version. Then type: % installkeys This will give enable the software as before. If you don't have a demo key and would like one, please contact us at support@nvr.com. --------------- internet: toddb@nvr.com c--Q Q US: Todd Brunhoff; North Valley Research; ` 15262 NW Greenbriar Pkwy; Beaverton, OR 97006 - Phone: (503) 690-2357 Fax: (503) 690-2320 --------------------------------------------------------------------------- ~Subject: How will I get the NVR-Software ? From: Todd Brunhoff Date: Tue, 18 May 93 09:23:26 -0700 The price list and text-only versions of our product sheets are available via anonymous ftp to URL=ftp://nvr.com/pub/NVR-data-sheets/ [192.82.231.50]. Look in /pub/NVR-data-sheets. If you need glitzy paper versions to convey credibility, we are happy to mail our product sheets on request. The demonstration software package comes in several pieces via anonymous ftp to URL=ftp://nvr.com/pub/NVR-software/ [192.82.231.50) Look in /pub/NVR-software for the license agreement and README file. Briefly you will need: /pub/NVR-software/Manual.evenpages-1.0.2.ps.Z /pub/NVR-software/Manual.oddpages-1.0.2.ps.Z /pub/NVR-software/Product-1.0.4.tar.Z /pub/NVR-software/README and some selection from /pub/contrib/mpeg and /pub/contrib/jpeg depending on the kind of hardware you have. If you get our software via ftp, send us an email note and we will give you a demo license key so you can run it. --------------- internet: toddb@nvr.com c--Q Q US: Todd Brunhoff; North Valley Research; ` 15262 NW Greenbriar Pkwy; Beaverton, OR 97006 - Phone: (503) 531-5707 Fax: (503) 690-2320 --------------------------------------------------------------------------- ~Subject: SUBSECTION - MacIntosh --------------------------------------------------------------------------- ~Subject: Cdi Tools v2.0 Cdi Tools v2.0 is a complete Cdi/Video CD Authoring solution targeted for Mac C-programmer. Contents of Cdi Tools are: CDL - a real time scripting language BD - disc image builder (630 MB cdi image with 25'000 assets was bildt in 7 min 40 sec.) XLINK - MAC to OS9 cross linker RTRView - utility for analyzing real time files CDIView - utility for analyzing disc image files Reference productions with Cdi Tools: Burn Cycle, Escape from Cyber City, Video Speedway, Compton Encyclopedia, PGA Golf Tour Pricing information: MediaPlayback for PC/Mac US$1,200.00 MediaPreview for Mac US$3,995.00 MediaAuthor for PC/Mac US$5,999.00 ALPHA MEDIA, Inc. Media Integration & Consulting Neubrunn, 8488 Turbenthal, Switzerland Phone: (052) 454 281 Fax: (052) 453 138 E-mail: janosh@alphamedia.ch =========================================================================== ~Subject: SECTION 3. - FREE AVAILABLE SOFTWARE SUBSECTION - DOS SUBSECTION - Windows SUBSECTION - WINDOWS-NT SUBSECTION - OS/2 SUBSECTION - X-WINDOWS and UNIX SUBSECTION - VMS SUBSECTION - MacIntosh SUBSECTION - Atari SUBSECTION - Amiga SUBSECTION - NeXT SUBSECTION - SGI --------------------------------------------------------------------------- ~Subject: SUBSECTION - DOS --------------------------------------------------------------------------- ~Subject: AMpeg AMpeg v4.3-- A simple Audio Mpeg Layer 1& 2 encoder and a Layer 1,2, & 3 decoder suite. Source by ISO, compiled for MS-DOS by John Fulmer (jfulmer@databank.com) --- **Audio Mpeg Compression** Audio Mpeg Compression is a proposed standardized sound compression technique put out by the International Standards Organization (ISO). So far there has been three flavors, Layer 1 Layer 2, and Layer 3. It also features the following: * 8:1 to 10:1 compression for general music audio with no audible sound degredation. * 16:1 compression for general voice audio with no audible sound degredation. * On the fly decompression and playback (the Xing Layer 2 player comes to mind). * Xing also sells a Mpeg Layer 2 MCI driver for windows, and it's own encoder/decoder/editor package for windows. *Will hopefully become a standard for audio communications. **AMPEG** Ampeg is a straight compile of ISO's freely available and distributed code for a Audio Mpeg Layer 1 and Layer 2 encoder and a Layer 1, 2, and 3 decoder. It was compiled using DJGPP C (the MS-DOS port of GNU's C compiler) and falls under both IS0's and the FSF's copyrights (see ISOREL.txt and COPYING.TXT). ISO's orgional source code was only slightly changed to accomidate the DJGPP compiler's unique mindframe (a MS-DOS compiler that thinks it's a UNIX compiler, or vice versa). The orgional source code is available from ISO, or a affiliated ftp site, or the code for this version is available at the SIMTEL archive, or from me upon request. I've put minimal time into this, so don't expect perfection. It's just that no one else seems to have done the simple task of compiling this and releasing it in a usable form to the public. AMPEG runs under MS-DOS and Windows (and probably OS/2), with minimal memory requirements. Also compatable with Xing's audio MPEG Layer 2 player for Windows. The program is released as freeware and may be distributed freely, as long as this file, COPYING.TXT, the Readme files, and all other documentation accompany it. If you don't like it, compile it yourself! Note: This program had not been optimized in any way, and runs very slowly. For encoding, a 2MB file will take 5 minutes to process and a 20MB file will take at least an hour. Decoding is much faster but still fairly slow. However, I believe in the theory that a slow, free, useful program is better than no program at all. **Directions** AMPEG is made up of three components: 1) the aencode.exe program, which takes a PCM file (.WAV or .SND) and compresses it using Audio MPEG Layer 1 or Layer 2. 2) the adecode.exe program, which decodes Audio MPEG files into headerless PCM files (.SND). You can use a .SND to .WAV converter to reconvert the file to a .wav format. 3) the TABLE files, which both programs use to perform the MPEG compressions. There are two ways of running aencode and adecode. 1) (RECOMMENED) just type AENCODE (or ADECODE) and the program will prompt you for whatever information it needs. This method is very solid and works nicely. The possible options are: Sampling Frequency --> 44100(default), 48000, 32000 BitRate --> 64, 128, 256, 384(default) Compression Layer --> 1 or 2 2) (NOT RECOMMENDED) type AMPEGIN (or AMPEGOUT) [options] . This takes the input file and applys the program defaults and produces the output file. THIS METHOD IS NOT RECOMMENDED AND MAY CAUSE YOU TO LOSE YOUR ORIGIONAL FILE! Only specifying the input file without the output file, will cause the input file to be erased! This is a bug due to the fact that this program was written for a UNIX environment and it's not worth it to me to hunt it down. **Installation** AMPEG needs to know where the TABLE files are. This is a pretty clunkly installation procedure, but it works.... 1) put all non-text and non-executable files that were included in this .ZIP file into a directory by themselves called TABLESES. Not good english, but necessary to get around a bug 2) AMPEG MUST BE RUN FROM the directory ABOVE TABLESES (ie, if TABLESES is located in C:/util/tables; AMPEG must be run from the C:/util directory). 3) Alternatively you can create a environment variable to point to TABLES. Add the following line to your autoexec.bat file: SET MPEGTABLES = C:\\TABLES where is the path to the TABLESES directory. It seems that AMPEG looks for a directory whose name get corrupted somewhere in the AMPEG code. So if you name the directory "TABLESES" AMPEG will find it if 'TABLES' is in the SET statement, if you name it "CHAIRSRS" Ampeg needs to be told "Chairs" in the Set statement. Anyway AMPEG should now run. **Changes since 1.0 (first and last version)** *Changed version name to match ISO's version. *Found decoder source with layer 3 decompression. *decompression runs MUCH faster. **Disclaimer** I hold no responsibility for any damage, loss, or problems encountered in the use of this program. It is provided as-is, and there will be no future versions or bug fixes (unless ISO releases another). John Fulmer (jfulmer@databank.com) --------------------------------------------------------------------------- ~Subject: MAPLAYPC MAPLAYPC v1.2 ============= DOS port of the realtime full quality mpeg audio player for 11/22/44 khz playback on 486dx2 / p60 / p90 / higher + soundblaster 8/pro/16/awe. Original sources included. Get it now!. MAPLAYPC, the msdos (blech!) port of the famous MAPLAY program. It's a realtime full-quality MPEG audio player for dx2-66 / p60 / p90 and Soundblaster 8 / Pro / 16 / Awe . On ftp.cdrom.com : /pub/demos/incoming/music/programs/maplaypc.zip teeri.oulu.fi : /pub/msdos/programming/incoming/maplaypc.zip Done by MikMak / HaRDCoDE '95 --------------------------------------------------------------------------- ~Subject: More MPEG-Audio for MSDOS From: richie@ljouwert.et.tudelft.nl (Richie B) Date: Mon, 26 Feb 96 22:38:59 MET Hi there, MPEG layer II is really great, but for poor MS-Windows users, all it offers is the Xing shareware decoder. This decoder only plays MONO sound at low (really bad) quality. Since I started using MPEG encoding for my own site recently, I ported 2 freeware MPEG 2 decoder to MSDOS (namely "maplay" and "mpegaudio"). They are at: http://morra.et.tudelft.nl/~richie/ftp/sound/utils/ ftp://morra.et.tudelft.nl/pub/prince/sound/utils/ Perhaps they are of some use to you guys. Richie --------------------------------------------------------------------------- ~Subject: layr_200 From: "Matthias Hanft" Date: Thu, 23 Jun 1994 18:10:28 +0200 Subject: SUN and PC Version of MPEG Audio Codec Shareware SOFTWARE: MPEG Audio Layer 3 Shareware Codec and Windows Realtime Player ---------------------------------------------------------------- MPEG Audio Codec and Windows REALTIME Player from Fraunhofer IIS ---------------------------------------------------------------- Fraunhofer IIS announces l3enc/l3dec V2.00 and WinPlay3 V1.00. For high quality audio compression, the shareware l3enc/l3dec V2.00 package is available for Linux, SUN, NeXT and DOS on Versions for SGI and HP will follow soon. The shareware package for DOS includes a demo version of WinPlay3, a Windows MPEG Audio Layer 3 realtime-player. With MPEG Audio Layer 3 you can get a 12:1 compression with a CD like quality. Instead of 12 MByte / minute (stereo 44.1 kHz) you only need about 1 Mbyte / minute! More information can be found on or contact --------------------------------------------------------------------------- Subject: MPEG1-IIS Public C source code for MPEG1 audio decoder available now The source code for the MPEG1 audio decoder layer 1, 2 and 3 is now available on ftp.fhg.de (153.96.1.4). There are two files: mpeg1_iis.tar.Z (Unix: lines seperated by line feed only) mpeg1iis.zip (PC: lines seperated by carriage return and line feed) They are in the directory /incoming now but will be moved to the directory /pub/layer3/public_c. Please note that the public C code for the decoder is *not* identical to the shareware provided by Fraunhofer IIS. However we at Fraunhofer IIS did check that the layer 3 part of the public C source decoder works correctly. (As usual this does not imply any warranties). popp@iis.fhg.de (Harald Popp) --------------------------------------------------------------------------- ~Subject: mpeg2ppm This is the MPEG to PPM converter running under DOS. Its based on the MPEG-decoder called "mpeg_play" by the Berkeley Research Group. The basic idea was coming from the PPM-patch by Jef Poskanzer. Many thanks to both. SHAREWARE --------- MPEG2PPM is inexpensive shareware. If you are continuing using it after a 30 day trial-period, please send a letter containing the filled and signed registration-form and the little donation of 10 $ or 15 DM in cash to the adress below. ATTENTION: The dots the shareware version of MPEG2PPM produces are just delay, to force you to register. ATTENTION: A registration is recommended for commercial use. ATTENTION: The full-licenced version is restricted to a local area netword (company) or a privat single host. MPEG2PPM will decode a (video-only) MPEG-I-stream and extract the rebuild frames as PPM-files (Portable Pixmap). The extracted frames will be numbered starting from zero (0), the first part of the filename is derived from the original MPEG-stream, the files extension will be .PPM. The final PPM-files will be in 24-bit-format. MPEG2PPM expects MPEG-1 video streams only. It can not handle multiplexed MPEG streams or video+audio streams. The converter uses the paris entropy coding table set (which I believe to be the MPEG-1 standard). MPEG2PPM was developed by PHADE Software Inh. Frank Gadegast Leibnizstr. 30 10625 Berlin GERMANY phade@powerweb.de --------------------------------------------------------------------------- ~Subject: vmpeg VMPEG is now out in Version 1.5, Stefan sold the full version, but the "Lite" version is still available to the public, he included a nice button player interface, audio (!!), systemstream and CD support. It's just the best MPEG-utility for the end-user ever seen, yo ! From: stefan@lis.e-technik.tu-muenchen.de (Stefan Eckart) VMPEG V1.2 DOS / Windows MPEG player by Stefan Eckart September 1994 1. Features =========== - full MPEG-1 video standard (ISO 11172-2): I,P,B frames of arbitrary size - plays system layer (ISO 11172-1) files (audio is discarded) - high speed: e.g. 21 frames/s on a 386DX/33 for a 160x120 I frame sequence (mjackson.mpg) - supports VGA and a variety of SVGAs - display options: 4x4 ordered dither normal size (8 bit) 4x4 ordered dither double size (8 bit) grayscale (8 bit) true color (24 bit) - requires: - '386,'486 or '586 processor (no '286) - 4 MB RAM - VGA or Super VGA - Windows version: Windows 3.1, Win32s and optionally WinG 2. Overview =========== VMPEG is a fast decoder / viewer for MPEG encoded video sequences (.mpg files). MPEG (Moving Pictures Expert Group) is a video compression algorithm standardized by the International Organization for Standardization (ISO) and the International Electrotechnical Commision (IEC) as ISO/IEC IS 11172. Main application of MPEG is the storage and retrieval of video on/from Compact Disk at a rate of about 1.5 Mbit/sec. VMPEG can play MPEG system layer streams containing both video and audio. Most streams from CD-ROM (Video-CD) are of this type. The audio stream is discarded by the decoder. VMPEG automatically detects whether the file is a video compression layer or a system layer file. I have also included a small utility (MPGSPLIT) which extracts the video and audio streams from a system layer stream into separate files (cf. MPGSPLIT.DOC). The DOS version of VMPEG is compiled with the GNU C compiler (gcc) into '386 code and runs under the DOS extender GO32 by DJ Delorie which is included in the archive file. The DOS version of VMPEG cannot be run from Windows. The Windows version of VMPEG is the first release for Windows. It is not as thoroughly tested as the DOS version but already seems to be reasonably stable. Please feel free to report any bugs you encounter to my email address. The Windows version requires Windows 3.1 and the free Windows extensions MS Win32s (32 bit support) and optionally WinG (screen output acceleration). These packages are available by anonymous ftp from (currently) URL=ftp://ftp.microsoft.com:/developr/win32dk/sdk-public/Win32s115a.Zip URL=ftp://ftp.microsoft.com:/developr/drg/WinG/WINGBT.ZIP and perhaps somewhere on CompuServe. 3. Installation =============== 3.1 DOS version --------------- - You need at least a '386 with a VGA and 512 KB of RAM. 4 MB are strongly recommended. XT, AT, EGA and CGA are not supported. A '387 is not required nor does it increase speed. VMPEG doesn't use floating point. - You should leave about 2 MB of RAM (XMS) unused: if you have, say, a 4 MB system you shouldn't reserve more than 2 MB for a RAM drive. Otherwise the DOS extender would start swapping memory pages from and to disk. This would slow down the program, even if swapping to a RAM drive. - If you have installed EMM386 make sure you don't have specified the 'noems' option in your config.sys file. - Create a subdirectory for installation: md \vmpeg cd \vmpeg - Unzip the archive into this subdirectory: pkunzip -d vmpeg12.zip - Edit VMPEG.BAT and VMPEG24.BAT; you probably have to change drive and/or path specifications and to select a suitable graphics driver (see paragraph 4). 3.2 Windows version ------------------- - Install Win32s and (optionally) WinG. These packages come with their own installation instructions. Basically you have to run the setup program supplied with them. Installation of Win32s copies a couple of files (w32sys.dll, win32s.ini, win32s16.dll, winmm16.dll) to the Windows system directory and creates a WIN32S subdirectory with additional files. It also adds two entries (for winmm16.dll and w32s.386) to the system.ini file in the Windows directory. You can deinstall Win32s by removing these files and restoring your original system.ini file (saved in system.old by the setup program). Installation of WinG is optional. I have included two versions of VMPEG, one with WinG calls (VMPEGWIN.EXE) and one without (VMPEGNWG.EXE). The WinG version is faster, but the difference is only notable for large (CIF/SIF) MPEGs (may depend on your SVGA). WinG adds several files (wing.dll, wing32.dll, wingde.dll, wingdib.drv, wingpal.wnd, dva.386) to the system directory and adds an entry for DVA.386 to your system.ini file. To deinstall WinG simply remove this entry from system.ini. If you start VMPEG (or any other program using WinG) for the first time, a performance test window appears which adapts and optimizes WinG for the VGA in your PC. This takes a while (about 3 minutes on my computer), don't despair... - Create a subdirectory for installation: md \vmpeg cd \vmpeg - Unzip the archive into this subdirectory: pkunzip -d vmpeg12.zip if you don't need the DOS version, you can delete vmpeg, go32.exe, the drivers subdirectory and the vmpeg*.bat batch files - You can start the program (vmpegwin.exe / vmpegnwg.exe) either from the file manager or from the program manager (File->Run menu item) or you can define a program entry in the program manager (File->New menu item). - both VMPEG and the Win32s libraries need a lot of memory (about 3-5 MB in total), and you may therefore have to increase the size of the swap file. 4 MB of RAM are sufficient, however, to run the program without swapping (except during program startup). 4. Graphics Drivers (DOS version) ================================= The DRIVERS subdirectory contains a set of graphics drivers for different Super VGAs. Select the one that matches your graphics card by editing the file VMPEG.BAT (for 8 bit display). If none of the drivers work, you may try to use the (go32 internal) VESA driver and a TSR VESA BIOS extension. A collection of such drivers is available at URL=ftp://oak.oakland.edu/pub/msdos/graphics/vesadrv2.zip and on all other SimTel mirrors. True color support requires VESA BIOS. It works for my configuration (a Cirrus Logic GD5422 based card with VESA BIOS) and should work for most other 'well behaved' boards as well. You may have to adjust the -y option in the last line of VMPEG24.BAT. The number indicates the length of each scanline. This is usually either 1920 or 2048. If the frames appear scattered over the screen, the setting is probably wrong... If you get incorrect colors (red sky, blue faces) you have a card with reversed RGB order. Simply replace the -y... by a -Y... to fix this. 5. Troubleshooting ================== DOS version: If you get a message about the CPU not being in Real Mode, you have to remove the noems option from the EMM386.EXE (or any other EMS emulator) line in your CONFIG.SYS. Windows version: If you get the message 'Can't find WING32.DLL' you don't have WinG properly installed. Either install WinG or use VMPEGNWG.EXE instead. If starting VMPEGWIN briefly switches to text mode and displays the message 'This program cannot be run in DOS mode', Win32s is not installed properly. If you get 'Out of Memory' errors, you have to increase the size of your swap file (from the control panel). 6. Command Line Options ======================= The following command line options are valid for both DOS and Windows versions. To specify options to the Windows version, you have to run it from the program manager (File->Run menu). Of course you can set all these options interactively after starting vmpegwin (without command line options). vmpeg [options] input.mpg vmpeg24 [options] input.mpg vmpegwin [options] input.mpg vmpegwng [options] input.mpg options: -l loop the sequence (infinitely until you press a key) -x1 skip B frames -x2 skip B and P frames, i.e. only I frames are displayed; you should use this option for I-frame-only sequences (including Xing compatible streams) to make the program run faster (as it doesn't have to manage reference frames) -d0 (default) ordered 4x4 dither -d1 grayscale -d2 similar to -d0 but display magnified by a factor of 2 True color mode is selected by using vmpeg24 instead of vmpeg. In this case the -d switch isn't effective. DOS version only: -in displace output by n pixel in horizontal direction -jn displace output by n pixel in vertical direction VMPEG centers the MPEG on the screen. If the frame is larger than the screen you can use the -i and -j options to pan the visible area. positive n shifts to the right or bottom, negative n to the left or upwards. -zn reduce display speed. This is done by a counting loop, so you have to experiment until you get the speed you want. The program can be terminated by pressing an arbitrary key (DOS version). 7. Remarks ========== Please report bugs (don't forget to mention which version of VMPEG you are using!) to my email address: stefan@lis.e-technik.tu-muenchen.de or by mail to: Stefan Eckart Kagerstr. 4 D-81669 Muenchen, Germany 8. Acknowledgements, Copyrights =============================== This program comes without any warranty. Your are using it at your own risk. VMPEG is copyrighted software (C) Stefan Eckart, 1994. You may use, copy and distribute this program without restrictions but only in unmodified form and without charging money for it. GO32.EXE, DRIVERS\*.GRD: Copyright (C) DJ Delorie 24 Kirsten Ave Rochester NH 03867-2954 These files are part of DJGPP which is available from host: oak.oakland.edu (or another SimTel mirror) login: ftp password: send your e-mail address directory: /pub/msdos/djgpp other DRIVERS: Copyright (C) 1991 DJ Delorie, 24 Kirsten Ave, Rochester NH 03867-2954 Copyright (C) 1992 Csaba Biegl, 820 Stirrup Dr, Nashville, TN 37221 VMPEG: The library VMPEG is linked with is Copyright (c) Regents of the University of California. acknowledgement: ``This product includes software developed by the University of California, Berkeley and its contributors'' * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The program is compiled with GNU GCC, the C compiler of the Free Software Foundation (FSF), Inc. 675 Mass Ave, Cambridge, MA 02139, USA. VMPEG does not contain code covered by the FSF General Public License. 9. Known Bugs ============= Interframe coded macroblocks theoretically can experience wrap-around (255<->0). This happens rarely enough to live with it (fixing would reduce speed for all sequences). Accuracy of the IDCT does not meet the requirements of IEEE 1180-1990. It is, however, a reasonable trade-off between speed and image quality. Display should be synchronized to the frame rate signalled in the sequence header. The program should use VESA BIOS supplied information instead of the -y option. 10. References ============== 1. Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbit/s, International Standard ISO/IEC IS 11172, 1993. 2. Frequently Asked Questions (FAQ) of the alt.binaries.pictures and comp.compression newsgroup: contains an introduction to MPEG. 3. Documentation of the PVRG MPEG software: a thorough overview covering many aspects of MPEG. 4. Documentation of the MSSG MPEG-2 codec (mpeg2codec, see below). Appendix A: Related Software ============================ This list is probably incomplete, but it's all I'm aware of. Of course there are programs for other systems as well (Mac, Amiga etc.). mpeg2codec MPEG-1 and MPEG-2 codec from the MPEG Software Simulation Group Authors: Stefan Eckart, C. Fogg, C. Aeyung, S. Papuc Includes source code for Unix X11 and Windows (Win32s / NT) and compiled versions for PC. URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/ or URL=ftp://ftp.netcom.com/pub/cf/cfogg/mpeg2/ mpeg2play a speed optimized version of the decoder from mpeg2codec URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/mpeg2play/ mpeg_play MPEG Video Software Decoder (Version 2.0; Jan 27, 1993) Authors: Lawrence A. Rowe, Ketan Patel, and Brian Smith Computer Science Division-EECS, Univ. of Calif. at Berkeley URL=ftp://toe.cs.berkeley.edu/pub/multimedia/mpeg/mpeg-2.0.tar.Z cmpeg an MPEG encoder for the PC (DOS, 640K, no '386 req.) for Targa, PBMPLUS and Alchemy RAW images Author: Stefan Eckart URL=ftp://garbo.uwasa.fi:/pc/graphics/cmpeg10.zip dmpeg MPEG decoder and player for the PC (DOS, 640K, VGA) Author: Stefan Eckart URL=ftp://garbo.uwasa.fi/pc/graphics/dmpeg11.zip mpegwin Port of mpeg_play for MS-Windows by: Michael Simmons, msimmons@ecel.uwa.edu.au toe.cs.berkeley.edu:/pub/multimedia/mpeg/Ports/mpegw* (HiColor & TrueColor support, Shareware) mpeg.exe DOS MPEG player from Xing Technologies (XingIt V2.1) (high speed, but decodes only a small subset of the MPEG standard, audio (.WAV,.MP2) support, Windows) mpegview.zip (available from many ftp sites) MPEGv1.1/1.2alpha MPEG Software Encoder/Decoder Authors: Portable Video Research Group (PVRG) URL=ftp://havefun.stanford.edu:/pub/mpeg/ MPEGv*.tar.Z disp a display program for pictures and animations including MPEG (based on mpeg_play) contains additional drivers that can also be used with VMPEG. Author: Jih-Shin Ho, u7711501@bicmos.ee.nctu.edu.tw URL=ftp://NCTUCCCA.edu.tw/PC/graphics/disp/ APPENDIX B: MPEG files ====================== Two good sources for MPEG files: s2k-ftp.cs.berkeley.edu:/pub/multimedia/mpeg/movies havefun.stanford.edu:/pub/mpeg High quality MPEGs you simply can't afford to miss: tennis.mpg flowg.mpg bike.mpg -- Stefan Eckart, stefan@lis.e-technik.tu-muenchen.de Kagerstr. 4, D-81669 Munich, Germany. Stefan Eckart, stefan@lis.e.technik.tu-muenchen.de --------------------------------------------------------------------------- ~Subject: cmpeg Stefan Eckart's CMPEG, another Freeware MPEG maker! Here is another MPEG creator! This one supports 8086+, so if you thought you couldn't make MPEGs, boy were YOU wrong. :-) Can make Xing (I-frame) or normal MPEGs (which contain I, P & B frames, and offer better compression). Be full aware of the fact that the slower your machine, the longer it will take to compress your files into an MPEG animation (does this need to be said?). (Don't expect eyeball-charring performance from your 286, please..) Due to its small size, I am offering CMPEG here at a2i. Access info: --------------------------------------------------------------------------- ~Subject: dmpeg Public Domain MPEG decoder by Stefan Eckart June 1993 1. Features DMPEG is another MPEG decoder/player for the PC: - decodes (nearly) the full MPEG video standard (I,P,B frames, frame size up to at least 352x288) - can save decoded sequence in 8 or 24bit raw file for fast off-line display (two pass mode) - optional on-screen display during decoding - several dithering options for 8 bit displays: ordered dither, Floyd-Steinberg, grayscale - selectable color-space - runs under DOS, 640KB RAM, no MS-Windows or '386 required - compact (small code / small data models, 16 bit arithmetic) - supports VGA, many Super-VGAs (including VESA) and some TrueColor SVGAs DMPEG is both an MPEG viewer AND converter. When viewing, it is important to note that it is markedly slower than the Xing player. That is, unless you CONVERT the MPEG to DMPEG's proprietary RAW format. You then use a special player, included, which will show the RAW format animation on VGA, SVGA, or VESA screens! And, hey 286 users, this one actually works on 80286 machines (albeit a little slowly). The converter does a remarkable job, and I use it for the "essential" MPEGs that I would like to view at the highest speed possible. If you have the anim loaded in RAMdisc then you have a really nice framerate even on a lowly 386! :) In the newly released 1.1 version, the converter and viewer are now included in one executable. It is important to note that this viewer will allow users to see MPEGs that the Xing player will not. This is because DMPEG is programmed to view all 3 frametypes, while Xing's player isn't. If the MPEG won't view using Xing, try this player, DMPEG. --------------------------------------------------------------------------- ~Subject: secmpeg [ This is the README.DOS file out of the SECMPEG-archive. Read below in ] [ the UNIX-section for more information about SECMPEG. ] SECMPEG is a program based on a rather complex algorythm to ensure a confidentiality and a integrity service for the video-stream MPEG-I. SECMPEG.ZIP (c) 1994 by Frank Gadegast and Juergen Meyer This is my DOS-port of the MPEG-filter called "secmpeg". Read the provided file README and the man-page first. It was compiled with the DOS-port of the GNU GCC-compiler, called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please read the GNU-Licence-file 'LICENCE.GNU'. You find the DOS executable in this distribution under 'secmpeg.exe'. NEEDS and INSTALL Cause of DJGCC, the final executable is not running under DPMI (so not in a Windows-DOS-Box) nor on a 286-machine. The executable 'GO32.EXE' has to be somewhere in the PATH. If running on a 386, the emulationfile 'EMU387' has to be, where the environment variable GO32 is pointing to, so if the emu-file is in D:\LIB enter: set GO32=emu d:/lib/emu387 Permission to use, copy, modify, and distribute this soft- ware and its documentation for any purpose and without fee is hereby granted, provided that the archive remains com- plete, that this author notice will appear in all copies and as long as you don't try to make money off it, or pre- tend that you wrote it. --------------------------------------------------------------------------- ~Subject: mpegstat [ The first tool to test a MPEG-I-stream ! Including statistics, frame- ] [ order, decoding times !! Now you can test, if archives are ok or if a ] [ file uudecoded ok without playing it ! This code is surely based on ] [ the berkeley-decoder. ] MPEGSTAT.ZIP (c) 1994 by PHADE Software This is my DOS-port of the MPEG-filter called "mpegstat". It was compiled with the DOS-port of the GNU GCC-compiler, called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please read the GNU-Licence-file 'LICENCE.GNU'. NEEDS and INSTALL The executable 'GO32.EXE' has to be somewhere in the PATH. If running on a 386, the 387-emulationfile 'EMU387' has to be, where the environment variable GO32 is pointing to, so if the emu-file is in D:\LIB enter: set GO32=emu d:/lib/emu387 That should do, KeyJ Phade (phade@powerweb.de) --------------------------------------------------------------------------- ~Subject: enc11dos [ Well, and soon as it was out, I ported Berkeley's new MPEG-ecndoder ] [ to DOS as well, here the README.DOS file. For more information see ] [ below in the UNIX-section. ] ENC11DOS.ZIP (c) 1993 by PHADE Software This is my DOS-port of the MPEG-encoder called "mpeg_encode" by the Berkeley Research Group. It was compiled with the DOS-port of the GNU GCC-compiler, called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please read the GNU-Licence-file 'LICENCE.GNU'. NEEDS and INSTALL The executable 'GO32.EXE' has to be somewhere in the PATH. If running on a 386, the 387-emulationfile 'EMU387' has to be, where the environment variable GO32 is pointing to, so if the emu-file is in D:\LIB enter: set GO32=emu d:/lib/emu387 That should do, KeyJ Phade (phade@powerweb.de) --------------------------------------------------------------------------- ~Subject: pvrg MPEG [ Well, this is just class. The Stanford-Codec is now available for ] [ DOS-users. The file is usually called PVRGMPEG.ZIP, it supports ] [ IPB-Frames and Xing-Format ! Sometimes called MPGCODEC too. ] From: glogan@taynet.co.uk Subject: PVRG MPEG CODEC Date: 15 Jun 93 20:09:52 +0100 This archive contains the following files: README.1ST This file PVRGMPEG.EXE My port of the PVRG MPEG CODEC PPM2CYUV.EXE My port of the PVRG YUV file splitter CYUV2PPM.EXE My port of the PVRG YUV file combiner MAKEMPEG.TXT Details of how I did the port USEMPEG.TXT Details on using PVRGMPEG SHORT.MPG A XING compatible version of short.mpg supplied by PVRG with the source code. SHORT*.GIF The 10 frames in GIF format to make SHORT.MPG I hope I have not offended anybody by putting this archive together. I offer no warranty of any description with respect to my porting. All of the EXE files were compiled by me from Publicly available source code from the FTP sites listed in MAKEMPEG.TXT. I would like to thank the PVRG group for writing such an excellent encoder and for their help in getting at the Alpha release of v1.2 so quickly (I can't name this person as the PVRG copyright notice forbids it). Also I would like to thank Jelle van Zeijl for sending me the XING patch originally written by Mats Loftvist which has subsequently been included the Alpha release of v1.2. Have fun and please mail me to let me know how you get on. A copy of any interesting movies would be appreciated. This is the MAKEMPEG.TXT file from pvrgmpeg.zip it may help you port the PVRG MPEG CODEC to your platform. Hi All you Eager MPEG Makers, here is how to port the PVRG MPEG encoder/decoder to DOS/PC (386). Tools required: Well the ones that I used. GNU C version 2.2.2 An uncompress util for UNIX .Z files An untar util for UNIX tar files Text Editor (sorry some code needs tweaked) Note: Diff from the GNU File utilities, could be used instead Source required: 1) /pub/mpeg/MPEGv1.2.alpha.tar.Z from havefun.stanford.edu /pub/mpeg/MPEGDOCv1.1.tar.Z from havefun.stanford.edu documentation still to be updated. 2) The DOS port of PPM2CYUV called ppm2cyuv.exe 3) Image Alchemy from a number of ftp sites. eg /mirrors4/garbo.uwasa.fi/graphics/alch16.zip at wuarchive.wustl.edu Image Alchemy may be replaced with giftoppm.exe from the pbmplus set of graphics tools. Graham Logan June 15th 1993 glogan@taynet.co.uk --------------------------------------------------------------------------- ~Subject: SUBSECTION - Windows --------------------------------------------------------------------------- ~Subject: CoolEdit 1.5.3 [ This is really cool ! MPEG encoding and decoding in a windows-tools. ] [ Surely not it realtime, but it works ;o), check their site under ] [ http://www.syntrillium.com/#Cool ] ---------------------------------- MPEG Layers I and II for Cool Edit ---------------------------------- The complete MPEG file filters for Cool Edit consists of the following: MPE.FLT MPEG encoder MPG.FLT MPEG decoder MPEG.DAT MPEG related data (psychoacoustic models, etc.) COPYING.TXT GNU General Public License document README.TXT This file. This MPEG implementation is covered under the GNU General Public License, so the source code for Cool Edit's MPEG implementation is available upon request. No special optimization was performed (which means it will be about 1998 before Cool Edit will be able to read MPEG II files in real time with this current module on common PCs). MPEG audio data is saved without any headers, and in Intel byte ordering format. Some ShareWare (and retail) players are available that will play files saved by Cool Edit. The Xing audio player is one of them. Happy compressing!!! -David Johnston Syntrillium Software Corporation --------------------------------------------------------------------------- ~Subject: Maplay 1.2 for Win32 Maplay 1.2 for Win32 Last modified: Februrary 3, 1995 What is maplay 1.2? Maplay 1.2 is a program written for UNIX systems by Tobias Bading. What it does is decodes MPEG Audio Layer 1 and 2 files, which are factor of 6-12 times smaller than uncompressed audio (like Windows PCM WAVE, Sun AU, or Mac AIFF files). Despite the huge compression, there is no audible signal loss! You can retain CD-quality sound at compression ratios around 1:6 (128 kbit/s). Unfortunately, decoding MPEG audio streams is a very CPU intensive process. And until now, there have been no fully-featured decoders available for Windows. What is maplay 1.2 for Win32? Thanks to Bading's hard work in maintaining portability in maplay, I was able to retarget maplay to run on the Windows 95 and Windows NT operating systems. I also added a few features such as WAV playing, pausing, stopping, and repeating MPEG audio playback. It took about 4 weeks, since I had no prior Windows programming experience. Doesn't XingSound do the same thing? No. Compare the features in the following table: Program L1 L2 WAV Bits/sample Sample Stereo Win3.1 Win95WinNT freq. XingSound1 ? YesYes 162 22.0 kHz No Yes Yes3 Yes3 maplay for Win32 Yes YesYes 16 44.1 kHz Yes No Yes Yes 1Freeware version of XingSound. There is a full-featured version, but it is not free. 2Low precision 3Not a native 32-bit program Should I even consider XingSound at all? Yes. Maplay 1.2 for Win32 is recommended for 486DX2-66 or higher x86 machines (for stereo playback), running Windows 95 or Windows NT. It will not run on Windows 3.1 or lower operating systems, even if you have Win32s. It is also pretty CPU intensive due to its high precision and playing frequency. Also, it does not work on 8-bit sound cards yet. Finally, unlike XingSound, maplay 1.2 for Win32 cannot fast forward, rewind, or search for tracks. If you need these features or don't have what it takes to run maplay 1.2 for Win32, get XingSound (115k) instead. But if quality is a priority and you have a 16-bit sound card and decent computer and multimedia equipment, maplay is the way to go! Cool. Where can I get maplay for Win32? Maplay for Win32 is available here in following six flavors: With Source Code Without Source Code 386 compatiblempw32-3s.zip mpw32-3n.zip Intel 486 mpw32-4s.zip mpw32-4n.zip Pentium mpw32-5s.zip mpw32-5n.zip ... Or from an FTP site to be announced later. E-mail me if you have problems obtaining it. If you have a non-Intel CPU, choose the 386 version. For my testers, these versions should be much smoother. How do I use maplay for Win32? Maplay for Win32 supports command-line playback, so you can associate MP2 or MPG files with maplay in the File Manager of Windows Explorer. You can also use it as a viewer in Netscape. The MIME type is "audio", and the subtype is "x-mpeg". Finally, you can use as a stand-alone program, as there is a menu item to open files. Feel free to E-mail me if you need further instructions. How much does maplay for Win32 cost? Nothing. Well, almost nothing. Of course you still have to pay for the access time and the long distance charges to download it! I do request that you e-mail me and tell me if it worked on your system. Also, your generous donations are welcomed but not required. Are there any bugs in maplay for Win32? Well, as I said before, I'm new at Windows programming, so I'm sure there are. But the following are the only bugs I know about: * Sometimes the shortcut keys don't work. You just have to use the mouse. I'll work on getting rid of these bugs, and if you find any others, please e-mail me. Where can I get MPEG audio files? Good news if you're into Japanese animation music because I've recorded a number of MPEG audio files from my favorite anime. The Underground Music Archive also has MPEG audio streams of unsigned artists. I'll list some more sources shortly. Credits Well, I hope I'm not being to presumptuous by listing credits, but here goes: Original Source Code by Tobias Bading. Copyright (C) 1993, 1994 Berlin University of Technology. Win32 port and interface by Jeff Tsay. License rights granted by the Free Software Foundation, Inc. Academic (reduced price for students) C++ compiler sold by Borland International. Thanks to my computer science teachers and professors at Eastern High School and UC Berkeley! Need more information? Broken links? Comments? Please contact me at ctsay@pasteur.eecs.berkeley.edu. --------------------------------------------------------------------------- ~Subject: WinPlay ---------------------------------------------------------------- MPEG Audio Codec and Windows REALTIME Player from Fraunhofer IIS ---------------------------------------------------------------- Fraunhofer IIS announces l3enc/l3dec V2.00 and WinPlay3 V1.00. For high quality audio compression, the shareware l3enc/l3dec V2.00 package is available for Linux, SUN, NeXT and DOS on Versions for SGI and HP will follow soon. The shareware package for DOS includes a demo version of WinPlay3, a Windows MPEG Audio Layer 3 realtime-player. With MPEG Audio Layer 3 you can get a 12:1 compression with a CD like quality. Instead of 12 MByte / minute (stereo 44.1 kHz) you only need about 1 Mbyte / minute! More information can be found on or contact --------------------------------------------------------------------------- ~Subject: XingIt [ This is Xing's new Public-Domain-Player. It is enhanced, but still ] [ has of bugs. You have to deinstall the old .DLL's and the MCI-driver ] [ to have it running proper. The DOS-MPEG-Player included in this file ] [ (named MPEGVIEW.EXE) doesn NOT run with all Soundblaster-compatible ] [ cards and kills the machine quit often. ] XingIt! MPEG Player Software Demo (August 27,1993) The file MPEGVIEW.EXE installs Xing Technology, Inc.'s XingIt! MPEG Player Software Demo for IBM PC compatibles. Xing's "XingIt!" real-time video MPEG capture board, including encoding software, video and sound editor, and the full-featured player is available direct from Xing Technology, Inc. in Arroyo Grande, CA (See below for order info). The file MPEGVIEW.EXE is a self extracting archive. To install the player, create a new directory on your hard drive and copy MPEGVIEW.EXE into it. Change to that directory and type MPEGVIEW to extract the player files. MPEGVIEW.EXE also contains a DOS version of the player, MPEG.EXE. To run the DOS version, change to the directory where you extracted MPEGVIEW.EXE and type "MPEG MPEGFILENAME.MPG". --------------------------------------------------------------------------- ~Subject: mpgaudio Now there is the MPEG AUdio Player for Win3.1 ! This program is Shareware. To encode your own MPEG Audio files, you need to buy the MPEG Audio Software Encoder program for Win3.1 . [ Look above. Get some freeware encoder in software, much better !] --------------------------------------------------------------------------- ~Subject: SUBSECTION - WINDOWS-NT --------------------------------------------------------------------------- ~Subject: mpeg2ply [The June 30 edition of mpeg2w11 does not contain encoder port] MPEG Software Simulation Group codecs for Windows 32s (MPEG-L@netcom.com) MPEG2DEC.EXE and MPEG2ENC.EXE are Windows 32s ports with integrated display functions of the MPEG Software Simulation Group's programs. MPEG2PLY.EXE is the port of mpeg2play---Stefan Eckart's variation of mpeg2decode which optimizes speed through fast decoding methods such as approximation techniques, loop unravelling, et al. All Win32s programs were ported with Microsoft Visual C++. Only the main() program and display files (mpeg2dec.c, mpeg2enc.c, or mpeg2ply.c) differ from the standard "Unix distribution." If you do not have a 32-bit Windows environment (e.g. Win 4.0 Chicago, Windows NT), but plain old Windows 16 (e.g. Windows 3.1), yet you do possess either a 386, 486, or Pentium-based PC, you can download the Microsoft 32-bit extension program, "Win32s" from the Microsoft FTP site: URL=ftp://ftp.microsoft.com/developers/DEVTOOLS/Win32SDK/Win32s115a.zip [198.105.231.1] (this is the latest edition--June 23, 1994) Win32s archive (mpeg2w11.zip): mpeg2dec: mpeg2dec.c Main() routine. Initiates application and display. mpeg2dec.r MS Visual C++ resource file. makefile MS Visual C++ project file. gui.h #include constants for MS GUI values. mpeg2dec.exe Speed-optimized executable grayleo.ico mpeg2dec.exe 32x32 4-bit System Palette icon About the windows icon: The 32x32 4-bit icon for MPEG2DEC.EXE and MPEG2ENC.EXE is a silhouette of Dr. Leonardo Chiariglione (CSELT, Italy), none other than our co-founder and exhaulted lifetime Convenor of MPEG. Acknowledgement: Many thanks to Sorin Papuc (sop@compcore.com) for porting these programs to Windows 32s. --------------------------------------------------------------------------- ~Subject: mpegplay [ This new version of it, is running now extremly nice, the subsystem ] [ is no harm at all. The file should be known as MPEGW32W.ZIP. ] From: michael@ecel.uwa.edu.au (Michael Simmons - division) MPEGPLAY V1.61 (c) 1993,1994 Michael Simmons Please READ ALL of this file! This is Release Version 1.61 of my port of the Berkeley mpeg player. Note this version requires the WIN32s V1.15a Windows(tm) Extender. Also this version will only work under (beta 612) of Windows NT(tm) V3.5 or later. Features added in this version include (1) Support for MPEG1 System Layer files (you don't have to split them now). (2) Support for the Microsoft(tm) WinG(tm) Windows(tm) gaming library. (3) Improved colours for the Ordered and 2x2 Order dithers. (4) "Save As" For all the Mosaic Users. (5) Improved Error handling for corrupt/non standard mpeg files. (6) Support for CDI(tm) and VideoCD Streams. Either as an extracted MPEG sequence or as a RAW CDROM grab. (7) Recompiled using the Microsoft Daytona(tm?) (beta 612) SDK Compiler. Please Email me with any suggestions you may have on improving the player! (See the section CONTACTING ME). This player can play standard mpeg files that include P and B frame encoding, and large 354x288 movie files. It has several display options including mono, gray scale, color dither and Full colour (for Hicolor graphic cards). 8MB of Ram or greater is recommended if large Image size MPEG files are played. This program is SHAREWARE Please read the REGISTER.TXT file for information on registering your copy. To install the player. If you don't have Win32s V1.15a installed, install it first. Unzip the file disk1.zip to a floppy disk. Then run the setup.exe file via the Progman File-Run Menu Item. Note: This will also install the Microsoft WinG(tm) extensions to Windows(tm) Should you wish to remove these extensions at a later date please refer to the section near the end of this Readme.txt file. Read the Disclaimer in the online Help before loading any mpeg movie files. The latest version of this software can be found first on URL=ftp://ftp.ecel.uwa.edu.au/users/michael/ UNREGISTERED VERSION LIMITATIONS: The unregistered version will display the About box at startup. IT WILL ALSO NOT HANDLE FILES BIGGER THAN 1MB! DISTRIBUTION: The Unregistered Version of the Player may be freely Re-Distributed so long as (1) None of the files are modified. (2) All files in this archive are re-distributed together. (3) None of the files are removed from this archive. (4) It is clearly stated that this program is Shareware, extended use of which requires payment to myself Michael Simmons as described in the players about box and the REGISTER.TXT file. (5) If any additional files are added it must be clearly stated which files have been added, who added these files and why!. It must be stated that I "Michael Simmons" am in no way responsible for these additional files. (6) None of the added files can instruct the user or modify the player in any way possible to enable the Unregistered Version Limitations to be overcome. The Registered Version may only be Re-Distributed with my written approval. KNOWN BUGS: The player does not like certain PD/Shareware desktop addons (Clocks etc). A small number of people are getting a GPF in POINTER.DLL. If you have this problem and solve it please contact me. So far I can not reproduce the fault. The player does not multitask while scanning a file to determine whether or not it is a system layer or straight video file. This is only a problem on large misaligned RAW CDI or VideoCD grabs. RAW CDI or VideoCD grabs have only be tested on 4 CDI Disks. Given the variation found between these disks I would not be surprised if there are problems with some disks. If you are having a problem with a certain CDI/VideoCD disk please send a copy (both original CD's) of it to me. If I don't already have it I will treat it as a registration fee. If you have a problem and are really stuck try and find a machine on which it works and compare the two configurations. If you really really get stuck then see the section CONTACTING ME. CHANGE LOG: (there is more to read after this section) Changes V1.0 -> V1.2 (1) Re complied using the latest (March) WIN32 Beta. (2) Includes the latest (March) Win32s windows 3.1 extension. (3) Fix bug in finding help file. The working directory can now be different to the Command Line directory. (4) Increase number of clicks at startup to 4 Changes V1.2 -> 1.25 (1) Major rewrite of source code to clean up bugs (2) Now saves options in a .ini file (3) Can split a multi stream MPEG into separate files. (4) Loop is now a separate option (5) Can be set to skip over B and P frames ( best to stop and rewind player 1st) (6) Decrease the number of About Box clicks to one (7) Can started via the file manager (associate .mpg with the player) (7b) Also startable from other applications i.e. NCSA Mosaic. (8) Recompiled with the release version of the Visual C++ for NT compiler (9) includes the Win32s version 1.1 files (10) Can change InputBufferSize in .ini file (i.e. InputBufferSize=80000) (11) Don't have to Close MPEG before OPEN ing (12) MPEG images are properly clipped when they are displayed (13) Hopefully no one will have any display problems now (try Use Small DIBS) Changes V1.25 -> V1.30 (1) Increased speed 10-20% (mainly P B frames and gray, Full/Hi Color dither). (2) Fixed bug, old mpegs causing exceptions (bus.mpg,flower.mpg,flowb.mpg etc). (3) Decreased the memory usage. (4) Added HiColor Dither (Uses 16 Bit DIBS,These are not supported by many drivers yet, NT emulates support in the GDI). (5) Dropped Fs2 and Fs4 dither (use Fs2Fast) Changes V1.30 -> V1.50 (1) Added Push button, VCR like controls. (2) Now has a Separate Video Window. (3) Automatically Displays the 1st frame of the MPEG. (4) Redraws the current frame when needed. (5) Displays MPEG File Name, Image Dimensions and File Size in Video Caption (6) Saves all window positions correctly when exiting. (7) Detects when saved windows position is off the screen. (8) Added Experimental Set+Blt Mode for transferring images to the screen. Changes V1.50 -> V1.60 (1) Support for MPEG1 System Layer files (you don't have to split them now). (2) Support for the Microsoft(tm) WinG(tm) Windows(tm) gaming library. (3) Improve colors for the Ordered and 2x2 Order dithers. (4) "Save As" For all the Mosaic Users. (5) Improve Error handling for corrupt/non standard mpeg files. (6) Support for CDI(tm) and VideoCD Streams. Either as an extracted MPEG sequence or as a RAW CDROM grab. (7) Recompiled using the Daytona (beta 612) SDK Compiler. ACKNOWLEDGMENTS: This code was derived from the U.C. Berkeley MPEG Player (version 2.0) developed by L.A. Rowe, K. Patel, and B. Smith (Rowe@CS.Berkeley.EDU). Permission to use their code in this Sharware product was obtained. THAT code included the following copyright: /* * Copyright (c) 1992 The Regents of the University of California. * All rights reserved. * * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose, without fee, and without written agreement is * hereby granted, provided that the above copyright notice and the following * two paragraphs appear in all copies of this software. * * IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR * DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT * OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF * CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANT ABILITY * AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS * ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO * PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. */ /* OTHER ACKNOWLEDGMENTS: Frank Gadegast (the MPEG FAQ Maintainer) for his helpful suggestions. Many others for their suggestions and support. PATENTS: Should this player infringe on a patent held by someone somewhere. Please contact me as soon as possible. See the section CONTACTING ME CONTACTING ME: In any correspondence please clearly state your email and snail mail addresses! I have been receiving a large number of emails. In-order to handle these efficiently I would ask that you note the following: (1) If possible look on URL=ftp://ftp.ecel.uwa.edu.au/users/michael/faq.txt (2) Mark all emails that do not require a reply "No Reply Expected". I will READ THESE! (3) Bounced replies due to incorrect email addresses (unless obvious) will not be chased up! Email to michael@ecel.uwa.edu.au Talk to michael@div-pc-michael.ecel.uwa.edu.au (8:30am to 5:00pm WA time). Phone to (Int)+ 61 9 344 1998 (Home number with answering machine) Don't automatically expect me to ring outside of Western Australia. I can be contacted via snail mail to PO Box 506,NEDLANDS WA 6009,AUSTRALIA NOTE None of the source code to this player is on any of the machines connected to the net via the University of Western Australia. IF someone on network news is flaming me or my port of the player. Please Email me about it. OTHER INFO: There is another mpeg player for windows available for free from URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/mpeg2w11.zip I have nothing to do with this player. None of the source for that player is related to mine. All of the money from registration is being spent on tools and hardware to improve the player and further my knowledge of MPEG and programming. This player is written and maintained in my free time. It is in no-way related to the University of Western Australia. They have indicated they have no interest in the player or its copyright. The Source to this player is NOT Available! HOW TO REMOVE THE WIN32s EXTENSIONS to WINDOWS(tm) (1) exit to DOS. (2) backup your hard disk. (3) delete the Win32s directory and all its files. (4) edit the system.ini file in the window directory. and remove the line device=C:\WINDOWS\SYSTEM\WIN32S\W32S.386 (5) return to windows (6) remove the Win32 Applications Progman group HOW TO REMOVE THE WING EXTENSIONS TO WINDOWS(tm) (1) exit to DOS. (2) backup your hard disk. (3) delete the following files from you c:\windows\system directory dva.386 wing.dll wing32.dll wingde.dll wingdib.drv wingpal.wnd (4) edit the system.ini file in the window directory. and remove the line device=C:\WINDOWS\SYSTEM\dva.386 (5) return to windows Windows NT, Win32s, Windows 3.1, WinG are trademarks of the Microsoft Corporation. CDI is a trademark of Phillips. --------------------------------------------------------------------------- ~Subject: SUBSECTION - OS/2 --------------------------------------------------------------------------- ~Subject: mp mp.lha gfx/show 45K 83 MPEG player for EHB display. --------------------------------------------------------------------------- ~Subject: SUBSECTION - X-WINDOWS and UNIX --------------------------------------------------------------------------- ~Subject: FHG Layer 3 ISO-MPEG Audio Layer 3 software only Encoder and Decoder for Unix Version 2.00. copyright Fraunhofer - IIS 1994, 1995 - 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 - 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), in RIFF/WAVE format as used by Microsoft Windows .WAV files, in AIFF/AIFC format as used by SGI and Mac or in .snd/.au format used by NeXT and Sun. - 44.1kHz sampling frequency (32 kHz and 48 kHz also for registered users) - packed bit stream conforming to ISO/MPEG Layer III - output of decoder is in raw format (16 bit signed integer), in .snd/.au format, in AIFF/AIFC format or in RIFF/WAVE format - .WAV music files can be played with Windows Media Player - Under rare circumstances the .WAV output is broken. Please use raw format in that cases. - optional decoder output as 24 bit hex ascii data - written by the very same people at Fraunhofer-IIS who did the Layer III codecs for the ISO and ITU-R (former 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 l3v200.UNIX_NAME.tar.gz: l3enc encoder program V2.00 l3dec decoder program V2.10 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 history.txt infos on the history of this shareware product go32.exe DOS extender winplay3/ in this directory is a demo version of the realtime Windows player WinPlay3 mp3-bitstreams.tar.gz: contents.txt short discription of the following Layer 3 bitstreams (CR/LF format) contents short discription of the following Layer 3 bitstreams (LF format) funky.mp3 demo layer 3 bitstream (96 kbit/s, stereo, 44.1 kHz) spot1.mp3 demo layer 3 bitstream (96 kbit/s, stereo, 44.1 kHz) spot2.mp3 demo layer 3 bitstream (96 kbit/s, stereo, 44.1 kHz) spot3.mp3 demo layer 3 bitstream (96 kbit/s, stereo, 44.1 kHz) classic1.mp3 demo layer 3 bitstream (56 kbit/s, stereo, 22.05 kHz) classic2.mp3 demo layer 3 bitstream (48 kbit/s, stereo, 22.05 kHz) The song used for funky.mp3 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). The other bitstreams were provided by OMNI-Mediasound. 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. 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 or try http://www.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 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. --------------------------------------------------------------------------- ~Subject: Berkeley's MPEG Tools [ These tools were still in Beta-Version when the FAQ was compiled ] [ Try ftp to URL=ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/ [ find the next 4 tools. ] This version of the Berkeley MPEG Tools packages together the decoder (mpeg_play), the encoder (mpeg_encode), and three analysis tools (mpeg_stat, mpeg_blocks, and mpeg_bits). Our last estimate was that over 60,000 copies of the decoder have been FTP'd since the first release in November 1991, and over 15,000 copies of the encoder have been FTP'd since it was released in July 1993. For other information on multimedia research at U.C. Berkeley, see the home page for the Plateau Multimedia Research Group. http://www-plateau.cs.berkeley.edu/plateau.html Further about the FTP site is included in INDEX. See ANNOUNCE for our posted announcement of the tools. (Last updated: May 5, 1995) -- Eugene Hung eyhung@garnet.berkeley.edu Peter's Theorem: Incompetence plus incompetence equals incompetence. --------------------------------------------------------------------------- ~Subject: MPEG-1 Video Software Encoder MPEG-1 Video Software Encoder (Version 1.5; May 8, 1995) Lawrence A. Rowe, Kevin Gong, Eugene Hung, Ketan Patel, Steve Smoot and Dan Wallach Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains the freely distributed Berkeley MPEG-1 Video Encoder. The encoder implements the standard described in the ISO/IEC International Standard 11172-2. The code has been compiled and tested on the following platforms: DECstation 5000 and Alpha HP PA-RISC (HP/UX 9.X) (i.e., HP 9000/7XX and 9000/3XX) SGI Indigo running IRIX 5.0.1 Sun Sparc (SunOS 4.X) In addition, Rainer Menes from the Technical University of Munich has ported the encoder and decoder to the Macintosh. You can get that code directly from him (menes@statistik.tu-muenchen.de), or from the Berkeley FTP archive (mm-ftp.CS.Berkeley.EDU). If you decide to port the code to a new architecture, please let us know so that we can incorporate the changes into our sources. This directory contains everything required to build the encoder and run it. We have included source code, makefiles, binaries for selected platforms, documentation, and test data. Installation instructions are given in the file named src/mpeg_encode/INSTALL. A man page is given in the file doc/mpeg_encode.1. A detailed user manual is provided in postscript format in the file doc/user-manual.ps. The encoder will accept any input file format as long as you provide a script to convert the images to PPM, YUV, JPEG, or JMOVIE format. Input file processing is described in the file doc/INPUT.FORMAT. Options to control input file processing and compression parameters are specified in a parameter file. Very little error processing is done when reading this file. We suggest you start with the sample parameter file examples/template.param and modify it. See also examples/default.param. The convert directory of Mpeg-Tools contains utilities you might find useful including: programs to do PPM/YUV conversion and programs to convert Parallax XVideo JPEG files into PPM, YUV, or JPEG frames. The motion vector search window can be specified, including half-pixel block matching, in the parameter file. We have implemented several search algorithms for P-frames including: 1) exhaustive search, 2) subsampled search, and 3) logarithmic search. We have also implemented several alternatives for B-frame block matching including: 1) interpolate best forward and best backward block, 2) find backward block for best forward or vice-versa (called CROSS2), and 3) exhaustive cross product (i.e., go out for coffee and a donut!). The search algorithms are controlled by options in the parameters file. For tips on choosing the right search technique, see the user manual. The encoder can be run on one computer (i.e., sequential) or on several computers (i.e., parallel). Our goal is to produce a portable, easy-to-use encoder that we can use to encode large volumes of video material for the Berkeley VOD system (see paper VodsProp93.ps.Z on the FTP archive). The parallelism is done on a sequence of pictures. In other words, you can spawn one or more children to encode continuous runs pictures. The uncompressed data can be accessed either through NFS or TCP sockets. The goal is to allow you to encode using multiple processors, think spare cycles on workstations, to speed up the encoding time. Although performance depends on the speed of individual processors, the file system and network, and the P/B frame search methods, we have encoded 3.75 frames/second on 8 HP Snakes running in parallel as compared with 0.6 frames/second on 1 Snake. These are preliminary results. We are continuing to experiment with and tune the code. Instructions to run the parallel system are given in the man page and the parallel.param example parameter file. We have done some tuning to produce a reasonable encoder, but there are many more optimizations that we would like to incorporate. These extensions are listed in the file doc/EXTENSIONS. If you succeed in implementing any of them, please let us know! Send bug reports to: mpeg-bugs@CS.Berkeley.EDU Problems, questions, or patches should be sent to this address. Anyone interested in providing financial support for this research or discussing other aspects of this project should contact Larry Rowe at Rowe@CS.Berkeley.EDU (+1 510-642-5117). This software is freely distributed. That means, you may use it for any non-commercial purpose. However, patents are held by several companies on various aspects of the MPEG video standard. Companies or individuals who want to develop commercial products that include this code must acquire licenses from these companies. For information on licensing, see Appendix F in the standard. ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard and Fujitsu who provided financial support for this work. We also want to thank the following people and organizations for their help: Jef Poskanzer who developed the pbmplus package. --------- Copyright (C) 1989, 1991 by Jef Poskanzer. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This software is provided "as is" without express or implied warranty. --------- Eiichi Kowashi of Intel and Avideh Zakhor of U.C. Berkeley who provided valuable suggestions on motion vector searching. Chad Fogg of the University of Washington who has helped us understand many issues in MPEG coding and decoding. Rainer Menes of the Technical University of Munich who has ported the the Berkeley MPEG encoder and decoder to the Macintosh, and he has provided us with many suggestions to improve the code. Robert Safranek of ATT for comments, suggestions, and most of the code for custom quantization tables. Jim Boucher of Boston University for jmovie2jpeg. The San Diego SuperComputing Center for providing facilities to develop some of the code contained within. -- Eugene Hung eyhung@garnet.berkeley.edu --------------------------------------------------------------------------- ~Subject: MPEG Video Software Decoder MPEG Video Software Decoder (Version 2.1; May 1 1995) Lawrence A. Rowe, Ketan Patel, Brian Smith, Steve Smoot, and Eugene Hung Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains a public domain MPEG video software decoder. The decoder is implemented as a library that will take a video stream and display it in an X window on an 8, 24 or 32 bit deep display. The main routine is supplied to demonstrate the use of the decoder library. Several dithering algorithms are supplied based on the Floyd-Steinberg, ordered dither, and half-toning algorithms that tradeoff quality and performance. Neither the library nor the main routine handle real-time synchronization or audio streams. The decoder implements the standard described in the Committee Draft ISO/IEC CD 11172 dated December 6, 1991 which is sometimes refered to as "Paris Format." The code has been compiled and tested on the following platforms: HP PA-RISC (HP/UX 9.X, X11R5) (i.e., HP 9000/7XX and 9000/3XX) Sun Sparc (SunOS 4.X, X11R5) DECstation 5000 and Alpha Silicon Graphics Indigo MIPS RISC/os 4.51 If you decide to port the code to a new architecture, please let us know if there are any significant changes, so that we can incorporate them into our sources. This directory contains everything required to build and display video. We have included source code, a makefile, an Imakefile, installation instructions, and a man page. Data files can be obtained from the same ftp site this was located in. See the INSTALL file for instructions on how to compile and run the decoder. The data files were produced by XING. XING data does not take advantage of P or B frames (ie, frames with motion compensation). Performance of the player on XING data is significantly slower (half or less) than the performance when motion compensated MPEG data is decoded. We are very interested in running the software on other MPEG streams. Please contact us if you have a stream that does not decode correctly. Also, please send us new streams produced by others that do utilize P and B frames. Our future plans include porting the decoder to run on other platforms, integrating it into a video playback system that supports real-time synchronization and audio streams, and further experiments to improve the performance of the decoder. Vendors or other organizations interested in supporting this research or discussing other aspects of this project should contact Larry Rowe at Rowe@CS.Berkeley.EDU. Other Versions: There are three variations of the old mpeg_play: One added a very nice Motif interface (variously named mpeg_play-2.0.1 and xmpegplay). One was mpegvga.patch and let linux play straight to a VC. One was an X interface (mpegplayer.tar.gz on linux sites) We have notified the authors of those programs, and will have new versions of them here as soon as they can find the time to update them. Reporting bugs: If you find any bugs in this software, please send them to mpeg-bugs@plateau.cs.berkeley.edu. Since this software is unsupported, we make no guarantees about how long it will take to fix the bug, or if it will be fixed at all. Bug fixes will be cheerfully accepted. Please include as much detailed information as possible, including: 1) the version number of the program you are using (cf. VERSION) 2) the data file that caused the bug (if possible) 3) the OS version and machine type you ran the program on 4) the compiler used to compile the program ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor Research Corporation for financial support. We also want to thank the following people for their help: Tom Lane of the Independent JPEG Group provided us with the basic inverse DCT code used by our player. (tom_lane@g.gp.cs.cmu.edu) Reid Judd of Sun Microsystems provided advice and assistance. Todd Brunhoff of NVR provided advice and assistance. Toshihiko Kawai of Sony provided advice and assistance. -- Eugene Hung eyhung@garnet.berkeley.edu --------------------------------------------------------------------------- ~Subject: MPEG Video Software Analyzer MPEG Video Software Analyzer (Version 1.0; May 81995) Lawrence A. Rowe, Doug Banks, Steve Smoot, and Sam Tze-San Fung Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains a public domain tool to monitor and modify MPEG video streams. mpeg_bits takes as input an mpeg stream and presents graphical feedback on the distribution of bits in the stream, on a macroblock-by-macroblock level. mpeg_bits also provides a simple user interface to generate specifics files that can be used by mpeg_encode to re-encode a stream, modifying the encoding on a macroblock-by-macroblock level. [The present version of mpeg_encode does not support this..] This tool does not support system layer streams. mpeg_bits supports the standard described in the Committee Draft ISO/IEC CD 11172 dated December 6, 1991 which is sometimes refered to as "Paris Format." The code has been compiled and tested at least once on the following platforms: HP PA-RISC (HP/UX 9.X, X11R5) (i.e., HP 9000/7XX and 9000/3XX) Sun Sparc (SunOS 4.X, X11R5) If you decide to port the code to a new architecture, please let us know about important changes, so that we can incorporate the changes into our sources. This directory contains everything required to build and use mpeg_bits. We have included source code, a makefile, installation instructions, and a man page. See the INSTALL file for instructions on how to compile and run the analyzer. Our future plans consist of more fully supporting an interactive editor paradigm; specifying changes directly on the display, seeing the results of edits on the video stream immediately as they occur, etc. We would also like to port the code to run on more platforms, and add support for system layer streams. Vendors or other organizations interested in supporting this research or discussing other aspects of this project should contact Larry Rowe at Rowe@CS.Berkeley.EDU. Reporting bugs: If you find any bugs in this software, please send them to mpeg-bugs@plateau.cs.berkeley.edu. Since this software is unsupported, we make no guarantees about how long it will take to fix the bug, or if it will be fixed at all. Bug fixes will be cheerfully accepted. Please include as much detailed information as possible, including: 1) the version number of the program you are using (cf. VERSION) 2) the data file that caused the bug (if possible) 3) the OS version and machine type you ran the program on 4) the compiler used to compile the program ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor Research Corporation for financial support. We also want to thank the following people for their help: Tom Lane of the Independent JPEG Group provided us with the basic inverse DCT code used by our player. (tom_lane@g.gp.cs.cmu.edu) Reid Judd of Sun Microsystems provided advice and assistance. Todd Brunhoff of NVR provided advice and assistance. Toshihiko Kawai of Sony provided advice and assistance. -- Eugene Hung eyhung@garnet.berkeley.edu --------------------------------------------------------------------------- ~Subject: MPEG Blocks Analyzer MPEG Blocks Analyzer (Version 1.0; Feb 1 1995) Ketan Patel Steve Smoot Brian Smith Sam Tze-San Fung Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains a public domain MPEG video software analyzer. It operates by playing a video stream in one window, while another window displays the block type and motion vectors for each block in the current frame. The decoder implements the standard described in the Committee Draft ISO/IEC CD 11172 dated December 6, 1991 which is sometimes refered to as "Paris Format." The code has been compiled and tested on the following platforms: HP PA-RISC (HP/UX 8.X, X11R4) (i.e., HP 9000/7XX and 9000/3XX) Sun Sparc (SunOS 4.X, X11R5) This directory contains everything required to build and display video. We have included source code, a makefile, installation instructions, and a man page. Data files can be obtained from the same ftp site this was located in. See the INSTALL file for instructions on how to compile and run mpeg_blocks. Problems, questions, or patches should be sent to: mpeg-bugs@Plateau.CS.Berkeley.EDU ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor Research Corporation for financial support. We also want to thank the following people for their help: Tom Lane of the Independent JPEG Group provided us with the basic inverse DCT code used by our player. (tom_lane@g.gp.cs.cmu.edu) Reid Judd of Sun Microsystems provided advice and assistance. Todd Brunhoff of NVR provided advice and assistance. Toshihiko Kawai of Sony provided advice and assistance. -- Eugene Hung eyhung@garnet.berkeley.edu --------------------------------------------------------------------------- ~Subject: MPEG Video Software Statistics Gatherer MPEG Video Software Statistics Gatherer (Version 2.2; May 8, 1995) Lawrence A. Rowe, Steve Smoot, Ketan Patel, and Brian Smith Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains a public domain MPEG video statistics gatherer. The decoder implements the standard described in the Committee Draft ISO/IEC CD 11172 dated December 6, 1991 which is sometimes referred to as "Paris Format." The code has been compiled and tested on the following platforms: HP PA-RISC (HP/UX 9.X) (i.e., HP 9000/7XX and 9000/3XX) Sun Sparc (SunOS 4.X) DECstation 5000 and Alpha Sequent Irix 4.0.5 Linux See the CHANGES file for information on all the improvements over 2.0 See the manual page for information on how to use mpeg_stat. Send bug reports to mpeg-bugs@plateau.cs.berkeley.edu, job offers (PhD in '96) to smoot@cs.berkeley.edu ;-) Vendors or other organizations interested in supporting this research or discussing other aspects of this project should contact Professor Larry Rowe at rowe@CS.Berkeley.EDU. FUTURE PLANS: In the next version I'd like to beef up the verification code and do something with system layer audio (when present). In addition (major though) MPEG-2 would be cool. If you send me code to do any of this, it will be much appreciated. (In general, though, I'll only be improving it to meet my thesis needs. -srs) INSTALL: If you have gcc, type "make" See the file INSTALL for slightly more help. AUDIO (we don't do audio, but Chad Fogg points out): CCETT has been distributing executables only of their Audio bitstream syntax verifier. The site address is: 161.105.2.22 Audio conformance bitstreams are also at ftp.tnt.uni-hannover.de ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard, Fujitsu, the Semiconductor Research Corporation for financial support. We also want to thank the following people for their help: Tom Lane of the Independent JPEG Group provided us with the basic inverse DCT code used by our player. (tom_lane@g.gp.cs.cmu.edu) Reid Judd of Sun Microsystems provided advice and assistance. Todd Brunhoff of NVR provided advice and assistance. Toshihiko Kawai of Sony provided advice and assistance. -- Eugene Hung eyhung@garnet.berkeley.edu --------------------------------------------------------------------------- ~Subject: xmg XMG v1.0 - The X MPEG Grabber ******************************* DESCRIPTION +++++++++++ XMG is a utility for the X Window System which allows you to create MPEG-1 video streams by repeatedly grabbing a window on the screen and then joining the frames into an MPEG sequence. XMG has several options that modify its behaviour, but it also provides sensible defaults for most of them. The two switches that you'll use most of the time are -fps (or -fpm) and -frames. These specify the number of frames per second (or per minute) and the total number of frames to grab. Here's an example invocation : xmg -fps 1 -frames 20 This specifies that we want to grab 20 frames, one per second, and also that we want to see what's going on during the grabbing process. At this point the XMG window will appear : Click on the "Grab" button and then click with the left mouse button inside the window that you want to grab. Once you've done this, the grabbing process will begin immediately, displaying some progress information as it does it. It is possible to change a few parameters directly from inside the window, instead of specifying them on the command line. When all the frames have been grabbed, the MPEG encoding process begins: go off and make yourself a nice cup of tea and come back later. By default the program creates a file called xmgout.mpg in the current directory. This file can then be viewed with any MPEG player which supports I,P and B frames of any size (Xing for example, doesn't support them). You can specify a different name for the output file with the -output switch. For example, the command : xmg -fps 1 -frames 20 -output mympeg.mpg will create a file called mympeg.mpg. When XMG is grabbing the frames, it stores them in a temporary RLE compressed and archived format called XLA. This file can become quite large very quickly, especially if you're grabbing several frames of a certain size. This file will be created by default in the /tmp directory with the name xmgtmp.$$$. This can be changed with the -tmp option : xmg -fps 1 -frames 20 -tmp /empty/xmpeggrab.tmp which will create it in the /empty directory with the name xmpeggrab.tmp. Make sure you've got plenty of space on the device ! To actually perform the encoding, XMG requires a parameter file. By default this file is called xmg.param and has to be in the current directory. Don't worry if you haven't got one : XMG will create a default one for you and use that. A different parameter file can be specified with the -param switch : xmg -fps 1 -frames 20 -param flower.param This will use the file flower.param. A description of the possible contents of the paramter file is provided later on. SYNOPSIS ++++++++ xmg -help -display host:dpy -frames nframes -fps nfps -fpm nfpm -terse -output filename -tmp filename -param filename OPTIONS +++++++ -fps nfps : specifies the number of frames per second to grab. Even if the machine you're using is slow, XMG will grab the server during the grab, so that no other application can write to the screen at the same time. As soon as the frame has been grabbed, the server is released so that the other applications can redraw their client area. -fpm nfpm : specifies the number of frames per minute to grab. -frames nframes : specifies the number of frames to grab in total. -output filename : specifies a name and location for the generated MPEG stream. By default XMG creates a file in the current directory called xmgout.mpg. -tmp filename : specifies a name and location for the temporary storage of the grabbed frames. This file is deleted when XMG has completed the encoding process. The default is /tmp/xmgtmp.$$$ -terse : does not display the XMG status window during the grabbing/encoding process. The default is to display the XMG window. -param : specifies a name and location for the parameter file. By default the file is called xmg.param and has to be in the current directory. If one doesn't exist, a default one will be created for you. PARAMETER FILE ++++++++++++++ The parameter file MUST contain the following lines : PATTERN pattern --------------- pattern is a sequence of I's, P's and B's, that specifies the order of the frames in the MPEG stream. GOP_SIZE n ---------- n is roughly the number of frames in a Group of Pictures (roughly because a GOP must begin with an I-frame) SLICES_PER_FRAME n ------------------ n is roughly the number of slices per frame. Note, at least one MPEG player may complain if slices do not start at the left side of an image. To ensure this does not happen, make sure the number of rows is divisible by SLICES_PER_FRAME. PIXEL (FULL or HALF) -------------------- use half-pixel motion vectors, or only full-pixel ones RANGE ------ use a search range of +/- n pixels PSEARCH_ALG algorithm --------------------- algorithm must be one of {EXHAUSTIVE, TWOLEVEL, SUBSAMPLE, LOGARITHMIC}. Tells what kind of search procedure should be used for P-frames. Exhaustive gives the best compression, but logarithmic is the fastest. You select the desired combination of speed and compression. TWOLEVEL is an exhaustive full-pixel search, followed by a local half- pixel search around the best full-pixel vector (the PIXEL option is ignored for this search algorithm). BSEARCH_ALG algorithm must be one of {SIMPLE, CROSS2, EXHAUSTIVE}. Tells what kind of search procedure should be used for B-frames. Simple means find best forward and backward vectors, then interpolate. Cross2 means find those two vectors, then see what backward vector best matches the best forward vector, and vice versa. Exhaustive does an n-squared search and is EXTREMELY slow in relation to the others (Cross2 is about twice as slow as Simple). IQSCALE ------- use n as the qscale for I-frames PQSCALE ------- use n as the qscale for P-frames BQSCALE ------- use n as the qscale for B-frames REFERENCE_FRAME (ORIGINAL or DECODED) ------------------------------------- If ORIGINAL is specified, then the original images are used when computing motion vectors. To be more accurate, use DECODED, in which the decoded images are used. This should increase the quality of the image, but will take a bit longer to encode. The lines may appear in any order, except the following exceptions. NOTES +++++ If XMG was compiled with the -DMITSHM switch enabled, then shared memory will be used if available and will increase performance noticeably. AUTHOR ++++++ Tristan Tarrant - University of Sussex, UK, tristant@cogs.susx.ac.uk CREDITS +++++++ MPEG encoding based on mpeg_encode by : Kevin Gong - University of California, Berkeley, keving@cs.berkeley.edu Ketan Patel - University of California, Berkeley, kpatel@cs.berkeley.edu Dan Wallach - University of California, Berkeley, dwallach@cs.berkeley.edu BUGS AND LIMITATIONS ++++++++++++++++++++ XMG works only on Pseudo-Color displays. No known bugs. Tristan Tarrant, tristant@cogs.susx.ac.uk --------------------------------------------------------------------------- ~Subject: mpegstat Tom Pfeifer (pfeifer@fokus.gmd.de) announces: [ mpegstat.tar.Z was uploaded to mm-ftp.cs.berkeley.edu, the DOS-port ] [ is available on http://www.powerweb.de/mpeg ] [ It will probably included in the next version of Berkeley's encoder ] This is mpegstat v1.0 - an analyzing took for MPEG-I video streams for Unix. It is based on the Berkeley MPEG player v2.0, utilizing the Berkeley parsing and decoding routines for the MPEG data stream. MPEGSTAT is a useful utility for analyzing MPEG-I video streams. It is based on the Berkeley MPEG movie player. MPEGSTAT reads a video stream from a file or stdin and shows the frame type pattern as it is found while parsing. After the stream is completely parsed it displays the frame pattern as it would be displayed by a MPEG viewer. It then generates a summary of various mpeg format related statistics. MPEGSTAT works for MPEG movies that are Paris format compatible. Authors Multimedia systems project - Technical University of Berlin, Germany Tom Pfeifer, Dept. of Computer Science, pfeifer@fokus.gmd.de Jens Brettin - Alexander Schulze - Harald Masche - Dirk Schubert --------------------------------------------------------------------------- ~Subject: mplex ********************************************************************* * * * ANNOUNCING OF A FREE MPEG 1/SYSTEMS MULTIPLEXER * * * * thanks to * * ^^^^^^^^^ * * SIEMENS LTD, CORPORATE RESEARCH AND DEVELOPMENT ZFE ST SN 11 * * TECHNICAL UNIVERSITY OF MUNICH, PROF. SCHLICHTER * * * ********************************************************************* Hello all. This is an announcing for all of those that have already been waiting on the release of my code for multiplexing one MPEG 1 Audio and one MPEG 1 Video Stream into a MPEG 1/SYSTEMS multiplexed data stream according to the ISO/IEC 11172-1 specs. Sorry for all of those that needed the code really bad and kept mailing me on it. I couldn't hold my promises because of copyright release on part of the University. But here it is: I uploaded the source code on URL=ftp://hpsystem2.informatik.tu-muenchen.de//pub/comp/graphics/mpeg/mplex/mplex-1.0beta.tar.gz [131.159.0.198] ftp.informatik.tu-muenchen.de .gz means it is compressed with GNU zip. Should somebody not have it, you can find it on our FTP server under /pub/comp/gnu/gzip/ else, just try get mplex-1.0beta.tar.Z Our FTP server will do an on-the-fly-compressing with the 'compress' (.Z) format. Now to the code itself: I have been kept really busy with my papers on multiplexing (they will shortly be available on the FTP server also, I will post on that), so sorry if I couldn'g tighten the code up a bit. There is no real docu- mentation yet, please try out the code. Feel free to email me for any further questions. As of now, this code will only run under standard UN*X-Style platforms providing a (K&R-Style) C compiler (GNU CC is fine). It tested fine on SUN's, HEWLETT PACKARD's series 700, SILICON GRAPHICS machine's. There is * NO DOS PORT AVAILABLE (YET) *. Contact me if you are planning such a thing. There will be better releases, and I promise to clean up the code soon. :) This Software is released under the terms of the GNU public license, see the tar archive for further details. Feel free to archive the code on other FTP servers or post it to newsgroups, if there is such interest. Research done at SIEMENS LTD, CORPORATE RESEARCH AND DEVELOPMENT ZFE ST SN 11 TECHNICAL UNIVERSITY OF MUNICH, PROF. SCHLICHTER Christoph Moar moar@Informatik.TU-Muenchen.DE (Christoph Moar) --------------------------------------------------------------------------- ~Subject: xmplay [ Here it is !! The first, fully-featured MPEG-player with X11-interface. ] [ XMPLAY exists currently in Version 1.0, patches are available. The next ] [ Version 1.1 is currently in development. Thats the announcement ! ] XMPLAY [Version 1.1] - Sun Apr 10 14:51:22 MDT 1994 This distribution is the result of a project worked out at the Technical University (TU) Berlin, held in Winter 93/94 by Tom Pfeifer. The basic idea is created by Frank Gadegast, the programing work was then done by Juergen Meyer, Metin Cetinkaya and Frank Gadegast. This software is ftp-able from: http://www.powerweb.de/mpeg [ 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 download XMPLAY from http://www.powerweb.de/mpeg. If you get problems (not really possible) to compile it or if you have comments send them to the authors, reachable at: phade@powerweb.de (responsible for compiling and X11) jm@cs.tu-berlin.de (responsible for the mpeg-code) or brain@cs.tu-berlin.de --------------------------------------------------------------------------- ~Subject: xplayer Version 2.0; Jan 27, 1993) (Motif interface; Jan 30, 1994) Lawrence A. Rowe, Ketan Patel, and Brian Smith Computer Science Division-EECS, Univ. of Calif. at Berkeley Motif Interface: Daeron Meyer The Geometry Center, University of Minnesota There are several mailing lists established for messages about the decoder: mpeg-list-dist@CS.Berkeley.EDU deo Software Decoder (Version 2.0; Jan 27, 1993) (Motif interface; Jan 30, 1994) Lawrence A. Rowe, Ketan Patel, and Brian Smith Computer Science Division-EECS, Univ. of Calif. at Berkeley Motif Interface: Daeron Meyer The Geometry Center, University of Minnesota There are several mailing lists established for messages about the decoder: mpeg-list-dist@CS.Berkeley.EDU General information on the decoder for everyone interested should be sent to this list. This should become active after 11/20/92 mpeg-list-request@CS.Berkeley.EDU Requests to join or leave the list should be sent to this address. The subject line should contain the single word ADD or DELETE. mpeg-bugs@CS.Berkeley.EDU Problems, questions, or patches should be sent to this address. If you have any questions or bug reports for the motif version (and I'm sure there will be plenty) please send mail to: daeron@geom.umn.edu Also check out the online web documentation for the motif version: http://www.geom.umn.edu/docs/mpeg_play/mpeg_play.html --------------------------------------------------------------------------- ~Subject: xmpeg.tk It's a bit confusing to have now 2 utilities having the same name (as xmpeg is already a part of the XMPLAY distritution. It would be nice to rename the following tool to xmpeg.tk, contacted the author about that but got no reply :o( xmpeg (ver 0.5b) Tk/Tcl based front end to mpeg_play. xmpeg is a simple script that allows users of mpeg_play to have a graphical front end to mpeg_play. This means that one does not have to remember what the command line switches are needed, or what kinds of dithering are available. The idea for this came about when we started using NCSA's xmosaic. Sometimes it would take 10 minutes to retrieve an mpeg file and it would only be displayed once. If you missed it or wanted to view it again, you would have to retreive it again and again. Thus xmpeg came into play. It takes a file name as an argument (a temp file in xmosaic's case) and allows the user to specify the settings they wish to use. Then the user clicks on 'Play Anim' and mpeg_play is invoked. REQUIREMENTS: In order to use xmpeg you should have Tk 3.3, Tcl 7.0 and mpeg_play 2.0. This has been tested on Sun's running SunOS 4.1.3. Comments and/or questions should be directed to Alexei Rodriguez (alexei@cis.ufl.edu). AVAILABILITY: xmpeg is available at URL=ftp://ftp.cis.ufl.edu/pub/xmpeg [128.227.100.252] I will upload it to harbor.ecn.purdue.edu. --------------------------------------------------------------------------- ~Subject: mpeg2encode / mpeg2decode From: cfogg@netcom.com (Chad Fogg) Subject: MPEG-2 source code and MS-DOS executables available via anon. FTP We, the MPEG Software Simulation Group, are releasing our MPEG-2 and MPEG-1 Video encoder and decoder source code, along with example bitstreams and pre-compiled MS-DOS executables. Please read the following extracts from our README file for more information: mpeg2encode / mpeg2decode ========================= MPEG-2 Encoder / Decoder, Version 1.0, May 1994 MPEG Software Simulation Group (MPEG-L@netcom.com) Contents: 1. Overview 2. Introduction 3. Contacting the MPEG Software Simulation Group 4. Availability 5. Installation 6. Acknowledgements 7. History of the technical report 1. Overview =========== This directory contains our implementation of an ISO/IEC DIS 13818-2 codec. It converts uncompressed video frames into MPEG-1 and MPEG-2 video coded bitstream sequences, and vice versa. The files mpeg2enc.doc and mpeg2dec.doc in the doc/ directory contain further information about the codec. The doc directory also contains an FAQ file answering frequently asked questions about MPEG. A precompiled version of the programs for MSDOS (requires at least a '386) and a set of verification files are available separately. Subdirectories src/mpeg2enc and src/mpeg2dec contain the source code for the encoder and decoder, subdirectory par/ contains a couple of example encoder parameter files for 25 and 30 frames/sec MPEG-2 and MPEG-1 video. 2. Introduction =============== MPEG-2 Video is a generic method for compressed representation of video sequences using a common coding syntax defined in the document ISO/IEC 13818 Part 2 (CD: Nov. 1993, DIS: March 1994) by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), in collaboration with the International Telecommunications Union (ITU) as Recommendation H.262. The MPEG-2 concept is similar to MPEG-1, but includes extensions to cover a wider range of applications. The primary application targeted during the MPEG-2 definition process was the all-digital transmission of broadcast TV quality video at coded bitrates between 4 and 9 Mbit/sec. However, the MPEG-2 syntax has been found to be efficient for other applications such as those at higher bit rates and sample rates (e.g. HDTV). The most significant enhancement over MPEG-1 is the addition of syntax for efficient coding of interlaced video (e.g. 16x8 block size motion compensation, Dual Prime, et al). Several other more subtle enhancements (e.g. 10-bit DCT DC precision, non-linear quantization, VLC tables, improved mismatch control) are included which have a noticeable imporvement on coding efficiency, even for progressive video. Other key features of MPEG-2 are the scalable extensions which permit the division of a continuous video signal into two or more coded bit streams representing the video at different resolutions, picture quality (i.e. SNR), or picture rates. The MPEG Software Simulation Group is currently developing MPEG software with the purpose of providing aid in understanding the various algorithms which comprise an encoder and decoder, and giving a sample implementation based on advanced encoding models. The MPEG-2 software project is on on-going development. Since the current version of the encoder already employs a reasonable (and the most popular) subset of the MPEG-2 signal coding toolkit, and there appears to be sufficient public interest, we have decided to make a first public release of the code. This encoder can also be used for generating good quality constant bitrate MPEG-1 sequences and is (to our knowledge) the first public release of an encoder based on the relatively sophisticated TM5 coding model. 3. Contacting the MPEG Software Simulation Group ================================================ We welcome any project-specific questions, comments, suggestions, bug reports etc. They should be sent to the Internet address: MPEG-L@netcom.com which automatically forwards them to the authors. 4. Availability =============== The current version of the codec source code is available by anonymous ftp from: URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/ or URL=ftp://ftp.netcom.com/pub/cf/cfogg/mpeg2/ This directory contains the following files: README this file mpeg2codec_v1.0.tar.gz codec source code and documentation mpeg2codec_verify_v1.0.tar.gz verification archive mpeg2v10.zip MS-DOS executable archive tennis.m2v sample MPEG-2 video sequence (8 frames 704x576) tennis.par, tennis.stat.gz parameter file and statistics output for tennis.m2v You need gunzip (GNU zip/unzip) to uncompress the .gz archives. Alternatively, the files may be retrieved by sending E-mail to: ftp-request@netcom.com ... with the following line in the body of the message: SEND cfogg/mpeg2/mpeg2codec_v1.0.tar.gz You can retrieve the directory listings by sending the following command to ftp-request@netcom.com: DIR cfogg/mpeg2 General information can be retrieved with the command: HELP 5. Installation =============== [ommitted from this Usenet posting] 6. Acknowledgements =================== Authors of the current release are: Stefan Eckart (stefan@lis.e-technik.tu-muenchen.de) Chad Fogg (cfogg@netcom.com) Cheung Auyeung (auyeung@mot.com) 7. History of Technical Report Project ====================================== The Technical Report, a document which primarily consists of a C source code program, was initiated by the MPEG committee to: - Provide an example of MPEG video syntax being intelligently employed to generate good quality video. - A reference tool for implementors - Aid in understanding the MPEG specification MPEG would like to especially thank Dr. Stefan Eckart for his contributions have greatly helped the MPEG-2 Technical Report project start onto a successful path towards the final 13818-5 document. MPEG lends a kind acknowledgement to Arian Koster (PTT) for initiating the MPEG-1 technical report project in Autumn 1992, and Leonardo Chiariglione (Chairman of MPEG) and Didier Le Gall (Chairman of MPEG Video) for support throughout both projects. Also many thanks to MPEG-1 project contributors Peter Au (Hughes Aircraft), Ron Burns (Hughes Aircraft), Stefan Eckart (Technical University of Munich), Chad Fogg, Tsuyoshi Hanamura (Waseda University), Kinya Oosa (Nippon Steel), Brian Quandt (Heuris Logic) and Hiroshi Watanabe (NTT). Regards, Chad Fogg MPEG Chair for Software Simulation cfogg@netcom.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Version 1.1a of the MPEG Software Simulation Group's MPEG-2 codec is now available via anonymous ftp from URL=ftp://ftp.netcom.com/pub/cfogg/mpeg2/mpeg2codec_v1.1a.tar.gz [192.100.81.1] If you have mpeg2codec_v1.1.tar.gz and the program 'patch', it is sufficient to download mpeg2codec_v1.1_v1.1a.diff to upgrade vom v1.1 to v1.1a. The most import difference between v1.1 and v1.1a is the fix of a bug which caused decoding of MPEG-1 sequences to fail if the compiler assumes 'char' to be unsigned. Thanks to all who had offered assistance in finding this bug. A Windows 32s port of mpeg2decode (and mpeg2play), courtesy of CompCore, is available as mpeg2w11.zip. A DOS version of mpeg2encode and mpeg2decode is available as mpeg2d11.zip. Best regards, Stefan Eckart, MPEG Software Simulation Group. --------------------------------------------------------------------------- ~Subject: mpegaudio [ You can find this under the name MPEGAUDI or ftp it from the IUMA- ] [ server URL=ftp://sunsite.unc.edu/pub/electronic-publications/IUMA [ For a further description of IUMA look into the WHERE-INFOS section. ] Last updated 1/5/94 The good news is that source is now available. Look in /IUMA/mpeg_players for the file mpegaudio.tar.Z We will continue to gather source and executables and hope that some enterprising shareware authors or academics will provide various platforms with real-time players. According to Jared V Boone below, the Xing real-time player for Windows plays only the lower half of each subband of only one of the two channels. By my ears, that's pretty good. Another worthy undertaking would be porting the source to the DSPs increasingly being found on motherboards and add-in cards, such as the Mac AV series' AT&T 3210 or the Turtle Beach MultiSound's Motorola 56001, for real-time full-quality encoding and playback. That would be cool. =) -IUMA staff Here's the latest word on other non-commercial MPEG audio players for Unix workstations. I found this in a zip file, the test suite missing, as well as the Makefile. I hacked together a quick makefile, and altered the musicout code so that if the destination filename is "stdout" it writes the song to stdout so you can pipeline it into sox then into /dev/audio or your equivilant. (Handling 30 meg files takes mucho diskspace I dont have :) Basically, all you need to do is run it in a pipeline: decode snd.mp2 stdout | sox [your favorite opts] > /dev/audio (or equiv) >Some of those favorite opts: >sox -t .raw -r 44100 -s -w -c 2 file.mp2.dec -t .au -r 8000 file1.au >sox -t .au -c 2 -w -s file1.au -t .au -c 1 -b -u file2.au avg I have both encoded and decoded with this. I decoded a song off the IUMA archives, and encoded a topgun soundtrack I digitzed myself. One thing to note, at the default encoding bitrate of 384 bits, things dont compress hardly at all, you'll want to input something like 128 bits, which does on average 8-10:x1 compression. Encoding takes a *LONG* time... :) -Crh Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/ --------------------------------------------------------------------------- ~Subject: maplay From: "Tobias 'Doping' Bading" This announcement has been posted to the following newsgroups: alt.comp.compression, comp.compression, alt.binaries.multimedia, comp.multimedia, alt.binaries.sounds.misc, de.alt.binaries.sounds last edit: 6/23/94 14:36:07 Hi MPEG audio fans, I'd like to announce the second release of my free, software-only MPEG audio player maplay. Those of you who are already familiar with maplay 1.1 may take a look at the list of changes in version 1.2: - required CPU time reduced by 50% - support of 16 bit soundcarts under Linux Implemented by Louis P. Kruger (lpkruger@phoenix.princeton.edu) - 8 kHz u-law realtime playback on amd devices (SPARC 2/IPX/...) or conversion to 8 kHz u-law to stdout Based on an implementation by Jim Boucher (jboucher@flash.bu.edu) - some bug-fixes (-u options, Solaris 2.3 problem, problems with older GNU C++ releases, makedepend usage removed) All in all version 1.2 is now capable of - playing MPEG audio layer I or II streams on SPARC 10 (SunOS 4.1.3 or Solaris 2.x), Silicon Graphics Indigo (IRIX 4.0.x or IRIX 5.x) and Linux machines in nearly CD-quality. On a SPARC 10/40, maplay needs about 46% CPU time for realtime stereo playback and 26% for mono playback. (maplay can't be compiled under IRIX 5.x because of the missing audio library, but an IRIX 4.0.5F binary works under IRIX 5.x, too) - playing these streams in 8 kHz u-law format on SPARC 2/IPX/... (SunOS 4.1.x) machines using the amd device. On a SPARCstation IPX, maplay needs about 43% CPU time for realtime mono playback. - decoding streams to raw 16 bit pcm format at the frequency of the stream (32, 44.1 or 48 kHz) or to 8 bit u-law format downsampled to 8 kHz. The C++ sourcecode of maplay 1.2 and a short layer II MPEG audio stream for testing purposes has been posted to alt.binaries.multimedia on 6/23/94. The sources and some binaries are available via the ftp server URL=ftp://ftp.cs.tu-berlin.de/incoming/maplay1.2/ It contains: -rw-r--r-- 1 bading doping 4290 Jun 23 14:20 ANNOUNCEMENT -rw-r--r-- 1 bading doping 95691 Jun 23 14:19 maplay1_2.tar.Z -rwxr-xr-x 1 bading doping 96497 Jun 22 12:30 maplay_indigo.Z* -rwxr-xr-x 1 bading doping 81469 Jun 22 12:12 maplay_sol2.Z* -rwxr-xr-x 1 bading doping 88881 Jun 22 12:17 maplay_sunos4_1_3.Z* -rwxr-xr-x 1 bading doping 93125 Jun 22 12:35 maplay_ulaw_sunos4_1_3.Z* -rw-r--r-- 1 bading doping 372821 Jun 23 12:16 things.mp2 Due to slow Internet connections to this site, please use the mail server mail-server@cs.tu-berlin.de. Send an email to this address with the contents SEND incoming/maplay1.2/maplay1_2.tar.Z and you will receive a mail with an uuencoded copy of the requested file. Sending a mail containing "SEND help" returns a mail with more infos about this mail server. The available precompiled binaries are (in compressed format) - maplay_sunos4_1_3.Z for SPARCstations with a dbri device (e.g. SPARC 10, CD-quality) under SunOS 4.1.x (created under SunOS 4.1.3) - maplay_ulaw_sunos4_1_3.Z for SPARCstations with an amd device (e.g. SPARC 2 or IPX, telephone quality) under SunOS 4.1.x using 8 kHz u-law output (created under SunOS 4.1.3) - maplay_sol2.Z for SPARCstations with a dbri device (e.g. SPARC 10, CD-quality) under Solaris 2.x (created under Solaris 2.3 [= SunOS 5.3]) - maplay_indigo.Z for Silicon Graphic Indigo machines (CD-quality) under IRIX 4.0.x or IRIX 5.x (created under IRIX 4.0.5F) To extract the source code, you may use "zcat maplay1_2.tar.Z | tar xvf -" or "uncompress maplay1_2.tar.Z ; tar xvf maplay1_2.tar". Please take a look at the README file next. For a binary, you may use "uncompress maplay_sunos4_1_3.Z". You may also take a look at the Internet Underground Music Archive (IUMA) ftp server sunsite.unc.edu (152.2.22.81) in the directory /pub/electronic-publications/IUMA/audio_utils/mpeg_players/Workstations If you are also looking for an encoder, please take a look at the file /pub/electronic-publications/IUMA/audio_utils/converters/source/mpegaudio.tar.Z on the IUMA ftp server. It contains sources for an encoder and a decoder. That's all for now, Tobias Bading (bading@cs.tu-berlin.de) --------------------------------------------------------------------------- ~Subject: Scanning MPEG's ... STC Version 1.0 A simple program that prints and plots the bits-per-picture of a MPEG-1 or MPEG-2 bitstream file. The program is called "stc" (since it only checks for picture_start_code's and thus runs very quickly). stc can be conveniently run in conjunction with an MPEG encoder, since stc can wait on the bitstream file and plot new points as they become available (or produce a new graph if the bitstream file becomes shorter, presumably because the MPEG encoder was restarted). stc is only about 500 lines of C code, but it uses gnuplot for plotting. stc was developed for an x-windows display and postscript printer, but it can be very easily modified to use any of the many other displays and printers that gnuplot supports. Simply compile stc.c with your favorite ANSI-C compiler, and that's all there is to it. For graphing functions, you must have gnuplot in your $PATH. * Copyright (c) 1993 by The Trustees of Columbia University in * the City of New York. * All rights reserved. --------------------------------------------------------------------------- ~Subject: MPEG decoder... Date: Sun, 2 Jan 1994 22:57:48 -0800 From: Jared V Boone I have an MPEG decoder that I can make available. It is in C and I have succeeded in compiling it under Windows NT Visual C++ and NetBSD 0.9 with GNU V2.4. The code is rather rough, only decodes Layer II, and is rather slow. However, I figure if I release the code to the public, some rocket scientist can make it ran fast... My only conditions are that I am acknowleged and notified when someone uses the code in a freeware/shareware/commercial product. Let me know if you're interested. - Jared Boone, Oregon State University (jboone@instruction.cs.orst.edu) P.S. I'm also working on an encoder. It appears that Xing's encoder is not all that great (sound quality), and also does not conform to the MPEG-I spec. If you'd like, I can keep you posted on this as well... --------------------------------------------------------------------------- ~Subject: MPEGTool MPEGTool is an application which combines MPEGTool encoder and MPEGTool statistics with X11/Motif based Graphical User Interface (GUI). MPEGTool encoder is an MPEG-1 encoder for RGB and CCIR-601 format input video sequences. MPEGTool statistics is a graphical statistics tool which can be used to analyze the statistical pro- perties of the encoding process. MPEGTool allows a user to speci- fy several of the MPEG parameters such as the intraframe to in- terframe ratio, and the quantizer scale through its GUI. MPEGTool has been tested on Sun SparcStation and HP9000 current- ly. To compile under these machines, see instructions in Makefile. GUI of MPEGTool is based on Motif toolkit from the Open Software Foundation (OSF), so Motif (Xm) libraries as well as X Toolkit (Xt) libraries and Xlib are required to compile MPEGTool. Although MPEGTool can be executed under several window managers, Motif window manager (mwm) is recommended. We've tested mwm, Open look window manager (olwm), Tab window manager (twm). With the twm, we recommend to put 'DecorateTransients' in your .twmrc file. MPEGTool supports disk and tape device for video data input and MPEG code output. Also, MPEGTool creates statistics data on the disk. Statistics data requires around 1/350 to 1/250 of video data size and MPEG code requires 1/10 to 1/5 depending on the parameter. MPEGTool encoder encodes RGB/CCIR-601 format video input data from tape or disk device by MPEG-1 specification and write the encoded data into tape or disk. In addition, the statistics data can be stored into disk device for MPEGTool statistics analysis. We can set several encoding parameters from MPEGTool Encoder win- dow. For setting device related parameters, click Configure but- ton and modifying parameters in MPEGTool Encoder Configuration window. To start Encoding, click Start and MPEGTool begins encode if there is no parameter error or device related error. MPEGTool statistics creates types of graphs to analyze statisti- cal properties of MPEG encoded video stream. Four types of graphs can be selected, Distribution, Generation Record, Autocorrelation and Interarrival Time. First three of these plot each statistics of MPEG code in five levels, Bit/Frame, Bit/Slice, Bit/MacroBlock, ATM/Frame and ATM/Slice. Interarrival Time plots the time elapsed between arrivals of ATM packets within a frame. The interarrival times are calculated from the bits generated per macroblock within a frame. This interarrival time is normalized to units of X seconds (where X will depend on the hardware imple- mentation of the coder). "MPEGTool: An X windows based MPEG encoder and statistics tool", Proceedings of ACM Multimedia '93, Anaheim, CA This paper contains more details and several examples about MPEGTool. PostScript file of this paper is placed on anonymous ftp on atum.ee.upenn.edu. --------------------------------------------------------------------------- ~Subject: What is "SECMPEG" ? SECMPEG is first a newly defined stream, that ensures the service of confidentiality and integrity for a MPEG-I-video-stream. 'Cause of the amount of multimedia-data it is NOT possible to use the same crypto- or checking-techniques for multimedia-data then for normal files or streams. 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. 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@powerweb.de --------------------------------------------------------------------------- ~Subject: PVRG-MPEG Codec From: msimmons@ecel.uwa.edu.au (Michael Simmons - mgmt_staff) Subject: Standford MPEG codec Date: Thu, 25 Feb 1993 16:07:18 +0800 (WST) MPEG Image and Image sequence compression/decompression C software engines The Portable Video Research Group at Stanford have developed image/image sequence compression and decompression engines (codecs) for MPEG, CCITT H.261, and JPEG. The primary goal of these codecs is to provide the functionality - these codecs are not optimized for speed, rather completeness, and some of the code is kludgey. Development of MPEG, P64, and JPEG engines is not the primary goal of the Portable Video Research Group. Our research is focused on software and hardware for portable wireless digital video communication. For more information about current research, please send e-mail to Professor Teresa Meng at meng@tilden.stanford.edu. COMMENTS/DISCLAIMERS: This code has been compiled on the Sun Sparc and DECstation UNIX machines; some code has been further checked on the HP workstations. For comments, bugs, and other mail relating to the source code, we appreciate any comments. The code author can be reached at Andy C. Hung at achung@cs.stanford.edu. The standard public domain disclaimer applies: Caveat Emptor - no guarantee on accuracy or software support. References related to these codecs should NOT use any author's name, or refer to Stanford University. Rather the Portable Video Research Group or the acronym (PVRG) should be used, such as PVRG-MPEG, PVRG-P64, PVRG-JPEG. PVRG-MPEG CODEC: (MPEGv1.1.tar.Z) [ is now MPEGv1.2.tar.gz ] This public domain video encoder and decoder was generated according to the Santa Clara August 1991 format. It has been tested successfully with decoders using the Paris December 1991 format. The codec is capable of encoding all MPEG types of frames. The algorithms for rate control, buffer-constrained encoding, and quantization decisions are similar, but not identical, to that of the (simulation model 1-3) MPEG document. The rate control used is a simple proportional Q-stepsize/Buffer loop that works though not very well - better rate-control is the essence for good quality buffer-constrained MPEG encoding. Verification of the buffering is possible so as to provide streams for real-time decoders. The MPEG codec performs compression and decompression on raw raster scanned YUV files. The companion display program for the X window system is described in section IV) below. A manual of approximately 50 pages describes the program's use. There are also MPEG compressed files from the table tennis sequence in tennis.mpg and the flower garden sequence in flowg.mpg. This codec was recently tested with the MPEG decoder of the Berkeley Plateau Research group. If what you want is decoding and X display, then you might want to look into their faster public domain MPEG decoder/viewer. The Berkeley player is available via anonymous ftp from URL=ftp://mm-ftp.cs.berkeley.edu//pub/multimedia/mpeg/mpeg-2.0.tar.Z [128.32.149.157] ACKNOWLEDGEMENTS: Funded by the Defense Advanced Research Projects Agency. I am especially grateful to Hewlett Packard and Storm Technology for their financial support during the earlier stages of codec development. Any errors in the code and documentation are my own. The following people are acknowledged for their advice and assistance. Thanks, one and all. The Portable Video Research Group at Stanford: Teresa Meng, Peter Black, Ben Gordon, Sheila Hemami, Wee-Chiew Tan, Eli Tsern. Adriaan Ligtenberg of Storm Technology. Jeanne Wiseman, Andrew Fitzhugh, Gregory Yovanof and Chuck Rosenberg of Hewlett Packard. Eric Hamilton and Jean-Georges Fritsch of C-Cube Microsystems. Lawrence Rowe of the Berkeley Plateau Research Group. Tom Lane of the Independent JPEG Group. Katsumi Tahara from Sony. Ciaran Mc Goldrick. Karl Lillevold --------------------------------------------------------------------------- ~Subject: wdgt [ Jim Frost was putting the Berkeley-Code into a Motif and/or Xt-Widget. ] [ Its called WDGT, Version 2.0b is up-todate, but no description ] [ was included. This is from the man-page:] Mpeg is a version of the MPEG player from the Berkeley Plateau Research Group group as a widget. It can be used either as a Motif widget subclassed from XmPrimitive or as a toolkit-independant widget subclassed from Core. Mpeg inherits from Core. The Motif version also inherits from XmPrimitive. The class pointer is xmpegWidgetClass. The class name is Xmpeg. 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. --------------------------------------------------------------------------- ~Subject: SUBSECTION - VMS --------------------------------------------------------------------------- ~Subject: vms MPEG 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: URL=ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/vms/ [128.32.149.157] 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. --------------------------------------------------------------------------- ~Subject: SUBSECTION - MacIntosh --------------------------------------------------------------------------- ~Subject: Sparcle From: maynard@elwing.otago.ac.nz (Maynard James Handley) Subject: Sparkle 2.1.2 MPEG player for Macs Date: Thu, 28 Jul 1994 10:24:46 GMT Sparkle 2.12 A mac-look-and-feel MPEG and QT player and converter. This should replace Sparkle 2.1 in the info-mac archives. This version makes the following changes to Sparkle 2.1 * A few minor bugs were fixed. * One major bug was fixed, which required extensive reworking of Sparkle internals. This is why I haven't been able to get this version out sooner. * Somewhat better (though not yet great) support for QT movies with only sound and no video. * In reponse to many mail message from people who didn't understand the new features in 2.1, I've added a lot more documentation, in the ReadMe 2nd file, and I've added balloon help. You will get slightly better results with this version if you throw away your old Sparkle preferences file (in the Preferences folder in the System folder) before running Sparkle 2.12. This isn't essential but will improve performance a little. This version * is not PPC native * does not support sound * does not support apple events * does not support online help These are all high priorities, pretty much in that order. As always, if you find any bug or anomaly in this code please tell me. The sooner you tell me, the sooner I'll fix it. As always there remain a few rough edges to this program, though I hope most of them won't be too distressing to users. Like previous rough edges, they'll be done away with in time. %%% !!! If you write to me PLEASE give me a decent address I can reply to. !!! About 10% of the e-mail I receive has a bogus return address---I try !!! to reply to you and a few hours or days later I get a message from the !!! mail system that my mail could not be delivered. !!! This is very frustrating to me and a waste of your and my time. !!! I have NEVER just ignored mail sent to me about Sparkle. If I don't !!! reply to you, it's because you sent me mail with a garbage return address. !!! Check out your mail system and write to me again when it works properly. %%% WHAT IS IT? Sparkle plays MPEGs, PICTs and QT movies and converts between them. It is multifinder friendly and, with enough memory, will open multiple documents at once. It is free. REQUIRES: System 7 or greater. QuickTime 1.6 or greater. An 020 based mac or greater. This version requires the Thread Manager. You can ftp Sparkle from URL=ftp://sumex-aim.stanford.edu/info-mac/grf/util/ (or a mirror like mrcnext.cso.uiuc.edu) You can ftp the Thread Manager from URL=ftp://ftp.apple.com/dts/mac/sys.soft/extensions/Thread_manager_201.hqx Maynard Handley maynard@elwing.otago.ac.nz July 28 1994 --------------------------------------------------------------------------- ~Subject: Qt2MPEG From: Rainer Menes 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: URL=ftp://suniams1.statistik.tu-muenchen.de/pub/mac/MPEG/encoder/ [131.159.64.1] --------------------------------------------------------------------------- ~Subject: Audio on Macintosh ?! This just in... There is now a program for Macs that allows automatic real-time playback of MPEG files called MPEG/CD. You can download it from ftp.iuma.com, or check out our Macintosh help page with a web browser at: http://www.iuma.com/IUMA/html/use/Macintosh.html The following is a text dump of the Mac help page... PLAYING AUDIO ON A MACINTOSH Last updated: 95-02-14 _________________________________________________________________ New!!! MPEG CD for Macintosh is now all you need in order to hear realtime MPEG audio on your Macintosh or decompress an MPEG file to an easily readable AIFF. All you need to do is download ... MPEG_CD__1.0.1.sea.bin (480 Kb) ... from URL=//ftp.iuma.com/audio_utils/mpeg_players/Macintosh/ For system requirements for MPEG/CD, read the plain text Readme file. _________________________________________________________________ CONFIGURING NETSCAPE FOR AUTOMATIC PLAYBACK Yes! You can now have Netscape automatically launch your MPEG audio player when you click on an MPEG audio file. Just follow these simple instructions... 1. Click on Preferences under the Options menu in Netscape. 2. Select Helper Applications from the menu in the Preferences window. 3. Click on the New... button. 4. Enter audio for the Mime type and x-mpeg for the Mime subtype. 5. Enter mp2 in the Extensions box. 6. Selct MPEG/CD for the Application and choose MPEG as the File type. 7. Click on Launch application for the Action. ... and that should be it! _________________________________________________________________ Special thanks go to Brian Balthazor for bringing us this cool not-so-little utility! -Jeff Patterson IUMA Co-Czar --------------------------------------------------------------------------- ~Subject: SUBSECTION - 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) 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 --------------------------------------------------------------------------- ~Subject: SUBSECTION - 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) --------------------------------------------------------------------------- ~Subject: MPEG2DCTV This is a quick and dirty program to decompress MPEG video streams to a DCTV display buffer. 'mpeg2dctv' _REQUIRES_ a 68020 or higher CPU, and a 68881 or higher FPU. On an Amiga 3000, (25 MhZ 68030 and 25 MhZ 68882), 'mpeg2dctv' plays at about one frame per second in grayscale (the default option), and at about 8/10 of a frame per second in full color. 'dctv.library' is copyrighted 1991 by Digital Creations, Inc. The MPEG source code used in 'mpeg2dctv' is copyrighted 1992 by the Regents of the University of California. 'mpeg2dctv' is copyrighted 1993 by Benjamin Reich. This software is provided AS IS. It is provided free of charge, except that if you find this program useful, I request that you make a donation of US$10 (or the equivalent) to the charity of your choice. -Benjamin Reich Portal: Counsellor BIX: ben_rich Delphi: BEN_RICH Usenet: Counsellor@cup.portal.com U.S. mail: 805 Lincoln Drive Voorhees, NJ 08043 --------------------------------------------------------------------------- ~Subject: SUBSECTION - NeXT --------------------------------------------------------------------------- ~Subject: MPEG_Play.app [ This piece of software is now available in Version 2.5. Its usally ] [ called MPEG_Play.*, but due of filename conventions its called ] [ MPPLAY, mpegplay.* or mpeg_play.* . ] 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 Official place for this pice of software is: URL=ftp://ftp.CS.ORST.EDU/software/NeXT/binaries/graphics/MPEGPlay2.6.FAT.tar.Z Brian Willoughby Software Design Engineer, BSEE NCSU NeXTmail welcome here Sound Consulting: Software Design and Development BrianW@SoundS.WA.com Bellevue, WA --------------------------------------------------------------------------- ~Subject: 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 --------------------------------------------------------------------------- ~Subject: SUBSECTION - SGI A publically available program which can convert SGI movie files created with the IRIX 4.0.5 Movie Tools to MPEG. It was all compiled on a SGI indigo Elan running 4.05. Rob (kooper@cc.gatech.edu) =========================================================================== ~Subject: SECTION 4. - MPEG-RELATED HARDWARE We even have MPEG-AUDIO-solutions now, but still not a lot of information about them :o( who knows more ? --------------------------------------------------------------------------- ~Subject: MetaSound MetaSound A partial software MPEG-1 decoder with effective cost and high quality MetaSound is a cost-effective and high-quality MPEG-1 decoder, provided by Meta Media Inc. MetaSound is a partial software decoder, designed to work with hardware video decoders. This solution can reduce the hardware cost due to no hardware audio decoder required. In another aspect, MetaSound can support high-quality decoding with the help of hardware video decoder sharing the computation load. Currently, MetaSound has been successfully incorporated to work with three hardware video decoders. Important features of MetaSound: * High performance: For 486 DX4-100 machines or above, MetaSound can deliver FM quality (22 KHz) sound. For Pentium-90 or above machines, MetaSound requires only 40% CPU bandwidth to deliver CD quality (44.1 KHz) sound. * High Fidelity CD quality sound. MetaSound produces near CD quality sound. Under the lab test, the sound quality is better than several good hardware audio decoders. * Compatibility with MS Windows/3.1 and Windows/95. * Portability to other platforms. According to experiences, it takes less than one month to port to new hardware video decoders. * CD standard supports including Video CD 1.0, Video CD 2.0, and CDI. * Friendly user interface with full set of functions. Volume control, stop, pause, forward, backward, mute, resume, select the previous/next program track (Video CD 2.0), randomly select a program track (Video CD 2.0). * Error Recovery. MetaSound can automatically skip error bitstreams. About Meta Media Inc. --------------------- Meta Media Inc. is a multimedia software company providing with solutions of system integration and value-adding multimedia software for hardware companies. The company has several professional members, supporting R&D, including experienced PhDs and Masters. The company also has strong technical supports from universities. In addition to MetaSound, the company is also developing several other MPEG-related products. Meta Media, Inc. F8, #10-1, Ho-Ping East Rd. Sec. 1 Taipei, Taiwan, R.O.C. Phone: 011-886-2-369-3330 FAX: 011-886-2-369-3331 email: mmedia@ms4.hinet.net.tw --------------------------------------------------------------------------- ~Subject: MPEG audio Layer-3 from Cenlay Proton Data has a ready-to-sell real-time Layer-3 decoder based on the MAS 3503 chip from Intermetall, ITT Semiconductors. The adapter module is plugged into the parallel printer board ("Centronics") of a computer; it plays back Layer-3 files (mono or stereo) with bitrates from 32 to 320 kbps and sample rates of 32, 44.1 and 48 kHz. A MCI driver for MS Windows and some example programmes for MS-DOS are coming along with the decoder module. More informations are available directly at Proton Data in Flensburg (Tel. +49-461-366590, Fax +49-461-3816948, 100411.3206@compuserve.com). --------------------------------------------------------------------------- ~Subject: MPEG audio Layer-3 From: popp@iis.fhg.de (Harald Popp) 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) --------------------------------------------------------------------------- ~Subject: Video-Maker From: jmm73@frmug.fr.mugnet.org (Jean-Michel Mercier) 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. --------------------------------------------------------------------------- ~Subject: I2M's MEDIA PLAYBACK Description: Add-on board for Apple Macintosh and PC For Mac: a full size Nubus board For PC: a full size ISA board Processor: Motorola 68341/running 16 MHz Video Hardware: Motorola MCD210 Audio Hardware: Yamaha YM6064 ADPCM Controller System Memory: 4MB controlled by the MCD210 Video Expansion: Motorola MCD250 MPEG1 Full Motion Video Decoder. This is a CD-I MPEG Video decoder which requires only a single 4Mbit DRAM for FMV decoding. Decodes System and Video Layers at up to 5Mbits/sec, converts from 24/25/30 fps IPB streams to 25/30 fps output video in 24bit RGB/YUV format. Supports extra CD-I functions such as windowing and still picture mode. Targeted at consumer applications such as CD-I, CD-Karaoke, Video-CD and cable TV. Audio Expansion: Motorola MCD260 MPEG1 Audio Decoder The MCD260 is a interface IC which goes between a 68K bus and a DSP56K and strips out the MPEG System Layer whilst also buffering and synchronizing. A 33MHz 56001 with 8K words of DSP RAM decodes the MPEG Audio (ISO Layer 1/II @ 44.1KHz, all modes and bit rates) Video Output: PAL/NTSC Video Composite, RGB Audio Output: Stereo ADPCM and MPEG Audio I/O Outputs: one port compatible CD-I 210/220, can uses Mac mouse as CD-I ouse. System Software: Runs OS9/CD-RTOS system software, downloaded from host memory. System Requirements: - Apple macintosh with Nubus slot (Centris, Quadra, AV) - Minimum 4MB DRAM - Apple 300 CD-ROM Drive (internal or external) - Composite Video Monitor for display or Video Overlay Board. PC 486/25Mhz with ISA slot Minimum 4MB DRAM Double speed, Multisesion, CD-I capable CD-ROM drive Composite Video Monitor for display (or video grabbing board) MS Windows 3.1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx I2M's MEDIA AUTHOR Technical Specification Description: Add-on board for Apple Macintosh and PC For Mac: a full size Nubus board For PC: a full size ISA board Processor: Motorola 68341/running between 8MHz and 25MHz Video Hardware: Motorola MCD210 Audio Hardware: Yamaha YM6064 ADPCM Controller System Memory: 4MB controlled by the MCD210 Video Expansion: Motorola MCD250 MPEG1 Full Motion Video Decoder. This is a CD-I MPEG Video decoder which requires only a single 4Mbit DRAM for FMV decoding. Decodes System and Video Layers at up to 5Mbits/sec, converts from 24/25/30 fps IPB streams to 25/30 fps output video in 24bit RGB/YUV format. Supports extra CD-I functions such as windowing and still picture mode. Targeted at consumer applications such as CD-I, CD-Karaoke, Video-CD and cable TV. Audio Expansion: Motorola MCD260 MPEG1 Audio Decoder The MCD260 is a interface IC which goes between a 68K bus and a DSP56K and strips out the MPEG System Layer whilst also buffering and synchronizing. A 33MHz 56001 with 8K words of DSP RAM decodes the MPEG Audio (ISO Layer 1/II @ 44.1KHz, all modes and bit rates) Video Output: PAL/NTSC Video Composite, RGB Audio Output: Stereo ADPCM and MPEG Audio I/O Outputs: one game port, one serial port compatible CD-I 210/220, can uses Mac/PC mouse as CD-I mouse. System Software: Runs OS9/CD-RTOS system software, downloaded from host memory. Debugger: High level debugger functions implemented with breakpoints on specific sectors or specific OS9 calls. Emulation: Dynamic emulation mode capable of slowing down or accelerating the data rate from your CD-I application. Third Party Software: - MediaMogul/Mac version from Optimage. - HAL90/Mac version. - Any third party can develop software for this new platform. System Requirements: - Apple macintosh with Nubus slot (Centris, Quadra, AV) - Minimum 4MB DRAM - Apple 300 CD-ROM Drive (internal or external) - Composite Video Monitor for display or Video Overlay Board. PC 486/25Mhz with ISA slot Minimum 4MB DRAM Double speed, Multisesion, CD-I capable CD-ROM drive Composite Video Monitor for display (or video grabbing board) MS Windows 3.1 Pricing information: MediaPlayback for PC/Mac US$1,200.00 MediaPreview for Mac US$3,995.00 MediaAuthor for PC/Mac US$5,999.00 ALPHA MEDIA, Inc. Media Integration & Consulting Neubrunn, 8488 Turbenthal, Switzerland Phone: (052) 454 281 Fax: (052) 453 138 E-mail: janosh@alphamedia.ch --------------------------------------------------------------------------- ~Subject: Some 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). --------------------------------------------------------------------------- ~Subject: Optibase OPTIBASE's MPEG2000 (Herzliya - Israel, Canoga Park - Calif.) It use an CCUBE (witch?), DSP56001 ant DCT chips from LSI. --------------------------------------------------------------------------- ~Subject: ReelMagic [ 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) --------------------------------------------------------------------------- ~Subject: Cinerama 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. --------------------------------------------------------------------------- ~Subject: XingIt!-card [ 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) --------------------------------------------------------------------------- ~Subject: MPEG-decompression hardware list Company Product Support Resolution Price Ace Classic 1,5,6,11,23 Ace Movie24 1,2,3,4,5,6,12,14,16,20 1280x1204 AllMedia 2000 1,5,8,9,12,13,16 AllMedia III 1,5,6,8,9,(12),13,16 ArtMedia MD-341 1,2,3,4,5,14,15,16 640x480 Aztech V. Galaxy 1,5,6,16 Bluepoint MPX-3 1,2,3,4,5,10,11,16 Creative MP400 1,2,3,11 1024x768 Hellfrich Peggy Plus 1,5,6,12,(Amiga) DEM 998 Edison MPEG card 1,5,6,10,11,16,20,23 1024x768 K+s computing Master 1,2,3,5,11,14,23 DEM 599 MovieVision MPEG 2in1 1,5,8,9,12,13,16,18 800x600 Optibase PCMOtionPro 1,5,6,9,12 Orchid Kelvin MPEG 1,2,3,5,6,11,13,22 1024x768 Sigma Designs RealMagic 1,2,3,4,5,6,11,12,14,16,22 1024x768 DEM 499 Spea Showtime + 1,2,3,4,5,6,7,8,10,12,13,14,22 1024x768 DEM 850 Vitec DRT1 1,14,21,23 Vitec MM2 1,5,11 1024x768 1 = MPEG-1 2 = CD-I 3 = CD-V 4 = Karaoke 5 = 16-bit audio 6 = Audio Level 2 7 = Audio Level 3 8 = AVI-grabber 9 = VfW 1.1 comp. 10 = VESA comp. 11 = RealColor 12 = 24 bit True C. 13 = VGA-card 14 = MCI driver 15 = API 16 = ISA 17 = EISA 18 = VLB 19 = PCI 20 = Feature conn. 21 = TV-decoder 22 = RealMagic com. 23 = S-VHS out 24 = CD-Rom The resolution is the highest with MPEG-playback. *8 most cards support the freezing of single MPEG-frames and capturing of incoming frames, but only a few support real grabbing *11 most cards only support 64k color when playing MPEG *23 this can be a Composite Video Out or similar I know there are many, many more, please send my info about YOUR mpeg solution. Should we put the companies addresses here as well ? --------------------------------------------------------------------------- ~Subject: Amiga CD32 [ Ha, a game-console with MPEG-support, a bit crazy, but the best things ] [ get pushed by nig-nag ] From: George Sanderson Date: Thu, 3 Feb 94 12:28:31 +1000 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 =========================================================================== ~Subject: SECTION 5. - MAILBOX-ACCESS That's how you can get MPEG-related files via modem. --------------------------------------------------------------------------- ~Subject: Xing Technologies BBS and fax This is the phone number of Xing Technologies' BBS: 805-473-2680 (2400b) (USA) 805) 473-0147 (Fax) Bryan Woodworth 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. =========================================================================== ~Subject: SECTION 6. - FTP-ACCESS --------------------------------------------------------------------------- ~Subject: FTP-ACCESS - Overview Please contact these ftp-sites for files before e-mailing to me !!! URL=ftp://ftp.powerweb.de/pub [194.77.15.46] URL=ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio [161.105.2.22] URL=ftp://busop.cit.wayne.edu/sys/pub/simpsons/incoming/mpeg URL=ftp://busop.cit.wayne.edu/sys/pub/simpsons/incoming/mpeg1 URL=ftp://amiga.physik.unizh.ch/pub/aminet/ [130.60.80.80] URL=ftp://ftp.cica.indiana.edu/ [129.79.20.17] URL=ftp://ftp.cs.tu-berlin.de/pub/msdos/incoming/ URL=ftp://ftp.cs.tu-berlin.de/pub/msdos/dos/graphics/ URL=ftp://ftp.cs.tu-berlin.de/pub/msdos/windows3/graphics URL=ftp://ftp.cs.tu-berlin.de/pub/aminet/ [quepasa.cs.tu-berlin.de] [130.149.17.7] URL=ftp://ftp.germany.eu.net/ [192.76.144.75] URL=ftp://ftp.luth.se/pub/graphics/animation/mpeg URL=ftp://ftp.uni-erlangen.de/pub/aminet/ [131.188.1.43] URL=ftp://ftp.uni-kl.de/pub/aminet/ [131.246.9.95] URL=ftp://ftp.wustl.edu/ [128.252.135.4] URL=ftp://isfs.kuis.kyoto-u.ac.jp/ URL=ftp://litamiga.epfl.ch/pub/aminet/ [128.178.151.32] URL=ftp://merlin.etsu.edu/ [192.43.199.20] URL=ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/ [128.32.149.157] URL=ftp://nic.funet.fi/ [128.214.6.100] URL=ftp://phoenix.oulu.fi/ [130.231.240.17] URL=ftp://pinus.slu.se/pub/graphics/mpeg/ [130.238.98.11] URL=ftp://sumex-aim.stanford.edu/info-mac/app/ URL=ftp://suniams1.statistik.tu-muenchen.de/pub/mac/MPEG/encoder/ [131.159.64.1] URL=ftp://ftp.iuma.com/ URL=ftp://sunsite.unc.edu/pub/electronic-publications/IUMA URL=ftp://wuarchive.wustl.edu/ [128.252.135.4] URL=ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio --------------------------------------------------------------------------- ~Subject: MPEG-2 validation bitstreams The MPEG Committee MPEG-2 Systems Transport Layer validation bitstreams (July 1994 edition) are now available via anonymous FTP. Also included in the archive is a copy of Munsi Haque's draft ANSI-C source code for Transport layer demultiplexing. These bitstreams are not guaranteed to be 100% correct (especially since the MPEG-2 Systems document, ISO/IEC 13818-1, is still undergoing technical content changes), but they are produced by none other than the world's experts on the subject. URL=ftp://wuarchive.wustl.edu/graphics/x3l3/pub/bitstreams/systems/ [128.252.135.4] total 3.22 Megabytes 1171551 teracom-3.tar.gz Teracom bitstream 27833 COMMENTS Comments regarding bitstreams 26731 munsi_v13.tar.gz MPEG-2 Demultiplexer source code 355823 divicom-3.tar.gz Divicom bitstream 879635 nta-1.tar.gz NTA bitstream 777316 sa-2.tar.gz Scientific Atlanta bitstream MPEG-2 Video validation bitstreams are also available in graphics/x3l3/pub/bitstreams/video/ Kind regards, Chad Fogg cfogg@netcom.com --------------------------------------------------------------------------- ~Subject: Audio streams and utils CCETT has been distributing executables only of their Audio bitstream syntax verifier. The site address is: 161.105.2.22 Audio conformance bitstreams are also at URL=ftp://ftp.tnt.uni-hannover.de/ --------------------------------------------------------------------------- ~Subject: 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) --------------------------------------------------------------------------- ~Subject: Where will I find test-material for MPEG-encoders ? [ You can find this in the URL=ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/ [ 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. =========================================================================== ~Subject: SECTION 7. - WWW-ACCESS Well, MPEG is a multimedia format and fits perfectly the needs of the World Wide Web, so there are WWW-site that store their material in MPEG format and, the other way round, sites that store information about MPEG itself. --------------------------------------------------------------------------- ~Subject: Where is the WWW-home of this FAQ ? Oh, don't get confused here. This new version 4.1 of this FAQ is available in HTML form from: URL=http://www.powerweb.de/mpeg/mpegfaq/ The HTML-Version of the FAQ supports pictures and e-mail addresses and file location via HTTP-links. At the following URL you find the famous MPEG Archive, it contains all news, tools for several platforms and any publication about I wrote regarding MPEG (currently this archive had more than 3 million downloads in 13 month !): URL=http://www.powerweb.de/mpeg/ --------------------------------------------------------------------------- ~Subject: Where can I find MPEG-2 resource on the Web ? Brand new is the section of the MPEG Archive concerning MPEG-2 ! Check URL=http://www.powerweb.de/mpeg2 including more than 400 MB of software, streams and documents. This archive will be avilable soon as CD-Rom ! --------------------------------------------------------------------------- ~Subject: Where can I find a list of books and papers regarding MPEG audio compression ? From: scott.k.diamond@tek.com His list is now downloadable from http://www.powerweb.de/mpeg/audiowww.html --------------------------------------------------------------------------- ~Subject: An Interactive Explanation on the Web ? From: Kevin Lussie I had to write an interactive HTML paper on MPEG for my Digital Image Processing class that I am currently taking here at the University of Idaho and Washington State University. I just wanted to say that your MPEG FAQ was a great resource. I was just wondering if you could check out my INTERACTIVE MPEG PAPER, if you have time. It is located at http://www.cs.uidaho.edu/~lussi923/mpeg-project/index.html --------------------------------------------------------------------------- ~Subject: Where is the WWW-demo of "The Internet MPEG CD-Rom" ? Try and USE the Internet OFFLINE !!! To make the "Internet MPEG CD-Rom" interactive, one big hypertext- document explains and displays the whole contents of the archive, giving the user a powerful tool, called Cello, to browse through Megabytes of documentaton and to interactevly select and play hours and hours of music and movies. The whole archive itself is organized as one big hypertext-document. It includes a complete Wide-World-Web (WWW) document, the tools to use this document on Windows-, Windows-NT-, Linux-, SunOS- and Solaris- machines are included, most UNIX-hosts can include "The Internet MPEG CD-Rom" into their hyptertext-services with a single link !!! You can find a few of all these WWW-documents as an example under the address: URL=http://www.powerweb.de/phade/products/mpegcd/mpegcd.htm For a complete description of this famous MPEG archive, real below, in the MAIL-ACCESS section. --------------------------------------------------------------------------- ~Subject: Which archive is mostly related to MPEG-Audio ? The Internet Underground Music Archive is the biggest archive storing music in MPEG-Audio format. The already have more than 500 bands presenting their music and on of the nicest Web-sites ever seen ! Just connect to URL=http://www.iuma.com/ .___ ____ ___ _____ _____ | | | \ \ / _ \ 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. --------------------------------------------------------------------------- ~Subject: What's with Bryan Woodworth ftp-area ? He changed his internet provider and close his old ftp-site. The new site is reachable via WWW (the better way) and still presents lots of information about MPEG and graphics at all: From: bryanw@best.com (Bryan Woodworth) Subject: WWW Graphics Page now UP [Lastmod: 09.01.94 11:37:55] !!=new info The WWW Graphics Page is now online via the World Wide Web! URL=http://www.best.com/~bryanw/ [Even if you don't have a graphical front-end, you can still access the information. Plain ASCII output (via the program LYNX) is available for those users using dial-up accounts (e.g. Netcom, a2i, Portal, CRL, and many more). You may already have lynx installed online! Enter "lynx" at the shell prompt. If it doesn't exist, just ftp the source and compile it yourself. See .signature at bottom of message for details on obtaining the FAQ via ftp.best.com.] If you're using a Unix dialup account and Microsoft Windows, now you can experience the glory of the World Wide Web's great interface without having to pay for a SLIP account or SLIP emulator! Try SlipKnot today.. URL=ftp://oak.oakland.edu/pub/win3/internet/ More info available from the WWW Graphics page! !! This info-file is becoming too time-consuming to update. Therefore, !! you are encouraged to check out the homepage once a week or so, and click !! on the "Latest Additions" link for a listing of the latest updates! Information of the following variety awaits you: o The FAQ desk -- Graphics information * Tom Lane's JPEG faq -- Obtaining viewers and understanding the JPEG image format * A link to the NCSA Mosaic FTP site, for those looking for Mosaic, the famous WWW graphical browser * Jim Howard's alt.binaries.pictures FAQ -- Info on how to decode pictures, posting, and much more * MPEG information: Links to Frank Gadegast's MPEG faq and MPEG homepage; The WWW Graphics Page's very own MPEG faq; The MPEG Standards Homepage (info on MPEG standards, site for MPEG movies, and more); and an MPEG movie archive * A link to the massive Usenet FAQ pages at Ohio State, an outstanding resource * A link to Thomas Boutell's fantastic WWW faq! In living WWW format! (Also availble via FTP from the WWW Graphics Page as a ZIPped Ascii file) Info on WWW browsers for all platforms (even Unix dial-up), writing HTML documents, and more! A M U S T R E A D F O R E V E R Y O N E -- Internet Service FAQ pages * The Internet Services FAQ * FSP (alternative to FTP) FAQ * Internet Gopher FAQ -- Miscellaneous FAQs (selection subject to change) * Howard Stern * Unix X-Windows on Intel Architecture * The MS-DOS Archives * Playboy Enterprises (required reading!) * The alt.supermodels FAQ! Read on for juicy info on your favourite supermodels.. o Computer Support Areas -- Where to obtain programs of a graphical nature for your architecture * Macintosh -- MPEG players, contact sheet makers, dl/gl/fli viewers, etc. * IBM PC -- MPEG players, JPEG viewers, a link to the Xing Technology FTP site, and official QPEG support site for North America (including the latest version of QPEG, along with a link to Oliver Fromme's homepage in Germany) NOW DIVIDED INTO COGENT areas: JPEG/GIF viewers, MPEG viewers, contact sheet makers, AVI viewers, and probably a few other juicy tidbits. * Unix/X-Window -- MPEG source, movies; information on XAnim, a wonderful graphics program by Mark Podlipec * The QuickTime Support Link. A pointer to Robert A. Lentz's exquisite QuickTime information page, with info on flattening quicktimes and programs and utils for Macintosh, X Window, and Microsoft Windows. A MUST see!! * Archie link added! Just click and voila, you have access to Archie. (Some browsers may require an external telnet application; consult your documentation.) * Winsock support area. Link to the Winsock Application FAQ. In addition, the WWW Graphics Page is now the official distribution site in the USA for EWAN, the fantastic freeware telnet program for Winsock! o The Tennis Center -- Information on my favorite game, tennis. (I realize this is tangential, but.. so what!) * The rec.sport.tennis FAQ * The Tennis Homepage (In Canada, with links to another tennis homepage) !! * A cute picture of Barbi Benton and Hugh Hefner posting with their tennis racquets at a tennis court !! * Fascinating photos of Andre Agassi's new haircut o Favorite Links -- Other sites you should try, and IMMEDIATELY! * The Yahoo Sever - a great link, equipped with an easy-to-use subject search index for easy access to other links! Find what you want quickly and easily. * The Multimedia Maddman's hOmeY page -- Graphics Info and more! Just try it! * Michel Buffa's Video Games Page (3DO, Atari Jaguar, SNES, Sega, Gameboy, etc..) * The UnOfficial Nine Inch Nails Homepage * The Beastie Boys Homepage * The Llama Mailserver (MPEG resource and more!) * The alt.sex.movies Homepage * The CDnow! homepage -- ordering CDs via WWW * The Playboy Enterprises, Inc. homepage -- now you can explore Playboy's catalog via WWW! * A section on graphics links.. including the very nice IAMfree area, your local WWW Art Gallery! The material is presented in a refreshing format, just for YOU! If you do not want this site to die, your feedback must be submitted via email. Do not let it go to waste! The vitality of this site is up to you alone.. The WWW Graphics Page.. your online WWW resource for Graphics Utilities! Try it today! URL=http://www.best.com/~bryanw/ -- Bryan Woodworth (bryanw@best.com) Try The WWW Graphics Page today! URL: http://www.best.com/~bryanw Need a WWW browser? FTP to ftp.best.com:/pub/bryanw/wwwfaq.zip Info on WWW browsers for all platforms -- even Unix dial-up --------------------------------------------------------------------------- ~Subject: What are other good URL's ? A more up-to-date list you can find under http://www.powerweb.de/mpeg/mplinks.html Archives MPEG Archive http://www.powerweb.de/mpeg/ MPEG-2 Archive http://www.powerweb.de/mpeg2/ Articels MPEG FAQ 4.1 http://www.powerweb.de/mpeg/mpegfaq/ Compac using MPEG ? http://www.compaq.com/cgi-bin/present/whatsnew/pr.html Decoding MPEG Decoders http://www.doceo.com/mpegbord.html Digital Video (Issue Aug. 95): 2 MPEG Articels http://www.dv.com/dv/Mag/Aug95/Contents.html General web MPEG-Audio resources http://www.powerweb.de/mpeg/audiowww.html UNIXopen 12/95 - MPEG: Ein packendes Format http://www.powerweb.de/mpeg/mpuo12.html UNIXopen 05/96 - MPEG 2: ein breites Spektrum http://www.powerweb.de/mpeg/mpuo05.html How to make MPEG movies (unix) http://www.arc.umn.edu/GVL/Software/mpeg.html MPEG Infos at CRS4 http://www.crs4.it/~luigi/MPEG/mpegfaq.html Audiostreams BAWP - MPEG poems http://www.cs.brown.edu/fun/bawp/home.html David Bowie OUTSIDE http://www.davidbowie.com Fritz (radiostation with MPEG-sounds) http://www.fritz.de Mammoth Records - The Listening Room http://netit.com/mammoth/audio/index.html Music clips http://www.kspace.com/ Music Kitchen Music Videos http://www.directnet.com/Crash/MovingPictures Rock'n'Roll magazine http://www.addict.com/ATN/ Towhead http://pcd.stanford.edu/umbra/Towhead/Towhead.html Violet Arcana http://www.csos.orst.edu/rfr/va/arcana.html Virginia Tech Music Department http://server.music.vt.edu Companies Arasmith Engineering http://www.open2u.com Aspen, Colorado Site http://www.aspenonline.com/aspenonline C-Cube http://www.c-cube.com Doceo http://www.doceo.com Digital Video Systems http://www.dvsystems.com Hyundai Electronics America http://www.hea.com/ MPEG International http://www.formpeg.com/ MPEG Plaza http://www.visiblelight.com/mpeg/ NB Engineering (MPEG compression service) http://www.powerweb.de/mpeg/nb.html Open MPEG-1 representatives group http://cinax.com/OM-1 Sigma Design (RealMagic Decoder)) http://www.realmagic.com/ Universal Studios http://www.firstunion.com/universal/nettoob Link collections PHADE's ultimate MPEG link list http://www.powerweb.de/mpeg/mplinks.html Tristan's General web MPEG resources http://www.bok.net/~tristan/MPEG/MPEG-content.html#top MPEG-2 Video Compression for Broadcasting http://www.hei.ca/hei/mpeg2.html Utilities PHADE's util collection http://www.powerweb.de/mpeg/mpega.html Action Netscape Plug-In supporting MPEG http://www.open2u.com/action/action.html Active Movie Player http://www.microsoft.com/advtech/ActiveMovie/AMStream.htm CompCore (MPEG software and hardware producer) http://www.compcore.com CoolEdit 1.5.3 http://www.syntrillium.com/#Cool Maplay 95/NT http://po.eecs.berkeley.edu/~ctsay/mp2win32.html MPEG-2 archive of Chadd Fogg ftp://ftp.netcom.com/pub/cf/cfogg/mpeg2/ MPEG audio Layer 2 http://www.mpr.ca/products/transport/ MPEG-audio Layer 3 (FHG) http://www.iis.fhg.de/ MPEG play/MI (Motif) http://www.geom.umn.edu/docs/mpeg_play/mpeg_play.html MPEG/CD 2.0.5 for Macs http://www.kauai.com/kauai MPEGe Lib http://www.tardis.ed.ac.uk/~ark/mpegelib/ MPEG utils and some cool bands http://www.io.org/~cme Video & 8mm FILM http://www.kyushu-id.ac.jp/kid/free/RYOUTEI/MPEG/tsuzuki02.html Net Toob MPEG Player http://www.duplexx.com PreVU Netscape Plug-In for MPEG Video http://www.intervu.com/sysreq.html xa X11 Animator supporting MPEG http://www.cita.utoronto.ca/~richards/DCR/xa.html Video-streams 100+ Fractal Movie samples with MPEG http://www.cnam.fr/fractals/anim.html 150+ MPEGs, Anim, AVI,FLI, MOV http://www.acm.uiuc.edu/rml/Mpeg 300+ Outer Space Animations with MPEG http://www.univ-rennes1.fr/ASTRO/anim-e.html Andrew's MPEG Archive http://www.ugcs.caltech.edu/~werdna/mpegs.html Darin's MPEG Movie Archive http://www.ugcs.caltech.edu/~darinh/mpegs.shtml Daerons MPEG Player http://www.geom.umn.edu/docs/mpeg_play/mpeg_play.html FilmArt movies http://www.filmart.co.at/filmart Fractal Animations http://iseran.ira.uka.de/Fraktdemos/ Hangliding MPEGs http://cougar.stanford.edu:7878/MoviePage.html#MPEG Mathematical MPEGs http://www.csc.fi/math_topics/Movies/ MPEG-2 validation bitstreams ftp://wuarchive.wustl.edu/graphics/x3l3/pub/bitstreams/systems/ Movies ftp://ftp.informatik.tu-muenchen.de/pub/rec/movies/mpeg MPEG Movie Archive http://w3.eeb.ele.tue.nl/mpeg/index.html MPEG MONSTER LIST http://www.islandnet.com/~carleton/monster/monster.html Porsche Videos http://www.nbeng.com/nbe/html/samples.htm Pink Floyd and Blade Runner http://wwwzenger.informatik.tu-muenchen.de/persons/paula/mpeg/index.html Windsurfing MPEGs http://www.dsg.cs.tcd.ie/dsg_people/afcondon/windsurf/video/video.html =========================================================================== ~Subject: SECTION 8. - MAIL ORDER That's about what you can get via mail. --------------------------------------------------------------------------- ~Subject: The Internet MPEG CD-Rom PHADE SOFTWARE and Hartmann Multimedia Service Inh. Frank Gadegast Dipl. Ing. Stefan Hartmann present ======================================================= The Internet MPEG CD-Rom Version 1.0 Monday December 28th 1995 ======================================================= * Get yourself the latest MPEG Video and MPEG Audio software tools ! * Listen to over 150 songs from the Internet Underground Music Archive (IUMA)! (without having to download a single one ! incl. XingSound MPEG Audio player) * Browse the Internet Offline and click yourself through over 200 MPEG movies ! (you don't need to be online, everything is just a click away !) * Learn, how to use the World Wide Web , Offline ! * Try the Demo of this CD-Rom _ONLINE_ at: http://www.powerweb.de/phade/products/mpegcd/ The "Internet MPEG CD-Rom" is a rather unique collection of Multimedia- Data stored in a compression-format called MPEG. It includes 600 MB of digital movies, sounds, songs and all utilities for composing, encoding and decoding, playing and rearranging this multimedia material. The "Internet MPEG CD-Rom" is especially compiled for those, who want to follow the digital multimedia revolution or who want to develop MPEG-utilities or create MPEG-compressed sounds or movies. The "Internet MPEG CD-Rom" is NOW available as an ISO-9660 conform CD-Rom disc! Readable on DOS, Windows, Windows-NT, OS/2, Ultrix, Unix, MACs, etc .... Installation programs and all needed viewers are included for Windows, Linux, SunOS and Solaris ... "The Internet MPEG CD-Rom" includes the FAQs and MPEG utility programs, source-code, movies and information-files. Just everything about MPEG-I and now even MPEG-II. The CD-Rom includes (in addition to the versions which are stored on the ftp-Servers out there) all the 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-MPEG-Encoder, other DOS-ports, a security-filter for MPEG-I-video- and -audiostreams called secmpeg and secmpaudio, some selfmade movies, new versions and utilities that were specially made for THIS CD-Rom and that you will never find on other media... Try and USE the Internet OFFLINE !!! To make the "Internet MPEG CD-Rom" interactive, one big hypertext- document explains and displays the whole contents of the archive, giving the user a powerful tool, called Cello, to browse through Megabytes of documentaton and to interactevly select and play hours and hours of music and movies. The whole archive itself is organized as one big hypertext-document. It includes a complete Wide-World-Web (WWW) document, the tools to use this document on Windows-, Windows-NT-, Linux-, SunOS- and Solaris- machines are included, most UNIX-hosts can include "The Internet MPEG CD-Rom" into their hyptertext-services with a single link !!! You can find a few of all these WWW-documents as an example under the adress: http://www.powerweb.de/phade/products/mpegcd/ "The Internet MPEG CD-Rom" contains at least the following sections: 24,888,655 E:\AUDIO\MUSIC 20,583,631 E:\NVR 49,339,823 E:\AUDIO 12,108,204 E:\PHADESW 10,103,748 E:\BIN 3,000,035 E:\UTIL\AMIGA 640,532 E:\DEMO 152,576 E:\UTIL\DEC 11,618,223 E:\DOC 20,073,867 E:\UTIL\DOS 3,157,665 E:\FAQ 338,116 E:\UTIL\IRIX 189,569,667 E:\IUMA\MUSIC 5,390,454 E:\UTIL\MAC 191,150,646 E:\IUMA 1,802,240 E:\UTIL\NEXT 15,102,123 E:\MOVIES\IFRAME 2,152,491 E:\UTIL\OS2 99,083,167 E:\MOVIES\IPBFRAME 5,944,282 E:\UTIL\SPARC 114,185,290 E:\MOVIES 30,885,363 E:\UTIL\UNIX 52,781,148 E:\MPEG1 3,060,754 E:\UTIL\WINDOWNT 250,441 E:\MPEG2 4,042,098 E:\UTIL\WINDOWS 37,465,169 E:\NFM\MUSIC 76,842,276 E:\UTIL 37,537,740 E:\NFM 23,231,772 E:\VIDEOS 3,232,740 E:\WWW Total = 607,537,581 bytes Please be sure, to get always the most-up-to-date description of "The Internet MPEG CD-Rom" before requesting it ! EMail to: phade@powerweb.de or try to find the latest MPEGFAQ (current Version 3.2). Look at the date of this info file, something older than 6 months can't be up-to-date ! Be faster than the Internet and order now !!! Ordering can be done now immediately via email or via letter. To obtain "The Internet MPEG CD-Rom" you have the following choices: o fill the ORDER.FRM and send it via e-mail or fax it to PHADE Software (if paying with VISA-card only !) o fill the ORDER.FRM and send it via letter to PHADE Software (only VISA-card and EC-cheques (German Marks only) accepted !) o order it in your book store via: ISBN-number: 3-930736-40-3 Title : The Internet MPEG CD-Rom Version 1.0 Publisher : Hartmann Multimedia Service Author : PHADE Software, Inh. Frank Gadegast o try our WWW-server and get the latest info via URL=http://www.powerweb.de/phade/ o you can order at your local computer or CD-Rom shop (try to convince your local dealer to order from Hartmann Multimedia Service) ORDER-FORM for "The Internet MPEG CD-Rom" [Version 1.0] Monday NOVEMBER 13th 1995 ======================================================= Please fill out this form carefully to order "The Internet MPEG CD-Rom" Version 1.0. Then send it via letter to: PHADE Software Inh. Frank Gadegast Leibnizstr. 30 10625 Berlin, GERMANY Fon/Fax: ++ 49 30 312 81 03 E-Mail : phade@powerweb.de Web : http://www.powerweb.de/phade/ The price of the MPEG-CD-Rom is DM 49.90, plus o DM 10 for shipping inside Germany o DM 15 for shipping inside Europe o DM 28 for shipping outside Europe. The German price already includes 15 % VAT. All other prices are without VAT. So the total prices inclusive shipping and handling will be: Germany: 59.90 DM Europe: 64.90 DM International: 77.90 DM Shipping will be done via airmail, so you have the fastest delivery ! So, e.g. if you order one CD-Rom disc from inside Europe and pay via EC-cheque, fill the EC-cheque with DM 64,90. (Only for Germans: Innerhalb Deutschland, setzen Sie bitte den Betrag von DM 59.90 in Ihren Euro- oder Verrechnungs-Scheck ein.) Feel free to ask for our special price list for distributors, contributors or for special prices for bundling with other hard- and software. If you order several CD-Rom's, you only have to add the shipping fees once ! Exchange rate today is about : 1 US$ = 1.40 DM, but please fill out all cheques in German Deutsch Marks (DM) only !!! By signing the order you agree to the following terms: The use of "The Internet MPEG CD-Rom Version 1.0" is limited to one local area network or one single computer. The re-use of parts of this CD-Rom disc or the whole CD-Rom without the written permission of PHADE Software and Hartmann Multimedia Service is strictly prohibited. Especially BBS systems, Mailboxes, Networks on the Internet, ftp- or HTTP- server or Online-Services like CompuServe(R) do NOT have the permission to re-use the contents of this CD-Rom for the benefit of their users. Please ask PHADE Software for that permission and Hartmann Multimedia Service for the conditions ! Some single programs, tools, documentation files or streams can be copied and used for whatever purpose, according to the limitations from the original authors, because they are Shareware or freeware. It is strictly prohibited to use the o installation files (like INSTALL.EXE, INSTALL.HLP, the install-scripts) o utilities copyrighted by PHADE Software (like DBMP.EXE, BROWSER.EXE, WINEXE.EXE), the CD-Rom documentation files o HTML-pages and their pictures o sound-, pictures-, text- and other files belonging into the audio- archives "IUMA", "NFM" or "BerlinBands" o all MPEG-streams that are not already available in the Internet, like most of the MPEG-1-systemstreams, other streams and the Intro, consisting of MPEGCD.M1V, MPEGCD.MPG, MPEGCD.MP2 and MPEGCD.WAV for another purpose than in conjuction with using this CD-Rom disc. A copy of those files for a different purpose is strictly prohibited and protected by German Law. The music of the Intro is copyrighted by Stefan Hartmann, Hartmann Multimedia Service, Berlin and should not be copied either. PHADE Software claims the compilation copyright. Other projects should not benefit from copying the structure, methods or utility-combinations developed, tested and used for this CD-Rom disc. And now for our German customers: Die Internet MPEG CD-Rom ist eine einzigartige Kollektion von MPEG- Audio- und Video-Daten. Sie enthält ca. 600 MB digitale MPEG-Filme, MPEG-Songs (inclusive Internet Underground Music Archiv) und alle Utilities und Infos, die gebraucht werden, um das Material rein per Software abzuspielen, zu schneiden, zu variieren und zu erzeugen. Die CD ist eine ISO9660 CD-Rom und kann auf DOS/Windows-, allen UNIX-Systemen und MACs gelesen werden. Sie enthält MPEG-Tools und Utilities für diese Platformen. Alle Utilities sind Shareware oder Public Domain. Die Internet MPEG CD-Rom wurde als interaktives HTML-Hypertext-Dokument organisiert, so daß Sie sich mit einem WWW-Viewer durch das Archiv klicken können, ohne dabei den Überblick zu verlieren. So können Sie sich interaktiv per Mausklick durch über 150 MPEG-Songs von 40 Bands und durch über 200 MPEG-Filme bewegen ! Unter Windows wird der CELLO-WWW-Viewer installiert, mit dem Sie OFFLINE durch das Internet "surfen" können. (alle WWW-Seiten auch unter Unix und auf MACs abrufbar !) Lernen Sie, wie das Internet funktioniert, OFFLINE von der CD ! Sie brauchen keine Modem-Verbindung zum Netz ! Keine langen Download-Wartezeiten mehr ! Alles ist nur einen Klick entfernt ! Erleben Sie die Welt der neusten multimedialen Kompressionstechniken, die Ihnen Stunde für Stunde Musik und Filme bringt ! Ein Klick und Sie hören via Realtime-Software-MPEG-Audio-Player die Bands in CD-Qualität ! Noch ein Klick und Sie sehen die MPEG-Filme rein per Software-Playback ! Keine MPEG-Hardware erforderlich ! Seien Sie schneller als das Internet, holen Sie sich diese CD-Rom: The Internet MPEG-CD-Rom ! ====================== cut here and mail or email this part only ! ========== Name : _____________________________________ First Name : _____________________________________ Title : _____________________________________ Company : _____________________________________ Address : _____________________________________ Town : _____________________________________ Post code : _____________________________________ Country : _____________________________________ Phone : _____________________________________ Fax : _____________________________________ E-mail : _____________________________________ Enter here the number of CD-Rom's you want to order (defaults to 1): ( ) number of CD-Rom's I pay "The Internet MPEG CD-Rom" by ... ( ) VISA-card, include your Card-Nr.: _____________________ Name of cardholder: _____________________ Expiration date: _____________________ ( ) EC-Cheque, please fill in DM (German Deutsch Marks, only !) ( ) Verrechnungsscheck (nur in Deutschland, only inside Germany) ============= ====================================== (date) ^-- sign here ====================== cut here cut here cut here ======================= -- PHADE Software, Leibnizstr. 30, 10625 Berlin, GERMANY Inh. Frank Gadegast Fon/Fax: +49 30 3128103 phade@powerweb.de http://www.powerweb.de/phade/ --------------------------------------------------------------------------- ~Subject: The Internet MPEG Audio Archive PHADE SOFTWARE and Hartmann Multimedia Service Inh. Frank Gadegast Dipl. Ing. Stefan Hartmann and Francis-Verlag present ======================================================= The Internet MPEG Audio Archive Version 1.0 January 1th 1996 ======================================================= o MPEG Audio software tools for DOS, Windows and UNIX ! o Biggest One-Disk-Music-Sampler ever ! o Internet OFFLINE on CD-ROM o Internet OFFLINE Training o Over 70 songs from more than 30 bands in CD quality ! o More than 150 MPEG audio files ! o More than 1500 files ... The Internet MPEG Audio Archive (IMAA) features 35 music bands with over 377 MBytes of MPEG Audio material, that is 77 complete music songs (351 MBytes=3:47 hours) and all in all 157 MPEG Audio files on one CD-Rom ! It uses the MPEG Audio compression format, which makes it possible to store more than 10 times the amount of music data on one CD-Rom disc than with conventional PCM Audio encoding. The IMAA CD-Rom also features an unique collection of MPEG-Audio tools for Windows, DOS and Unix platforms to encode, decode, play and rearrange this MPEG Audio material. All programs and utilities are public domain or Shareware. The CD-Rom itsself is a standard ISO-9660 disc and can be read and used on DOS, Windows, UNIX and MAC systems. A complete installation program for Windows3.x and Windows95 is included. To make the IMAA CD-ROM disc interactive and access all the music songs via an easy to use point and click interface, the IMAA CD-Rom is compiled as a big HTML hypertext document, which you can browse via a WEB (World Wide Web) browser program. For Windows3.x and Windows95 the browser program (Cello) is already included on the CD-Rom disc. All the HTML pages explain and display all the infos from the music bands and the whole contens of the archive. You can browse also through Megabytes of documentation about MPEG compression and interactively select and play hours of hours of music. The Internet MPEG Audio Archive is especially compiled for those people, who want to follow the digital multimedia revolution or want to develop MPEG Audio utilities or create and listen to MPEG audio songs. Try and USE the Internet OFFLINE !!! To make the "Internet MPEG Audio Archive" interactive, one big hypertext- document explains and displays the whole contents of the archive, giving the user a powerful tool, called Cello, to browse through Megabytes of documentaton and to interactevly select and play hours and hours of music. The whole archive itself is organized as one big hypertext-document. It includes a complete Wide-World-Web (WWW) document, the tools to use this document on Windows-, Windows-NT-, Linux-, SunOS- and Solaris- machines are included, most UNIX-hosts can include "The Internet MPEG Audio Archive" into their hyptertext-services with a single link !!! Internet MPEG Audio Archive, Version 1.0 ISO 9660 conform CD-Rom disc, 435 MB , 1561 Files easy point and click HTML-interface via Cello WEB-Browser "The Internet MPEG CD-Rom" contains at least the following sections: 170 MB AUDIO general Audio Files 17 MB BIN Installation programs for Windows 1 MB FAQ Frequently Asked Question files 138 MB IUMA Internet Underground Music Archive 108 MB NFM Net For Music archive 11 MB UTIL Tools and source code for Amiga, DOS, Unix & Windows 137 MB WOLVERIN Wolverine Records archive 10 MB WWW HTML-dokuments to explains contents Total = 425 bytes Please be sure, to get always the most-up-to-date description of "The Internet MPEG Audio Archive" before requesting it ! EMail to: phade@powerweb.de Look at the date of this info file, something older than 6 months can't be up-to-date ! Be faster than the Internet and order now !!! Ordering can be done now immediately via email or via letter. To obtain "The Internet MPEG Audio Archive" you have the following choices: o fill the ORDER.FRM and send it via e-mail or fax it to PHADE Software (if paying with VISA-card only !) o fill the ORDER.FRM and send it via letter to PHADE Software (only VISA-card and EC-cheques (German Marks only) accepted !) o order it in your book store via: ISBN-number: 3-7723-8252-5 Title : The Internet MPEG Audio Archive Version 1.0 Publisher : Francis Verlag Author : PHADE Software, Inh. Frank Gadegast o try our WWW-server and get the latest info via URL=http://www.is.in-berlin.de/~phade/imaa.html o you can order at your local computer or CD-Rom shop (try to convince your local dealer to order directly fom PHADE Software) ORDER-FORM for "The Internet MPEG Audio Archive" CD-Rom [Version 1.0] Tuesday February 20th 1996 ===================================================================== Please fill out this form carefully to order "The Internet MPEG Audio Archive" Version 1.0. Then send it via letter to: PHADE Software Inh. Frank Gadegast Leibnizstr. 30 10625 Berlin, GERMANY Fon/Fax: ++ 49 30 312 81 03 E-Mail : phade@powerweb.de Web : http://www.is.in-berlin.de/~phade/imaa.html The price of the MPEG-CD-Rom is DM 49.-, plus o DM 10 for shipping inside Germany o DM 15 for shipping inside Europe o DM 28 for shipping outside Europe. The German price already includes 15 % VAT. All other prices are without VAT. So the total prices inclusive shipping and handling will be: Germany: 59.- DM Europe: 64.- DM International: 77.- DM Shipping will be done via airmail, so you have the fastest delivery ! So, e.g. if you order one CD-Rom disc from inside Europe and pay via EC-cheque, fill the EC-cheque with DM 64.-. (Only for Germans: Innerhalb Deutschland, setzen Sie bitte den Betrag von DM 59.- in Ihren Euro- oder Verrechnungs-Scheck ein.) If you order several CD-Rom's, you only have to add the shipping fees once ! Exchange rate today is about : 1 US$ = 1.40 DM, but please fill out all cheques in German Deutsch Marks (DM) only !!! By signing the order you agree to the following terms: The use of "The Internet MPEG Audio Archive" CD-Rom Version 1.0 is limited to one local area network or one single computer. The re-use of parts of this CD-Rom disc or the whole CD-Rom without the written permission of PHADE Software and Francis Verlag is strictly prohibited. Especially BBS systems, Mailboxes, Networks on the Internet, ftp- or HTTP- server or Online-Services like CompuServe(R) do NOT have the permission to re-use the contents of this CD-Rom for the benefit of their users. Please ask PHADE Software or Francis Verlag for permission and conditions ! Some single programs, tools, documentation files or streams can be copied and used for whatever purpose, according to the limitations from the original authors, because they are Shareware or freeware. It is strictly prohibited to use the o installation files (like INSTALL.EXE, INSTALL.HLP, the install-scripts) o utilities copyrighted by PHADE Software (like DBMP.EXE, BROWSER.EXE, WINEXE.EXE), the CD-Rom documentation files o HTML-pages and their pictures o sound-, pictures-, text- and other files belonging into the audio- archives "IUMA", "NFM" or "WOLVERIN" o all MPEG-audio-streams that are not already available in the Internet, like most of the songs, other streams and the Intro. for another purpose than in conjuction with using this CD-Rom disc. A copy of those files for a different purpose is strictly prohibited and protected by German Law. The music of the Intro is copyrighted by Stefan Hartmann, Hartmann Multimedia Service, Berlin and should not be copied either. PHADE Software claims the compilation copyright. Other projects should not benefit from copying the structure, methods or utility-combinations developed, tested and used for this CD-Rom disc. ====================== cut here and mail or email this part only ! ========== Name : _____________________________________ First Name : _____________________________________ Title : _____________________________________ Company : _____________________________________ Address : _____________________________________ Town : _____________________________________ Post code : _____________________________________ Country : _____________________________________ Phone : _____________________________________ Fax : _____________________________________ E-mail : _____________________________________ Enter here the number of CD-Rom's you want to order (defaults to 1): ( ) number of CD-Rom's I pay "The Internet MPEG Audio Archive" by ... ( ) VISA-card, include your Card-Nr.: _____________________ Name of cardholder: _____________________ Expiration date: _____________________ ( ) EC-Cheque, please fill in DM (German Deutsch Marks, only !) ( ) Verrechnungsscheck (nur in Deutschland, only inside Germany) ============= ====================================== (date) ^-- sign here ====================== cut here cut here cut here ======================= -- PHADE Software Inh. Dipl-Inform. Frank Gadegast Buy the Internet MPEG CD-Rom ! Leibnizstr. 30 Buy the Internet MPEG Audio Archive CD-Rom ! 10625 Berlin, GERMANY Buy the best MPEG-tools the Internet offers ! Fon/Fax ++ 49 30 3128103 E-mail phade@powerweb.de Web site http://www.powerweb.de/phade/ --------------------------------------------------------------------------- ~Subject: Conversion, WWW and CD-Rom production service VITEC Video Toolbox CD ====================== ... with lots of MPEG-1 programs and tools DM 189,- The CD-Rom includes all MPEG-1 software from VITEC, all running under Windows 3.x including MPEG MAKER, Video Clip AVI, VIDEO Clip MPEG (demo version), IMAGER and Video for Windows Runtime. MPEG MAKER alone cost usally DM 449,- Order via http://www.powerweb.de/phade/mpeg/vtcdor.html or via Fax. ========================================================================= PHADE Software Inh. Dipl-Inform. Frank Gadegast Leibnizstr. 30 10625 Berlin, GERMANY Fon/Fax ++ 49 30 3128103 E-mail phade@powerweb.de Web site http://www.powerweb.de/phade/ --------------------------------------------------------------------------- ~Subject: Conversion, WWW and CD-Rom production service 1) 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 video-conversion). 2) PHADE Software is offering WWW-server design Beeing expirienced with right now to CD-Rom WWW-productions and the configuration, design and programming of several HTTP-server PHADE Software can offer a complete implementation of HTTP-server. Check our site under http://www.powerweb.de, we can bring YOUR company onto the Internet ! Complete service, low and constant prices and brilliant connections. 3) PHADE Software is offering CD-Rom productions Having two own CD-Roms selling successfully in the market and having programmed and designed several others, PHADE Software can offer quick, high-quality interfaces to CD-Roms. Multimedia extensions included, several platforms supported. Please send any jobs or commercial mail to phade@powerweb.de --------------------------------------------------------------------------- ~Subject: How can I order information from C-CUBE ? 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 =========================================================================== ~Subject: SECTION 9. - ADDITIONAL INFORMATION Here you find hints about how to find other documents, or questions and their answers that are not having their own section so far ! ------------------------------------------------------------------------------- ~Subject: What are the MPEG standard documents ? From: billd@cray.com (Bill Davidson) 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. --------------------------------------------------------------------------- ~Subject: So, the Xing decoder is cheating, right ? [ About what Xing is messing up again ... ] Date: Mon, 3 Jan 1994 12:20:33 -0800 (PST) From: Jared V Boone 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) --------------------------------------------------------------------------- ~Subject: Will MPEG be included in QuickTime ? From: mwilliam@envy.Reed.Edu (Son of Sam) 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... --------------------------------------------------------------------------- ~Subject: What about good MPEG Hardware encoders (Optivision) ? OptImage does sell one (2 actually: Mac&PC)) MPEG-hardware-boards along with other tools (multiplexer, disc builder, disc burner...) please change the contact point to: info@optimage.com or sales@optimage.com 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.. ? [ about 20.000 $ !!! ] The streams from this board have a few artifacts, but over-all look quite good. Their telephone number in the US is: (415) 855-0200 --------------------------------------------------------------------------- ~Subject: What's about CD-I ? 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 . --------------------------------------------------------------------------- ~Subject: What is the PCMotion Player ? From: kothary@mprgate.mpr.ca 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. ------------------------------------------------------------------------------- ~Subject: What is the MPEG-2 ISO number ? From: Tom Pfeifer Date: Fri, 29 Apr 1994 16:26:01 +0200 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}) ------------------------------------------------------------------------------- ~Subject: Some papers about MPEG-audio From: scott.k.diamond@email.HUB.TEK.COM Subject: MPEG Audio Date: Wed, 25 Jan 1995 18:47:02 -0800 ISO-MPEG-1 Audio: A Generic Standard for Coding of High Quality Digital Audio Karlheinz Brandenburg and Gerhard Stoll Journal of the Audio Engineering Society October 1994, Volume 42, Number 10 Pages 780-792 Guide to MPEG-1 Audio Standard Seymour Shlien IEEE Transactions on Broadcasting December 1994, Volumne 40, Number 4 Pages 206-218 Wideband Speech and Audio Coding Peter Noll IEEE Communications Magazine November 1993, Volume 31, Number 11 Pages 34-44 Signal Compression Based on Models of Human Perception Nikil Jayant, James Johnston and Robert Safranek Proceedings of the IEEE October 1993, Volume 81, Number 10 Pages 1385-1421 Overview of the MPEG/Audio Compression Algorithm Proceedings of the SPIE, Volume 2187, 1994 pages 260-273 Scott Diamond \ / Tektronix, Audio Measurement Group / \ P.O. Box 500, M.S. 58-639 < s > Beaverton, Oregon 97077-0001 \ / wk: (503) 627-6304 hm: (503) 643-6779 / \ scott.k.diamond@tek.com ------------------------------------------------------------------------------- ~Subject: Where can I find more documents about what Berkeley is doing ? From: Larry Rowe 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. --------------------------------------------------------------------------- ~Subject: Who are CD-I producers ? There is a company called: ProLearn, Herr Vigneron [ I would really like to start a list here. Please feedback me ;o) ] --------------------------------------------------------------------------- ~Subject: Where can I get VideoCD and CD-I coding ? 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 Multimedia Service Mr. Dipl. Ing. Stefan Hartmann Berlin, Germany Tel: ++ 49 30 344 23 66 email: harti@harti.de --------------------------------------------------------------------------- ~Subject: Who offers MPEG encoding via Internet ? The sponsor of the MPEG Archive, NB Digital Solutions, offer encoding services for AVI, MPEG, MPEG-2 and more under http://www.nbeng.com --------------------------------------------------------------------------- ~Subject: Where can I do MPEG encoding ? We are offering MPEG-1 encoding from VHS, S-VHS, Video8 and Hi-8 tape. You send us your tape, we will encode it to MPEG-1 standard IBP MPEG SYSTEM stream, compatible with White book or Reel Magic format. Standard Format 352x288 PAL or 352x240 NTSC will be supported Then we can also write it for you on a CD-ROM disk, so that you can play it on a Philips CD-I player with Digital Video Cartridge or via an MPEG player card like the Sigma Reel Magic card inside a PC via a CD-ROM drive. Up to 70 minutes of Digital MPEG Video and Audio will fit on a single CD disk ! Rates are: 70 DM per Minute (with at least 15 minutes for one order) 60 DM per Minute (if it gets more than 30 minutes) Writing it on CD-Rom is an additional 150 DM charge per order. All prices without VAT. (Current exchange rate is about 1.60 DM / 1 US$) Please let me know, what you need. Best regards, Dipl. Ing. Stefan Hartmann, c/o Hartmann Multimedia Service, Berlin, Germany email to: harti@harti.de FAX: ++ 49 30- 344 92 79 Phone: ++ 49 30- 344 23 66 --------------------------------------------------------------------------- ~Subject: What the problem with all these file extensions for MPEG-files ? Hm, nobody standarized the file extensions yet, the are just common use. the first MPEG-users (Xing) just used .mpg for a file extension, but they had their special (non MPEG-standard) format. Then the "invented" .mp2 for audio only files (well .mp2 looks more like MPEG-2, does it ? Some had file-extension they wanted, some ignored MS-DOS file systems ... The following extensions are there: .mpg could be everything ;o) usally only Xing-format (only I-frame) .mps MPEG-1 IPB Systemstream (video and audio) .m1v MPEG-1 IPB only video or systemstream .mpv MPEG-1 IPB only video (sometime even .vmp) .mp2 MPEG-1 only audio (mostly layer 1 or 2) .mpa MPEG-1 only audio (mostly layer 1 or 2) (sometimes even .amp) .l3 MPEG-1 only audio (layer 3) .m2v MPEG-2 IPB only video (is there some MPEG-2 audio out ?) My own idea for file extension looks like this: .m1s MPEG-1 IPB systemstream (video and audio) .m1v MPEG-1 IPB videostream .m1a MPEG-1 IPB audiostream .m2s MPEG-2 IPB systemstream (video and audio) .m2v MPEG-2 IPB videostream .m2a MPEG-2 IPB audiostream There is no real need for a support of I-frame only streams anymore. There are PD-players with IPB-frame support for every platform now and the new players can play the old streams too. Roman Czyborra is working on getting these extension registered for WWW-use, so let's see ... Look up the URL=http://www.cs.tu-berlin.de/~czyborra/registrations/ for how this process is going on. --------------------------------------------------------------------------- ~Subject: How can I do RTP encapsulation of MPEG1/MPEG2 ? There is a Internet Draft about that. It is usally called: draft-hoffman-rtp-mpeg-encap-01.txt Here's the excerpt: This draft describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two profiles are described. The first is designed to support maximum interoperability with MPEG2 System environments. The second is designed to maximize simplicity of implementation and to leverage other efforts within IETF. ~Subject: Wo kann ich den MPEG-standard bestellen ? [ Only for Germans... ] Ihr koennt den MPEG-draft-I beim Beuth Verlag bekommem. =========================================================================== ~Subject: SECTION 10. - WHERE TO FIND MORE INFOS --------------------------------------------------------------------------- ~Subject: What are some good books about MPEG ? Titel: Bilddatenkompression mit JPEG und MPEG (german) Autor: Heiner Kuester Verlag: Franzis Preis: 78.00 DM incl. 1 CD (Player, mpeg-streams etc.) Titel: MPEG compression Author: Bill Pennebaker, Joan Mitchell Date: July 1994 --------------------------------------------------------------------------- ~Subject: Where are some good artikels about MPEG ? Titel: MPEG - ein packendes Format (german) Paper: UNIXOpen - 12/95 Author: Frank Gadegast URL: http://www.powerweb.de/mpeg/mpuo12.html Title: MPEG 2 - ein breites Spektrum (german) Paper: UNIXOpen - 05/96 Author: Frank Gadegast URL: http://www.powerweb.de/mpeg/mpuo05.html Titel: 50 Hot Digital Video Web Sites Paper: DV, July Issue 1995 --------------------------------------------------------------------------- ~Subject: What newsgroups discuss MPEG ? 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 the FAQ for the newsgroup 'comp.compression'. --------------------------------------------------------------------------- ~Subject: How can 'archie' help me ? 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 =========================================================================== ~Subject: SECTION 11. - 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) 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. 2) Who can send me informations about MPEG-1-Videos stored on CD-I CD's ? Who can provide a list and keep it up-to-date ? Who can provide information about CD-I and MPEG in general ? 3) Is this FAQ really readable with the FAQ-mode from emacs ? Can you read it with a good news-reader question by question ? Did not try this out ... 4) How many people would like to have a CD-Rom containing material for testing MPEG-encoders ? Source material, example streams for several needs, for several formats, comparable encoding results and messurements and all needed encoding, decoding tools could be supplied. If there are enough, we might do some. We already have enough reference material, frames and utils and ideal streams to compare results. Please mail to: phade@powerweb.de if you have more information, than I have. =========================================================================== The end of ... THE MPEG-FAQ ==================================================== PHADE Software Inh. Dipl-Inform. Frank Gadegast Leibnizstr. 30 10625 Berlin, GERMANY Fon/Fax ++ 49 30 3128103 E-mail phade@powerweb.de Web site http://www.powerweb.de/mpeg ===========================================================================