H.264 (MainConcept?) not coding efficiently?

[cwm9]

PROBLEM SOLVED. Don't bother reading this thread. I will delete it soon, after those who helped see what happened.

[Toti]

Hey CWM9, The file should not grow in size just the quality will suffer somewhat since now the black bars are getting encoded.

The problem I found with MainConcept is not that quality is bad or that the file size is too big but rather that after the encode the video is shorter than the audio. This however does not happen when you encode with Sonic's CineVision 1.2 which uses the same engine as MC 2.0.15.

[cwm9]

Perhaps I wasn't completely clear.

The file size DID change, even though the bit rate did not.

The 19MB is right in line with what I would EXPECT for 13 seconds @ 9500kbps average, yet the file with the smaller resolution did not achieve this size.

I can only assume that the encoder decided it didn't need that many bits, and chose not to use them.

The fact that it decided it DID need that many bits for the version with the black bars concerns me. It seems to me it should have assigned very few bits to the macro blocks with the black bars (since they aren't changing at all!) and that the rest of the clip should have been encoded exactly the same as it was previously. So I'd expect the prior file size (6MB) plus a little extra for the black macro blocks, so maybe an extra MB. But to be 3x as large?

Obviously if I encode a long enough clip, the encoder will eventually start putting more bits into each frame in order to bring the average up to 9500kbps. This file size phenomenon is only going to show up on very short clips. But why would the compressor do this, and, more importantly, is it always wasting this much bandwidth when encoding black bars?

Let me put it one more way: the compressor felt the need to burn off an extra 13MB out of 19MB just to encode black bars. Does that mean if I encode a 1 hour clip that 13/19ths of my bandwidth has gone into encoding black bars?!

[Sagittaire]

The problem is not black borders. It's simply little bug in mainconcept 2.1 with pulldown mode. Ajust your average bitrate for obtain correct final size.

If you want encode without problem, you can make the progessive pulldown (23.976@59.94) in the avisynth script. Don't forget that for 720p the framerate must be at 59.940 fps with 0.606 sec for max GOP length (36 frames here).

[Clown shoes]

I don't think that's the problem in this case Sagittaire. What he's saying is he has done two encodes with identical settings apart from a very small amount of cropping that should not account for a file size reduction of almost two thirds.

@Cwm9

If you haven't already done so, do you have time to repeat the test? One thing I have noticed is that settings in the Mainconcept encoder do not always stick. If you get exactly the same results, I will also do some tests when I have some time.

If it is confirmed, then yes, that does appear to be a strange bug.

[cwm9]

Problem solved. Thanks for helping.

It turns out the problem was with an in-house automation tool I was using to generate the AVS script. :stupid:

A bug in the code caused the resolution to be changed when the crop was made and I didn't notice because I was viewing the final result in a small window in the corner of my screen. I went back and double checked... without the crop the resolution was correct; adding the crop caused a scaling line to be dropped from the file.

Sorry for the false alarm, but thank you very much for your help anyway.

I'll leave this up for a little while so you can see what happened and then destroy the thread to keep people from wandering in and wasting any time.