Here are some of the Whys and Wherefores of MPEG symbols:
These 32-bit byte-aligned codes provide a mechanism for cheaply searching coded bitstreams for commencement of various layers of video without having to actually parse or decode. Start codes also provide a mechanism for resynchronization in the presence of bit errors.
(CBP not to be confused with Constrained Parameters) When the frame prediction is particularly good, the displaced frame difference (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.
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.
Saves unnecessary run-length codes. At optimal bitrates, there tends to be few AC coefficients concentrated in the early stages of the zig-zag vector. In MPEG-1, the 2-bit length of EOB implies that there is an average of only 3 or 4 non-zero AC coefficients per block. In MPEG-2 Intra (I) pictures, with a 4-bit EOB code, this number is between 9 and 16 coefficients. Since EOB is required for all coded blocks, its absence can signal that a syntax error has occurred in the bitstream.
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 evaporated. Stuffing can be achieved 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, macroblock stuffing is now illegal in MPEG-2.
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.
How would you explain MPEG to the data compression expert ?
What are the implementation requirements ?
MPEG pushes the limit of economical VLSI technology (but you get what you pay for in terms of picture quality or compaction efficiency)
Video Typical decoder Total DRAM bus width Profile transistor count DRAM @ speed ------------ ---------------- ------- ------------------- MPEG-1 CPB 0.4 to .75 million 4 Mbit 16 bits @ 80 ns MPEG-1 601 0.8 to 1.1 million 16 Mbit 64 bits @ 80 ns MPEG-2 MP@ML 0.9 to 1.5 million 16 Mbit 64 bits @ 80 ns MPEG-2 MP@High1440 2 to 3 million 64 Mbit N/A70 or 80ns DRAM speed is a measure of the shortest period in which words can be transferred across the bus. In the case of MPEG-1 SIF, 80ns implies (1/80ns)(16bits) or about 25 MBytes/sec of bandwidth. Lack of cheap memory (DRAM) utilization is where the original DVI algorithm made a costly mistake. PAL required expensive VRAM/SRAM chips (a static RAM transistor requires 6 transistors compared to 1 transistor for DRAM). Fast page mode DRAM (which has slower throughput than SRAM and requires near-contiguous address mapping) is viable for MPEG due almost exclusively to the block nature of the algorithm and syntax (DRAM memory locations are broken into rows and columns).
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.)