==================================================== THE MPEG-FAQ [Version 3.0 - 11. Oct 1993] ==================================================== PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY Inh. Frank Gadegast Fon/Fax: +49 30 3128103 phade@cs.tu-berlin.de =========================================================================== This is my summary about MPEG. It's the fourth publication of this file. Lots of errors have been removed, and lots of information has been added (which has surely brought other errors with it, see Murphy's Law). This fourth addition is VERY different to the previous ones. First: Some sections have been removed, because they are old or there was nothing changing. So if you are NOT familiar with the theme, get the last MPEG-FAQ's (Version 1.1 or 2.0) via ftp from host: ftp.cs.tu-berlin.de (130.149.17.7) or quepasa.cs.tu-berlin.de file: /pub/msdos/dos/graphics/mpegfa11.zip file: /pub/msdos/dos/graphics/mpegfa20.zip This new FAQ will be there soon too, as 'mpegfa30.zip'. My MPEG-related software and my DOS-ports of several programs can be found there too. Second: There are sections in the FAQ about MPEG-Audio (written by Morten Hjerde) and MPEG-II (written by Chad Fogg) now. Third : The theme of the FAQ is changing slowly from a FAQ about MPEG-video and the available utilities to a FAQ explaining whats going on in the scene. Themes like MPEG-Audio, MPEG-II, MPEG-IV e.g will be discusses more detailed from now on. Everybody should nearly know what MPEG is and how to find and play the videos by this time. In the utility-sections you only find infos about the NEW programs or NEW versions of them, to find a complete list of available utilities refer to the section WHERE TO FIND written by Bryan Woodworth. Fourth: The people where more interested to get the complete archives. Therefore the TRAIL-PACK-Service is still running. I'm still collecting EVERY info, video, sound or program. Get the Trail-Pack ! The Trail-Pack on floppies is CANCELED, because the archive is now TOO big to fit on floppies at all. You should read carefully through this FAQ this time, cause lots of new information is hidden in all the sections. F.e. news about Dos, Amiga-, Atari-, OS/2-, Windows-, Windows-NT, VMS-, NeXT, Unix- and Mac-Players and coders !!! Read about the future of MPEG ... This summary is devided in 12 parts: I | WHAT IS MPEG-VIDEO/AUDIO ? II | PROFESSIONAL SOFTWARE III | PUBLIC-DOMAIN SOFTWARE OR SHAREWARE IV | MPEG-RELATED HARDWARE V | MAILBOX-ACCESS VI | FTP-ACCESS (PD) VII | MAIL-ORDER VIII | RETRIEVED MAIL OR ARTICLES IX | ADDITIONAL INFORMATION X | WHERE TO FIND MORE INFOS XI | NEWS XII | QUESTIONS I add my comments in brackets [], lines (---- or ====) seperate the chapters. Please try and find out more information yourself. I had enough to do by getting and preparing this information. And only bother me with file- request if its not possible for you to get it somewhere else !!! If you want to contribute to this FAQ in any way, please email me (probably by replying to this posting). My email address is: phade@cs.tu-berlin.de Or send any additional information via fax or e-mail. The fax is only reachable between Mo.-Fr. from 10.00-13.00 and from 15.00-18.30 german time. Phade (Frank Gadegast) DISCLAIMER: I HAVE NOTHING TO DO WITH THE NAMED COMPANIES, NO BUSINESS, IT'S JUST MY PERSONAL INTERESTED. THESE COMPANIES ARE NAMED, BECAUSE, THEY ARE THE FIRST BRINGING MULTIMEDIA TO THE PC- WORLD. SURE I MAKE ADVERTS FOR THEM WITH THIS FAQ, BUT HOPE- FULLY YOU, AS A READER OF THIS FAQ, WILL FORCE THEM TO PRODUCE MORE AND BETTER PRODUCTS. =========================================================================== I.1 | WHAT IS MPEG-VIDEO/VIDEO =============================== ------------------------------------------------------------------------------- I.1 | MPEG-Video ----------------- From comp.compression Mon Oct 19 15:38:38 1992 Sender: news@chorus.chorus.fr Author: Mark Adler [71] Introduction to MPEG (long) What is MPEG? Does it have anything to do with JPEG? Then what's JBIG and MHEG? What has MPEG accomplished? So how does MPEG I work? What about the audio compression? So how much does it compress? What's phase II? When will all this be finished? How do I join MPEG? How do I get the documents, like the MPEG I draft? [ There is no newer version of this part so far. Whoever wants to update ] [ this description, should do the job and send it over. ] ------------------------------------------------------------------------------ Subject: [71] Introduction to MPEG (long) Written by Mark Adler . Q. What is MPEG? A. MPEG is a group of people that meet under ISO (the International Standards Organization) to generate standards for digital video (sequences of images in time) and audio compression. In particular, they define a compressed bit stream, which implicitly defines a decompressor. However, the compression algorithms are up to the individual manufacturers, and that is where proprietary advantage is obtained within the scope of a publicly available international standard. MPEG meets roughly four times a year for roughly a week each time. In between meetings, a great deal of work is done by the members, so it doesn't all happen at the meetings. The work is organized and planned at the meetings. Q. So what does MPEG stand for? A. Moving Pictures Experts Group. Q. Does it have anything to do with JPEG? A. Well, it sounds the same, and they are part of the same subcommittee of ISO along with JBIG and MHEG, and they usually meet at the same place at the same time. However, they are different sets of people with few or no common individual members, and they have different charters and requirements. JPEG is for still image compression. Q. Then what's JBIG and MHEG? A. Sorry I mentioned them. Ok, I'll simply say that JBIG is for binary image compression (like faxes), and MHEG is for multi-media data standards (like integrating stills, video, audio, text, etc.). For an introduction to JBIG, see question 74 below. Q. Ok, I'll stick to MPEG. What has MPEG accomplished? A. So far (as of January 1992), they have completed the "Committee Draft" of MPEG phase I, colloquially called MPEG I. It defines a bit stream for compressed video and audio optimized to fit into a bandwidth (data rate) of 1.5 Mbits/s. This rate is special because it is the data rate of (uncompressed) audio CD's and DAT's. The draft is in three parts, video, audio, and systems, where the last part gives the integration of the audio and video streams with the proper timestamping to allow synchronization of the two. They have also gotten well into MPEG phase II, whose task is to define a bitstream for video and audio coded at around 3 to 10 Mbits/s. Q. So how does MPEG I work? A. First off, it starts with a relatively low resolution video sequence (possibly decimated from the original) of about 352 by 240 frames by 30 frames/s (US--different numbers for Europe), but original high (CD) quality audio. The images are in color, but converted to YUV space, and the two chrominance channels (U and V) are decimated further to 176 by 120 pixels. It turns out that you can get away with a lot less resolution in those channels and not notice it, at least in "natural" (not computer generated) images. The basic scheme is to predict motion from frame to frame in the temporal direction, and then to use DCT's (discrete cosine transforms) to organize the redundancy in the spatial directions. The DCT's are done on 8x8 blocks, and the motion prediction is done in the luminance (Y) channel on 16x16 blocks. In other words, given the 16x16 block in the current frame that you are trying to code, you look for a close match to that block in a previous or future frame (there are backward prediction modes where later frames are sent first to allow interpolating between frames). The DCT coefficients (of either the actual data, or the difference between this block and the close match) are "quantized", which means that you divide them by some value to drop bits off the bottom end. Hopefully, many of the coefficients will then end up being zero. The quantization can change for every "macroblock" (a macroblock is 16x16 of Y and the corresponding 8x8's in both U and V). The results of all of this, which include the DCT coefficients, the motion vectors, and the quantization parameters (and other stuff) is Huffman coded using fixed tables. The DCT coefficients have a special Huffman table that is "two-dimensional" in that one code specifies a run-length of zeros and the non-zero value that ended the run. Also, the motion vectors and the DC DCT components are DPCM (subtracted from the last one) coded. Q. So is each frame predicted from the last frame? A. No. The scheme is a little more complicated than that. There are three types of coded frames. There are "I" or intra frames. They are simply a frame coded as a still image, not using any past history. You have to start somewhere. Then there are "P" or predicted frames. They are predicted from the most recently reconstructed I or P frame. (I'm describing this from the point of view of the decompressor.) Each macroblock in a P frame can either come with a vector and difference DCT coefficients for a close match in the last I or P, or it can just be "intra" coded (like in the I frames) if there was no good match. Lastly, there are "B" or bidirectional frames. They are predicted from the closest two I or P frames, one in the past and one in the future. You search for matching blocks in those frames, and try three different things to see which works best. (Now I have the point of view of the compressor, just to confuse you.) You try using the forward vector, the backward vector, and you try averaging the two blocks from the future and past frames, and subtracting that from the block being coded. If none of those work well, you can intra- code the block. The sequence of decoded frames usually goes like: IBBPBBPBBPBBIBBPBBPB... Where there are 12 frames from I to I (for US and Japan anyway.) This is based on a random access requirement that you need a starting point at least once every 0.4 seconds or so. The ratio of P's to B's is based on experience. Of course, for the decoder to work, you have to send that first P *before* the first two B's, so the compressed data stream ends up looking like: 0xx312645... where those are frame numbers. xx might be nothing (if this is the true starting point), or it might be the B's of frames -2 and -1 if we're in the middle of the stream somewhere. You have to decode the I, then decode the P, keep both of those in memory, and then decode the two B's. You probably display the I while you're decoding the P, and display the B's as you're decoding them, and then display the P as you're decoding the next P, and so on. Q. You've got to be kidding. A. No, really! Q. Hmm. Where did they get 352x240? A. That derives from the CCIR-601 digital television standard which is used by professional digital video equipment. It is (in the US) 720 by 243 by 60 fields (not frames) per second, where the fields are interlaced when displayed. (It is important to note though that fields are actually acquired and displayed a 60th of a second apart.) The chrominance channels are 360 by 243 by 60 fields a second, again interlaced. This degree of chrominance decimation (2:1 in the horizontal direction) is called 4:2:2. The source input format for MPEG I, called SIF, is CCIR-601 decimated by 2:1 in the horizontal direction, 2:1 in the time direction, and an additional 2:1 in the chrominance vertical direction. And some lines are cut off to make sure things divide by 8 or 16 where needed. Q. What if I'm in Europe? A. For 50 Hz display standards (PAL, SECAM) change the number of lines in a field from 243 or 240 to 288, and change the display rate to 50 fields/s or 25 frames/s. Similarly, change the 120 lines in the decimated chrominance channels to 144 lines. Since 288*50 is exactly equal to 240*60, the two formats have the same source data rate. Q. You didn't mention anything about the audio compression. A. Oh, right. Well, I don't know as much about the audio compression. Basically they use very carefully developed psychoacoustic models derived from experiments with the best obtainable listeners to pick out pieces of the sound that you can't hear. There are what are called "masking" effects where, for example, a large component at one frequency will prevent you from hearing lower energy parts at nearby frequencies, where the relative energy vs. frequency that is masked is described by some empirical curve. There are similar temporal masking effects, as well as some more complicated interactions where a temporal effect can unmask a frequency, and vice-versa. The sound is broken up into spectral chunks with a hybrid scheme that combines sine transforms with subband transforms, and the psychoacoustic model written in terms of those chunks. Whatever can be removed or reduced in precision is, and the remainder is sent. It's a little more complicated than that, since the bits have to be allocated across the bands. And, of course, what is sent is entropy coded. Q. So how much does it compress? A. As I mentioned before, audio CD data rates are about 1.5 Mbits/s. You can compress the same stereo program down to 256 Kbits/s with no loss in discernable quality. (So they say. For the most part it's true, but every once in a while a weird thing might happen that you'll notice. However the effect is very small, and it takes a listener trained to notice these particular types of effects.) That's about 6:1 compression. So, a CD MPEG I stream would have about 1.25 MBits/s left for video. The number I usually see though is 1.15 MBits/s (maybe you need the rest for the system data stream). You can then calculate the video compression ratio from the numbers here to be about 26:1. If you step back and think about that, it's little short of a miracle. Of course, it's lossy compression, but it can be pretty hard sometimes to see the loss, if you're comparing the SIF original to the SIF decompressed. There is, however, a very noticeable loss if you're coming from CCIR-601 and have to decimate to SIF, but that's another matter. I'm not counting that in the 26:1. The standard also provides for other bit rates ranging from 32Kbits/s for a single channel, up to 448 Kbits/s for stereo. Q. What's phase II? A. As I said, there is a considerable loss of quality in going from CCIR-601 to SIF resolution. For entertainment video, it's simply not acceptable. You want to use more bits and code all or almost all the CCIR-601 data. From subjective testing at the Japan meeting in November 1991, it seems that 4 MBits/s can give very good quality compared to the original CCIR-601 material. The objective of phase II is to define a bit stream optimized for these resolutions and bit rates. Q. Why not just scale up what you're doing with MPEG I? A. The main difficulty is the interlacing. The simplest way to extend MPEG I to interlaced material is to put the fields together into frames (720x486x30/s). This results in bad motion artifacts that stem from the fact that moving objects are in different places in the two fields, and so don't line up in the frames. Compressing and decompressing without taking that into account somehow tends to muddle the objects in the two different fields. The other thing you might try is to code the even and odd field streams separately. This avoids the motion artifacts, but as you might imagine, doesn't get very good compression since you are not using the redundancy between the even and odd fields where there is not much motion (which is typically most of image). Or you can code it as a single stream of fields. Or you can interpolate lines. Or, etc. etc. There are many things you can try, and the point of MPEG II is to figure out what works well. MPEG II is not limited to consider only derivations of MPEG I. There were several non-MPEG I-like schemes in the competition in November, and some aspects of those algorithms may or may not make it into the final standard for entertainment video compression. Q. So what works? A. Basically, derivations of MPEG I worked quite well, with one that used wavelet subband coding instead of DCT's that also worked very well. Also among the worked-very-well's was a scheme that did not use B frames at all, just I and P's. All of them, except maybe one, did some sort of adaptive frame/field coding, where a decision is made on a macroblock basis as to whether to code that one as one frame macroblock or as two field macroblocks. Some other aspects are how to code I-frames--some suggest predicting the even field from the odd field. Or you can predict evens from evens and odds or odds from evens and odds or any field from any other field, etc. Q. So what works? A. Ok, we're not really sure what works best yet. The next step is to define a "test model" to start from, that incorporates most of the salient features of the worked-very-well proposals in a simple way. Then experiments will be done on that test model, making a mod at a time, and seeing what makes it better and what makes it worse. Example experiments are, B's or no B's, DCT vs. wavelets, various field prediction modes, etc. The requirements, such as implementation cost, quality, random access, etc. will all feed into this process as well. Q. When will all this be finished? A. I don't know. I'd have to hope in about a year or less. Q. How do I join MPEG? A. You don't join MPEG. You have to participate in ISO as part of a national delegation. How you get to be part of the national delegation is up to each nation. I only know the U.S., where you have to attend the corresponding ANSI meetings to be able to attend the ISO meetings. Your company or institution has to be willing to sink some bucks into travel since, naturally, these meetings are held all over the world. (For example, Paris, Santa Clara, Kurihama Japan, Singapore, Haifa Israel, Rio de Janeiro, London, etc.) Q. Well, then how do I get the documents, like the MPEG I draft? A. MPEG is a draft ISO standard. It's exact name is ISO CD 11172. The draft consists of three parts: System, Video, and Audio. The System part (11172-1) deals with synchronization and multiplexing of audio-visual information, while the Video (11172-2) and Audio part (11172-3) address the video and the audio compression techniques respectively. You may order it from your national standards body (e.g. ANSI in the USA) or buy it from companies like OMNICOM phone +44 438 742424 FAX +44 438 740154 ------------------------------------------------------------------------------- I.2 | MPEG-Audio ----------------- From: Morten Hjerde <100034.663@compuserve.com> Date: 16 Sep 93 18:53:30 EDT Subject: Re: MPEG-FAQ Audio-part ? 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 Level I, II and III. Level I is the simplest, a subband coder with a psycoacustic model (You'll get the details of this stuff further on). Layer II adds more advanced bit allocation techniques and greater accuracy. Layer III adds a hybrid filterbank and non- uniform qantization. Layer I, II and III gives increasing quality/compression ratios with increasing complexity and demands on processing power. The reason for recommending 3 methods where partly that the testers felt that none of the coders was 100% transparent to all material and partly that the best coder (Layer III) was so computing heavy that it would seriously impact the acceptance of the standard. Q. So I need three decoders? A. Actually I've never seen a Layer III bit stream. Let alone any coder or decoder. The spec says that a valid Layer III decoder shall be able to decode any Layer I, II or III MPEG Audio stream. A Layer II decoder shall be able to decode Layer I and Layer II streams. I would not worry too much about Layer III. Layer II is where its happening and the info in this FAQ is mainly about this coder. 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 psyco- acustic principles. Q. How good is MPEG audio compression? A. MPEG can compress to a bitstream of 32kbit/s to 384kbit/s (Layer II). A raw PCM audio bitstream is about 705kbit/s so this gives a max. compression ratio of about 22. "Normal" compression ratio is more like 1:6 or 1:7. If you think that this is not much please remember that unlike video we are talking about no perceivable quality loss here! 96kbit/s is considered transparent for most practical purposes. This means that you will not notice any difference between the original and the compressed signal for rock'n roll or "popular music" (well, I don't anyway). For more demanding stuff like piano concerts and such you will need to go to 128kbit/s. 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 quanization 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 psyco- acustics that deals with the way the human brain perceives sound. And MPEG uses psycoacustic 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 coder 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 1000Hz 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. I a real-life situation you have sounds in most bands and the masking effects are additive. In addition the coder considers the sensivity 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 psycoacustic properties. In MPEG layer II, each subband is 625Hz wide. It would been better if the subbands where narrower in the low frequency range and wider in the high frequency range. To do this you need complex filters. To keep the filters simple they chose to add FFT in parallel with the filtering and use the spectral components from the FFT as additional information to the coder. This way you get higher resolution in the low frequencies where the ear is more sensitive. 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 have a lot of redundancy between channels. The last step before formatting is 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 II the coder works on 23 ms of sound (1152 samples) at a time. For some material the 23 ms time-window can be a problem. This is normally in a situation with transients where there are large differences in sound level over the 23 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 III addresses this problem specifically. Q. How does MPEG affect other systems like Dolby Surround? A. MPEG does not affect systems like Dolby Surround or Dolby Pro-Logic. Q. What is the hardware demands? A. According to my informations Layer III needs about 20MIPS per channel for real-time coding. This means a real fast DSP. Layer II on the other hand needs only a simple DSP like for example the AD2015 that can be had for a few dollars. The process is asymmetrical, much more processing is needed on the coding side. A decoder could be made to work without hardware assistance on a decent computer. Q. Who are using MPEG? A. Philips uses MPEG for their new "digital video" CD's. They say they will start shipping movies and music videos on CD's for their CD-I player by the end of this year. MPEG is accepted by Eureka-147. That means that when digital radio broadcasts starts in Europe a couple of years from now, you will receive MPEG coded audio. Q. What sampling frequencies do MPEG work with? A. You can have 48kHz, (used in professional sound equipment), 44,1kHz (used in consumer equipment like CD-audio) or 32kHz (used in some communications equipment). Q. How many audio channels? A. MPEG I allows for two audio channels. These can be either single (mono) dual (two mono channels), stereo or joint stereo (intensity stereo or m/s-stereo). 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 II allows for several channels in the same stream. 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 psycoacustic models. Written by Morten Hjerde <100034,663@compuserve.com> ------------------------------------------------------------------------------- I.3 | MPEG-II -------------- From: Chad Fogg Date: Mon, 4 Oct 1993 02:02:58 -0700 Subject: MPEG-2 FAQ -- second installment (draft) This is the second draft installment of the long promised MPEG-2 FAQ. This draft is less than 50% complete. If you have any additional questions or information you would like added, please E-mail to: cfogg@cdac.com --CF Herein is not the official opionions of the MPEG "committee" (MPEG opinions are self-cancelling---linear superposition theory). Q. What are the important themes of MPEG? A. [Other than those introduced by Mark Adler...] 1. Application specific. MPEG does not solve everybody's application needs, but offers a syntax that is a good solution for most. MPEG does not, for example, decorrelate energies situated 1/256th of a pixel between a non-linear combination of 1000 frames. The syntax was designed to occupy an optimum between cost and quality ... in other words, between computational complexity (VLSI area, memory size and bandwidth) and compaction (compression) efficiency. 2. The DCT and Huffman algorithms are some of the least significant aspects of the standard, and yet somehow receive the most press coverage. MPEG-2 made its greatest improvements through enhancement of prediction. 3. In the encoding algorithm, you can do what you want as long as the bistreams produced are compliant. There is a huge difference in picture quality between, for example, the test model and real-world propriety implementions of encoding. Q. Can MPEG-1 encode higher rates than 352 x 240? A. Yes. The MPEG-1 syntax permits sampling dimensions as high as 4095 x 4095 x 60 frames per second. The MPEG most people think of as "MPEG-1" is actually a kind of subset known as Constrained Parameters Bitstream (CPB). Q. What are Constrained Parameters Bitstreams? A. CPB are a limited set of sampling and bitrate parameters designed to normalize computational complexity, buffer size, and memory bandwidth while still addressing the widest possible range of applications. CPB limits video to 396 macroblocks (101,376 pixels) per frame. For SIF images this is 352 pixels per line and either 240 or 288 lines per frame depending on whether the frame rate is 25 or 30 frames per second, respectively. The total maximum sampling rate is 3.8 Ms/s (million samples/sec) including chroma. The coded video rate is limited to 1.862 Mbit/sec. In industrial practice, the bitrate is the most often waived parameter of CPB, with rates as high as 6 Mbit/sec in use. Q. Why is Constrained Parameters so important? A. It is an optimum point that allows (just barely) cost effective VLSI implementations in 1992 technology (0.8 microns). It also sets a guarantee of conformance for many decoders. CPB implies a minimum achievable point for both decoders and encoders. Q. Are there ways of getting around constrained parameters bitstreams for SIF class applications and decoders ? A. Yes, some. Remember that CPB limits frames to 396 macroblocks (as in 352 x 288 SIF frames). 416 x 240 x 24 Hz sampling rates are still within the constraints, but this only aids NTSC displays. Deviating from 352 samples/line could throw off many decoder implementations that have limited horizontal sample rate conversion modes (doubling, e.g. 352 to 704 samples/line via binary taps). Also remember that the 1.86 Mbit/sec limit is often ignored in real life. Q. What is MPEG-2 Video Main Profile and Main Level? A. MPEG-2 Video Main Level is analogous to MPEG-1's CPB, with sampling limits at CCIR 601 parameters (720 x 480 x 30 Hz). Profiles limit syntax (i.e. algorithms), whereas Levels limit parameters (sample rates, frame dimensions, coded bitrates, etc.). Together, Video Main Profile and Main Level (abbreviated as MP@ML) normalize complexity within feasible limits of 1994 VLSI technology (0.5 micron), yet still meet the needs of the majority of application users. Level Max. frame Pixels/ Max. DC Significance sample size sec bitrate bits --------- ---------- ------- ------- ---- -------------------------- Low 352 x 288 3.05 M 4 Mb/s 8,9,10 CIF, consumer tape equiv. Main 720 x 480 10.40 M 15 Mb/s 8,9,10 CCIR 601, studio TV High 1440 1440 x 1152 47.00 M 60 Mb/s 4x 601, consumer HDTV High 1920 x 1080 62.70 M 80 Mb/s production SMPTE 240M std Note 1: pixel rate and luminance (Y) sample rate are equivalent. 2: Low Level is similar MPEG-1's Constrained Parameters Bitstreams. Profile B pictures? Syntax Comments ------- ----------- ------------------------------------------------ Simple No Intended for software applications, perhaps CATV Main Yes Most decoder chips, CATV, satellite. 95% of users. Main+ Yes Main with Spatial scalability Next Yes Main+ with 4:2:2 marcoblocks Profile and Level combinations Level Profile Low Main High 1440 High ------ ------------ ---------------- ---------------- ---------------- Simple Teleconfer. CATV HDTV teleconf. Not allowed Main Not allowed CATV, DBS HDTV broadcast Main+ HDTV simulcast Next [Subject to change at whim of MPEG Requirements sub-group] Q. Is it MPEG-2 (arabic numbers) or MPEG-II (roman)? A. Committee insiders most often use the arabic notation with the hyphen, e.g. MPEG-2. Only the most retentive use the official designation: Phase 2. In fact, M.P.E.G. itself is a nickname. The official name is: ISO/IEC JTC1 SC29 WG11. The militaristic lingo has so far managed to keep the enemy (DVI) confused and out of the picture. ISO: International Organization for Standardization IEC: Interntional Electrotechnical Commission JTC1: Joint Technical Committee 1 SC29: Sub-committee 29 WG11: Work Group 11 (moving pictures with... uh, audio) Q. Why MPEG-2? Wasn't MPEG-1 enough? A. MPEG-1 was optimized for CD-ROM or applications at about 1.5 Mbit/sec. Video was strictly non-interlaced (i.e. progressive). The international co-operation had executed so well for MPEG-1, that the committee began to address applications at broadcast TV sample rates using the CCIR 601 recommendation (720 samples/line by 480 lines per frame by 30 frames per second... or about 15.2 million samples/sec including chroma) as the reference. Unfortunately, today's TV scanning pattern is interlaced. This introduces a duality in block coding: do local redundancy areas (blocks) exist exclusively in a field or a frame... (or a particle or wave) ? The answer of course is that some blocks are one or the other at different times, depending on motion activity. The additional man years of experimentation and implementation between MPEG-1 and MPEG-2 improved the method of block-based transform coding. Q. How do MPEG and JPEG differ? A. The most fundamental difference is MPEG's use of block-based motion compensated prediction (MCP)---a general method falling into the temporal DPCM category. The second most fundamental difference is in the target application. JPEG adopts a general purpose philosophy: independence from color space (up to 255 components per frame) and quantization tables for each component. Extended modes in JPEG include two sample precisions (8 and 12 bit sample accuracy), combinations of frequency progessive, spatially progressive, and amplitude progressive scanning modes. Color independence is made possible thanks to downloadable Huffman tables. Since MPEG is targeted for a set of specific applications, there is only one color space (4:2:0 YCbCr), one sample precision (8 bits), and one scanning mode (sequential). Luminance and chrominance share quantization tables. The range of sampling dimensions are more limited as well. MPEG adds adaptive quantization at the macroblock (16 x 16 pixel area) layer. This permits both smoother bit rate control and more perceptually uniform quantization throughout the picture and image sequence. Adaptive quantization is part of the JPEG-2 charter. MPEG variable length coding tables are non-downloadable, and are therefore optimized for a limited range of compression ratios appropriate for the target applications. The local spatial decorrelation methods in MPEG and JPEG are very similar. Picture data is block transform coded with the two-dimensional orthanormal 8x8 DCT. The resulting 63 AC transform coefficients are mapped in a zig-zag pattern to statistically increase the runs of zeros. Coefficients of the vector are then uniformily scalar quantized, run-length coded, and finally the run-length symbols are variable length coded using a cannonical (JPEG) or modified Huffman (MPEG) scheme. Global frame redundancy is reduced by 1-D DPCM of the block DC coefficients, followed by quantization and variable length entropy coding. MCP DCT ZZ Q Frame -> 8x8 spatial block -> 8x8 frequency block -> Zig-zag scan -> RLC VLC quanitzation -> run-length coding -> variable length coding. The similarities have made it possible for the development of hard-wired silicon that can code both standards. Even microcoded architectures can better optimize through hardwired instruction primitives or functional blocks. There are many additional minor differences. They include: 1. DCT and quantization precision in MPEG is 9-bits since the macroblock difference operation expands the 8-bit signal precision by one bit. 2. Quantization in MPEG-1 forces quantized coefficients to become odd values (oddification). 3. JPEG run-length coding produces run-size tokens (run of zeros, non-zero coefficient magnitude) whereas MPEG produces fully concatenated run-level tokens that do not require magnitude differential bits. 4. DC values in MPEG-1 are limited to 8-bit precision (a constant stepsize of 8), whereas JPEG DC precision can occupy all possible 11-bits. MPEG-2, however, re-introduced extra DC precison. Q. What happened to MPEG-3? A. MPEG-3 was to have targeted HDTV applications with sampling dimensions up to 1920 x 1080 x 30 Hz and coded bitrates between 20 and 40 Mbit/sec. It was later discovered that with some (compatible) fine tuning, MPEG-2 and MPEG-1 syntax worked very well for HDTV rate video. The key is to maintain an optimal balance between sample rate and coded bit rate. Also, the standardization window for HDTV was rapidly closing. Europe and the United States were on the brink of committing to analog-digital subnyquist hybrid algorithms (D-MAC, MUSE, et al). European all-digital projects such as HD-DIVINE and VADIS demonstrated better picture quality with respect to bandwidth using the MPEG syntax. In the United States, the Sarnoff/NBC/Philips/Thomson HDTV consortium had used MPEG-1 syntax from the beginning, and with the exception of motion artificats (due to limited search range in the encoder), was deemed to have the best picture quality of all three digital proponents. HDTV is now part of the MPEG-2 High-1440 Level and High Level toolkit. Q. What is MPEG-4? A. MPEG-4 targets the Very Low Bitrate applications defined loosly as having sampling dimensions up to 176 x 144 x 10 Hz and coded bit rates between 4800 and 64,000 bits/sec. This new standard would be used, for example, in low bit rate videophones over analog telephone lines. This effort is in the very early stages. Morphology, fractals, model based, and anal retentive block transform coding are all in the offering. MPEG-4 is now in the application identification phase. Q. Where can I get a copy of the latest MPEG-2 draft? A. Contact your national standards body (e.g. ANSI Sales in NYC for the U.S.) Q. What is the latest working drafts of MPEG-2 ? A. The latest versions of video (version 4), and systems were produced at the Brusells meeting (September 10, 1993). The latest audio working draft was produced in New York (July 1993). MPEG-2 Video, Audio, and Systems will reach CD at the November 1994 Seoul, Korea meeting. Q. What is the latest version of the MPEG-1 documents? A. Systems (ISO/IEC IS 11172-1), Video (ISO/IEC IS 11172-2), and Audio (ISO/IEC IS 11172-3) have reached the final document stage. Part 4, Conformance Testing, is currently a CD. Q. What is the evolution of standard documents? A. In chronological order: New Proposal (NP) Working Draft (WD) Committee Draft (CD) Draft International Standard (DIS) International Standard (IS) Q. When will an MPEG-2 decoder chip be available? A. Several chips will be sampling in late 1993. For reasons of economy and scale in the cable TV application, all are single-chip (not including DRAM and host CPU/controller) implementations. They are: SGS-Thomson STi-3500 first MPEG-2 chip on market multi-tap binary horizontal sample rate convertor. pan & scanning support for 16:9 requires external, dedicated microcontroller (8 bit) 8-bit data bus, no serial data bus. LSI Logic L64112 successor (pin compatible) serial bus, 15 Mbit coded throughput. smaller pin-count version due soon. C-Cube CL-950 successor (?) In 1994, we can look forward to: Pioneer single-chip MPEG-2 successor to CD-1100 MPEG-1 chip set. IBM single-chip decoder. Q. Are there single chip MPEG encoders? A. Yes, the C-Cube CL-4000 is the only single-chip, real-time encoder that can process true MPEG-1 SIF rate video. Single chip for +/- 15 pel motion estimation at SIF rates (352x240x30 Hz) Two chips for +/- 32 pel at SIF rates (hierarchical) 5 or 6 chips for MPEG-2 at CCIR 601 rates (704 x 480 x 30 Hz) Highly microcoded architecture. Can code both H.261 and JPEG. Implements high picture quality microcode programs. [more details from CICC'93 and HotChips '93 conference to be included] IBM and SGS-Thomson plan to introduce more hard-wired, multichip solutions in 1994. Q. What about MPEG-1 decoder chips? A. By implication of MPEG-2 Conformace requirements, all MPEG-2 decoders are required to decode MPEG-1 bitstreams as well. These chips, however, are strictly MPEG-1: C-Cube CL-450 SIF rates. Single-chip. Has on-board CPU. SGS-Thomson 3400 SIF rates. Single-chip. Hardwired. Motorola MCD250 SIF rates. Single-chip. LSI 641172 CCIR 601 rates. Single-chip. Systems packet decoder on-chip. Q. What about audio chips? A. To date, only Layer I and Layer II have been implemented in dedicated (ASIC) silicon: Motorola MCD260 TI 32010something (hardwired with systems parsing) LSI L64111 (hardwired w/CPU) with systems parsing. GCA/ASCII ? Crystal Semiconductor ? Dolby AC-3 MPEG NY disclosure claimed to be less computationally intensive Zoran, GI working on own DSP-like dedicated chips. Q. Will there be an MPEG video tape format? A. There is a consortium of companies (Philips, JVC, Sony, Matushista, et al) developing a metal particle based 6 milimeter consumer digital video tape format. It will initially use more JPEG-like independent frame compression for cheap encoding of source analog (NTSC, PAL) video. The consequence of course is less efficient use of bandwidth ( 25 Mbit/sec for the same quality acheived at 6 Mbit/sec with MPEG). Pre-compressed video from broadcast sources will be directly recorded to tape and "passed-through" as a coded bitstream to the video decompression "box" upon playback. Q. What do B-frames buy you? A. Since bi-directional marcoblock predictions are an average of two maroblocks blocks, noise is reduced at low bit rates. At nominal MPEG-1 video (352 x 240 x 30, 1.15 Mbit/sec) rates, it is said that B-frames improves SNR by as much as 2 dB. (0.5 dB gain is usually considered worth-while in MPEG). However, at higher bit rates, B-frames become less useful since they inherently do not contribute to the progressive refinement of an image sequence (i.e.not used as prediction by subsequent coded frames). Regardless, B-frames are still politically controversial. Q. Why do some people hate B-frames? A. Computational complexity, bandwidth, delay, and picture buffer size are the four B-frame Pet Peeves. Computational complexity is increased since a some macroblock modes require averaging between two macroblocks. Worst case, memory bandwidth is increased an extra 16 MByte/s (601 rate) for this extra prediction. An extra picture buffer is needed to store the future prediction reference (bi-directionality). Finally, extra delay is introduced in encoding since the frame used for backwards prediction needs to be transmitted to the decoder before the intermediate B-pictures can be decoded and displayed. Cable television (e.g. General Instruments) have been particularly adverse to B-frames since the extra picture buffer pushes the decoder DRAM memory requirements past the magic 8-Mbit (1 Mbyte) threshold into the realm of 16 Mbits (2 MByte) for CCIR 601 frames (704 x 480), yet not for lowly 352 x 480. However, cable does not realize that DRAM does not come in convenient high-volume (low cost) 8-Mbit packages as 16-Mbit does. In a few years, the cost differences between 16 Mbit and 8 Mbit will become insignificant compared to the gain in compression. For the time being, cable boxes will start with 8-Mbit and allow future drop-in upgrades to 16-Mbit. The early market success of B-frames seem to have been determined by a fire at a Japanese DRAM plant. Q. How do MPEG and H.261 differ? A. H.261 was targeted for teleconferencing applications where motion is naturally more limited. Motion vectors are restricted to a range of +/- 15 pixels. Accuracy is reduced since H.261 motion vectors are restricted to integer-pel accuracy. Other syntactic differences include: no B-pictures, different quantization method. H.261 is also known as P*64. "P" is an integer number meant to represent multiples of 64kbit/sec. In the end, this nomenclature probably won't be used as many services other than video will adopt the philosophy of arbitrary B channel (64kbit) bitrate scalability. Q. Is H.261 the de facto teleconferencing standard? A. Not exactly. To date, about seventy percent of the industrial teleconferencing hardware market is controlled by PictureTel of Mass. The second largest market controller is Compression Labs of Silicon Valley. PictureTel hardware includes compatibility with H.261 as a lowest common denominator, but when in comminication with other PictureTel hardware, it can switch to a mode superior at low bit rates (less than 300kbits/sec). In fact, over 2/3 of all teleconfercing is done at two-times switched 56 channel (~P = 2) bandwidth. Long distance ISDN ain't cheap. In each direction, video and audio are coded at an aggregate of 112 kbits/sec (2*56 kbits/sec). The PictureTel proprietary compression algorithm is acknowledged to be a combination of spatial pyramid, lattice vector quanitzer, and an unidentified entropy coding method. Motion compensation is considerably more refined and sophisticated than the 16x16 integer-pel block method specified in H.261. The Compression Labs proprietary algorithm also offers significant improvement over H.261 when linked to other CLI hardware. Currently, ITU-TS (International Telecommunications Union--Teleconferencing Sector), formerly CCITT, is quietly defining an improvement to H.261 with the participation of industry vendors. Q. Where will be see MPEG in everyday life? A. Just about wherever you see video today. DBS (Direct Broadcast Satellite) The Hughes/USSB DBS service will use MPEG-2 video and audio. Thomson has exclusive rights to manufacture the decoding boxes for the first 18 months of operation. No doubt Thomson's STi-3500 MPEG-2 video decoder chip will be featured. Hughes/USSB DBS will begin service in North America in April 1994. Two satellites at 101 degrees West will share the power requirements of 120 Watts per 27 MHz transponder. Multi-source channel rate control methods will be employed to optimally allocate bits between several programs on one data carrier. An average of 150 channels are planned. CATV (Cable Television) Despite conflicting options, the the cable industry has more or less settled on MPEG-2 video. Audio is less than settled. For example, General Instruments (the largest U.S. consumer cable set-top box manufacturer) have announced the planned use of the Dolby AC-3 audio algorithm. The General Instruments DigiCipher I video syntax is similar to MPEG-2 syntax but uses smaller macroblock predictions and no B-frames. The DigiCipher II specification will include modes to support both the GI and full MPEG-2 Video Main Profile syntax. Services such as HBO will upgrade to DigiCipher II in 1994. HDTV The U.S. Grand Alliance, a consortium of companies that formely competed for the U.S. terrestrial HDTV standard, have already agreed to use the MPEG-2 Video and Systems syntax---including B-pictures. Both interlaced (1440 x 960 x 30 Hz) and progressive (1280 x 720 x 60 Hz) modes will be supported. The Alliance must then settle upon a modulation (QAM, VSB, OFDM), convolution (MS or Viterbi), and error correction (RSPC, RSFC) specification. In September 1993, the original consortium of European companies supporting D-MAC switched to MPEG-2. The only remaining analog or digital-analog hybrid system left in the world is NHK's MUSE. Q. What did MPEG-2 add to MPEG-1 in terms of syntax/algorithms ? A. Here is a brief summary: More aspect ratios. A minor, yet neccessary part of the syntax. Horizontal and vertical dimensions are now required to be a multiple of 16 in frame coded pictures, and the vertical dimension must be a multiple of 32 in field coded pictures. 4:2:2 and 4:4:4 macroblocks were added in the Next profiles. Syntax can now signal frame sizes as large as 16383 x 16383. Syntax signals source video type (NTSC, PAL, SECAM, MAC, component) to help post-processing and display. Source video color primaries (609, 170M, 240M, D65, etc.) and opto- electronic transfer characteristics (709, 624-4M, 170M etc.) can be indicated. Four scalable modes [see scalable section below] All MPEG-2 motion vectors are half-pel accuracy. DC precision can be user-selected as 8, 9, 10, or 11 bits. Concealment motion vectors were added to I-pictures in order to increase robustness from bit errors since I pictures are the most critical and sensitive in a group of pictures. A non-linear macroblock quantization factor that results in a more dynamic step size range, from 0.5 to 56, than in MPEG-1 (1 to 32). New Intra-VLC table for dct_next_coefficient (AC run-level events) that is more geared towards I-frame probability distribution. EOB is 4 bits. The old tables are still included. Alternate scanning pattern that (supposedly) improves entropy coding performance over the original Zig-Zag scan used in H.261, JPEG, and MPEG-1. The extra scanning pattern is geared towards interlaced video. Syntax to signal 3:2 pulldown process (repeat_field_first flag) Syntax flag to signal chrominance post processing type (4:2:0 to 4:2:2 upsampling conversion) Progressive and interlaced frame coding Syntax to signal source composite video characteristics useful in post-processing operations. (v-axis, field sequence, sub_carrier, phase, burst_amplitude, etc.) Pan & scanning syntax that tells decoder how to, for example, window a 4:3 image within a wider 16:9 aspect ratio image. Vertical pan offset has 1/16th pixel accuracy. Macroblock stuffing is now illegal in MPEG-2 (hurray!!) Two line modes (interlaced and progressive) for DCT operation. Now only one run-level escape code code (24-bits) instead of the single (20-bits) and double escape (28-bits) in MPEG-1. Improved mismatch control in quantization over the original oddification method in MPEG-1. Now specifies adding or subtracting one to the 63rd AC coefficient depending on parity of summed quantized coefficients. Many additional prediction modes (16x8 MC, field MC, Dual Prime) and, correspondingly, macroblock modes. Overall, MPEG-2's greatest compression improvements over MPEG-1 are: prediction modes, Intra VLC table, DC precision, non-linear macroblock quant. Implementation improvements, well,.. uh... macroblock stuffing was eliminated. Q. What are the scalable modes of MPEG-2? A. Scalable video is permitted only in the Main+ and Next profiles. Currently, there are four scalable modes in the MPEG-2 toolkit. These modes break MPEG-2 video into different layers (base, middle, and high layers) mostly for purposes of prioritizing video data. For example, the high priority channel (bitstream) can be coded with a combination of extra error correction information and decreased bit error (i.e. higher Carrier-to-Noise ratio or signal strength) than the lower priority channel. Another purpose of scalablity is complexity division. For example, in HDTV, the high priority bitstream (720 x 480) can be decoded under noise conditions were the lower priority (1440 x 960) cannot. This is "graceful" degradation. By the same division however, a standard TV set need only decode the 720 x 480 channel, thus requiring a less expensive decoder than a TV set wishing to display 1440 x 960. This is simulcasting. A brief summary of the MPEG-2 video scalability modes: Spatial Scalablity-- Useful in simulcasting, and for feasible software decoding of the lower resoultion, base layer. This spatial domain method codes a base layer at lower sampling dimensions (i.e. "resolution") than the upper layers. The upsampled reconstructed lower (base) layers are then used as prediction for the higher layers. Data Partitioning-- Similar to JPEG's frequency progressive mode, only the slice layer indicates the maximum number of block transform coefficients contained in the particular bitstream (known as the "priority break point"). Data partitioning is a frequency domain method that breaks the block of 64 quantized transform coefficients into two bitstreams. The first, higher priority bitstream contains the more critical lower frequency coefficients and side informations (such as DC values, motion vectors). The second, lower priority bitstream carries higher frequency AC data. SNR Scalability-- Similar to the point transform in JPEG, SNR scalability is a spatial domain method where channels are coded at identical sample rates, but with differing picture quality (through quantization step sizes). The higher priority bitstream contains base layer data that can be added to a lower priority refinement layer to construct a higher quality picture. Temporal Scalability--- A temporal domain method useful in, e.g., stereoscopic video. The first, higher priority bitstreams codes video at a lower frame rate, and the intermediate frames can be coded in a second bitstream using the first bitstream reconstruction as prediction. In sterescopic vision, for example, the left video channel can be prediction from the right channel. Other scalability modes were experimented with in MPEG-2 video (such as Frequency Scalability), but were eventually dropped in favor of methods that demonstrated similar quality and greater simplicity. Q. What is all the fuss with cositing of chroma components? A. It is important to properly co-site chroma samples, otherwise chroma shifting may result. [insert data from usenet posting] Q. What is the reasoning behind MPEG syntax symbols? A. Here are some of the Whys and Wherefores of MPEG symbols: Start codes These 32-bit byte-aligned codes provide a mechanism for cheaply searching coded bitstreams for commencment of various layers of video without having to actually parse or decode. Start codes also provide a mechanism for resynchronization in the presense of bit errors. Coded block pattern (CBP --not to be confused with Constrained Parameters!) When the frame prediction is particularly good, the displaced frame differencene (DFD, or prediction error) tends to be small, often with entire block energy being reduced to zero after quantization. This usually happens only at low bit rates. Coded block patterns prevent the need for transmitting EOB symbols in those zero coded blocks. DCT_coefficient_first Each intra coded block has a DC coefficient. Inter coded blocks (prediction error or DFD) naturally do not since the prediction error is the first derivative of the video signal. With coded block patterns signalling all possible non-coded block patterns, the dct_coef_first mechanism assigns a different meaning to the VLC codeword that would otherwise represent EOB as the first coefficient. End of Block Saves unecessary run-length codes. At optimal bitrates, there tends to be few AC coefficients concentrated in the early stages of the zig-zag vector. In MPEG-1, the 2-bit length of EOB implies that there is an average of only 3 or 4 non-zero AC coefficients per block. In MPEG-2 Intra (I) pictures, with a 4-bit EOB code, this number is between 9 and 16 coefficients. Since EOB is required for all coded blocks, its absense can signal that a syntax error has occurred in the bitstream. Macroblock stuffing A genuine pain for VLSI implementations, macroblock stuffing was introduced to maintain smoother, constant bitrate control in MPEG-1. However, with normalized complexity measures and buffer management performed on a a priori (pre-frame, pre-slice, and pre-macroblock) basis in the MPEG-2 encoder test model, the need for such localized smoothing evaportated. Stuffing can be acheived through virtually unlimited slice start code padding if required. A good rule of thumb: if you find yourself often using stuffing more than once per slice, you probably don't have a very good rate control algorithm. Anyway, marcoblock stuffing is now illegal in MPEG-2. MPEG's modified Huffman VLC tables The VLC tables in MPEG are not Huffman tables in the true sense of Huffman coding, but are more like the tables used in Group 3 fax. They are entropy constrained, that is, non-downloadable and optimized for a limited range of bit rates (sweet spots). With the acception of a few codewords, the larger tables were carried over from the H.261 standard of 1990. MPEG-2 added an "Intra table". Note that the dct_coefficient tables assume positive/negative coefficient pmf symmetry. Rate control and adaptive quantization TM rate control: The MPEG-2 Test Model rate control method offers a dramatic improvement to the Simulation Model method used for MPEG-1. The fundamental philosophical difference is: normalized complexity measurements. Rate control and adaptive quantization are divided into three steps: Step One: Complexity Estimation Global complexity initial values Says "I frame is more important than P frame" because its got a bigger complexity constant. Normalized activity measures Target bit rates Step 3 is controversial But just when people had spent several nervous months reverse engineering Thomson's step 3, Thomson disclosed the method in a patent. Step Two: Rate Control Step Three: Adaptive Quantization Block based coding has large address contigoius that makes page mode addressing ameinable to MPEG. coded length is proportional These seemingly small costs should really be incorperated into the rate control model. MPEG-2 Test model is frozen as v5b Test model was not by any strech of the imagination meant to be the show-stopping, best algorithm. It was designed to excersize the syntax, verify the algorithm, test the *relative* performance of proposals in a way that could be duplicated by co-experimentors in a timely fashion. Otherwise there would be more endless debates about model interpretation than actual time spent in verification. Improvements to SM3 for MPEG-1 video Use TM rate control MPEG for the data compression expert MPEG-2 profiles and toolkits Implementation requirements: Profile Total DRAM DRAM data bus width ---------- ---------- ------------------- MPEG-1 CPB 4 Mbit 16 bits @ 80 ns MPEG-2 MP@ML 16 Mbit 64 bits @ 80 ns 70 or 80ns (40-50 MHz clock, 3 clocks per fast page mode word transfer). Cheap memory whose prices have been driven down by quantity. This is where the original DVI algorithm made a mistake. It required expesnive VRAM chips. DRAM chips have slower throughput, and require blocks of near-contigures address. DRAM memory locations are broken into rows and columns. Q. Is exhuastive search "optimal" ? A. Definately not in the context of block-based MCP. Since one motion vector represents the prediction of 256 pixels, divergent pixels within the macroblock are misrepresented by the "global" vector. This leads back to the general philosophy of block-based coding as an approximation technique. Exhuastive search may find blocks with the least distortion (displaced frame difference) but will not produce motion vectors with the least entropy. Q. What is a good motion estimation method, then? When shopping for motion vectors, the three basic characteristics are: Search range, search pattern, and matching criteria. Search pattern has the greatest impact on finding the best vector. Hierarchical search patterns first find the best match between downsampled images of the reference and target pictures and then refine the vector through progressively higher resolutions. [Accuracy vs. Ambiguity] Some ways of solving problem (Gary Sullivan--ICASSP '93), but not syntacitally compatible. Q. What is MPEG 1.5 and MPEG++ ? A. MPEG-1.5 was not exactly a proprietary twist in terms of syntax, but operating parameters. Again, people (erronously) consider MPEG-1 to be limited to SIF rates (352 x 240 x 30 Hz). After interrogation, most MPEG 1.5 proponents will confess that MPEG 1.5 is simply MPEG-1 at CCIR 601 rates (704 x 480 x 30 Hz) and that it may or may not include B-frames. MPEG++ is/was proprietary only at the transport layer (compatible syntax at the video layer). This name was coined by the Sarnoff/Philips/ RCA/Thomson HDTV consortium. Both MPEG 1.5 and MPEG++ are now moot since MPEG-2 Simple profile and MPEG-2 Systems layer fill these potentials, respectively. Q. What about MPEG-2 audio? A. MPEG-2 audio attempts to maintain as much compatibility with MPEG-1 audio syntax as possible, while adding discrete surround-sound channels to the orignal MPEG-1 limit of 2 channels (Left, Right or matrix center and difference). The main channels (Left, Right) in MPEG-2 audio will remain backwards compatible, whereas new coding methods and syntax will be used for the surround channels. A total of 5.1 channels are included that consist of the two main channels (L,R), two side/rear, center, and a 100 Hz special effects channel (hence the ".1" in "5.1"). At this time, non-backwards compatible (NBC) schemes are being considered as an ammedment to the MPEG-2 audio standard. One such popular system is Dolby AC-3. MPEG-2 systems Transport Program ATM PES Q. What are the typical MPEG-2 bitrates and picture quality? [examples of typical frame sizes in bits] Picture type I P B Average MPEG-1 SIF @ 1.15 Mbit/sec 150,000 50,000 20,000 38,000 MPEG-2 601 400,000 200,000 80,000 130,000 @ 4.00 Mbit/sec Note: parameters assume Test Model for encoding, I frame distance of 15 (N = 15), and a P frame distance of 3 (M = 3). Of course with scene changes and more advanced encoder models found in any real-world implementation, these numbers can be very different. Q. At what bitrates is MPEG-2 video optimal? A. The Test subgroup has defined a few examples: "Sweet spot" sampling dimensions and bit rates for MPEG-2: Dimensions Coded rate Comments ------------- ---------- ------------------------------------------- 352x480x24 Hz 2 Mbit/sec Half horizontal 601. Looks almost NTSC (progressive) broadcast quality, and is a good (better) substitute for VHS. Intended for film src. 544x480x30 Hz 4 Mbit/sec PAL broadcast quality (nearly full capture (interlaced) of 5.4 MHz luminance carrier). Also 4:3 image dimensions windowed within 720 sample/line 16:9 aspect ratio via pan&scan. 704x480x30 Hz 6 Mbit/sec Full CCIR 601 sampling dimensions. (interlaced) [these numbers subject to change at whim of MPEG Test subgroup] Q. How does MPEG video really compare to TV, VHS, laserdisc ? A. VHS picture quality can be acheived for source film video at about 1 million bits per second. It is very difficult to objectively compare MPEG to VHS. The response curve of VHS places -3 dB at around 2 MHz of analog luminance bandwidth (equivalent to 200 samples/line). VHS chroma is considerably less dense in the horizontal direction than MPEG source video (compare 80 samples/line to 176!). From a sampling density perspective, VHS is superior only in the vertical direction (480 lines compared to 240)... but when taking into account interfield tape crosstalk and the Kell factor, not by all that much. VHS is prone to timing errors (which can be improved with time base correctors), whereas digital video is fully discretized. Pre-recorded VHS is typically recorded at very high duplication speeds (5 to 15 times real time playback), which leads to further shortfalls for the format that has been with us since 1977. Broadcast NTSC quality can be approximated at about 3 Mbit/sec, and PAL quality at about 4 Mbit/sec. Of course, sports sequences with complex spatial-temporal activity need more like 5 and 6 Mbit/sec, respectively. Laserdisc is a tough one to compare. Disc is composite video (NTSC or PAL) with up to 425 TVL (or 567 samples/line) response. Thus it could be said laserdisc has 567 x 480 x 30 Hz "resolution". The carrier-to-noise ratio is typically better than 48 dB. Timing is excellent. Yet some of the clean characteristics of laserdisc can be acheived at 1.15 Mbit/sec (SIF rates), especially for those areas of medium detail (low spatial activity) in the presense of uniform motion. This is why some people say MPEG-1 video at 1.15 Mbit/sec looks almost as good as Laserdisc or Super VHS. Regardless of the above figures, those clever proprietary encoding algorithms can push these bitrates even lower. Q. Why film does so well with MPEG ? A. Several reasons, really: 1) The frame rate is 24 Hz (instead of 30 Hz) which is a savings of some 20%. 2) the film source video is inherently progressive. Hence no fussy interlaced spectral frequencies. 3) the pre-digital source was severly oversampled (compare 352 x 240 SIF to 35 milimeter film at, say, 3000 x 2000 samples). This can result in a very high quality signal, whereas most video cameras do not oversample, especially in the vertical direction. 4) Finally, the spatial and temporal modulation transfer function (MTF) characteristics (motion blur, etc) of film are more ameniable to the transform and quantization methods of MPEG. Q. What is the best compression ratio for MPEG ? A. The MPEG sweet spot is about 1.2 bits/pel Intra and .35 bits/pel inter. Experimentation has shown that intra frame coding with the familiar DCT-Quantization-Entropy hybrid algorithm acheives optimal performance at about an average of 1.2 bits/sample or about 6:1 compression ratio. Below this point, artifacts become noticable. Q. What are some pre-processing enhancements ? Adaptive de-interlacing: This method maps interlaced video from a higher sampling rate (e.g 720 x 480) into a lower rate, progressive format (352 x 240). The most basic algorithm measures the variance between two fields, and if the variance is small enough, uses an average of both fields to form a frame macroblock. Otherwise, a field area from one field (of the same parity) is selected. More clever algorithms are much more complex than this, and may involve median filtering, and multirate/ multidimensional tools. Pre-anti-aliasing and Pre-blockiness reduction: A common method in still image coding is to pre-smooth the image before compression encoding. For example, if pre-analysis of a frame indicates that serious artifacts will arise if the picture were to be coded in the current condition, a pre-anti-aliasing filter can be applied. This can be as simple as having a smoothing severity proportional to the image activity. The pre-filter can be global (same smoothing factor for whole image) or locally adaptive. More complex methods will use multirate/multidimensional tools again. The basic idea of multidimensional/multirate pre-processing is to apply source video whose resolution (sampling density) is greater than the target source and reconstruction sample rates. This follows the basic principles of oversampling, as found in A/D converters. Most detail is contained in the lower harmonics anyway. Sharp-cut off filters are not widely practiced, so the "320 x 480 potential" of VHS is never truly realized. Q. Why use these "advanced" pre-filtering techniques? A. Think of the DCT and quantizer as an A/D convertor. Think of the pre-filter as the required anti-alias prefilter found before every A/D. The big difference of course is that the DCT quantizer assigns a varying number of bits per sample (transform coefficient). Judging on the normalized activity measured in the pre-analysis stage of video encoding, and the target buffer size status, you have a fairly good idea of how many bits can be spared for the target macroblock, for instance. Other pre-filtering techniques mostly take into account: texture patterns, masking, edges, and motion activity. Many additional advanced techniques can be applied at different immediate layers of video encoding (picture, slice, macroblock, block, etc.). Q. What are some advanced encoding methods? Quantizer feedback [Thomson patent] Horizontal variance motion vector cost: this is true for any syntax elements, really. Signalling a macroblock quantization factor or a large motion vector differential can cost more than making up the difference with extra quantized DFD (prediction error) bits. The optimum can be found with, for example, a Lagrangian process. In summary, any compression system with side information, there is a optimum point between signalling overhead (e.g. prediction) and coding prediction error. Post-processing Interpolation methods (Gersho-Wu) Convex hull projections Some ICASSP '93 papers, etc. Conformance vs. post-processing: Post-processing makes judging decoder output for conformace testing impossible. Q. What are some journals on related MPEG topics ? A. IEEE Multimedia IEEE Transactions on Consumer Electronics IEEE Transactions on Broadcasting IEEE Transactions on Circuits and Systems for Video Technology Advanced Electronic Imaging Electronic Engineering Times (EE Times) IEEE Int'l Conference on Acoustics, Speech, and Signal Processing (ICASSP) International Broadcasting Convention (IBC) Society of Motion Pictrures and Television Engineers (SMPTE) SPIE Visual Comminications and Image Processing Q. Can motion vectors be used to measure object velocity? A. Motion vector information cannot be relaibly used as a means of determining object velocity unless the encoder model specifically set out to do so. First, encoder models that optimize picture quality form vectors that typically minimze prediction error and, consequentally, the vectors often do not represent true object translation. Standards convertors that resample one frame rate to another (as in NTSC to PAL) use different methods (field coding, edge detection, et al) that are not concerned with SNR vs bitrate. Secondly, motion vectors are not transmitted for all macroblocks anyway. Q. How do you code interlaced video with MPEG-1 syntax? A. Concatenation of the fields is necessary to maintain syntactic compatibility. Display() function Film source video is simply progressive to start with. (MPEG-2 then offers superior performance through greater DC block precision, non-linear mquant, intra VLC, etc.) Optionally apply pre-processing on the interlaced source video and then concatenate fields to form an interleaved, progressively coded frame. Then, upon display, re-interlace to form two fields. Q. How many cable box alliances are there? A. Many. To start with: Scientific Atlanta, Kaledia, and Silicon Graphics General Instruments and Microsoft Q. What is the rundown on public domain MPEG source software? A. There are two public domain source codes available: Berkeley encoder (v1.1) by Larry Rowe, Ketan Patel, Brian Smith... Log, telescopic, and exhastive search variable rate operation designed for parallel machine operation Loeffler, Lightenberg, Moschytz "Practical fast 1-D DCT algorithms with 11 multipications" from ICCASP-89. Optimized for speed. Stanford encoder (v1.2) by Andy C. Hung Telescopic search SM-3 coding strategy and rate control Chen, Smith, Fralick algorithm or floating point direct matrix multiply. Optimized for flexibility. Stanford decoder does not include display functions. Q. Is MPEG patented? A. Yes. patent pool blocking patents method-specific patents (proprietary algorithms, architectures) Patents, Intellectual Property Rights, and MPEG Q. What are the tell-tale MPEG artifacts? A. If the encoder did its job properly, and the user specified a proper balance between sample rate and bitrate, there shouldn't be any visible artifacts. However, in sub-optimal systems, you can look for: Gibbs phenomenon/Ringing/Aliasing (too few AC bits, not enough pre-filtering) Blockiness (not considering your neighbors before quantizing) Posterization (too few DC bits) Checkerboards (DCT eigenimages as a result of too few AC coefficients) Colorbleeding (not considering color in encoder cost model) Q. What are some myths about MPEG? A. There are two major myths that I am aware of: Block displacements: macroblock predictions are formed out of arbitrary 16x16 areas from previously reconstructed pictures. Many people believe that the prediction macroblocks have boundaries that fall on interchange boundaries (pixel 0, 15, 31, 53... line 0, 15, 31, 53... etc.). In fact, motion vectors represent relative translations with respect to the target reconstruction macroblock co-ordinates. The motion vectors can point to half pixel co-ordinates which requires that the prediction macroblock to be formed via interpolation of pixels. Displaced frame (macroblock) difference construction: the prediction error formed as the difference between the prediction macroblock and source macroblock is coded much like an Intra macroblock. The prediction may come from different locations (B-macroblocks) or fields (MPEG-2), but the DFD is always coded as if part of a progressive I-frame. ..and worst of all... Compression ratios: ----- End of MPEG-2 FAQ Installment No. 2 (September 27, 1993) ----- Copyright Chad Fogg. cfogg@cdac.com ------------------------------------------------------------------------------- From: cfogg@ole.cdac.com (Chad Fogg) Subject: MPEG Press Release -- NY meeting Date: 22 Jul 93 05:31:41 GMT INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND ASSOCIATED AUDIO ISO/IEC JTC1/SC29/WG11 N0500 July 16, 1993 Source: ISO/IEC JTC1/SC29/WG11 ~Title: Press Release (Final) -- MPEG New York Meeting Status: For immediate release Summary This week in New York, at a meeting hosted by Columbia University, the Moving Picture Experts Group (MPEG) completed definition of MPEG-2 Video, MPEG-2 Audio, and MPEG-2 Systems. MPEG therefore confirmed that it is on schedule to produce, by November 1993, Committee Drafts of all three parts of the MPEG-2 Standard, for balloting by its member countries. To ensure that a harmonized solution to the widest range of applications is achieved, MPEG, an ISO/IEC working group designated ISO/IEC JTC1/SC29/WG11, is working jointly with the ITU-TS Study Group 15 "Experts Group for ATM Video Coding." MPEG also collaborates with representatives from other parts of ITU-TS, and from EBU, ITU-RS, SMPTE, and the North American HDTV community. MPEG-2 Video MPEG is developing the MPEG-2 Video Standard, which specifies the coded bit stream for high-quality digital video. As a compatible extension, MPEG-2 Video builds on the completed MPEG-1 Video Standard (ISO/IEC IS 11172-2), by supporting interlaced video formats and a number of other advanced features, including features to support HDTV. As a generic International Standard, MPEG-2 Video is being defined in terms of extensible profiles, each of which will support the features needed by an important class of applications. At the March MPEG meeting in Sydney, the MPEG-2 Main Profile was defined to support digital video transmission in the range of about 2 to 15 Mbits/sec over cable, satellite, and other broadcast channels, as well as for Digital Storage Media (DSM) and other communications applications. Building on this success at this week's New York meeting, MPEG experts from participating countries in Asia, Australia, Europe, and North America further defined parameters of the Main Profile and Simple Profile suitable for supporting HDTV formats. This week the MPEG experts also extended the features of the Main Profile by defining a hierarchical/scalable profile. This profile aims to support applications such as compatible terrestrial TV/HDTV, packet-network video systems, backward-compatibility with existing standards (MPEG-1 and H.261), and other applications for which multi-level coding is required. For example, such a system could give the consumer the option of using either a small portable receiver to decode standard definition TV, or a larger fixed receiver to decode HDTV from the same broadcast signal. This week's accomplishments in New York mean that the technical definition of MPEG-2 Video has been completed. This was a critical milestone, and shows that MPEG-2 Video is on schedule for a Committee Draft in November. MPEG-2 Audio MPEG is developing the MPEG-2 Audio Standard for low bitrate coding of multichannel audio. MPEG-2 Audio coding will supply up to five full bandwidth channels (left, right, center, and two surround channels), plus an additional low frequency enhancement channel, and/or up to seven commentary/multilingual channels. The MPEG-2 Audio Standard will also extend the stereo and mono coding of the MPEG-1 Audio Standard (ISO/IEC IS 11172-3) to half sampling-rates (16 kHz, 22.05 kHz, and 24 kHz), for improved quality for bitrates at or below 64 kbits/s, per channel. This week in New York, MPEG produced an updated version of the MPEG-2 Audio Working Draft, and is on track for achieving a Committee Draft specification by the November MPEG meeting. The MPEG-2 Audio multichannel coding Standard will provide backward-compatibility with the existing MPEG-1 Audio Standard (ISO/IEC IS 11172-3). Together with ITU-RS, MPEG is organizing formal subjective testing of the proposed MPEG-2 multichannel audio codecs and up to three non-backward-compatible (NBC) codecs. The NBC codecs are included in order to determine whether an NBC mode should be introduced as an addendum to the standard. If the results show clear evidence that an NBC mode improves the performance, a formal call for NBC proposals will be issued by MPEG, with a view to incorporate these features in the audio syntax. MPEG-2 Systems MPEG is developing the MPEG-2 Systems Standard to specify coding formats for multiplexing audio, video, and other data into a form suitable for transmission or storage. There are two data stream formats defined: the Transport Stream, which can carry multiple programs simultaneously, and which is optimized for use in applications where data loss may be likely, and the Program stream, which is optimized for multimedia applications, for performing systems processing in software, and for MPEG-1 compatibility. Both streams are designed to support a large number of known and anticipated applications, and they retain a significant amount of flexibility such as may be required for such applications, while providing interoperability between different device implementations. The Transport Stream is well suited for transmission of digital television and video telephony over fiber, satellite, cable, ISDN, ATM, and other networks, and also for storage on digital video tape and other devices. It is expected to find widespread use for such applications in the very near future. The Program Stream is similar to the MPEG-1 Systems standard (ISO/IEC 11172-1). It includes extensions to support new and future applications. Both the Transport Stream and Program Stream are built on a common Packetized Elementary Stream packet structure, facilitating common video and audio decoder implementations and stream type conversions. This is well-suited for use over a wide variety of networks with ATM/AAL and alternative transports. This week in New York, MPEG completed definitions of the features, syntax, and semantics of the Transport and Program Streams, enabling product designers to proceed. Among other items, the Transport Stream packet length was fixed at 188 bytes, including the 4-byte header. This length is suited for use with ATM networks, as well as a wide variety of other transmission and storage systems. MPEG-4 Work on a new MPEG initiative for very low bitrate coding of audiovisual programs has been approved by unanimous ballot of all national bodies of ISO/IEC JTC1. This work will begin officially at the next MPEG meeting in Brussels in September 1993. It is scheduled to result in a draft specification in 1997. This work will require the development of fundamentally new algorithmic techniques. In conjunction with the MPEG meeting this week in New York, a one-day seminar was held on current research ideas applicable to low bitrate coding. Demonstrations and papers were presented on a number of techniques, including model-based image coding, human interaction with multimedia environments, and low-bitrate speech coding. When completed, the MPEG-4 standard will enable a whole spectrum of new applications, including interactive mobile multimedia communications. =========================================================================== II | PROFESSIONAL SOFTWARE =========================== ------------------------------------------------------------------------------- II.1 | DOS ----------- Ingenieurbuero Gatz & Hartmann, Fehrbelliner Str. 32, 13585 Berlin, GERMANY Tel: 030- 344 23 66 or 030-375 55 68 FAX: 030- 344 92 79 or 030-375 56 55 email to: leo@zelator.in-berlin.de (Stefan Hartmann) 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( ] --------------------------------------------------------------------------- [ Looks like, if I don't have to translate this ;o) ] [ Well, I know, looks like advert, but they are the only ones, that ] [ produce MPEG-Hard- and Software for this price. Hereby I declare, ] [ everybody can send me their lists, too. I will publish them in the ] [ next FAQ. Current Dollar-DeutschMark-course is: 1$ = 1,67 DM !!! ] --------------------------------------------------------------------------- II.2 | WINDOWS --------------- Gatz and Hartmann proudly presents: PC-Hurricane Win3.x Winhurri Version 1.5 This is our new control program for the moviegrabber board PC-Hurricane ============ This version 1.5 only runs in Hicolor modes 32K or 64K colors ! So use these Windows Hicolor drivers to use this piece of software. Functions: ---------- 1. You can digitize video movies in realtime (up to 25 frames/second) into Extendend Memmory and play them also back in realtime with this Winhurri program. Now you can also do Harddisk-Video-Recording in realtime up to 384x288 screen size (full field resolution ) ! 2. You can save every single frame or the whole movie in one shot to the harddrive. 3. Due to the DIB or BMP output you can load the DIB sequence directly into the VideoEditor of Microsoft's Video for Windows(tm) program and generate an compressed AVI movie. The BMP output is for the Xing Technology MPEG encoder, so you can choose to make AVI or MPEG movies from the digitized raw data. 4. You can watch television with this card by connecting a tuner and clicking the VIEW button. At 160x120 screen size it gives you realtime video display without the need of an feature connector cable to your VGA card or the hassle to be unable to use the highest Hicolor windows driver. So you can watch TV while working in a windows resolution of e.g. 1024x768x64K colors and still doing word-processing or picture editing in Hicolor. Normal Overlay boards only support up to 256 colors windows drivers or only 640x480x32K colors, but not 1024x768x64K colors Noninterlaced! (like with the new Genoa VideoBlitz card with the Weitek P9000 chipset) Future versions: ---------------- We are already working on integrating WAV sound digitizing in realtime together with the video grabbing by using any installed soundcard under windows. This will allow synchroneous digitizing of sound and video in one shot. You can then save the DIB sequence and a WAV file and do an AVI movie with sound in one shot ! email to: harti@tron.gun.de PC-Hurricane in this moment sells for 499.-DM incl. 15 % VAT in Germany. Together with the Xing Technology MPEG Encoder and player it is 699.- DM incl. 15 % VAT in Germany. Foreign customers could get it by VISA card payment. It is 299.-US$ including airmail delivery to you. Together with the Xing MPEG Encoder and Player software for Windows it sells for 449.- US$ incl. shipping and handling. --------------------------------------------------------------------------- II.3 | UNIX ------------ [ Its really nice software, but its exepensive ! 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 Subject: Re: THE MPEG-FAQ - Version 2.0 Date: Thu, 13 May 93 10:31:32 -0700 North Valley Research Digital Media Systems North Valley Research is pleased to announce immediate availability of a family of products for working with video and other time-based media in a UNIX environment. These products are the first, affordable software products that enable the end user to take video and audio all the way from video camera or tape to an MPEG sequence that can be played back in real-time on most Sun SPARCstations. Starting now until May 5th, 1993, individual products can be purchased for $150 in quantities of 30 or more; or under $300 for quantity 1. These software products have well-designed Motif user interfaces and a robust architectural design. The first set of products is sold as a kit, and consists of three user interfaces: - The Player. This tool provides a viewing mechanism for working with + MPEG sequences + analog video (requires the Parallax XVideo board) + JPEG movies (requires the Parallax XVideo board with JPEG option) - The Recorder. This tool enables the user to peruse analog material with an interface very similar to the Player, but in addition, allows you to create JPEG movies using the JPEG hardware on the Parallax XVideo board. - The Compressor. This tool allows you to choose input files, specify the compression characteristics and finally, compress them with our software MPEG compression engine. The MPEG playback mechanism is purely software, requires no special framebuffer, and depending on the size of picture, the size of the window and bandwidth of the bitstream, can run at 6 - 30 fps with synchronized audio. The color is dithered from 19 bits down to 7 bits, gamma-corrected, with real-time adjustments for contrast and brightness. The displayed window can be one or four times the size of the MPEG sequence picture size. For example, a sequence compressed at 320x240 can be played back at 320x240 or 640x480 (depending on the performance of the host computer). Both the MPEG compression and playback mechanisms support: + variable I:P:B ratios + variable picture sizes from 64x48 to 320x240 + variable and fixed bit rate + three motion estimation algorithms (Jain & Jain and two Exhaustive methods) The MPEG compressor is relatively fast for compression that includes motion estimation, and depending on the input stream and the selected compression parameters, can compress a twenty second sequence in as little as an hour. The JPEG record and playback is accomplished with the aid of the Parallax XVideo board. Recording and playback of JPEG movies is controlled by a special software engine that always keeps the audio and video synchronized. Recorded sequences may be "running records" from a camera or broadcast, or assembled from a controllable video source with in and out points. Both the Player and Recorder support Sony's ViSCA/LANC, and Pioneer 4400 disc players (and other compatible models). VideoMedia's VLAN will be added in the future. Prices and Availability ----------------------- All prices below are retail, with a special, 40%-off, introductory price in parenthesis. These special prices are good until May 5, 1993. All products require: Operating System: Solaris 1.0.1 Computer: SPARCstation 1+, 2, IPC, IPX Availability: All products are available for immediate delivery Media: 8mm tape or Quarter-inch cartridge (QIC) Terms: P.O. prior to shipment, net 30 days with credit NVR Digital Media Player: Includes: Support for audio and viewing analog video, JPEG movies and software MPEG. Requirements: For analog video: Parallax XVideo board For JPEG movies: Parallax XVideo board with JPEG option For MPEG playback: most any 8-bit pseudo-color frame-buffer, including CG3, CG4, CG6 and Parallax XVideo. Black-and-white monochrome support available on request. Prices: 1 floating license $495 ($297 intro) 10 floating license $2,000 ($1,200 intro) 30 floating license $4,500 ($2,700 intro) NVR Digital Media Recorder Includes: Support for viewing analog video and creating JPEG movies Requirements: Parallax XVideo board Price: 1 floating license $1,595 ($960 intro) NVR Digital Media Compressor Includes: Support for compressing JPEG movies (both audio and video) into MPEG. Other input formats available on request. Requirements: No special display requirements Price: 1 floating license $2,495 ($1,495 intro) Development Kit: Includes: 5 Player licenses 1 Recorder license 1 Compressor license. Requirements: As above for each product Price: $3,995 ($2,395 intro) Support and Maintenance: Includes: software upgrades email support limited phone support Price: 15% of purchased product price (Free intro!) Further Information ------------------- You can reach us at: North Valley Research, Inc. 15262 NW Greenbrier Parkway Beaverton, OR 97006 Tel: (503) 531-5705 Fax: (503) 690-2320 email (sales and marketing): marketing@nvr.com email (technical questions): support@nvr.com This and other text-only versions of our product sheets are available via anonymous ftp to nvr.com (192.82.231.50). Look in /pub/NVR. We are happy to mail paper versions of our product sheets on request. If you require a demo version, please call or send mail to support@nvr.com. --------------- Todd Brunhoff Vice President, R&D North Valley Research --------------------------------------------------------------------------- From: Todd Brunhoff Subject: Re: NVR-Software Date: Tue, 18 May 93 09:23:26 -0700 The price list and text-only versions of our product sheets are available via anonymous ftp to nvr.com (192.82.231.50). Look in /pub/NVR-data-sheets. If you need glitzy paper versions to convey credibility, we are happy to mail our product sheets on request. The demonstration software package comes in several pieces via anonymous ftp to nvr.com (192.82.231.50). Look in /pub/NVR-software for the license agreement and README file. Briefly you will need: /pub/NVR-software/Manual.evenpages-1.0.2.ps.Z /pub/NVR-software/Manual.oddpages-1.0.2.ps.Z /pub/NVR-software/Product-1.0.4.tar.Z /pub/NVR-software/README and some selection from /pub/contrib/mpeg and /pub/contrib/jpeg depending on the kind of hardware you have. If you get our software via ftp, send us an email note and we will give you a demo license key so you can run it. --------------- internet: toddb@nvr.com c--Q Q US: Todd Brunhoff; North Valley Research; ` 15262 NW Greenbriar Pkwy; Beaverton, OR 97006 - Phone: (503) 531-5707 Fax: (503) 690-2320 =========================================================================== III | PUBLIC-DOMAIN-SOFTWARE OR SHAREWARE ========================================== --------------------------------------------------------------------------- III.1 | DOS ------------ [ This is the README.DOS file out of the SECMPEG-archive. Read below in ] [ the UNIX-section for more information about SECMPEG. ] SECMPEG is a program based on a rather complex algorythm to ensure a confidentiality and a integrity service for the video-stream MPEG-I. SECMPEG.ZIP (c) 1993 by Frank Gadegast and Juergen Meyer ======================================================== This is my DOS-port of the MPEG-filter called "secmpeg". Read the provided file README and the man-page first. It was compiled with Gnu's DOS-port of their GCC-compiler, called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please read the GNU-Licence-file 'LICENCE.GNU'. You find the DOS executable in this distribution under 'secmpeg.exe'. NEEDS and INSTALL ----------------- Cause of DJGCC, the final executable is not running under DPMI (so not in a Windows-DOS-Box) nor on a 286-machine. The Gnu-environment-executable 'GO32.EXE' has to be somewhere in the PATH. If running on a 386, the GNU-387-emulationfile 'EMU387' has to be, where the environment variable GO32 is pointing to, so if the emu-file is in D:\LIB enter: set GO32=emu d:/lib/emu387 Permission to use, copy, modify, and distribute this soft- ware and its documentation for any purpose and without fee is hereby granted, provided that the archive remains com- plete, that this author notice will appear in all copies and as long as you don't try to make money off it, or pre- tend that you wrote it. --------------------------------------------------------------------------- [ The first tool to test a MPEG-I-stream ! Including statistics, frame- ] [ order, decoding times !! Now you can test, if archives are ok or if a ] [ file uudecoded ok without playing it ! This code is surely based on ] [ the berkeley-decoder. ] MPEGSTAT.ZIP (c) 1993 by PHADE Software ======================================= This is my DOS-port of the MPEG-filter called "mpegstat". It was compiled with Gnu's DOS-port of their GCC-compiler, called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please read the GNU-Licence-file 'LICENCE.GNU'. WHERE IS IT ? ============= It will be posted the alt.binaries.pictures.utilities group these days. Reposts come as requested. It will stored on our ftp-server in the next days (probably there): host: ftp.cs.tu-berlin.de (130.149.17.7) file: /pub/msdos/dos/graphics/mpegstat.zip NEEDS and INSTALL ----------------- The Gnu-environment-executable 'GO32.EXE' has to be somewhere in the PATH. If running on a 386, the GNU-387-emulationfile 'EMU387' has to be, where the environment variable GO32 is pointing to, so if the emu-file is in D:\LIB enter: set GO32=emu d:/lib/emu387 That should do, Phade (phade@cs.tu-berlin.de) --------------------------------------------------------------------------- [ Well, and soon as it was out, I ported Berkeley's new MPEG-ecndoder ] [ to DOS as well, here the README.DOS file. For more information see ] [ below in the UNIX-section. ] ENC11DOS.ZIP (c) 1993 by PHADE Software ======================================= This is my DOS-port of the MPEG-encoder called "mpeg_encode" by the Berkeley Research Group. It was compiled with Gnu's DOS-port of their GCC-compiler, called DJGCC Version 2.4.1 and NDMAKE Version 4.5. So please read the GNU-Licence-file 'LICENCE.GNU'. WHERE IS IT ? ============= It will be posted the alt.binaries.pictures.utilities group these days. Reposts come as requested. It will stored on our ftp-server in the next days (probably there): host: ftp.cs.tu-berlin.de (130.149.17.7) file: /pub/msdos/dos/graphics/enc11dos.zip NEEDS and INSTALL ----------------- The Gnu-environment-executable 'GO32.EXE' has to be somewhere in the PATH. If running on a 386, the GNU-387-emulationfile 'EMU387' has to be, where the environment variable GO32 is pointing to, so if the emu-file is in D:\LIB enter: set GO32=emu d:/lib/emu387 That should do, Phade (phade@cs.tu-berlin.de) --------------------------------------------------------------------------- [ This is Xing's new Public-Domain-Player. It is enhanced, but still ] [ has of bugs. You have to deinstall the old .DLL's and the MCI-driver ] [ to have it running proper. The DOS-MPEG-Player included in this file ] [ (named MPEGVIEW.EXE) doesn NOT run with all Soundblaster-compatible ] [ cards and kills the machine quit often. ] XingIt! MPEG Player Software Demo (August 27,1993) The file MPEGVIEW.EXE installs Xing Technology, Inc.'s XingIt! MPEG Player Software Demo for IBM PC compatibles. Xing's "XingIt!" real-time video MPEG capture board, including encoding software, video and sound editor, and the full-featured player is available direct from Xing Technology, Inc. in Arroyo Grande, CA (See below for order info). The file MPEGVIEW.EXE is a self extracting archive. To install the player, create a new directory on your hard drive and copy MPEGVIEW.EXE into it. Change to that directory and type MPEGVIEW to extract the player files. MPEGVIEW.EXE also contains a DOS version of the player, MPEG.EXE. To run the DOS version, change to the directory where you extracted MPEGVIEW.EXE and type "MPEG MPEGFILENAME.MPG". --------------------------------------------------------------------------- [ CMPEG V1.0 is still available ! ] DMPEG V1.1 Public Domain MPEG decoder by Stefan Eckart June 1993 ================================================================== 1. Features =========== DMPEG is another MPEG decoder/player for the PC: - decodes (nearly) the full MPEG video standard (I,P,B frames, frame size up to at least 352x288) - can save decoded sequence in 8 or 24bit raw file for fast off-line display (two pass mode) - optional on-screen display during decoding - several dithering options for 8 bit displays: ordered dither, Floyd-Steinberg, grayscale - selectable color-space - runs under DOS, 640KB RAM, no MS-Windows or '386 required - compact (small code / small data models, 16 bit arithmetic) - supports VGA, many Super-VGAs (including VESA) and some TrueColor SVGAs Stefan Eckart, stefan@lis.e-technik.tu-muenchen.de, June 1993. --------------------------------------------------------------------------- [ 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 ! ] From: mitgml@dct.ac.uk Subject: PVRG MPEG CODEC Date: 15 Jun 93 20:09:52 +0100 This archive contains the following files: README.1ST This file PVRGMPEG.EXE My port of the PVRG MPEG CODEC PPM2CYUV.EXE My port of the PVRG YUV file splitter CYUV2PPM.EXE My port of the PVRG YUV file combiner MAKEMPEG.TXT Details of how I did the port USEMPEG.TXT Details on using PVRGMPEG SHORT.MPG A XING compatible version of short.mpg supplied by PVRG with the source code. SHORT*.GIF The 10 frames in GIF format to make SHORT.MPG I hope I have not offended anybody by putting this archive together. I offer no warranty of any description with respect to my porting. All of the EXE files were compiled by me from Publicly available source code from the FTP sites listed in MAKEMPEG.TXT. I would like to thank the PVRG group for writing such an excellent encoder and for their help in getting at the Alpha release of v1.2 so quickly (I can't name this person as the PVRG copyright notice forbids it). Also I would like to thank Jelle van Zeijl for sending me the XING patch originally written by Mats Loftvist which has subsequently been included the Alpha release of v1.2. Have fun and please mail me to let me know how you get on. A copy of any interesting movies would be appreciated. This is the MAKEMPEG.TXT file from pvrgmpeg.zip it may help you port the PVRG MPEG CODEC to your platform. Hi All you Eager MPEG Makers, here is how to port the PVRG MPEG encoder/decoder to DOS/PC (386). Tools required: Well the ones that I used. GNU C version 2.2.2 An uncompress util for UNIX .Z files An untar util for UNIX tar files Text Editor (sorry some code needs tweaked) Note: Diff from the GNU File utilities, could be used instead Source required: 1) /pub/mpeg/MPEGv1.2.alpha.tar.Z from havefun.stanford.edu /pub/mpeg/MPEGDOCv1.1.tar.Z from havefun.stanford.edu documentation still to be updated. 2) The DOS port of PPM2CYUV called ppm2cyuv.exe 3) Image Alchemy from a number of ftp sites. eg /mirrors4/garbo.uwasa.fi/graphics/alch16.zip at wuarchive.wustl.edu Image Alchemy may be replaced with giftoppm.exe from the pbmplus set of graphics tools. Graham Logan June 15th 1993 mitgml@dct.ac.uk --------------------------------------------------------------------------- III.2 | WINDOWS ---------------- --------------------------------------------------------------------------- III.3 | WINDOWS-NT ------------------- [ This new version of it, is running now extremly nice, the subsystem ] [ is no harm at all. The file should be known as MPEGW32B.ZIP. ] From: msimmons@ecel.uwa.edu.au (Michael Simmons - mgmt_staff) Subject: Update to MPEG Player Date: 10 Jun 1993 07:39:23 GMT I have uploaded an updated version of my port of the Berkeley MPEG Video Movie Player. It can be found at: ftp.cica.indiana.edu as /pub/pc/win3/uploads/mpegw32b.zip toe.cs.berkeley.edu as /pub/upload/mpegw32b.zip MPEGPLAY V1.2 (c) 1993 Michael Simmons This is Release Version 1.2 of my port of the Berkeley mpeg player. This player can play standard mpeg files that include P and B frame encoding, and large 354x288 movie files. It has several display options including mono,gray scale,color dither and Full color (for Hicolor graphic cards). This program is SHAREWARE Please read the About box and Help file for information on registering your copy. To install the player under Windows 3.1(tm), Unzip the file disk1.zip to a floppy disk. Then run the setup.exe file via the Progman File-Run Menu Item. Note: You will need to install the Win32s extensions to Windows 3.1 inorder to run this player. Should you wish to remove these extensions please refer to the section near the end of this Readme.txt file. To install the player under Windows NT(tm) copy the files mpegplay.exe and mpegplay.hlp to a common directory.Then create a new program item for the mpegplay.exe file via the File New option of the Program Manager. Read the Disclaimer in the online Help before loading any mpeg movie files. This program is SHAREWARE Please read the About box and Help file for information on registering your copy. DISTRIBUTION: This File must not be separated from the rest of this archive. Due to licensing conditions of the WIN32s(tm) System this archive can only be Redistributed in the following ways: (1) Archive site to End user. (2) Archive site to Archive site. The following means of redistribution are not permitted: (1) End user to End user. (2) End user to Archive site. Redistribution from Archive site to Archive site may only be performed by the operators of those sites. An Archive site is taken to be any large collection of software which is operated by a person or group of persons for the primary purpose of redistributing that software. An End user is taken to be the person or group of persons who use this software. Known Bugs: (1) The Mono Dither is not working properly. (2) The 2x2 Colour Dither has patches of incorrect colour. (3) Sometimes the player fails to display Full Colour 354x288 images after a previous movie has been Opened and then Closed. (4) The Player is slower than is possible. (5) Bug/feature The Player runs slow when ever the mouse is moving. Changes since V1.0 (1) Re complied using the latest (March) WIN32 Beta. (2) Includes the latest (March) Win32s windows 3.1 extension. (3) Fix bug in finding help file. The working directory can now be different to the Command Line directory. (4) Increase number of clicks at startup to 4 (I have only received one registration!!) ACKNOWLEDGEMENTS: This code was derived from the U.C. Berkeley MPEG Player (version 2.0) developed by L.A. Rowe, K. Patel, and B. Smith (Rowe@CS.Berkeley.EDU). That code included the following copyright: Michael Simmons B.E.E. The Department of Management Computer Officer University of Western Australia Phone: (w)+61-9-380 2985 Stirling Highway Nedlands WA 6009 Phone: (h)+61-9-390 4534 Australia Fax: +61-9-380 1004 Email: msimmons@ecel.uwa.edu.au --------------------------------------------------------------------------- III.4 | OS/2 ------------- [ Read the RETRIEVED-MAIL-section for more infos ! ] --------------------------------------------------------------------------- III.5 | X-WINDOWS and UNIX --------------------------- [ Well, here is what I was working on last half year ! ] ************************************************************************ ANNOUNCING SECMPEG ************************************************************************ What is "SECMPEG" ? =================== SECMPEG is first a newly defined stream, that ensures the service of confidentiality and integrity for a MPEG-I-video-stream. 'Cause of the amount of multimedia-data it is NOT possible to use the same crypto- or checking-techniques for multimedia-data then for normal files or streams. Therefore we defined a new stream, containing additional security information. We tested and filtered the MPEG-I-stream to ensure that only important and relevant data is encrypted or checked. The newly desinged methods are not proofed but quite good tested. We can't be sure so far, if these method really do what they are designed for. It is second a tool, that can insert and delete the confidentiality and integrity data into/from a MPEG-I-stream. If you get any results to proof our methods, we hope to here from you ! More information is available from te authors, like some PostScript- files, pictures and graphs. Where is it ? ============= It will be posted the alt.binaries.pictures.utilities and the security- relevant groups these days. Reposts come as requested. It will stored on our ftp-server in the next days (probably there): host: ftp.cs.tu-berlin.de (130.149.17.7) file: /pub/msdos/dos/graphics/secmpeg.zip or probably in the unix-directory somewhere. How does it compile ? ===================== The program already compiles under - SunOS 4.1.x using cc or gcc - SunOS 5.0 using cc or gcc - Solaris 2.1 using cc or gcc - INTERACTIVE Unix 2.2.1 using cc or gcc - Linux using gcc - MS-DOS using gcc or Borland C 2.0 (tcc), the dos-port shoulb be included as executable in the archive You need a compiler, that understands ANSI-C so far, but the rest is straight forward C, so it should compile nearly everywhere. What can you do ? ================= Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the archive remains complete, that this author notice will appear in all copies and as long as you don't try to make money off it, or pretend that you wrote it. Authors ======= Juergen Meyer Frank Gadegast Sonnenallee 50 Leibnizstr. 30 12045 Berlin GERMANY 10625 Berlin GERMANY Access: jm@cs.tu-berlin.de Access: phade@cs.tu-berlin.de --------------------------------------------------------------------------- Tom Pfeiffer (pfeiffer@fokus.gmd.de) announces: [ mpegstat.tar.Z was uploaded to toe.cs.berkeley.edu, the DOS-port ] [ should be available in the next days on ftp.cs.tu-berlin.de ] This is mpegstat v1.0 - an analyzing took for MPEG-I video streams for Unix. It is based on the Berkeley MPEG player v2.0, utilizing the Berkeley parsing and decoding routines for the MPEG data stream. MPEGSTAT is a useful utility for analyzing MPEG-I video streams. It is based on the Berkeley MPEG movie player. MPEGSTAT reads a video stream from a file or stdin and shows the frame type pattern as it is found while parsing. After the stream is completely parsed it displays the frame pattern as it would be displayed by a MPEG viewer. It then generates a summary of various mpeg format related statistics. MPEGSTAT works for MPEG movies that are Paris format compatible. Authors ======= Multimedia systems project - Technical University of Berlin, Germany Tom Pfeifer, Dept. of Computer Science, pfeifer@fokus.gmd.de Jens Brettin - Alexander Schulze - Harald Masche - Dirk Schubert /* * * Copyright (c) 1993 Technical University of Berlin, Germany * * for the parts of the Berkeley player used: * * Copyright (c) 1992 The Regents of the University of California. * All rights reserved. * */ --------------------------------------------------------------------------- [ This brand-new encoder is really nice. Supports parralell computation ! ] [ There is also a really nice TKTCL-X11-Interface included !!! ] [ I already ported this to DOS (surely without the parallel stuff. ] From: Larry Rowe Date: Fri, 30 Jul 1993 17:15:56 -0700 Subject: MPEG Video Encoder Release The Berkeley Plateau Research Group is happy to announce the release of Version 1.0 of its MPEG video encoder. The encoder is available via anonymous ftp from toe.cs.berkeley.edu (128.32.149.117) in /pub/multimedia/mpeg/mpeg_encode-1.0.tar.Z. That directory includes a sample uncompressed video sequence (flower.tar), our software MPEG video player, and some MPEG movies. Larry and Kevin Below is a copy of the README file: ------------------------------------------ MPEG-1 Video Software Encoder (Version 1.0; July 30, 1993) Lawrence A. Rowe, Kevin Gong, Ketan Patel, and Dan Wallach Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains the freely distributed Berkeley MPEG-1 Video Encoder. The decoder implements the standard described in the ISO/IEC International Standard 11172-2. The code has been compiled and tested on the following platforms: HP PA-RISC (HP/UX 8.X, X11R4) (i.e., HP 9000/7XX and 9000/3XX) Sun Sparc (SunOS 4.X, X11R5) DECstation 5000 and Alpha If you decide to port the code to a new architecture, please let us know so that we can incorporate the changes into our sources. This directory contains everything required to build the encoder and run it. We have included source code, makefiles, binaries for selected platforms, documentation, and test data. Installation instructions are given in the file named src/INSTALL. A man page is given in the file doc/mpeg_encode.1. The encoder will accept any input file format as long as you provide a script to convert the images to PPM or YUV format. Input file processing is described in the file doc/INPUT.FORMAT. Options to control input file processing and compression parameters are specified in a parameter file. Very little error processing is done when reading this file. We suggest you start with the sample parameter file examples/template.param and modify it. See also examples/default.param. We have also provided a Tcl/Tk script, named encode.tcl, that can be used to set parameters interactively (see the misc/ directory). The misc/ directory contains utility you might find useful including: programs to do PPM/YUV conversion and programs to convert Parallax XVideo JPEG files into PPM or YUV frames. The motion vector search window can be specified, including half-pixel block matching, in the parameter file. We have implemented several search algorithms for P-frames including: 1) exhaustive search, 2) subsampled search, and 3) logarithmic search. We have also implemented several alternatives for B-frame block matching including: 1) interpolate best forward and best backward block, 2) find backward block for best forward or vice-versa (called CROSS2), and 3) exhaustive cross product (i.e., go out for coffee and a donut!). The search algorithms are controlled by options in the parameters file. For tips on choosing the right search technique, see doc/TIPS. We have done some tuning to produce a reasonable encoder, but there are many more optimizations that we would like to incorporate. These extensions are listed in the file EXTENSIONS. If you succeed in implementing any of them, please let us know! We have established several mailing lists for messages about the Berkeley MPEG work: mpeg-list-dist@CS.Berkeley.EDU General information on the MPEG-1 decoder and encoder for everyone interested should be sent to this list. mpeg-list-request@CS.Berkeley.EDU Requests to join or leave the list should be sent to this address. The subject line should contain the single word ADD or DELETE. mpeg-bugs@CS.Berkeley.EDU Problems, questions, or patches should be sent to this address. Our future plans include porting the encoder to run on other platforms and completing a portable parallel version of the code that will run on a network of workstations. Vendors or other organizations interested in supporting this research or discussing other aspects of this project should contact Larry Rowe at Rowe@CS.Berkeley.EDU (+1 510-642-5117). ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard and Fujitsu who provided financial support for this work. We also want to thank the following people for their help: Jef Poskanzer who developed the pbmplus package. --------- Copyright (C) 1989, 1991 by Jef Poskanzer. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This software is provided "as is" without express or implied warranty. --------- Eiichi Kowashi of Intel and Avideh Zakhor of U.C. Berkeley who provided valuable suggestions on motion vector searching. Chad Fogg of the University of Washington who has helped us understand many issues in MPEG coding and decoding. --------------------------------------------------------------------------- [ You can find this in the /pub/multimedia/mpeg-directory of Berkeley's ] [ ftp-server. Belongs to there codec. ] This directory includes 150 raw YUV frames suitable for use with the MPEG encoder. The YUV frames are the files flower.*.tar.z. To uncompress, use the GNU 'gunzip' program. You should uncompress all of these files inside a directory named 'flowg'. To run the test, simply do 'mpeg_encode flower.param' To make sure the test worked, do 'diff flowgard.mpg result.mpg' (there shouldn't be any difference; if there is, let us know) Please see the file 'times,' which includes time results for various machines and compilers. --------------------------------------------------------------------------- [ A Public-Domain-Encoder-Kit for Unix ! Now in Version 1.2 ] From: msimmons@ecel.uwa.edu.au (Michael Simmons - mgmt_staff) Subject: Standford MPEG codec Date: Thu, 25 Feb 1993 16:07:18 +0800 (WST) MPEG Image and Image sequence compression/decompression C software engines =========================================================================== The Portable Video Research Group at Stanford have developed image/image sequence compression and decompression engines (codecs) for MPEG, CCITT H.261, and JPEG. The primary goal of these codecs is to provide the functionality - these codecs are not optimized for speed, rather completeness, and some of the code is kludgey. Development of MPEG, P64, and JPEG engines is not the primary goal of the Portable Video Research Group. Our research is focused on software and hardware for portable wireless digital video communication. For more information about current research, please send e-mail to Professor Teresa Meng at meng@tilden.stanford.edu. COMMENTS/DISCLAIMERS: This code has been compiled on the Sun Sparc and DECstation UNIX machines; some code has been further checked on the HP workstations. For comments, bugs, and other mail relating to the source code, we appreciate any comments. The code author can be reached at Andy C. Hung at achung@cs.stanford.edu. The standard public domain disclaimer applies: Caveat Emptor - no guarantee on accuracy or software support. References related to these codecs should NOT use any author's name, or refer to Stanford University. Rather the Portable Video Research Group or the acronym (PVRG) should be used, such as PVRG-MPEG, PVRG-P64, PVRG-JPEG. PVRG-MPEG CODEC: (MPEGv1.1.tar.Z) [ is now MPEGv1.2.tar.gz ] This public domain video encoder and decoder was generated according to the Santa Clara August 1991 format. It has been tested successfully with decoders using the Paris December 1991 format. The codec is capable of encoding all MPEG types of frames. The algorithms for rate control, buffer-constrained encoding, and quantization decisions are similar, but not identical, to that of the (simulation model 1-3) MPEG document. The rate control used is a simple proportional Q-stepsize/Buffer loop that works though not very well - better rate-control is the essence for good quality buffer-constrained MPEG encoding. Verification of the buffering is possible so as to provide streams for real-time decoders. The MPEG codec performs compression and decompression on raw raster scanned YUV files. The companion display program for the X window system is described in section IV) below. A manual of approximately 50 pages describes the program's use. There are also MPEG compressed files from the table tennis sequence in tennis.mpg and the flower garden sequence in flowg.mpg. This codec was recently tested with the MPEG decoder of the Berkeley Plateau Research group. If what you want is decoding and X display, then you might want to look into their faster public domain MPEG decoder/viewer. The Berkeley player is available via anonymous ftp from toe.cs.berkeley.edu (128.32.149.117) in /pub/multimedia/mpeg/mpeg-2.0.tar.Z. ACKNOWLEDGEMENTS: Funded by the Defense Advanced Research Projects Agency. I am especially grateful to Hewlett Packard and Storm Technology for their financial support during the earlier stages of codec development. Any errors in the code and documentation are my own. The following people are acknowledged for their advice and assistance. Thanks, one and all. The Portable Video Research Group at Stanford: Teresa Meng, Peter Black, Ben Gordon, Sheila Hemami, Wee-Chiew Tan, Eli Tsern. Adriaan Ligtenberg of Storm Technology. Jeanne Wiseman, Andrew Fitzhugh, Gregory Yovanof and Chuck Rosenberg of Hewlett Packard. Eric Hamilton and Jean-Georges Fritsch of C-Cube Microsystems. Lawrence Rowe of the Berkeley Plateau Research Group. Tom Lane of the Independent JPEG Group. Katsumi Tahara from Sony. Ciaran Mc Goldrick. Karl Lillevold --------------------------------------------------------------------------- III.6 | MAC ------------ [ Could somebody tell Bryan and me where to get this ? I couldn't find it ] From: maynard@msc.cornell.edu Date: Mon, 10 May 1993 23:20:20 -0400 Subject: Re: WERE.TO.GET.MPEG.PLAYERS (Xwin/MSwin/Dos/Mac/Amiga/VMS) There is a new mac MPEG player out, MINE! Called Sparkle. I have submitted it to sumex-aim.stanford.edu and mac.archive.umich.edu. It plays the MPEG and converts to QuickTime, but has a mac-look-and-feel to it and is multi-finder friendly. Maynard Handley --------------------------------------------------------------------------- From: Rainer Menes Subject: Re: LAST REPOST: THE MPEG-FAQ Version 2.0 - Part 2 Date: Wed, 6 Oct 1993 13:20:08 +0100 After a long time of waiting, I am happy to annonce the Quicktime to MPEG converter for the Mac. I had alot of problem related with the port so sorry for this long waiting time. Now what you will need: Quicktime to MPEG or short qt2mpeg need at last a MacII with 68881. It should run with 3 MByte of memory. I have tested it with all bit depth from 1 bit to 32 bit. Note you must have a FPU. Now how does it work: First there is a program call qt2YUV. This program converts Quicktime movies to YUV files and shell scripts for MacMiNT or UNIX. The second program, Hm it is a bit more than a program, MacMiNT is a multitasking OS for your Mac. Because it has some unique feature I decide to us this as enviroment for porting the encoders. 1.) MacMiNT is in most cases a BSD UNIX, so this made the port possible without changing the code to much. 2.) MacMiNT runs as forground and as background task under Finder. This means the mpeg encoder will run silently in background during conversation. You will be happy to have this feature for long MPEG sequences. Some hour conversation time isn't unusual for longer movies. 3.) Can use gcc2.4.5 with full optimisation to get best performance. No No No dont worry!!! You won't need to be a UNIX wizard to deal with MacMiNT during installation and use of the MPEG encoders. You only need to know that "ls" changes dirs. Yes thats all you need to know. I hope this isn't to much. ( I am joking) Recommended Hardware: As said befor it will run on any Mac with 68020, 68030 and 68040 with FPU, but I would recommend a fast Quadra or Centris modell with a big, no super big harddisk. The best machine because it includes a video IN feature is a Quadra 840 AV 16/1000 CD. Supported ENCODERS: You will have two encoder you could use. 1.) The Berkeley encoder version 1.0 2.) The Stanford encoder version 1.2 Where to get: You will find this software on: suniams1.statistik.tu-muenchen.de:/pub/mac/MPEG/encoder/... (131.159.64.1) --------------------------------------------------------------------------- [ Are MAC's not on the Internet ? Why do we not hear more from them ? ] --------------------------------------------------------------------------- III.7 | ATARI -------------- [ Bainstorm is not continuing to develop their MPEG-Player for ] [ the Atari, really sad :o( Maybe somebody can help them ? ] From: laurent@brasil.frmug.fr.net (Laurent Chemla) Subject: MPEG-FAQ - next version Date: Fri, 10 Sep 1993 14:39:39 +0000 (GMT) Frank, Of course you're right. Raphael Lemoine replied quickly, directly online on Compuserve, and as the author of our MPEG software he's quite disapointed by the little interest there is about. As a commercial entity, Brainstorm is trying to sell his work. But this kind of work is not an easy thing to sell. A few developpers asked us about our software, but could'nt pay for it. An easy solution would be to sell it to Atari Corp directly, and then developpers could get it from Atari at low price. But Atari licensed Cinepak for this usage, and they aren't interested in buying our MPEG. So we decided to forget it for a while. Our MPEG runs at the same (or so) rate, not depending on the resolution. It uses some of our 'real time' dithering algorithms on Atari. Added to the work on the DSP coding, you can see it's a good piece of software Raphael did. But it's not enough for selling it as a Shareware library, because it does'nt handle P and B frames nor the sound, and we wont work on it if we cant expect to be paid for this work. I have personnally written a few news about this software in the Atari's Usenet conferences, but only got 3 mails in return, and nothing really exciting. Anyway, be sure we will tell you if anything new occurs about that. Laurent Chemla @ Brainstorm -- Laurent Chemla : chemla@cnam.cnam.fr or laurent@brasil.frmug.fr.net Brasil BBS - +33 1 44 67 08 44 - Atari France developpers support --------------------------------------------------------------------------- III.8 | NEXT ------------- [ This piece of software is now available in Version 2.5. Its real name ] [ is, I thinx NXPLAY-something. Look into the FTP-section too. ] 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" which can be manipulated even while the video is playing. MPEG Play will keep track of different settings for each window, reflecting the current values in the Window Settings panel whenever you select a new main window. When playback is complete, a few interesting performance statistics are shown. Notes: You may have to wait some time after opening a new file before it will be shown. The frames will be counted as they are loaded. 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 Original Version: MPEG Play is a bare-bones MPEG animation viewer. It's free, subject to the standard GNU copyright restrictions and those in the X-windows MPEG viewer software out of which I hacked the mpegDecoder code. If you make any improvements, especially in speed and/or image quality, please share the code and drop me a note at warozzi@3m.com. Using MPEG Play: Open an MPEG document using the menu item. The filename must end in ".mpg" for the file to be recognized. A window will appear and the animation will start after a few seconds. Hit the Play Again menu item to restart at frame 1. Use the Colorspace and Zoom radio buttons to set the window's attributes. Enjoy. Brian Willoughby Software Design Engineer, BSEE NCSU BrianW@SoundS.WA.com Sound Consulting: Software Design and Development NeXTmail welcome --------------------------------------------------------------------------- III.9 | INFOS about Movies --------------------------- From: harti@mikro.ee.tu-berlin.de (Stefan Hartmann (Behse)) Subject: MPEG CD-ROM, how to submit animations. Date: 13 Feb 1993 13:07:16 GMT Stefan got a bit stuck with work, so the CD-ROM is not out yet, sad :o( =========================================================================== IV | MPEG-RELATED HARDWARE =========================== [ The first real MPEG-cards arrived ! ] From: jmm73@frmug.fr.mugnet.org (Jean-Michel Mercier) Subject: Info for the MPEG FAQ Date: Tue, 22 Jun 93 22:07:34 MET DST VITEC VIDEO-MAKER ================= Since December 92, there is a french MPEG PC-plugin. It's called VIDEO MAKER and it's manufactured by : VITEC 3 bis rue P. Baudry 92140 CLAMART FRANCE tel (33) 1.46.29.03.00 fax (33) 1.46.29.03.04 Features : Claims to be the world 1st MPEG board. 2 selectable video inputs NTSC/PAL/SECAM/S-VHS Picture up to 768x576 (by step of 16) Colors : 256/32K/16M Frame : 1 to 25 Fr/s No need for VESA Features connector 16 bit short card, no dip nor jumper, no DMA nor IRQ Windows software : IMAGER : record & compress moving or still picts. MPEG PLAYER : full software MPEG decoder/player, doesn't need the board (it seems that you can freely give this soft with your MPEG seqs.) MULTIMEDIA MANAGER VM : well known software from Multimedia Telecom to build your scripts with icons, sync. with sounds, etc... DLL for MCI & AVI availables What it's not said in the commercial : The card doesn't sample sound today but a daughter board should become available (you can still sample sound separ and the resync with M. MANAGER) You can't use the full specs at the same time (ie 768x576, 16M colors, 25 fr/s) even with a 486 as the compression is made by software In fact, the sequence is 1st stored in memory using a proprietary compression scheme and saved to disk as .VSF files. Then the offline compression could be achived. It seems that a PC with 8Mbytes of RAM should be able to record about 10 to 30 secondes of video. What's on the board : The board use Philips Digital Desktop video chipset (TDA8708+TDA8709+ SAA7191+SAA7197) witch provides 4:2:2 YUV video @ 14.75 Msmp/s It doesn't use the SAA7192 color space converter to get RVB so this should be done by software. There is also an XC3042-100 FPLA from Xilinx and 1Mx8bits of dynamic ram (70ns). Probably used for pre-compression. The public price is 3500FF ($625) but Surcouf (Paris' computer store) sells it about 2300FF ($410). There was an ad in march issue of BYTE (p127) @ $695. For US & canada the ad said to phone to 404-921-6167 or fax to 404-921-9243. There is an test of this card (9 other ones) in june issue of the french magazine "Multimedia Solutions". NOTE : I have nothing to do with VITEC. This is not an ad. It is my personnal understanding of VITEC's ads, magazines reports and phone calls to VITEC. Please contact VITEC for any contractual informations. MPEG CHIPS ========== Some new chips are about to be available from SGS-Thomson : STI3223 : motion estimator controller, intended to be used with previously released STI3220 STI3230 : MPEG coder STI3400 : MPEG coder (STI3240 coder + DCT processor) STI3500 : MPEG 2 coder Do you want me to get some more details fast ? TI introduce the TMS320AV110 MPEG audio decoder based on TI's 16 bits DSPs (about $14). Some other boards ================= OPTIBASE's MPEG2000 (Herzliya - Israel, Canoga Park - Calif.) It use an CCUBE (witch?), DSP56001 ant DCT chips from LSI. --------------------------------------------------------------------------- Please refer here to the section in the previous MPEG-FAQ Version 1.1, because I did not get a lot of new infos. =========================================================================== V | MAILBOX-ACCESS =================== --------------------------------------------------------------------------- V.1 | ------ GENOA has right now a new BBS in Germany (Stefan Hartmann will put new MPEG-software there too), phone: ++ 49 211 686756 (16.8Kb/sec with US Robotics Dual Standard) --------------------------------------------------------------------------- V.2 | ------ This is the phone number of Xing Technologies' BBS: 805-473-2680 (2400b) (USA) Bryan Woodworth 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. --------------------------------------------------------------------------- V.3 | ------ These are the phone numbers of Gatz & Hartmann's 7 line support BBS: ++49 30- 462 63 41 (v32bis) ++49 30- 462 64 35 (v32bis) ++49 30- 462 65 38 (v32bis) ++49 30- 462 60 22 (v32 + PEP) ++49 30- 462 61 37 (v32) ++49 30- 462 62 37 (v32) ++49 30- 461 86 50 (v22bis + HST) This is the professional Zelator-ACCESS-BBS system with Internet access. There will be several new MPEG clips and updates of the GENOA 7900 SVGA board drivers, 24 bit ET4000 programing infos,etc... Check it out ! You will enjoy it. Just log in with: guh That means: Gatz und Hartmann. =========================================================================== VI.1 | FTP-ACCESS (PD) ======================== There is an MPEG archive site at: phoenix.oulu.fi (130.231.240.17) in the directory /pub/mpeg Please contact this ftp-site for files before e-mailing to me !!! --------------------------------------------------------------------------- VI.3 | ------- There is an MPEG archive site at: toe.cs.berkeley.edu (128.32.149.117) in the directory /pub/multimedia/mpeg Please contact this ftp-site for files before e-mailing to me !!! --------------------------------------------------------------------------- VI.3 | ------- Gatz & Hartman BBS is now reachable via ftp, between 18.00 - 6.00 german time. Login as 'gast', then look for IBM-Files under File-Sector 14 : IBM_g_und_h zelator.in-berlin.de (192.109.42.11) Anon-ftp-uploads are not alowed anymore. The 'gast'-account can be restricted. Things change ;o) --------------------------------------------------------------------------- VI.4 | ------- Bryan Woodworth invites you to the ftp-server: ftp.rahul.net (192.160.13.1) in /pub/bryanw/pc/mpeg Login as "anonymous," any time of the day or night. [ Several MPEG-Information is located in the directory /pub/bryanw ] ear Bryan was the first one, that downloaded the brand new mpeg-player ] [ from Xing's BBS and posted it to a.b.p.u, thnx to Bryan ! ] He wrote: If the people have problems connecting, they should send a capture of the session to "support@rahul.net," so that the problem can be corrected. and wrote: If people want to know where they can find the Microsoft Windows MPEG player(s), DOS players, Amiga players, X Windows, VMS, and Macintosh players, they could cd to: /pub/bryanw/information and retrieve: WHERE.TO.GET.MPEG.PLAYERS This file is posted biweekly to alt.binaries.pictures.* The information subdirectory also contains an ABPE faq, this MPEG faq :-), JPEG information, information on X-windows on PCs, and I suppose that is all.. If I ever find good stuff, I put it here. --------------------------------------------------------------------------- VI.5 | ------- From: spagiola@frinext.stanford.edu (Stefano Pagiola) Subject: Re: MPEG viewer for the NeXT Date: Thu, 13 May 93 00:03:13 GMT M Scott OBrien writes >> I was hoping someone might point out a location of an MPEG viewer >>for the NeXT. > Id be very interestedin this too. If anyone knows There are two, both available at cs.orst.edu, in /pub/next/sources/graphics: MPEGPlay2.5.tar.Z and mpeg_next.2.0.tar.Z. --------------------------------------------------------------------------- VI.6 | ------- Good ftp-hosts to look for MPEG-related software are: ftp.cica.indiana.edu (129.79.20.84) ftp.germany.eu.net (192.76.144.75) ftp.cs.tu-berlin.de (130.149.17.7) mucket.vast.unsw.edu.au nic.funet.fi (128.214.6.100) pinus.slu.se (130.238.98.11) wuarchive.wustl.edu (128.252.135.4) =========================================================================== VII | MAIL-ORDER ================== --------------------------------------------------------------------------- VII.1 | TRAIL-PACK ------------------- >>> NEW ! You can receive the trail-pack on tape now <<< >>> but NO longer on floppy-disks !!! <<< >>> NEW ! There is an EROTIC section available now too ! <<< >>> GET THE "TRAIL-PACK" !!! NOW AVAILABLE ON TAPE TOO !!! <<< You can purchase a complete archive named the "Trail-Pack" including the FAQ and all named programs, source-code, movies and information-files. This archive includes (in addition to the ftp-access) all versions of the programs and source-code, additional movies (including the audio-wav-files) and lots of additional informations. This archive is NOT available via Internet nor ftp nor mailbox- or e-mail-access. It is ONLY available via post ! It is for those that don't have Internet-Access, everybody else can get these things anyway. THE HOST THE ARCHIVE IS ON IS NOT ON THE INTERNET ! === == ORDER FORM ======== cut here cut here cut here ======================= ORDER FORM: =========== The MPEG-TRAIL-PACK will contain at least: 2,826,398 D:\MPEG\AUDIO 31,716,544 D:\MPEG\BIGMOVIE 2,696,225 D:\MPEG\CODEC 1,263,884 D:\MPEG\DEMO 803 D:\MPEG\DOC\MOVIES 1,901,401 D:\MPEG\DOC 393,132 D:\MPEG\FAQ 13,628,403 D:\MPEG\MOVIES 4,383,715 D:\MPEG\NEWS 4,542,683 D:\MPEG\NVR 3,404,756 D:\MPEG\NVRMOVIE 2,817,024 D:\MPEG\UTIL 20,006,790 D:\MPEG\VIDEOS + UNPACKING UTILS ========================== Total = 89,982,527 bytes > 150 MB uncompressed MPEG ! and additional (if checked): 581,948 D:\OPTIC\BIGSEX 20,994,067 D:\OPTIC\SEX ========================== Total = 21,576,015 bytes ( ) <- check here to obtain the EROTIC-part of the TRAIL-PACK. AGREEMENT: By signing this paragraph you agree, that you will not copy the complete TRAIL-PACK-package or bigger parts of it to more than one computer nor publish it or bigger parts of it to any network or other public service or mailbox. The use of single files or small parts to whatever purpose is hereby granted. The commercial use of this package is not allowed. Contact PHADE Software for commercial use. This agreement does not touch any other regulations by the authors of the programs in this archive. ====================================== ^-- sign here ====================== cut here cut here cut here ======================= To obtain the "Trail-Pack" send a envelope, with the big-written key-word "Trail-Pack" on it to: PHADE SOFTWARE Inh. Frank Gadegast Leibnizstr. 30 10625 Berlin G E R M A N Y and include in it for the Trail-Pack: o 40 DM (fourty German Marks), to pay the time I spend on archiving all these movies, utilities and documents, copying tapes and going to the post (money, that will be over, will be used to prepare the next version of the MPEG-FAQ). Please do NOT included ANY coins. o enough money (at least 25 DM from other countries, 10 DM from inside Germany) to pay the postage of the "Trail-Pack" (the postage of your package to me, should be nearly the same, compared to, what I have to spend, to send the "Trail-Pack"; so, if you are living in Australia, send MORE money; the last package back to Australia did cost DM 42 !). Again, please do NOT include ANY coins nor checks. o a signed copy of the order-form. If you want to order the EROTIC- part of the TRAIL-PACK as well, check the section in the order-form and include a copy of a passport, driving licence e.g to prove that you are older that 18. o a hard-cover-envelope (big and strong enough to carry your QIC-tape, written with YOUR correct adress. o the QIC-tape (Quarter Inch Cartridge). I can write QIC-120, QIC-150 and QIC-250. You will get the tape back with the complete MPEG- archive on it in tar-format (no problem for Unix, for DOS you will need a SCSI-Streamer, the ASPI-Interface from Adaptec and Gnu-tar). I DO NOT: - take any floppy-streamer-tapes (Colorado eg.) - use any funny or comercial backup-programms (PC-Tools, Norton eg.) == HINTS ================================================================== Try to send me a ENVELOPE, not a packet. It should go through the letter box. NOTE: There is no guarantee, how, and when you will get the "Trail-Pack" back. I'll do my best to prepare the packages as quick as possible. But I can't guarantee for the post ;o) NOTE: Please do not send any schecks nor try to pay via credit-cards. NOTE: Requests, that are NOT complete will be send back, using the included money. Is no money included, nothing will be send back and my archive will thank you for your tape-gift !!! Is there no money neither tapes, your envelope will go to the bin. NOTE: You can send several tapes in one go, just add another 10 DM for each additional tape and send them along with everything else. NOTE: This is NOT a commercial offer, it's a service for those, that don't have internet-access !!! =========================================================================== --------------------------------------------------------------------------- VII.2 | CONVERSION ------------------- PHADE Software is offering a video-conversion-service ! A conversion of 1 MB video (GL,DL,MPEG,AVI,DIB-seq, e.g.) to one or the other format cost currently 30DM (20$). Over 10 MB gets then really cheap only 15DM (10$). Audio conversion is possible too (AVI, WAV, AU) and costs the half of the video-price (but is included if there is a video-conversion). Please send any jobs or commercial mail to 'phade@contrib.de' =========================================================================== VIII | RETRIEVED MAIL ======================= From: "Cave Newt" Date: Sat, 15 May 93 23:15:51 CDT Subject: Re: THE MPEG-FAQ - Version 2.0 - Part [2/3] >mpegplay.zip 97028 Full-screen 320x200 MPEG animation player >in pub/os2/2.x/graphics. > >[ Would be nice, if somebody could test this, and post some results. ] I did so; I've never seen/used any other MPEG viewer, however, so I have nothing with which to compare it. Nevertheless... On a 25MHz 386 running OS/2 2.0 GA+SP, and an ATI GUP with the 16-bit (slow) beta drivers, it displays roughly two frames per second in default mode on an actual movie posted to a.b.p.misc ("fan_bulb.mpg"). On the index20.mpg, it managed two to three frames per second; processing the whole file took exactly 15 seconds, of which about 2 seconds was initialization (before any display). The "-dither gray" option speeds things up by perhaps 50%. It's a port of "the Unix MPEG player," by which I assume the author is referring to the Berkeley software-only decoder. It gets the job done, I guess...I have yet to try any of the "standard" mpegs in the Berkeley collection. Greg Roelofs --------------------------------------------------------------------------- From: Morten Hjerde <100034.663@compuserve.com> Date: 17 Sep 93 13:08:21 EDT Subject: Re: MPEG-FAQ Audio-part ? The people I know is working on MPEG is Philips/Compression Labs for their "digital video" CD-I's. Digigram in France is producing some nice MPEG cards for the PC. You would want to avoid their older PCX3 cards because their MPEG implementation were a little odd. Their new PCX5 and PCX3 should be fine. Cardinal are introducing an MPEG driver for their new PC card. The driver has not been released. It's developed by Xing. I've played around with earlier Xing MPEG Audio stuff and it looked and sounded nice. C-Cube also have written an MPEG codec (for the AD2015 I believe). I don't know if they are doing anything with it. For broadcast industry use there are several others, also a couple of German vendors that makes stand-alone units. I don't have their names here. Here in Norway Tandberg are making a logger w. MPEG compression. (I have no connection to any of the above) Source code? I was hoping you could tell me that . --------------------------------------------------------------------------- From: kothary@mprgate.mpr.ca Subject: Optibase Date: Wed, 06 Oct 93 16:12:22 PDT I recently bought the Optibase PCMotion Player. This is the real time MPEG 1 decompressor. I have only tested it with a couple of clips so far but it seems to work very well. The decoded picture is the best I have seen so far. There are very few artifacts. The two clips I have tested to date are tigers.mps ( a system level stream they included with the board) and starwars.mpg (an older video level clip I had sitting around.) The tigers clip was very good while the Star Wars was not nearly as good. I don't know if this reflects advances in encoder technology or that Optibase does some funny stuff with their files. The board was very easy to install and ran pretty much the first time. The only problems I had with the company are that they are very difficult to contact and seem to be understaffed. I constantly hear the excuse that Mr X has not been able to contact me because he is very busy since he is on N different projects. Also they seem to be a funny company in that their employees seem to continually shift between their Isreal and two US offices. As you can imagine, it is very difficult to contact people who constantly change continents! The other big problem with the board is that it can only take data in through the ISA bus. It is not clear how to use this sort of card in a network unless one is willing to dedicate the entire PC to just one application. The bus on my PC seems quite full when I use this card. I think using either a T1, MVIP, SCSI, etc interface might make a more usuable card. Overall, for the kind of money they want, it seems to be a worthwhile board except the utility is limited to evaluation of MPEG and some composing rather than watching actual movies since networking is weak. The current list price for this board is $1499 USD. We are evaluating MPEG for use in video dialtone applications. =========================================================================== IX | ADDITIONAL INFORMATION ============================ From: gandhi@trix18.genie.uottawa.ca (rakeshkumar gandhi ) Date: Tue, 24 Nov 92 13:14:03 -0500 Subject: IEEE There is MPEG Hardware review in IEEE computer graphics and application magazine. --------------------------------------------------------------------------- From: Chad Fogg Date: Mon, 4 Oct 1993 02:02:58 -0700 Subject: Re: MPEG-2 FAQ -- first installment (draft) Q. Is there a book on MPEG compression? A. Yes, there will be a book published in Spring 1994 by the same authors who wrote the JPEG book (Bill Pennebaker, Joan Mitchell) with Didier Le Gall as an additional co-author. --------------------------------------------------------------------------- Only for Germans: Ihr koennt den MPEG-draft-I beim Beuth Verlag bekommem. =========================================================================== X | WHERE TO FIND MORE INFOS ============================= Well, first you can check the related news-groups: comp.graphics, comp.graphics.animation, comp.compression, comp.multimedia, comp.sys.amiga.multimedia, comp.mail.multi-media, alt.binaries.pictures.utilities The first part of this FAQ about MPEG came from Mark Adler, published in in FAQ for the newsgroup 'comp.compression'. --------------------------------------------------------------------------- Then you can ask 'archie' to find all NEW mpeg-releated software by sending the following mail (with no title): 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 prog whatever.you.look.for quit --------------------------------------------------------------------------- Then you could look for a newer version of the first part of this FAQ via ftp at: garbo.uwasa.fi (128.214.87.1), in /pub/doc-net The current version is named FAQC9301.ZIP --------------------------------------------------------------------------- Then read this (oh Bryan, still class ...): From: bryanw@rahul.net (Bryan Woodworth) Subject: WHERE TO GET MPEG UTILS FOR IBM/MAC/UNIX/VMS/NEXT Date: Wed, 8 Sep 1993 19:10:16 GMT Last Updated: 2.8.93 18:46:42 MPEG UTILITIES FOR VARIOUS PLATFORMS: OBTAINMENT INFORMATION All files may be obtained via ftp or ftpmail, some by other methods. Read individual sections for more information. [ *** = item changed/added since last release ] a. Microsoft Windows MPEG viewer info 1. Xing's MPEG Player 2. An exciting port of the Berkeley MPEG player b. IBM MSDOS MPEG viewer info 1. Xing's MPEG player for DOS! Only requires 386+, IBM or clone, VGA (320x200), and DOS! 2. DMPEG for DOS, another MPEG player for DOS machines from Stefan Eckart! Requires only 80286+, VGA. Utilizes SVGA/ram if present. c. IBM MSDOS MPEG CREATOR info 1. Graham Logan's port of the PVRG MPEG CODEC (v1.2 alpha) to MSDOS, which creates XING-format MPEGs (I-frame only) and standard MPEGs (which support I, P and B frames). 2. Stefan Eckart's (of DMPEG fame) CMPEG, a freeware MPEG CREATOR! Create Xing-compatible or normal MPEG data streams! d. Unix X-Windows viewer info e. Unix MPEG CREATOR INFO 1. The PVRG MPEG CODEC -- Also creates XING & standard MPEG animation streams f. Macintosh MPEG viewers -- CAN ALSO CONVERT MPEGS TO QUICKTIME! 1. Rainer Menes's MPEG viewer *** 2. Maynard Handley's MPEG viewer g. VMS viewer info h. Amiga viewer info i. NeXT MPEG viewers 1. Berkeley Plateau Research Group's MPEG viewer 2. A player from Brian Willoughby (BrianW@SoundS.WA.com) j. Reminders when obtaining files k. Information on obtaining files via email l. Where to obtain MPEG animations m. Using ARCHIE to find files n. How to make sure this FAQ stays current *** o. Where to get MPEG info if you have no Internet access ** p. Conclusion a. Windows MPEG viewers There are two Windows MPEG viewers. One is released by Xing Technology as freeware; the other is a Shareware viewer provided by a private party which is a port of the Berkeley v2.0 freeware MPEG player. First, I will detail Xing's MPEG player for Windows. 1. Xing's freeware MPEG player for Windows, version 2.0. I am not certain if it works with Windows 3.0, but who cares, right? Everyone uses Windows 3.1! And I know it works with 3.1. :-) Once you have Windows all you need is any SVGA card. The Windows MPEG player works with ANY SVGA card, provided it has a driver for 640x480x256 colors in Windows 3.x. Read HELP.INSTALLING.MPEG.FOR.WINDOWS for more information (see below). You may obtain the viewer via toe, simtel20 mirrors via ftp (see below) or email (see SIMTEL20.EMAIL at ftp.rahul.net [192.160.13.1] in /pub/bryanw/information, or next posting if you are reading this in a Usenet newsgroup). Herewith is the ftp info: You can get the viewer from: Site: toe.cs.berkeley.edu [128.32.149.117] Dir : /pub/multimedia/mpeg/Ports/Windows3.x File: mpegexe.zip + attendant dll (such as mddlati.zip) The viewer is also available from all simtel20 mirrors. One specific site I can remember is as follows: Site: oak.oakland.edu Dir : /pub/msdos/windows3 File: mpegexe.zip, + attendant dll (such as mdllati.zip) Here is a listing of all simtel20 mirror sites, from a recent posting by w8sdz@TACOM-EMH1.Army.Mil (Keith Petersen) to comp.archives.msdos.announce. Please remember to use the ftp site closest to you geographically: SIMTEL20 files are also available by anonymous ftp from mirror sites OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4), ftp.uu.net (137.39.1.9), archive.orst.edu (128.193.2.13), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk (146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6), nctuccca.edu.tw (140.111.3.21).... Please read HELP.INSTALLING.MPEG.FOR.WINDOWS, located on ftp.rahul.net, in /pub/bryanw/information, whence you obtained this file. It gives tips on installation and answers many questions. IP address for those whose servers don't accept names: 192.160.13.1 I spent a great amount of time compiling it, so I will hold a very low opinion of anyone who asks me for help without having read the HELP.INSTALLING.MPEG.FOR.WINDOWS file first. However, if there is a question you have which is not answered by the HELP.* file then please do send me email so I can add it to the HELP* file. 2. Berkeley MPEG player Port: Supports 15bit-24bit displays! The following is a verbatim transcription of an email message I received about this other player. It is worth a look. Please note, the author of this program, Michael Simmons, worked very hard in bringing this player to the MSDOS platform. It was not a simple port; much special work had to be done. Therefore a Shareware fee of $25 is asked. Please consider registering the program. Michael's player will play MPEGs that the Xing player cannot. Xing's player can only play I-frame MPEGs, which is what the majority of MPEGs consist of. However the number of MPEGs containing other frame types is growing, and it's always nice to have a software which will handle these other types. Let me dispel any fears those of you out there using Microsoft Windows 3.1 may have regarding installing the Win32s subsystem. To use this player, as you will learn below, you must install Win32s. This allows Microsoft Win 3.1 users to run Windows NT applications. I've installed the Win32s subsystem and tested Michael's MPEG player and experienced no problems (aside from the few bugs in the player, which will soon be fixed). My other Windows 3.1 apps run without any problems. The installation provided with Michael's player is painless and much like install programs provided with commercial programs. That is, you just run the install program, and it does everything automatically! Here is the information I received: --- begin --- ~Date: Mon, 29 Mar 93 10:00:08 MST ~From: rwebb@nyx.cs.du.edu (Russell Webb) To: bryanw@rahul.net ~Subject: Re: FTP SITE AVAILABLE FOR MSDOS GRAPHICS/UNIX UTILITIES Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept. I'm sorry to have seen your archive turned into a mini-archive, but your effort is still apreciated. Regarding the above information you currently provide: there is another MPEG player that you may have overlooked so far. Check toe.cs.berkeley.edu under /pub/multimedia/mpeg/ mpegnt.zip for a new (~March 15) Windows NT MPEG viewer, a port of the Berkeley Unix v2.0 player. It *will* run under Windows 3.1, but the Win32s subsystem is required. The Win32s package is bundled with the Spice32/ Nutmeg32 circuit design package that can be found on the ftp.cica.indiana.edu site (under /pub/pc/win3/nt/spice4?.zip, I believe). [ED. NOTE: ftp.cica.indiana.edu's IP address is 129.79.20.17] Why go through all the hassle of grabbing this if you don't have Windows NT? Because the player supports 15-bit and 24-bit color. It looks quite nice in comparison to the Xing player or an 8-bit X-Windows display. It's a bit slow (on my 486/50, 16M ram) and easy to crash--but still the only way I know of to get a hi-color/truecolor MPEG display on a PC (short of having a 15- or 24-bit X terminal on Intel hardware). I hope this information is a bit useful. Thanks again for your mini-archive and information postings. -Russell Webb rwebb@nyx.cs.du.edu --- end --- NOTE: I have been informed by the author that the latest version, complete with the Win32s package needed by the users of this new MPEG player, is available from ftp.cica.indiana.edu [129.79.20.17] in /pub/pc/win3/uploads/JUN93 as mpegw32b.zip. It is expected to be moved to /pub/pc/win3/desktop in the future. Remember, Michael's player is Shareware. If you use it, PAY FOR IT. b. IBM MSDOS MPEG viewers/converters I define an MSDOS MPEG viewer as one that views MPEGs without requiring MS Windows. And these two players fulfill that requirement, though DMPEG is quite special in this regard. 1. Xing MPEG Player for IBM MSDOS systems: No Windows required! Xing has released a Shareware viewer for MPEG files. It is important to note that this is NOT *Nagware*. There is no begging for you to register and so forth. If one choses to register, one receives better video support from the upcoming release, which will provide better resolution so that one can view the entire MPEG (320x240 resolution) complete with sound support, which this version lacks. One only needs an IBM with 80386, DOS and basic VGA (320x200x256). That's it! The program is very simple to use and command-line oriented. Syntax is "mpeg mpegfile". Because of its small size and importance, I am carrying it personally here at rahul.net. Info: Site: ftp.rahul.net [192.160.13.1] Dir : /pub/bryanw/pc/mpeg File: mpegdos.zip One may want to try using archie to see if this file exists at an archive nearer one. Try searching for "mpeg.exe." Most sites probably keep it in this form, since it is only roughly 60K in size. I opted to compress it using Pkzip 2.04g, and it is now a mere 17K. 2. DMPEG: Stefan Eckart's PUBLIC DOMAIN viewer, NO WINDOWS required! DMPEG is both an MPEG viewer AND converter. When viewing, it is important to note that it is markedly slower than the Xing player. That is, unless you CONVERT the MPEG to DMPEG's proprietary RAW format. You then use a special player, included, which will show the RAW format animation on VGA, SVGA, or VESA screens! And, hey 286 users, this one actually works on 80286 machines (albeit a little slowly). The converter does a remarkable job, and I use it for the "essential" MPEGs that I would like to view at the highest speed possible. If you have the anim loaded in RAMdisc then you have a really nice framerate even on a lowly 386! :) In the newly released 1.1 version, the converter and viewer are now included in one executable. It is important to note that this viewer will allow users to see MPEGs that the Xing player will not. This is because DMPEG is programmed to view all 3 frametypes, while Xing's player isn't. If the MPEG won't view using Xing, try this player, DMPEG. This utility is also very valuable, so I am offering it personally here at a2i via ftp. Obtainment info: Site: ftp.rahul.net [192.160.13.1] Dir : /pub/bryanw/pc/mpeg File: dmpeg11.zip c. IBM MSDOS MPEG CREATORS 1. The Port of the PVRG MPEG CODEC, by Graham Logan There now exists a way for IBM PC users to create MPEGs freely. The solution is CPU intensive and requires at least a 386, though I'm sure you'll want a 486.. And now I give the stage to Graham, who engineered the port (thanks Graham!) :-) --begin ~Date: Fri, 18 Jun 93 8:42 GMT ~From: "Graham Logan: Dept of Mechanical Engineering" To: BRYANW ~Subject: Re: MPEG FAQ UPDATE Hi, I know that this FAQ carries info on MPEG players but I have ported the latest version of the PVRG MPEG CODEC (v1.2 alpha) with an XING mode to DOS. The complete package has been posted to alt.binaries.pictures.utilities as a 9 part uuencoded zip file. The zip has also been uploaded to oak.oakland.edu and is called PVMPG1_2.ZIP. [Available in /pub/msdos/graphics. -Ed] This contains instructions on making your own version from the PVRG source as well as how to make an XING movie. Also included is 6 GIF files that were extracted from short.mpg (part of the PVRG distribution) resized for XING so that people can try it out straight away without having to get out the frame grabber. There are also tools for making the YUV files from PMM and PMM from YUV. In addition some method of converting GIF/BMP/TGA files to PPM is needed. I have discussed the port with PVRG and they seem quite happy for it to be distributed. Graham Logan mitgml@dct.ac.uk ---end 2. 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: Site: ftp.rahul.net [192.160.13.1] Dir : /pub/bryanw/pc/mpeg File: cmpeg10.zip d. Unix X-Windows MPEG viewer There is also an MPEG player for Unix X-windows platforms, which supposedly works fairly well. When I had Linux running on my 386/25 with X Windows, it worked fairly slowly, but this WAS an IBM 80386, no math compressor, and "only" 8 megs of ram. :-) Perhaps you will fare better. The term "X-Windows" encapsulates any computer which can run X-Windows software. These include Unix machines such as Suns, and other machines made by Hewlett Packard, etc. IBM computers can also emulate X-Windows using the Linux or 386BSD Operating Systems along with a port of the X windows environment. In addition, commercial Unix + X-Windows implementations are possible, but why pay for them if you only want to fiddle with X to view MPEGs? :-) For Linux information read comp.os.linux; 386BSD, see the following newsgroups for information on 386BSD: comp.os.386bsd.announce comp.os.386bsd.apps comp.os.386bsd.bugs comp.os.386bsd.questions Site info: Site: toe.cs.berkeley.edu [128.32.149.117] Dir : /pub/multimedia/mpeg File: mpeg-* e. The Unix PVRG MPEG CODEC: Make MPEGs Freely! There is a Unix alternative to making free MPEGs too! In fact, the MSDOS solution described above, was ported from this very source by Graham. I'll let various informations speak for me below. FYI, the Unix PVRC codec also creates XING and standard MPEG streams, but I believe the XING compatibility is only offered in the v1.2 beta version availble at havefun.stanford.edu (I don't know if it is elsewhere yet). The following was taken from the README at havefun.stanford.edu [36.2.0.35] --begin ANONYMOUS FTP: The following files can be obtained through anonymous ftp from havefun.stanford.edu, IP address [36.2.0.35]. The procedure is to use ftp with the user name "anonymous" and an e-mail address for the password. CODEC DESCRIPTION: I) PVRG-MPEG CODEC: (pub/mpeg/MPEGv1.1.tar.Z) 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 toe.cs.berkeley.edu (128.32.149.117) in /pub/multimedia/mpeg/mpeg-2.0.tar.Z. ---end Using archie, I found these alternate sources. If you're not in the US please try using archie to find outside, closer-to-home sources for your fileleeching needs. (See "archie" section for archie information.) 01 Host pinus.slu.se Location: /pub/graphics/mpeg/MPEG-stanford/MPEGv1.1.tar.Z File -r--r--r-- 00398093 1993 Mar 01 02:23:00 GMT MPEGv1.1.tar.Z 02 Host ftp.luth.se Location: /pub/graphics/animation/mpeg/MPEGv1.1.tar.Z File -rw-rw-r-- 00398093 1993 Apr 09 12:09:00 GMT MPEGv1.1.tar.Z 03 Host isfs.kuis.kyoto-u.ac.jp Location: /ftpmail/ftp.mei.co.jp/free/others/PVRG/mpeg/MPEGv1.1.tar.Z File -rw-r--r-- 00398093 1993 Mar 16 04:02:00 GMT MPEGv1.1.tar.Z f. Macintosh MPEG viewers 1. RAINER MENES'S MPEG VIEWER The Berkeley MPEG player seems to have provided the impetus for MPEG viewers on every system! The Berkeley MPEG viewer has now been ported to the Macintosh platform as well. Site info: Site: toe.cs.berkeley.edu [128.32.149.117] Dir : /pub/multimedia/mpeg/Mac File: mpeg_mac_* For the latest version of the Macintosh MPEGplayer, you should ftp to SUNIAMS1.STATISTIK.TU-MUENCHEN.DE (131.159.64.1) and cd to /pub/mac. Here is a description of the latest version, 0.3, taken from the README at SUNIAMS1.STATISTIK.TU-MUENCHEN.DE (131.159.64.1): --begin This dir contains the always the latest version of MPEG for the Mac. The file mpeg_mac_x.xx.sit.hqx includes a MPEG-player and a MPEG to QUICKTIME converter. The files *.mpg are for testing only. To avoid transfering the files over long distance try to find a server near you. This site suniams1.statistik.tu-muenchen.de is located in Muenchen Germany. In this dir there is a new dir utils which containts some helpfull utils, to make the MPEG-player and converter easyer to use. (Filetyper etc.) Please report bugs to menes@statistik.tu-muenchen.de -Rainer --end Please use archie to search for "mpeg_mac_0.3.sit.hqx" to find a site near you so that you don't have to ftp all the way to Germany. If no nearer site exists, or you can find no other site, then please use caution if you decide to ftp the site in Germany. I.E., do so only during "nice" hours and don't take too much at one time. Thanks. UPDATE: If you are in the USA or North America, you should use the following site. Please remember to try archie if you are not near the site where the program is offered. Thanks. Site: sumex-aim.stanford.edu Dir : /info-mac/app File: mac_mpeg* 2. MAYNARD HANDLEY'S MPEG VIEWER The following is from the author of Sparkle, an MPEG viewer and MPG->Quicktime converter for Macintosh machines. It provides information about the program and whence it may be obtained. --begin ~Date: Thu, 10 Jun 1993 02:10:32 -0400 ~From: maynard@msc.cornell.edu To: bryanw@rahul.net (Bryan Woodworth) Sparkle 1.03 is now at sumex-aim.stanford.edu in info-mac/grf/util. See ya, Maynard ~From: maynard@msc.cornell.edu To: bryanw@rahul.net (Bryan Woodworth) ~Date: Fri, 30 Jul 1993 14:37:35 -0400 Hi Bryan. Thought I'd tell you that Sparkle 1.5.2 is now out and I've seen it at the standard mac sites like sumex-aim.stanford.edu and mac.archive.umich.edu. It's an all round improvement over 1.03, being twice as fast, using a third less memory, much less likely to crash, etc etc. --end --begin [Some qualities of the viewer: ] * Mac look-and-feel. * Multi-finder friendly. Runs happily in background. * Drag-and-drop supported. * Uses QuickTime movie controller as its interface. * Converts MPEG to QuickTime movies. * Free. * In a 2MB partition it can handle a "standard sized" 160x120 MPEG. If you plan to open more than one movie at once, or have a larger sized MPEG (eg 320x24) you will have to increase the partition. I plan to improve it a lot when I get my copy of the MPEG draft international standard that's on order. Until I have that info, it's limited in some features, but still quite usable. Maynard ---end g. VMS MPEG viewer The VMS MPEG viewer is built by acquiring the regular Unix-specific mpeg source, then getting the VMS specific code. Using this mesh of code, you build your own VMS-compatible MPEG player. First, get the regular UNIX Mpeg viewer per the instructions in part "c" above. Then get the following: Site: toe.cs.berkeley.edu [128.32.149.117] Dir : /pub/multimedia/mpeg/vms File: Browse entire subdir, snag what you need Thanks to Terry Maton for this information. Here is some text from him which may be of help to VMS users: --begin OK -this is what you have to do... First go to toe.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. Then all is fine! --end h. Amiga MPEG viewers There are many MPEG viewers for the Amiga. They are all available via ftp from amiga.physik.unizh.ch [130.60.80.80] or one of its many mirrors. It is highly recommended you use the mirror geographically closest to you to reduce network bandwidth and increase transfer time. Here is a listing of all mirrors (including amiga.physik itself): Switzerland amiga.physik.unizh.ch 130.60.80.80 pub/aminet/ Switzerland litamiga.epfl.ch 128.178.151.32 pub/aminet/ Scandinavia ftp.luth.se 130.240.16.3 pub/aminet/ Germany ftp.uni-kl.de 131.246.9.95 pub/aminet/ Germany ftp.uni-erlangen.de 131.188.1.43 pub/aminet/ Germany ftp.cs.tu-berlin.de 130.149.17.7 pub/aminet/ Germany ftp.th-darmstadt.de 130.83.55.75 pub/aminet/ Germany ftp.uni-paderborn.de 131.234.2.32 pub/aminet/ USA ftp.wustl.edu 128.252.135.4 pub/aminet/ USA merlin.etsu.edu 192.43.199.20 pub/aminet/ USA oes.orst.edu 128.193.124.2 pub/aminet/ Australia splat.aarnet.edu.au 192.107.107.6 pub/aminet/ (*) (*) closed 6:30am to 4pm weekdays Here is a listing of filenames from the LONG.Z file. Merely cd to the proper subdirectory (in this case, /pub/aminet/gfx/show) and get what you need. Days Filename Directory Size/Old Description -------------------------------------------------------------------- mp.lha gfx/show 45K 83 MPEG player for EHB display. Needs OS2.0 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) You can also obtain the software via aminet using other means. From the README: OTHER AMINET ACCESSES --------------------- 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) i. NeXT MPEG players Many thanks to Stefano Pagiola for providing this information. There are two MPEG players available for NeXT machines. I know nothing about mpeg_next, since I don't have access to a NeXT and no one has given me any information on it. Perhaps someone would be kind enough to pass on some information to me so I can provide more details for all the curious folks out there? The two viewers are called MPEGPlay and mpeg_next. Thanks to Stefano for the following info on MPEGPlay: ---begin I don't know much about mpeg_next, but MPEGPlay is based on version 2.0 of the mpeg_play code from Berkeley. From the info panel: > 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. ---end MPEGPlay is done by Brian Willoughby (BrianW@SoundS.WA.com), and as Stefano says, is based on the mpeg_play code v2.0. As for mpeg_next, can anyone provide info? Please remember to get the files from the site closest to you geographically. Use archie to find sites closer to you (if you believe one exists, and I assure you, one definitely does). North America: cs.orst.edu [128.193.32.1] /pub/next/sources/graphics Look for: MPEGPlay2.?.tar.Z mpeg_next.2.0.tar.Z Europe : alf.uib.no [129.177.30.3] /pub/unix/next/source Look for: mpeg_next.tar.Z MPEGPlay2.?.tar.Z j. Reminders.. o Login anonymously. I.E. FTP server Omygosh-v2.21 "It's in there!", P in a Square Ltd READY. login: anonymous password: (enter your email address here, like "banshee@wicked.com") ...then you're in. o Use binary mode when transferring files from ftp sites. I.E. "type binary" or "binary" before transferring a file. E.g. ftp> binary Binary mode set. ftp> get mpegexe.zip ... k. Obtaining files via email Some of the sections above cover specific information for retrieving files via specific means, such as for the MSWIN Xing player (via simtel20's listservers) or the amiga (via other various means outlined in that section). For the remaining sections, it is possible to use the ftpmail server. FTPMAIL, obtaining files from a server via email which does the ftping for you, is not the best way to obtain files via ftp, but for some it is the only way. To get more information, send email to one of the servers below with the word HELP in the message body. In North America: Internet: ftpmail@decwrl.dec.com BITNET : bitftp@pucc.princeton.edu or BITFTP@PUCC In Europe: ftpmail@grasp.insa-lyon.fr l. Where to obtain MPEG animations Now that you have your glorious MPEG viewer, where to obtain MPEG files to test your program? Luckily there are a few sites whence many MPEGs may be obtained. The best site for MPEGs is toe.cs.berkeley.edu [128.32.149.117], which has a veritable slew of MPEGs available in /pub/multimedia/mpeg/movies, and a glorious MPEG MEGA demo, crafted by Stefan Hartmann (leo@zelator.in-berlin.de) in /pub/multimedia/mpeg/genoa. Another good site for MPEGs is phoenix.oulu.fi [130.231.240.17], but please use this site sparingly unless you are right next door to Finland -- bandwidth is getting expensive these days! Most files available on phoenix are already at toe anyhow. Have fun! m. Using ARCHIE ARCHIE can be used to find files you are looking for. It is a very fast and easy way to see if files can be found on archive sites closer to you. By using sites closer to where you are located, you save the Net money and resources, and that's a good thing. You can either telnet to an archie server closest to you, or use client software. Client software can be compiled on your system, making archie access easy and convenient. It is much gentler on archie and is recommended you use the archie client instead of archie via telnet. Here is some archie access info. Base info: telnet in, (login as "archie"), at the prompt enter "set search sub" and then enter the substring to search for, e.g. "prog x". If you know the exact filename you want, enter "set search exact" and "prog whatever.zip". Enjoy. *--------------------------------------------------------------------* | Archie Servers: | | archie.ans.net 147.225.1.10 | | archie.unl.edu 129.93.1.14 | | archie.sura.net 128.167.254.194 | | archie.rutgers.edu 128.6.18.15 | | | | archie.au 139.130.4.6 | | archie.funet.fi 128.214.6.100 | | archie.ncu.edu.tw 140.115.19.24 | | archie.doc.ic.ac.uk 146.169.11.3 | | archie.sogang.ac.kr 163.239.1.11 | | | | o Questions/comments to archie-admin@ans.net, site add/delete | | requests to archie-updates@bunyip.com | | | | Client software is available on ftp.ans.net:/pub/archie/clients; | | documentation in /pub/archie/doc. | *--------------------------------------------------------------------* n. How to make sure this FAQ stays current I am usually able to keep abreast of the latest MPEG developments for Unix, MSDOS, and MS Windows, but I need some help for the other platforms. Specifically, if anyone could email me when new programs are available for any of the below platforms, I would be grateful: Amiga, NeXT, Macintosh, VMS (?), Atari ST, and so forth. Not only will you be aiding me in keeping this FAQ current, but you'll be assisting those who really would like to know of the latest and greatest MPEG players for their platforms. Many people have helped me to put together this FAQ, too numerous to name. All of you know who you are -- I thank you. o. MPEG info for the Internet deprived: Frank Gadegast's TRAIL-PACK! p. Conclusion MPEG is a fascinating animation format which is compact yet offers lots of animation for the space! With ports of the MPEG player available now for most major platforms, MPEG can now be shared by almost everyone. I hope you will enjoy MPEG as much as I have. Sometimes it's annoying searching for a viewer for your platform, but it's all worthwhile in the end. -Bryan bryanw@rahul.net a2i network email bryanw@rahul.net for PGP public key =========================================================================== XI | NEWS ========== --------------------------------------------------------------------------- Xing is right now working on something called 'XingSound', that will be a programm running under Windows to encode and decode MPEG-I-Audio- sound-file. The got licence of Philipp'ss DCC-code. Xing is also working on a XingIt-Card, it will be a mixture of a digitizing card and a MPEG-board. It will write MPEG-stream (surely only in Xing-format) to the harddisk. But there will be a tool running under Windows, to create later on real MPEG-I-streams from the digitized stream. Let's see ... --------------------------------------------------------------------------- Well, here the news from the CEBIT'93 in Hannover GERMANY: Nothing special happened (except the new NeXT-Station with Intel- Board, Expansion-Slot for the Pentium and Localbus running Mach486, X11 and Windows 3.1 under the same GUI: NeXTStep) and except the MPEG-News: --------------------------------------------------------------------------- Leadtek was showing there DOS-full-screen-MPEG-player. They double the pixel in a tricky way, so they get 640x400 and the quality is really good. They told me, the player (with lots of additional software) is to buy for about $900. The contact address is: Mr. Terry Yeu at Leadtek Research Inc. Computer Graphics, Multimedia Design & Manufacture 5F, NO. 4, Alley 11, Lane 327, Sec. 2, Chung-Shan Rd., Chung-Ho, Taipei Shien, TAIWAN R.O.C. Tel: 886-2-2484101 Ext 113 Fax: 886-2-2484103 --------------------------------------------------------------------------- Sun has a new version of there 'Multimedia Solutions for Workgroup' out. And (but this is not official), they will support MPEG, but this was not to be seen. --------------------------------------------------------------------------- Here the latest infos from Stefan Hartmann, a bit more adverts ;o) From: harti@tron.gun.de (Stefan Hartmann) Subject: MPEG Texte von uns ! Date: Sat, 18 Sep 1993 23:30:00 +0200 Winhurri PRO Win3.1 software. =============================== It now supports digitisation of sound in sync with the video-harddisk- recording. The movie comes from the Michael Jackson song Black & White. You can play it with the Xing Technology MPEG for Windows Version 2.1 under Windows 3.1. The current version of the Xing MPEG player archive is called xing21.zip or mpegview.zip or mepgview.exe PC-Hurricane in this moment sells for 499.-DM incl. 15 % VAT in Germany. Together with the Xing Technology MPEG Encoder and player it is 699.- DM incl. 15 % VAT in Germany. Foreign customers could get it by VISA card payment. It is 299.-US$ including airmail delivery to you. Together with the Xing MPEG Encoder and Player software for Windows it sells for 449.- US$ incl. shipping and handling. This FTP site is only available at our local time from: 6.00 pm until 5.00 am cause this is the only time, we are connected to the Internet from Zelator BBS. The Winhurri program was programed by Patrick Hoffmann for Gatz & Hartmann (c) 1993. All rights reserved. We can't be sued for damage on your hardware and/ or software that might occur by using this software. --------------------------------------------------------------------------- PC-HURRICANE This description was still written for our old DOS Software, that still comes with the PC-Hurricane, for those who don't like to use Win3.1.... It is a hicolor color YUV (4:1:1) realtime video movie digitizer which can store 25 frames/sec(PAL) or 30 frames/sec (NTSC) into Expanded Memory. It has support for ET4000 Hicolor and true color boards and all VESA1.2 compatible SVGA cards. The software is a userfriendly DOS (or win3.1) software, which displays the incoming video signal in almost realtime (about 5-10 frames/sec) on a Hicolor board in 32768 colors/pixel or on a 256 color board. This is okay for video purposes, cause the noise inside a video movie almost does already the dithering to a true color quality.(simualar to 24 bit quality) If you don't have a Hicolor card inside your PC, then there is also a 256 color version driver, which displays the video signal in almost realtime in 3-3-2 color quantisation. (still the TGA pics are saved as 16 bit Hicolor/pixel, so quality from the saved output is the same as in the Hicolor software driver) If the sequence arrives, which you wanna digitize, just hit the space key. Then it is digitized into the Expanded Memory in realtime with 25 or 30 frames/sec maximum rate. This can be adjusted to 12.5 or 8 or 4 frames/sec ! During this storing process, you will not see any signal on your VGA monitor, but if the RAM is filled with e.g.396 frames at 320x240, then you can already watch the digitized movie play of the Expanded Memory! It plays in slow motion the YUV coded fields to the SVGA card via the ISA bus. This gives a slow motion Hicolor digital movie out of the RAM ! So if you have 32 MBytes of Ram on your motherboard, you can be happy. Then you can store about 16 seconds of realtime MPEG resolution 320x240 true color video with one shot ! Or doubble this, if you just only take 12.5 frames/sec... With the enclosed software you can save this with one command to single TGA pics onto the harddisk or save it as a complete Hicolor movie (uncompressed, big file size). PC-Hurricane also digitizes the resolutions: 384x288, 360x240, 320x240 and 320x200. So max. resolution is 1 PAL field (384x288). Field digitisation is preferred, cause it gives no Interlace artifacts, due to motion... PC-Hurricane has NTSC/PAL switchable. So it can also digitize NTSC video. It has Video(FBAS) and Y/C(SVHS/Hi8) inputs. --------------------------------------------------------------------------- Hi, for recording SVGA animations or VGA (also 24 bit support) presentations we currently have the following products over here in Germany: We currently have three solutions for you: 1. 24 bit to TV converter box which is a box connected outside of the PC to the SVGA card via its VGA connector. There must be a TSR program run in the background to change automatically the scanning frequencies of the SVGA board. This works also very well with win3.1 It supports up to 800x600x 65K colors (only PAL) and 640x480 with 24 bits color (true color) on the Genoa 7900 ET4000 SVGA board. It has Video (FBAS) and Y/C (SVHS/HI8) outputs. There is also a version of this box with additional RGB output, so you get the best picture quality on a TV-set with SCART - RGB-inputs.. The VGA Monitor is also connected to the 24 Bit to TV converter box, so if you don't start the driver software, your system is like normal: You see the picture on your SVGA monitor. The DC-power comes from the keyboard connector, so you don't have to fiddle around with AC-DC-aptor power supplies ! Just don't start the driver software, if you don't need video out ! The box doesn't interfere with your daily work. Just forget it behind you PC. If you need video out, just start the 2 KBytes driver software and then you can toggle between video out and VGA monitor display with a hot key ! The driver software is adapted to SVGA FLIC-files from Autodesk Animator PRO to give a 640x288 x256 colors Fullscreen-Overscan display on PAL TV-sets. This works by using double scanning with 50 Hz Non-Interlace ! Every scanline from the 288 is scanned twice, so it gives 640x576 Fullscreen display ! (with no flicker) This way you can record your favourite SVGA animations to tape without seeing any black borders ! There is also a NTSC version available, which works only up to 640x480 with 16, 256 ,32K , 65 K and 24 bits colors ! On NTSC model the 640x480 mode is already Fullscreen ! It also works with the new Hicolor FLI player, so you can play and record hicolor animation directly from a RAMdisk to VCR tape.. You don't need NO single frame accurate expensive VCR anymore ! Cause it works also with win3.1, you can record all your daily windows application work to video tape ! If you have a presentation program like Microsoft Powerpoint, no problem ! Just record your presentation to video tape to show it via video cassette to everyone, who has a VCR ! In windows the 24 bit to TV-box works in 50 or 60 Hz Interlace to display the 640x480 or 800x600 (only PAL) scanlines. This gives a little flicker on Menu-buttons, which have only very small horizontal lines with big contrast in color. So use an appropriate color palette under windows to reduce flicker.. With the Y/C output (SVHS/Hi8) you almost get SVGA monitor quality on your video tape ! 2. VGA2TV PRO adaptor. This is an internal board which is hooked inside the PC to the feature connector of the VGA card. So the VGA or SVGA board must have a feature connector ! The VGA2TV PRO samples the contens of the VGA RAM into its own dual ported RAM and gives it out with the Video scanning frequencies to its Video (FBAS) or Y/C output. It also has a Genlock possibility. So it can be used to do titling in front of a holiday movie video tape running in the background of the computer graphics titles ! Input of the external video source could also be FBAS or Y/C. VGA2TV PRO comes with integrated Flicker fixer. It has the flicker filter for making the Interlace flicker much less visible. It also has OverScan/Underscan feature and the position of the screen on the TV set could be controlled via software. Max. resolutions to convert VGA to TV with this VGA2TV PRO board is 640x480 with 256 colors ! It has the advantage, that it does not need any software ! Just plug and it plays ! Does not work with Cirrus Logic VESA Local Bus graphics cards ! 3. GL 800 Genlock Interface PC-Card. ==================================== This is our brand new own development. It works like the VGA2TV Pro card, but it has also 800x600x256 support and also can Overlay, MIX and Fade-In and Fade-Out the VGA graphic over the background video input. It does not have a flicker fixer, but works very stable. It has RGB, FBAS and Y/C outputs and Y/C and FBAS inputs. We recommend this board for fullscreen PAL output from 800x600 SVGA screens. This board is only 799.-DM incl. 15 % VAT. This board also works with VESA Local Bus cards ! --------------------------------------------------------------------------- PRODUCTLIST: Genoa 7900 SVGA 24 bit true color Multimedia Graphik-Karte.... 229.-DM ET4000 Chip, 640x480x24 bit Windows3.x Treiber, etc.. Genoa 8500 SVGA Win3.1 Accelerator Karte, true color...........249.-DM Genoa 8500VL SVGA Win3.1 Accelerator Karte,Vesa LB true color..269.-DM Genoa VideoBlitz Karte, P9000 Weitek chipset, 1600x1200x256 NI!.. 999.-DM 24 bit to TV Konverter Box, passend zu den Genoa Karten.......349.-DM 24 bit to TV Konverter CARD, passend zu den Genoa Karten......299.-DM 24 bit to TV Box mit zusaetzlichem RGB-Video Ausgang auf Scart..449.-DM 24 bit to TV CARD mit zusaetzlichem RGB-Video Ausgang auf Scart.399.-DM VGA2TV Pro Genoa Genlock-Karte,intern, Computergrafik ueber Video..999.-DM GL 800 Genlock card, up to 800x600x256 support.....................799.-DM PC-Titler Standard,Video Vertitelungs-Software fuer VGA-Karten.199.-DM PC-Titler Deluxe, Profi-Version vom PC Titler, mehr Effekte....399.-DM The Video Director, PC gesteuerter Video-Schnittplatz..........499.-DM Xing MPEG Encoder, digitales Video per Software,fuer TGA+BMP-pics...199,-DM MPEG Demo, 3 Disketten mit dem neuen WAV-support MPEG-player ....39.-DM PC-Hurricane,25 Bilder/sec realtime movie-grabber(Film Digitizer).499.-DM PC-Hurricane mit Xing MPEG Encoder und Player Software............699.-DM FG-02 , Hicolor DTP Framegrabber, 512x512 pixel Videodigitizer.499.-DM VT-Express,sehr schneller JPEG-Bild viewer, ca. 1.2 sec/Bild...199.-DM Hicolor(32768Farben) Animations-Software f. TGA-Animationen ...149.-DM email to: harti@tron.gun.de =========================================================================== XII | QUESTIONS ================ These are some questions, ideas or whatever problems, where still no solutions is found or nobody knows an answer. Please contact me via e-mail if YOU find a solution for: 1) Is there somebody out there (maybe from the MPEG-group), that could write an additional section for this FAQ, to bring it up to MPEG-II ? [ It looks like if somebody will do it ... but that should not stop ] [ you to send any related information. ] 2) Is Xing connected to the internet or compuserve or something ? 3) 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. 4) Is there a COMPLETE mpeg-stream somewhere out there ? Meaning including a system-, video- and audio-stream ... 5) Where is some code doing MPEG-Audio ? Or audio-streams ? Who's working on it ? 6) Who can send me informations about MPEG-I-Videos stored on CD-I CD's ? Are there driver or programs that read CD-I CD's with a coumputer CD-ROM-drive ? Please mail to: phade@cs.tu-berlin.de if you have for inormation, than I have. =========================================================================== The end of ... THE MPEG-FAQ ==================================================== PHADE SOFTWARE Leibnizstr. 30, 10625 Berlin, GERMANY Inh. Frank Gadegast Fon/Fax: +49 30 3128103 phade@cs.tu-berlin.de ===========================================================================