Help! Mpeg2 encoder shifts image up and adds a line at the bottom

[Asterra]

Not sure how to tackle this issue. Here's what's going on.

I've got a raw YUV video which I give to the mpeg2 encoder. It is 23.976fps progressive, and I am having it encoded as such. But no matter which pulldown mode I pick (2:3 or 3:2), what it spits out has the same problems:

1: The frame has been shifted upward by one pixel (ie, a vertical position of 239 rather than 240). To "fix" this, I rendered the raw off with a vertical displacement downward by one pixel, to compensate. Encoding the resulting raw video revealed the other problem:

2: The second-from-the-bottom horizontal line is shifted downward, which now makes it the bottom horizontal line. (What's possibly happening is the bottom two horizontal lines' vertical positions are being reversed, but since the original bottom horizontal line in my video is black, I can't be sure. In any event, what this leaves me with is a black gap one pixel wide between the bottom horizontal line and the rest of the frame.)

My video, in its original state, has black borders on the top and bottom, each two pixels wide. A "solution", if it could be called that, might be to cut off the top and bottom of my video's frame, making those black borders three pixels wide. This would defeat the issue I am having with this mpeg2 encoder. But I probably needn't describe how this is far from a desirable solution. I'd rather know why this encoder is doing this, and hopefully introduce a fix.

After spending literally two weeks getting this single project at the point I'm at, I now have less than a day to finalize everything, including hopefully the resolution of this issue. I hope somebody can offer some insight. Thanks!

[poisondeathray]

it might help if you listed what mpeg2 encoder or software you were trying to use

[Asterra]

Finally got back online. Encoder is CCESP (1 or 2; both produce the same results).

[guns1inger]

I haven't used CCE in years, but there is a parameter in the encoder settings that lets you choose whether or not to add an extra line. It is probably set to 1 by default, so you need to set it to 0. This has nothing at all to do with pulldown.

[dwero]

have u try other encoders? do not try to adjust the paremeter,for the default is the best.

[manono]

I haven't used CCE in years, but there is a parameter in the encoder settings that lets you choose whether or not to add an extra line. It is probably set to 1 by default, so you need to set it to 0. This has nothing at all to do with pulldown.

Yep, in the Advanced Setting, check the 'Output Top Field First Stream' box and set the 'Offset Line' to 'Zero'.

[Asterra]

Okay, thanks for the suggestions, everyone. I did a combination of the things suggested here and my own considerable experimentation. The issue seems to be that CCE SP (1 or 2) is incapable of encoding progressive MPEG2 in a manner which accurately matches the source video. I'll explain.

It happens that the footage I'm encoding is not only 23.976fps progressive, but it also fills almost the entire 720x480. This rare combination (generally you would expect 24fps to be widescreen film) permitted me to identify the most annoying particular issue with CCE SP's output: 1) Whatever video is on the next-to-the-bottom scanline gets duplicated on the very bottom.

2) The other problem with CCE SP's output in 24p mode is that it shifts the frame upwards by one pixel. Combine these two issues and you invariably have a problem at the bottom of the frame: A single scanline at the very bottom - the duplicate - with a black line above it, the rest of the frame above that, and the topmost scanline missing altogether.

I've toyed with the "Offset line" setting mentioned in an earlier post. The effect is that rather than shifting the entire frame up one scanline, CCE now shifts it down one. More perplexing, if I adjust the vertical position of the frame to compensate for what CCE is doing, there is no way to get it to lock perfectly to how my original video looks. It's either one pixel too high, or one pixel too low (or 3 too high or low, etc). CCE does not play nice.

Along the lines of the suggestion to try a different codec, after _considerable_ hesitation I decided that Adobe's own "MainConcept" mpeg2 codec was the only remaining option. This codec only lets me do a two-pass encode, which is absolute rubbish. It also has the following issues:

1) Whatever frame you set as your starting point, MainConcept will actually start at the immediately preceeding frame. Or, if there IS no preceeding frame, it simply duplicates the first frame. Talk about a ridiculous bug. Yet at this stage I consider it emblematic of the entire concept of Media Encoder.

2) MainConcept also has a tendency to truncate the render by two frames. But it does not always do this, and there's no apparent way to predict when it's going to. So if, say, you want your audio's length - and, indeed, starting point - to match what MainConcept spits out, you'd better be prepared to adjust accordingly.

In spite of these wonderful flaws, MainConcept has this going for it: These are things which I can somehow work around, AND MainConcept does NOT futz with the positioning or scanlines of the video. It plays nice.

[guns1inger]

What is your source ?
How are you loading it into your encoders ?

When I did use CCE, I only ever fed it Avisynth scripts, not direct source, and never experienced this issue.

[Asterra]

Sources have been variable but always uncompressed. Usually uncompressed UYVY 8-bit AVI (CCE chokes on V210). I've also tried uncompressed AVI from After Effects (8bpc, whatever it uses; evidently RGB) and uncompressed MOV. All have come from 23.976fps progressive project sources.

Debugmode Frameserver is supposed to work with PPro CS4, but for me and many others, it simply crashes Media Encoder. Fortunately, uncompressed AVI serves the same purpose.

To load into the encoder, I simply add the files. No fuss.

I never experienced these issues with CCE either, but then I also never tried using it to encode a 23.976p video at 23.976fps; I've always dealt with home video, which of course was 29.97fps, and CCE likes such footage well enough.

For encode settings, I have tried every possible permutation of: Rate conv [on/off] (most likely meaningless for 23.976fps video), pulldown [2:3/3:2], Preprocess deinterlacing [on/off] (again, probably meaningless), Interpolation method progressive frame [on/off] (same deal), Output top field first stream [on/off], Offset line [0/1], as well as tweaking the vertical position of the pre-CCE video by one or two pixels in both directions. The facts are that NONE of this worked, while MainConcept did not have these issues (it had other issues ;p ).

[poisondeathray]

I haven't had any of your problems with CCE or Mainconcept's MPEG2 encoder bundled with AME. But with CCE I use avisynth

Perhaps something is corrupt on your system? or there is an issue reading uncompressed files with CCE ? or you have a buggy version and should update to a newer version?

Is your source 4:3 or 16:9 ? What were your comp settings in AE, and what were your export settings? non square pixel format?

Maybe you have a playback or decoding issue?

Post a sample of the source or whatever you're trying to encode. And others can see if they have the same problem to help narrow down the issue

[manono]

I never experienced these issues with CCE either, but then I also never tried using it to encode a 23.976p video at 23.976fps;

Progressive 23.976fps encodes is about all I ever do, and I've never seen this problem. Feed CCE an AviSynth script and see if it replicates. And as pdr suggests, give us a small sample. Dollars to donuts it can't be reproduced using correct settings.

[Asterra]

Alright, here's an example. In the second image, we have the original frame. It had two-pixel black borders on the top and bottom before, but I shifted the frame down one pixel in an attempt to compensate for the fact that CCE's encodes were shifted one pixel up. This did work, but CCE tricked me by duplicating the second-from-the-bottom scanline at the bottom, resulting in the solitary scanline phenomenon you see at the bottom of the first image. Needless to say: Unusable. And I again point out that this was happening with both SP1 and SP2.

With CCE having failed me, I went with MainConcept. But since Adobe's products only let you do a two-pass, coupled with the fact that MainConcept is already a piece of trash, the result was pretty much worthless. So I have shifted gears and am now rendering the whole thing as a Bluray. Saves a lot of headaches.

[poisondeathray]

I've never seen that before with CCE. (And if manono has never seen it before, it probably doesn't happen when done correctly, he has like zillion years of experience with DVD) . Have you tried using avisynth to feed CCE? Have you tried to play back with other software (maybe a playback issue?)

Are you making SD blu-ray now? That's has it's own share of headaches. e.g. it only supports 60i for SD; and 24p in 60i (or telecine) muxers don't really exist or work very well for it, and playback isn't guaranteed in all players. Or are you making HD 23.976pN blu-ray but huge black borders?

[Asterra]

I have not tried feeding avisynth to CCE. My reasoning (besides the fact that I've abandoned MPEG2 in this case) is that I've already given CCE a chance with uncompressed video from two sources (Premiere Pro and After Effects) in multiple guises (AVI, MOV, etc.). I've confirmed the accuracy of CCE's encoding anomalies by using multiple playback codecs (between The KM Player and TotalMedia Theater 3) as well as standalone DVD players. And I have tried every combination of every setting CCE gives me, as mentioned a few posts back. That's a lot of work only to generate the same results. Why would I have to jump through so many hoops anyway, when I can feed the same video to any old alternative MPEG2 codec I have laying around and NOT get the same issues?

I'm not using Bluray's SD specs. I'm scaling the footage to fit 1080p. The main reason for doing this is to bypass the considerable artifacting inherent with poor MPEG2 options, meaning MainConcept. This isn't the first time I've taken this approach with SD material.

I've already had one person question the need to scale SD footage to 1080p when most players can do this themselves. Hopefully the answer is obvious: The higher the resolution, the smaller the compression artifacts. Obviously this rule fails if you're just scaling those compression artifacts also.