The entire ppmtojpeg directory was adapted by Bryan from the package mpeg_encode-1.5b-src (subdirectory mpeg_encode) on March 30, 1999. The program was called mpeg_encode in that package. It was dated August 16, 1995 and came from ftp://mm-ftp.cs.berkeley.edu/pub/multimedia/mpeg/ encode/mpeg_encode-1.5b-src.tar.gz Changes for Netpbm include: - mpeg_encode recognizes two input formats: "PPM" and "PNM". For PPM, mpeg_encode parses it itself. For PNM, it uses the Netpbm PNM library routines. In the Netpbm version, PPM is gone and "PPM" is accepted as a synonym for "PNM". For PNM, it uses the PPM (not PNM) Netpbm library routines. - mpeg_encode PNM code is broken for maxval != 255 (divides by zero if maxval < 255 and overly quantize if > 255 because PNMtoYUV() uses an integer divisor = maxval/256). In November 2004, Bryan rewrote large portions of the code so that he could read it easily enough to debug some problems. He eliminated long subroutines, global variables, gotos, and the like. See the file LOGIC for some documentation on how the code works. The following is the README from the aforementioned mpeg_encode subdirectory. MPEG-1 Video Software Encoder (Version 1.5; February 1, 1995) Lawrence A. Rowe, Kevin Gong, Eugene Hung, Ketan Patel, Steve Smoot and Dan Wallach Computer Science Division-EECS, Univ. of Calif. at Berkeley This directory contains the freely distributed Berkeley MPEG-1 Video Encoder. The encoder implements the standard described in the ISO/IEC International Standard 11172-2. The code has been compiled and tested on the following platforms: DECstation 5000 and Alpha HP PA-RISC (HP/UX 9.X) (i.e., HP 9000/7XX and 9000/3XX) SGI Indigo running IRIX 5.0.1 Sun Sparc (SunOS 4.X) In addition, Rainer Menes from the Technical University of Munich has ported the encoder and decoder to the Macintosh. You can get that code directly from him (menes@statistik.tu-muenchen.de), or from the Berkeley FTP archive (mm-ftp.CS.Berkeley.EDU). If you decide to port the code to a new architecture, please let us know so that we can incorporate the changes into our sources. This directory contains everything required to build the encoder and run it. We have included source code, makefiles, binaries for selected platforms, documentation, and test data. Installation instructions are given in the file named src/mpeg_encode/INSTALL. A man page is given in the file doc/mpeg_encode.1. A detailed user manual is provided in postscript format in the file doc/user-manual.ps. The encoder will accept any input file format as long as you provide a script to convert the images to PPM, YUV, JPEG, or JMOVIE format. Input file processing is described in the file doc/INPUT.FORMAT. Options to control input file processing and compression parameters are specified in a parameter file. Very little error processing is done when reading this file. We suggest you start with the sample parameter file examples/template.param and modify it. See also examples/default.param. The convert directory of Mpeg-Tools contains utilities you might find useful including: programs to do PPM/YUV conversion and programs to convert Parallax XVideo JPEG files into PPM, YUV, or JPEG frames. The motion vector search window can be specified, including half-pixel block matching, in the parameter file. We have implemented several search algorithms for P-frames including: 1) exhaustive search, 2) subsampled search, and 3) logarithmic search. We have also implemented several alternatives for B-frame block matching including: 1) interpolate best forward and best backward block, 2) find backward block for best forward or vice-versa (called CROSS2), and 3) exhaustive cross product (i.e., go out for coffee and a donut!). The search algorithms are controlled by options in the parameters file. For tips on choosing the right search technique, see the user manual. The encoder can be run on one computer (i.e., sequential) or on several computers (i.e., parallel). Our goal is to produce a portable, easy-to-use encoder that we can use to encode large volumes of video material for the Berkeley VOD system (see paper VodsProp93.ps.Z on the FTP archive). The parallelism is done on a sequence of pictures. In other words, you can spawn one or more children to encode continuous runs pictures. The uncompressed data can be accessed either through NFS or TCP sockets. The goal is to allow you to encode using multiple processors, think spare cycles on workstations, to speed up the encoding time. Although performance depends on the speed of individual processors, the file system and network, and the P/B frame search methods, we have encoded 3.75 frames/second on 8 HP Snakes running in parallel as compared with 0.6 frames/second on 1 Snake. These are preliminary results. We are continuing to experiment with and tune the code. Instructions to run the parallel system are given in the man page and the parallel.param example parameter file. We have done some tuning to produce a reasonable encoder, but there are many more optimizations that we would like to incorporate. These extensions are listed in the file doc/EXTENSIONS. If you succeed in implementing any of them, please let us know! Send bug reports to: mpeg-bugs@CS.Berkeley.EDU Problems, questions, or patches should be sent to this address. Anyone interested in providing financial support for this research or discussing other aspects of this project should contact Larry Rowe at Rowe@CS.Berkeley.EDU (+1 510-642-5117). This software is freely distributed. That means, you may use it for any non-commercial purpose. However, patents are held by several companies on various aspects of the MPEG video standard. Companies or individuals who want to develop commercial products that include this code must acquire licenses from these companies. For information on licensing, see Appendix F in the standard. ACKNOWLEDGEMENTS: We gratefully thank Hewlett-Packard and Fujitsu who provided financial support for this work. We also want to thank the following people and organizations for their help: Jef Poskanzer who developed the pbmplus package. --------- Copyright (C) 1989, 1991 by Jef Poskanzer. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. This software is provided "as is" without express or implied warranty. --------- Eiichi Kowashi of Intel and Avideh Zakhor of U.C. Berkeley who provided valuable suggestions on motion vector searching. Chad Fogg of the University of Washington who has helped us understand many issues in MPEG coding and decoding. Rainer Menes of the Technical University of Munich who has ported the the Berkeley MPEG encoder and decoder to the Macintosh, and he has provided us with many suggestions to improve the code. Robert Safranek of ATT for comments, suggestions, and most of the code for custom quantization tables. Jim Boucher of Boston University for jmovie2jpeg. The San Diego SuperComputing Center for providing facilities to develop some of the code contained within. This is the TODO file from the original Berkeley package: TODO list for next release -------------------------- Add option to do searches in Cr/Cb as well as Lum blocks jpeg5! (below) last-frame must be P/I error, and pattern interact badly add gnuconfigure so the Makefile is cake YUV correct (cf mail below) fix the "ifdef BUGGY_CODE" code in bframe.c Change sizing stuff so it works with non multiples of 16 Does "RESIZE WxH" work? Seems to for PPm but not JPG. Fix it. Document it mpeg_encode in parallel generates a "zero size warning" It should exit(1) here, when not in parallel, and not warn when in parallel. sometimes it generates a 0x0 MPEG! Give time estimates for parallel encoding Verify YUV file sizes with stat() call (when not STDIN) -------------------- YUV mail: Please have a look on these few lines extracted from the ISO mpeg2encode/readpic.c/read_ppm() available on ftp.netcom.com:/pub/cf/cfogg/mpeg2 : ......... /* convert to YUV */ y = cr*r +cg*g +cb*b; u = cu*(b-y); v = cv*(r-y); yp[j] = (219.0/256.0)*y + 16.5; /* nominal range : 16..235 */ up[j] = (224.0/256.0)*u + 128.5; /* nominal range : 16..240 */ vp[j] = (224.0/256.0)*v + 128.5; /* nominal range : 16..240 */ ........... I think there is a slight misunderstanding in the Berkeley's mpeg1 codec about what the YUV format looks like, exactly about how to translate from PPM to YUV and vice versa : the dynamic of YUV format has to be reduced as described above. Otherwise, on a full color display a Berkeley's MPEG bitstream has not exactly the right colors if played by an ISO compliant player. Best regards Thierry GODIN -------------------- And just for fun, kevin's list: To-do list (in no particular order) ---------- - should delete decoded frame files when done with them (need to make sure no one else needs it) - port to CM5 - try on Snake cluster, and other clusters (FDDI -- 100Mb/s) - fix bug on snakes (look at header file for queue length) - look at 24-bit display - try having I/O server getting things in order, and asking Master where to send them - bug: closing connections at end (on DEC 5000) - GOP on space in input list - pnm convolve - telescopic search - include system layer - update documentation - show error images - graphical interface (showing motion vectors, etc.) - use DCT-space when computing error terms - vary the q-scale according to the error term - modify the program to have a finer-grained parallelism option -- we can probably encode slices in parallel (this will only be useful if we want to do a few B-frames using exhaustive search) - make search technique stop at x.5, not x.0 - pel aspect ratio in parameter file (2.4.3.2) - skipped blocks options? - recover from parallel machine errors? - subsample B-search - bug: decoded with 1 machine can freeze - malloc bug: hello.param, with DECODED frames only - portability: times() function popen/pclose Oh yes, I liked the concept of a spiral for your full search algorithm, however I thought this code a little difficult to read. What about using a look up table (pre generated at compile time) to generate the coord offsets that would then spiral around the location in question? + change MAXPATHLEN to something else + put ./ in test in Makefile Currently, the IPPBPBB sequence is fixed for the entire sequence. A later version should probably either test for scene changes or allow the user to specify them. + check all << and >> to make sure they are used properly (note truncation of >>) + allow variable bit rate + allow size of video sequences to be set + make REMOTE usage more clear + fix bug: when I-frame only, and decoded, does a lot of extra work + replace ZAG[i] with a pointer? (in quantization) (and speed up by using 31 times the space (one for each q-value) + add interrupt handler to parallel encoder + should pad black instead of truncating - graph histogram of motion vectors - allow new PATTERN statements inside of file listing - put in run-time checks for size of int32, int16, etc. - replace pnm crap with ppm.dwallach - add option to allow different p-search in b-search - allow -frames option along with parallel option (shouldn't be too difficult) - incorrect compression rates given if do -frames option - enforce: >Hmmm...I will have to look at the standard. I did find something earlier -- >"forced updating" makes it illegal to have more than 132 P-frames without an >I-frame. But "forced updating" does not disallow any number of consecutive >B-frames. I'll have to check on limits for GOP lengths... - rectangular search windows - make parallel stats to 4 digits One of my friend just fixed the problem.....she retype the whole parameter file and it is working now. I think the problem was there were some spacing problem......for example, if there are some space is the line, when the program read in....it just mess everything up. It really become a problem if there is space after the image name... or even after the path name. Subject: may not want to >> 4 in postdct.c ------------------------------------------------------------------------ P.S. In the future versions (is one already been released), you could add option for encoder to remove picture after encoding it & therefore saving space on disk + option to sleep while picture it's waiting for is not done. I've hacked this: (in readframe.c) while ((tempfile = fopen(fullFileName, "r")) == NULL) { fprintf(stderr, "Cannot open '%s', retrying...\n", fullFileName); sleep(120); } fclose(tempfile); arijan@kette.fer.uni-lj.si