MPEG2 Specifications

Hi Everyone,

I received the following specifications from a client and I'm not quite getting it.

15 Mbps MPEG-2 using MP@ML and Long GOP at the Native Frame Rate, Program Stream

As far as I can tell MPEG-2 is limited to 8 Mbps and does not stream.

I'm using Compressor 2.01 with FCP 5.0.4


How do you all interpret this specification?

Thanks
Philip Robert

Hey Philip,

my initila question would be, what does the client ultimately want to do with the mpeg2 file?
does he want it for archival purposes, does he want it to create a DVD, does he want to upload to web, does he want to deliver to a cable station to air (VOD)?

when you ask your client and get back to us, i can tell you which way to proceed.

In the meantime, let me interpret the above spcification:

"15 Mbps MPEG-2 using MP(Main Profile) @ML(Main Level)":
The MP is one of about 5 that defines the file. All this says is that the GOP structure is the infamous (I,B,P) with a YUV color sampling of 4:2:0 and would be interlaced.
The ML is one of about 4 levels that defines the resolution, the frame rate/scan lines and the maximum bitrate allowed.

"Long GOP": is the standard 15 GOP size for NTSC (BIBBPBBPBBPBBPB) and 12 GOP for PAL (BIBBPBBPBBPB). Closed or Open GOP would really not matter in this case, for the most part.

"Native Frame Rate": all this means is that if the frame rate for your video is 29.97, then keep it like that, if it is 25 FPS, then keep it like that. Clients usually say this when there is the slight chance of the file being uploaded for web content.

Program stream (elementary streams) are the unmuxed, raw mpeg2 files. you will more than likely have a file with the extension of *.m2v which is only video and will have audio file with the extentions of either *.aif (*.wav if created in windows) or *.ac3 (Dolby). This usually means that the client will mux (build/compile) the file him/herself.

<<<In the meantime, let me interpret the above spcification: >>>

Well.

I'm out of breath.

Don't you traditionally start with a complete I frame? Otherwide, the Bidirectional frames don't have anything to base themselves on.

I understand you can do anything, but then MPEG decoders have to make special provisions to decode odd streams and it's not optimal.

Koz

Bloody hell. That's scary talk. I'm glad I still deliver on tape.

How would you go about making a program compliant to those kinds of specs? Given the long GOP talk, it sounds like HDV?

I'd appreciate a lesson on this.

Hi Mikey,

Thanks for the information. After talking things over with the client I discovered that his client is going to convert these files to flash for internet use. ????

Much easier for me to take the SD video directly to flash, and his client doesn't have to do that grunt work.

I'll keep mpeg 2 for DVD's that's a use that I can understand.

Always
Philip

<<<I'm glad I still deliver on tape. >>>

Tape? Long thin brown plastic ribbons?

The IBBPBB thing is one of the techniques that make MPEG2 so efficient. Most video doesn't change from frame to frame. Quick, if you took almost any of your videos and stepped one frame back and one frame forward, can you clearly tell which frame you're on? I can't either. "I" frames are the only real video. The Predictive and Bidirectional frames are difference frames. How different is the frame you're standing on now from the last one and the next one. Just send the differences. Sending whole frames, most of which are duplicates, is enormously wasteful.

The joke is the English Drawing Room Comedy. Since the scene doesn't change and nobody moves for 20 minutes at a time, all the B and P frames are zero except for a mouth or an arm here and there.

This is also grandly called Temporal Compression. If time goes by and the scene doesn't change, don't send anything.

There are problems. At an aggressive scene change, the neat parade of tiny B and P frames falls apart. There is a 100% change in video all of a sudden and the B and P frames become very large and messy. We could really use a forced I frame at the scene changes. We need something like, I don't know, compression markers?

Koz

I understand the whole i frames, bidirectional frames and stuff. What I don't understand is how you would prep a file to meet specs like "15 Mbps MPEG-2 using MP@ML and Long GOP at the Native Frame Rate, Program Stream"

OK. A 15mbps MPEG-2. Thats OK, I think, but Main profile at main level? According to Mikey, that means that " the GOP structure is the infamous (I,B,P) with a YUV color sampling of 4:2:0 and would be interlaced."

Great. How do you do that?

<<< Great. How do you do that?>>>

Someone will correct me, but I think you have to work hard *not* to do that. With the possible exception of the 15mbps thing, that pretty much defines the normal output of Compressor. Don't send the Lithuanian Second Language, Don't send Multiple Camera Angles, Don't send....etc.

The MPEG2 show you shipped last Thursday was already Main Profile, Main Level, YUV, etc.

Koz

Hey Guys

Kozikowski is right as far it is difficult not to make a MP@ML stream. almost any DVD encoder, by nature will do this. of course there are mpeg2 encoders that are DVD compliant (i.e. MP@ML) and yes there is a difference between a DVD encoder and a mpeg2 encoder.

Philip, i am glad that you made it easier for your client and will be able to deliver a file that he ultimately wanted, remember, communication with the client! not only that, he would have compressed a already compressed file, and i am pretty sure he would have had problems muxing these files, then would have probably given you a hard time about it (experience speaks).

Kozikowski, depending on the encoder is how the GOP structure is defined. i have an encoder that starts with BBI..., another that is BIB... and then i have compressor that is IBB. DVD decoders are so versatile today that it would see the BB or the B as a buffer until it references the I frame on the initial GOP structure only. after that, it would reference the previous structure.

Cool. I get that. Thanks guys.