How do you tell the difference between an MPEG video file that's MPEG-1 vs. MPEG-2? The parts of the header I'm looking at now seem to be identical between the two, so obviously I'm missing something.

MPEG2 is a comercial format. and it has more complex encoding algorithm. you can't play MPEG2 with your MPEG1 players because MPEG2-stream absolutly incompartable with MPEG1.

"A commercial format" - Could you please define what you regard as a "commercial format"? Wouldn't Vorbis be commercial too, if it was used commercially?
MPEG2 specs are open just like MPEG1's and 4's are, so what's your point?

MPEG2 is windely using in video industry. most of encoders have MPEG2 support only in comercial versions, not in freeware...

That's licensing, not commercialism. Though, I guess the two can go hand in hand.

Let me rephrase, since this is going nowhere - which byte(s) do I need to look at to differentiate between MPEG1 and MEPG2? I assume it would be somewhere in the header starting with 0x000001B3, which contains info on frame rate, bitrate, pixel aspect ratio, etc, but it's not there (as far as I can tell). So where should I look?

It's easy at the system level, because the PES packet headers have a different structure. But since an MPEG-2 system may contain MPEG-1 video, I assume you're more interested in knowing the video stream type.

0x000001B3 begins the sequence_header of every MPEG video stream. But in MPEG-2, this header must immediately be followed by an extension_start_code (0x000001B5) with a sequence_extension ID (1). (This extension contains all the additional MPEG-2 stuff.) MPEG-1 doesn't have this extension, so that's a sure way to tell the difference between MPEG-1 and MPEG-2 video streams.

Thank you fccHandler!! That is exactly the kind of information I was looking for!

MPEG-2 video basic is very much similar to MPEG-1 video, both are DCT based Transfrom coders with motion compensation..

However, MPEG-2 can support interlaced video in which MPEG-1 can't.. (MPEG-2 has a very different zig-zag scanning of DCT coefficients for interlaced video..)

Also, there are many profiles in MPEG-2 supporting all sorts of applications such as DVD, HDTV, Scalability and etc-etc.. MPEG-2 is more sophisticated..

Beside interlaced support, MPEG2 also offer greater DC-coefficient precision(Precision of the DCT transformed information). This leads to higher picture stability in MPEG2 compared to MPEG1, since there are less rounding inprecisions.

MPEG2 is mainly aimed at much higher bitrates than MPEG1.

EDIT: Does anyone know if MPEG1 can have individual per macroblock quantizers as MPEG2 can?

Yes, it's the same in MPEG-1. Each macroblock can have a quantizer scale code, used to index a linear table of quantizer scale values. The only difference is that MPEG-2 adds an optional non-linear table which allows for higher values of quantizer scale.

Another question about the search range of the motion compensation.. Since MPEG2 can be used for resolution as high as 1920 *1440 pixels (HDTV) wouldn't this mean that the search range will be greatly increased compared to those videos of a much lower resolution such as 320*240 pixels ?

If so, doesn't this mean that the motion compensation complexity will be increased many folds?

Good question. IIRC the MP@ML profile is limited to 720 x 576, so I assume HDTV would require a higher profile/level, perhaps with less restrictions on motion vector length. And obviously the MC work of the encoder increases exponentially as you increase the search range.

I don't think there are any restrictions on length of motion vectors in any MPEG format. But longer MV's are more costly than shorter, bitwise. MPEG4 is unrestricted in terms of MV-length, and I think it's the same for MPEG1+2.

For a similar sequences of an object in motion captured in 320*240 pixels and 1920*1440 pixels, the same object would have travelled much further (measured in pixels) in the 1920*1440 capture size in comparison to the 320*240 size.. It is would only mean that the motion search range would have greatly increased many folds for high resolution MPEG2 compression and so would the complexity of the motion search module.. I wondered if anyone could provide some numerical data on the computational complexity of the motion search as the video size increases?

Actually, I did implemented an 320*240 MPEG1 video encoder running real time on a Pentium 200Hz MMX. I noticed that the motion search module consumes a VERY-VERY large percentage of the CPU time, almost 75%.. I spent a lot of time optimizing this module..

In the case of 1920*1440 resolution, this problem is HORRIFYING!