mpeg-2 encoding, some thoughts.

farss wrote on 11/2/2004, 3:55 PM
No, this isn't about which is the best mpeg-2 encoder, it's about how to get the best out of any encoder. This isn't anything new, just stuff I've gleaned from a bit if searching and reading. To learn more you'll need to do your own but hopefully this will wet your appetite enough to go looking.

Firstly mpeg-2 encoding uses temporal compression, most probably know this and what it means but you need to keep that very much in mind when preparing or creating material for DVDs. But a further consideration is that the encoder(s) work on frames, not fields. The DVD spec was written primarily for movie release, starting with progressive scan material at 24fps.
To handle interlaced material the fields are merged into frames and the compression applied to the resulting frame. The player extracts the fields for output to the display device. However mpeg-2 works at 4:2:0 which looks like it's the same as PAL DV25 except the sampling matrix is different in mpeg-2 and remember the sampling is being done at the frame level. I'm suspecting this normally doesn't present any issues but still worth keeping in mind.

To get back to the issue of preparing material for temporal compression. This has been well covered in many places; the need for noise reduction is a vital area. Remember the encoder is looking at the difference between each pixel between frames, noise and dropouts are a nightmare for the encoder, they'll use up bandwidth big time. Wobbly shots are another big no no. But in general most well shot DV25 should encode fairly easily.

But there's another thing we can feed into the encoder, generated media, it can be still images or CGI.
Now this stuff can be at very high resolution, both in color sampling and in detail. If it's static then the encoder can do a great job. But what if we animate it, either in Vegas or in our CGI application. Lets look at a simple example. Create a vertical graduated fill in PS, save it in a lossless format, move the fill up one pixel in PS and save as a new frame. Now bring those two frames into Vegas and feed it to the encoder, Vegas feeds that at full res to the encoder, great you might think. Except we've now got two adjoining frames in which the value of every pixel has changed! Not a problem when rendering out to DV25 but a big ask for any mpeg-2 encoder. I'm suspecting using lossy compression to save the images would give the encoder much less stress. This is a pretty extreme example but it should show the issues you need to address, with almost all "natural" video the best quality input will give the best quality output, the same may not apply with generated media.

All compression systems, both for video and audio are based around how we see and hear. Normally they work just fine, however when we feed them things that aren't natural sources we need to be very careful lest we trip them up.
Some of what I've said here could have technical errors, anyone who knows better please feel free to correct me.

In any case my encoding workflow goes like this:
Check my source material for things I know will be hard to encode and fix them at the source, if I can't then at least I know not to blame the encoder. Check the encoded output, if I see something that looks bad address the issue at the source, you may well find that in some situations technically making your source worse will give a better result out of the encoder. Hollywood has way better encoders than most of us can afford and they still put a big effort into what goes into them.

With a moderate effort and without spending any more you should be able to get excellent results from the encoder that ships with Vegas. I'm not for a minute saying you cannot get better results with much more expensive encoders and if you have the budget then go for it. But even then the most capable encoders will give even better results if you prepare the material properly first.

Sorry for the long post, hope it at least gets a few heads thinking.

Bob.

Comments

Cunhambebe wrote on 11/2/2004, 6:08 PM
.....But there's another thing we can feed into the encoder, generated media, it can be still images or CGI.
Now this stuff can be at very high resolution, both in color sampling and in detail. If it's static then the encoder can do a great job. But what if we animate it, either in Vegas or in our CGI application. Lets look at a simple example. Create a vertical graduated fill in PS, save it in a lossless format, move the fill up one pixel in PS and save as a new frame. Now bring those two frames into Vegas and feed it to the encoder, Vegas feeds that at full res to the encoder, great you might think. Except we've now got two adjoining frames in which the value of every pixel has changed! Not a problem when rendering out to DV25 but a big ask for any mpeg-2 encoder.

I totally agree with you.................................................
farss wrote on 11/2/2004, 6:24 PM
Thought you'd like that bit.
From memory you're doing a lot of that kind of work, it might be worthwhile looking into just how you're creating your CGI stuff with the encoding issues in mind.

If it's all CGI have you thought about doing it at 24p? The players will still convert to 50i or 60i as needed but you'll avoid interlacing issues, the stuff will also look good on computer playback etc.

Bob.
Cunhambebe wrote on 11/2/2004, 6:41 PM
Haven't thought about that. I render in Lightwave at 29.something......Most of the video looks terrific but the series showing a spaceship flying onver a red planet.......is awfulll. Lots of banding. I've already read what you've written about color space conversion issue. Can you pelase help me with that?
Thanks.
If you want, please tell me a place where I can upload my TGA files, so that you can take a look and try to render them yourself. ;)
riredale wrote on 11/2/2004, 7:58 PM
A thoughtful discussion, but my understanding of MPEG is that it is especially good at encoding scenarios such as the one you mention. One of the major ways that MPEG gets its very high compression is through the use of motion vectors.

One of the things the encoder does when building a bitstream is to re-use as much already-sent data as possible. In other words, rather than transmit an entirely new "clump" of pixels on a succeeding frame, it looks to see if maybe the previous frame clump of pixels hasn't moved in the X or Y directions, or if it has, by how much. The encoder can then just transmit that motion information for that clump of pixels, and the decoder can create a very good approximation of the original by shifting the pixels by the amount specified. I'm not doing a very good job of describing the actual process, but you get the idea.

The result is that an image that just shifts in position over time is actually highly compressible. By contrast, just about the worst image an MPEG compressor has to deal with is an image with lots of video noise. In that case, there is practically nothing from a frame that carries over to a succeeding frame, so either the encoder has to use a very high bitrate to compress the succeeding frame (kind of like a jpeg compression) or the encoder has to turn the "quantization" way up, giving a very blocky appearance.

My apoligies if I'm missing something here. My head is spinning from watching the election returns. The CNN website is full of great state-by-state election data. They must have a small army of people feeding in all that stuff.
farss wrote on 11/2/2004, 8:11 PM
Are you certain your colors are legal?
Red planet, hm, how red?
I guess if it looks OK on VHS then you should be OK, would pay to check it on the scopes though.
Sorry I don't have anywhere to upload stuff at the moment and my video PC is undergoing preventive maintenance (read spring cleaning).

Bob.
farss wrote on 11/2/2004, 8:16 PM
As far s I know mpeg-2 doesn't use motion vectors, moeg-4 may, don't know enough about it but I seem to recall it can encode something like "this frame is the same as the last but move it one pixel up".
As far as I'm aware mpeg-2 just takes all the pixels used for the I frame and compares the subsequent frames to see which pixels changed. Using motion vectors can be very problematic, noise throws the algorithms into a total spin and on top of that it needs to find something that can define an 'object' to then work out which part moved.
Bob.
Cunhambebe wrote on 11/3/2004, 3:25 AM
....As far as I'm aware mpeg-2 just takes all the pixels used for the I frame and compares the subsequent frames to see which pixels changed.

I AGREE....
Cunhambebe wrote on 11/3/2004, 3:28 AM
farss wrote this:
.....Are you certain your colors are legal?
Red planet, hm, how red?

YES, I AM (Lightwave has a filter named - among many others - Video Legalize, for NTSC and also WAVE filter..for colors, gradient, etc...), besides, I'm still viewing the file on my monitor (please, don't say regular TV monitors don't detect "the banding" because they do). By the way, farss, I disagree with you when you say this can be a problem with colors or something like that. If you remember, at the beginning of this year, we had a discussion on the same subject and we wound up anywhere. I insist: If I render the whole stuff (Targa sequence, sorry, lol) setting Vegas'MC built-in at the highest bitrate, the quality gets better.
One more thing: Lightwave, if I'm not mistaken - doesn't have the option for rendering at 29.97...as I stated before; in fact, the options are, NTSC 720x486; NTSC 2; PAL; NTSC Wide, etc.....

Thanks for your help...Help, please....
farss wrote on 11/3/2004, 5:32 AM
I'm just trying to explore all the possibilities here but it sounds like you've already considered most of the ones I can think of.
From what you're saying if you up the bitrate the problem gets better then it sure sounds like too much happening for the encoder. Maybe it's smarter than we think, maybe it's trying some form of smoothing and that's producing the problem.
So lets see if I get this right. You render out of Lightwave as a Targa sequence and import the sequence into Vegas and then from the Vegas T/L encode to mpeg-2.
If that's the case what happens if you first render to a new avi (just plain NTSC DV) file and try to encode that? Does the intermediately rendered avi look OK?
Also I noticed you said Lightwave cannot render to 29.97, but it can render to NTSC 720x486, that should be fine for Vegas, some CGI apps I think treat NTSC as 30 fps not 29.97 but even so that's such a small difference you'll never notice it.
One other thought you could try is to reduce the resolution of the image in Vegas prior to encoding by using say the Median FX. I'd only try a few seconds as it's really slow to render. Don't go to all the trouble of burning a DVD, just drop the mpeg file back onto the Vegas T/L and have a look at it. I'm not suggesting this as a fix, just a way to try to diagnose just what's causing the problem.

It's kind of late over here, spent most of the day having firewire dramas but the Vegas PC is back on line at last. If you haven't made any progress by tomorrow I'll email you the address of my FTP server and maybe you can upload something for me to have a go at.

Bob.
riredale wrote on 11/3/2004, 10:15 PM
Regarding motion vectors, I think it's a standard part of a modern codec. Look here.