ATI MMC bitrate setting.. true to math?

[NIIDeep]

Hello,

I'm using an ATI AIW card to capture VHS video straight to MPEG2 using ATI MMC 9.03.

I'm having problems with getting the desired file size of caps. For example, for a 2 hr 51min VHS video source with 256 kbps audio, I've specified a 3.6 CBR in the MMC software. What I get in the end is a 3.5 GB file. The bitrate calculater tells me that I should have used a bitrate of ~3.3 Mbps but this looks like it would yield an even smaller file size.

What gives? Can anyone shed some light on this? I'm currently playing a guessing game at the painful expense of re-capping. Thought I could save time with eliminating the encoding step, replacing it with real time H/W encoding. This turns out to not be the case.

[Gregg]

Do it the other way: record 1 or 5 mins , check how big is the file you get, multiply /divide by the footage lenght /time/ and you'll have the bitrate you need.

Enjoy!

[lordsmurf]

CBR/VBR = AUDIO+VIDEO in MMC (and many other encoders)

I don't see the problem here. You captured 3 hours, and it's 3.5GB. That fits on a DVD just fine. Does it look good? Worry about QUALITY, not whether it will fit the disc. And even if you DO worry about disc size, worry about not enough disc, not too much disc.

[NIIDeep]

Gregg,

I've already tried your way for VBR and it's not consistent. For CBR, I need to see if I can some predicatability.

LordSmurf,

There are two problems:

1) It took me THREE guesses, which equates to THREE painful re-caps, totally nearly 8 hours of time, to get an acceptable file size of 3.5 GB. And really it's luck that I got this. I switched to CBR on the third try to try and get predictability. Ideally I'd like to use VBR (per your guide). But for the future, how can I avoid this "trial and error" method?

2) No doubt that I may use this last cap but I have 6 more tapes to go and would like to maximize the quality if possible relying on the math, mainly because I'm suppose to be able to do so.

Guess I'll have to come up with some formula. I'd almost say this is a bug in the ATI software. Not being able to cap with predictable results severely impacts the convenience of using a H/W encoder.

I'm almost better off capping in AVI and encoding later with s/w. May actually take less time..... something is just not right in this scenario.

[briandugas]

Sometimes, when I end up with a file size that is a little too big, I just author with TMPGEnc DVD Author, then use DVD Shrink (Complete Disk) to shrink it down, and it keeps the menus. I think I got this technique from LordSmurf's website, or one of his postings. Anyway, it works great.

[NIIDeep]

Yeah... I had asked about the Pros/Cons with using DVD Shrink in the DVD Authoring forum. The thread got moved somewhere... since it wasn't deemed to relate to authoring.

In any case, someone there mentioned it's always best to capture at the correct bitrate. Shrinking should be the option if you happen to be off by a few MBs. I might give this a try though.

It gets a bit confusing since I'm compressing source video (MPEG2) and then it gets compressed some more by DVD shrink. Is this "double" compression good or bad or irrelavent?

[lordsmurf]

It's isn't a "bug" of ATI software, but rather of the on-the-fly MPEG encoding method, period. Much like CQ modes, it's never 100% accurate.

If you insist on to-the-kilobyte accuracy, get a high-dollar encoder, do multi-pass VBR encoding (maybe CBR), and then convert to MPEG from AVI captures.

It is true that you should ALWAYS try to hit proper filesize the first time around, but a mistake can always be corrected by a transcoder. Or redo it again.

Again, you hit UNDER the max disc size, so again, I fail to see the issue.

You must have set the VBR too high if it went over 4.25GB size.
3.4 Mb/s VBR 352x480 with 4.0 max will yield right about 3 hours, no problems whatsoever.

Just in case, roll back to another MMC, not the "latest and greatest" version. 9.02 and 8.7 are perfect here, 8.7 is most stable of them all.

[NIIDeep]

Not looking for Kilobyte accuracy... I'd be very happy with Megabyte accuracy!

I guess I was inclined to expect the results from H/W encoding to be similar to those that people have received with S/W encoders. It's understood that it's not 100% accurate science but there is also a certain margin for error that's acceptable and not acceptable. Being off by 800 MB and performing trial and error is unacceptable. It's really a huge inconvenience.

I don't want this to turn into some moot debate, so I'll stop here.

But keep in mind LS, just because you have a certain standard that's acceptable to you doesn't mean the rest of us have that same standard. What you don't see as a problem may be an issue that other people would like to resolve.

Don't get me wrong though, you're opinions are valued and are taken under consideration.

Thanks! Off to derive my magical ATI bitrate calculator formula....

[lordsmurf]

Well, if you're off by ~1GB, there is a problem, and it's likely with your settings. I'd suggest posting screen caps of each ATI screen. Something is amiss. Also, try another MMC, as suggested.

[NIIDeep]

oh and again the main issue is that I still have 6 tapes to go that are also of varying lengths and greater than 2.5 hours.

For this current conversion.. YES I agree I got under the limit... but what about the next tape? I may be pretty good at guessing but in a worst case scenario I don't want to take THREE attempts at recapping to get the right file size. Make sense? 6 tapes x 3 guesses @ 2.5 hours = 45 hours worth of time that SHOULD have been able to be done in 1/3 as much time.

I suppose over time.. as I gather enough data points my guessing would improve with each successive tape. But seriously is this the way it was meant to be?

LS, you are fortunate that you deal mostly with videos of "1.5 hours" in length. This is less of an issue for you.

I'll try an earlier version of MMC. But if the behavior of the bit rate setting in 9.03 is worse than that from a previous version.... doesn't that make it a bug?

[lordsmurf]

I deal with many videos of many lengths. Most of my personal discs are 3-hour discs.

If 9.03 is off by 1GB, with the same settings, yes, that'd be a bug, and should be reported to ATI as such. But this is the FIRST I've heard of it, and this version has been out for a while. I think it's your settings.

Again, screen caps of all the settings would make a HUGE difference. Something as little as a bad GOP settings could skew the outcome.

[NIIDeep]

LS,

Here they are... settings were adopted from your guide.

[vhelp]

@ NIIDeep

Try another experiement, because I think maybe there is a bug or just
something that is not totally factored in, somewheres' in this equation
of trouble you're having (or maybe MMC) ..

Set MMC to capture exactly 1 minutes worth. Assuming that MMC has
this as a feature to capture in "timed" recording.. last I checked w/
my version, v7.1 I think.. it has a timer capture feature.
.
Then do what Gregg said.

The reason why I was asking this (and only you can do this w/ your
given setup) is because if the (say for instance) your 1 minute capture
gives you a certain MB filesize, "H.thetically speaking of 20mb",
THEN, you go and recapture again at 1 minute.. if you find the same 20mb
size file, then there is something else going on wrong in your process.
If the size fluctuates, then there is something wrong or gong on a
bit funny inside MMC, and there is probably nothing you can do about it,
short of using another Encoder all-to-gether. Make sure you are using
a CBR mode in this test scenario.

-vhelp 3048

[NIIDeep]

Will do.... I'm going to add that with the above settings... I'm getting an invalid file format when I try to load my 3.5 gig file in either DVD-LAB or TMPGEnc DVD Author.

But when I play it with ATI File Player and Windows Media Player, I get the DIVX Video logo in the lower right hand corner of my video, signify that the DIVX codec is being used.... all I can say is "huh?"

What is going on here? I'm utterly confused...

[lordsmurf]

Yeah, something isn't right here. Those settings should yield about 4-5GB file. The 3.7 Mb/s active would give about 165 minutes in 4.25GB space. Maybe a few more minutes since you're using 1-4-2 GOP.

I would still highly suggest an uninstall for the MMC issue.

The DIVX thing is likely a system-wide codec problem. Have you installed any codec packs? How clean is the system, how aged is the OS install? Use DXMAN to see what is on there, and kill unneeded codecs (leave ATI, Microsoft alone).

[NIIDeep]

LS,

will do a re-install of MMC... DXMan indicates DIVX codec from my WinDVD s/w.

Vhelp,

I tried two 59 sec caps. ATI isn't exact I guess. Same settings as above. Here's the data:

Cap1: 27938 KB
Cap2: 27904 KB

There were two others at 58 sec.

Cap1: 27468 KB
Cap2: 27452 KB

According to my back calcs, these are pretty much in the ballpark for 3.6 Mbps CBR. They're not exact but as LS said, this is expected, right?

[lordsmurf]

Expected to vary.

But 1 minute should NOT equal 27MB.

Kill the DIVX. You can always put it back.
WinDVD does not come with DIVX codecs.

[NIIDeep]

LS,

Are you sure? My math is as follows.....

27938 KB / 59 s = 473.53 KB/s x 8 = 3788.20 Kb/s = ~3.6 Mbps

I think this is right..

[lordsmurf]

Yeah, you're right, about 27 MB/min is the 3500k range. I was thinking something different.

[NIIDeep]

LS,

So I reinstalled everything....

I'm doing 1 minute caps of the video with VBR min: 3.15 Mbps max: 3.26 Mbps. The average should be ~3.2 Mbps.

I get the following file sizes:

Cap1: 14988 KB for 58 s
Cap2: 15458 KB for 59 s

Does this makes sense? If I calculate it, I end up with a average bitrate of ~2 Mbps. Shouldn't this calculated number fall somewhere between the max and min values?

I think this is where things got unpredictable. At least it looks like I can try using CBR with predictable results. I'll chalk that DIV X thing as a fluke (I hope). If things get messed up again.. I'm going to try MMC 9.02.

[lordsmurf]

VBR min is uncontrollable in most encoders, including MMC (Ligos encoder). Your one minute can easily have ~2 Mb/s ... it ONLY takes what it needs, UP TO the max, and ON AVERAGE, around the avg. AVG calcs intervals are not really known.

[Sulik]

VBR is VBR - hence the "Variable".
In my experience, the VBR result in MMC will always be under or clsoe to the average bitrate that you want, which is fine (basically, the minimum quantization level is capped, so it doesn't waste bits encoding blank frames at maximum quality)

If you record pure noise, your final file size will most likely be much closer to your target, because it's more difficult to compress (the quantization will always be higher than the CQ limit).
You can verify this by opening the file in "Bitrate Viewer", and you'll see a flat lower quantization level limit where the bitrate is much lower than the average.

Lordsmurf: ATI hasn't used the Ligos encoder since v6.x of MMC (Ligos isn't very good). It's their own encoder.

[lordsmurf]

It's based off Ligos, though. And I'd disagree about the "not good" part too. It's not much different than MainConcept in some regards.

[NIIDeep]

Well I did some characterization of VBR for my own understanding. I think this is where I got confused and then took a left turn when my weird DIVX thing happened.

I've discovered the following:

- VBR (for MMC) cannot produce predictable file size with great accuracy. You can maybe get the GB you want or close. File size depends on the dynamics of the video, i.e. how much motion(?). More motion, higher bitrates are used. Little or no motion, lower bit rates are used. I had originally expected that predictable estimates in filesize could be calculated by assuming that an average bitrate would be maintained. Average meaning the median between the MAX and MIN values. This is not the case.
- VBR will produce close to the average bitrate your shooting for and it's amazing how much difference in space saving between CBR vs. VBR. Could be a difference of .5 GB or more. Again it depends on the dynamics of your video. Quality remains the same although I haven't really put this to close scrutiny.
- After doing several dozens of 1 minute caps at different settings, I've concluded that for VBR in MMC, the bigger the delta between the MIN and MAX numbers, the bigger the filesize, which seems strange to me. I would think it should produce SMALLER file sizes, since you're allowing for a range of bitrates that can be used rather than one constant value as in CBR
For example, if I cap with MIN: 4.3 Mbps MAX: 4.7 Mbps the average is suppose to be 4.5 Mbps I would assume. The file generated here is smaller by quite a bit than if I cap with MIN: 4.0 Mbps MAX: 5.0 Mbps which should also yield averag 4.5 Mbps. Another example, 1 minute cap with CBR 4.5 Mbps does not produce a filesize that is equal to a 1 minute VBR cap with MIN and MAX both set to 4.5 Mbps (which techically should be the same as CBR). Very confusing.

Furthermore, going by my first sentence above, if the larger the delta produces the larger of filesizes then the best result for optimized filesize is when MIN and MAX are the same. Being so then what's the point of specifiying a MIN or MAX? I feel like I missing something here. LS did say that at least the MIN number is meaningless or irrelavent. If so, then why have the option to specify a MIN.. why not use 0 all the time?

For my use, I'm following some guideline I read somewhere to keep the MIN and MAX delta between 500 to 1000. This is sorta in sync with LS's guide as well. But I'm not sure why this is good... or bad.... since MIN / MAX for MMC VBR eludes my understanding.

I'd like perhaps some more insight on my findings if anyone would kindly oblige me.

Thanks.

[lordsmurf]

There is no "min" number in MMC. It's already zero. At least not in 7.1 to 9.02, there is not min. I've not installed 9.03, have no reason to. Doubt it's any different.

MMC sets the average and the max ONLY. The max may or MAY NOT ever be hit, depending on the video source and what it needs (determined by the card, the hardware section of this hard/soft mix). It tries for the avg, goes lower if it can, and goes higher up to max, if it's needed. Settings the max too high is BAD NEWS, as it may try to take TOO MUCH of the higher.

And again, it's not an "MMC thing" but literally an effect of the method altogether. MPEG compression is a bit more chaotical in active captures (hardware or software). After-the-fact is controlled (if you want to).

If you set VBR at 3.42 Mb/s and max at 3.6-4.0 Mb/s, you should get a file under 4.25GB @ about 3 hours. And watch the GOP settings. I found 1(I)-2(P)-2(B) and 1-3-2 to have less quality issues, though it may come at a slight loss in compression. Another reason I use VBR instead of CBR here.

[Sulik]

Also, if your source is very clean, your file might be larger with CBR, but the encoder may just be simply padding the bitstream with zero bytes in order to meet the CBR requirement (the larger file size does NOT necessarily mean higher quality).

[NIIDeep]

It's funny how the brain just arbitrarily makes assumptions without actually "seeing" the actual.

Lordsmurf you are 150% correct... there is no MIN settting. There is a "target" bitrate. For some reason, I saw MAX and assumed the setting underneath was for MIN. Don't know how many times I've seen that screen and still missed the fact. Actually if one refers to my screen capture it should show that it says "Target".

Now with the new understanding... everything makes sense from my previous post. I'm thoroughly embarrased. Nevertheless, I thank everyone for their patience and clarifications.