View Profile
View Forum Posts
Um, don't you mean 24 bytes overhead?
+ Reply to Thread
Results 31 to 58 of 58
-
-
Yes, you're right, that's what I meant.
-
Out of curiosity I had a look at some old AutoGK encodes. A folder containing "350MB AVIs", obviously encoded before I discovered the one size fits all idea wasn't optimum for quality, but they only varied between 349MB and 351MB, with the majority of them being 349.9MB. That was three seasons of Scrubs. Not much action or bitrate control required, I'd imagine.Originally Posted by manono
When I was doing this I don't think I remember being more than a MB off from the 700 or 701 MB I requested (since CDs burn up to 703 MB with no problem). I always used the GKnot bitrate calc. I have no idea how good the one included with XviD is but my suspicion is the OP is doing something wrong, even though this isn't exactly rocket science.Originally Posted by hello_hello
I had a look through a folder of old Stargate SG1 Encodes. Obviously by then I was running compression tests and picking a file size based on the result, but my OCD tendencies have always forced me to specify a file size which is a multiple of 5MB.... 465MB, 520MB etc. The largest deviation from a "5MB multiple" looks to be about 2.3MB. Many of those are between 1MB and 2MB over or under, so more action, more bitrate control, maybe a little more variation?
And I suspect, the larger the file size the more likely it might overshoot or undershoot the target bitrate a little. If an encode was 3MB or 4MB oversized, thinking about it, chances are it was 1803MB instead of 1800MB, so it's a bit relative I suppose, but I don't have the motivation to search through folders checking old movie encodes. Maybe later.
The TV show encodes I checked were all done with AutoGK (not sure exactly which version) and Xvid 1.2.0. -
And... the resulting file is 702 MB. I guess that's the best I'm gonna get.
By the way, I did burn that damn 704 MB file, just to see, and it did work. -
If you really need to analyze the chunk structure of AVI files VirtaulDub's hex editor with RIFF Chunk Tree view is very useful.
But I don't see why anyone cares. If you find your files are consistently turning out 704 MB rather than 700MB, or even just occasionally turning out oversized, just specify a lower bitrate. You won't see any difference in visual quality with a one percent or less difference in bitrate. -
Open it with VirtualDub, set the interlacing to 2 frames (assuming the audio isn't variable bitrate), save it as a new AVI and it'll probably be pretty close to 700MB.Originally Posted by lagartixa
You still haven't said whether you're using an Xvid profile with rate control. -
OK. I know I can always specify a lower birate, it's just that encoding takes hours to do so I wanted to learn how to calculate correctly to begin with, otherwise I have to encode once, see if it's oversized, then reduce the bitrate and encode again.If you really need to analyze the chunk structure of AVI files VirtaulDub's hex editor with RIFF Chunk Tree view is very useful.
But I don't see why anyone cares. If you find your files are consistently turning out 704 MB rather than 700MB, or even just occasionally turning out oversized, just specify a lower bitrate. You won't see any difference in visual quality with a one percent or less difference in bitrate. -
I did! You must have missed it. I am using the default profile called "Xvid Home" with default settings and I did not use zones / rate control.You still haven't said whether you're using an Xvid profile with rate control.
-
You mean "interleaving", right? I tried it and it did work too, setting it to 2 made the 702 MB file go to 701 MB and setting it to 3 made it go to 700 MB. I'd still like to know how to do it without changing that, though.Open it with VirtualDub, set the interlacing to 2 frames (assuming the audio isn't variable bitrate), save it as a new AVI and it'll probably be pretty close to 700MB.
-
No. You set the bitrate low enough that you never get a file bigger than your target. If some files come out a little smaller -- so what? You can't see a difference between a 695 MB video and a 700 MB video.Originally Posted by lagartixa
-
Yeah, I could do that, like hello_hello also suggested, I could aim for 695 MB.No. You set the bitrate low enough that you never get a file bigger than your target. If some files come out a little smaller -- so what? You can't see a difference between a 695 MB video and a 700 MB video.
-
For the record, the difference in size when saving with "Save as AVI..." and "Save old format AVI..." is only 2 KB. At first I did a test with a short clip of a few seconds, I saved it in those two ways, I compared the size and I thought "2 KB difference with a video of only a few seconds? It must save at least 1 MB with a long video" but yeah, I was wrong.
-
Sorry, I guess I did miss it.Originally Posted by lagartixa
I don't have Xvid installed so I can't check, but if you're referring to "Home Theatre" I'm pretty sure it'll use rate control. If you select the profile and look under the "Video Buffer Verifier" section and the fields aren't blank (buffer max size and max bitrate etc), that's the rate control I was referring to. It'd be interesting to discover if using a custom setup, with all the same settings as previously, minus any video buffer verifier settings, produces a different result. If it does, then it's the video buffer verifier restrictions effecting the over-all bitrate a little.
If that's the rate control you're referring to, then I guess you can ignore the above.
If I remember correctly, when you use Xvid's bitrate calculator it displays the expected average bitrate after you've entered a target size and audio size/bitrate etc. Have you checked the output average bitrate to see if it's a little different? For example if the calculator shows the average bitrate as 836kbps, is the average bitrate of the encoded video 836kbps? Maybe that's been asked and answered and I can't remember but it might help show whether the desired bitrate is a little of or if it's not, then it must be a problem with the calculation elsewhere (overhead, audio size etc). -
OK. I could be wrong but I think the "Video Buffer Verifier" is not really rate control because "Rate control" appears when you click "Zone Options..." but in any case now I know what you're referring to.If that's the rate control you're referring to, then I guess you can ignore the above.
I think I had seen the "Home Theatre" profile before but in Xvid 1.3.3 and I think since version 1.3.0 the options are "Xvid Mobile", "Xvid Home", "Xvid HD 720", "Xvid HD 1028", then the "MPEG4 SP" profiles, then the "MPEG4 ASP" profiles, and then "(unrestricted)".
I went and installed the old Xvid 1.2.1 that comes with AutoGK 2.55 and I saw the "Home Theatre NTSC" and "Home Theatre PAL" profiles. One thing I noticed that stood out, is that the default profile in Xvid 1.2.1 is "(unrestricted)" whereas the default profile in Xvid 1.3.3 is "Xvid Home".
The "Xvid Home" profile does use "Video Buffer Verifier" settings, in fact ALL profiles except the "(unrestricted)" profile use "Video Buffer Verifier" settings. I don't know what that means, but maybe later I will try encoding again with the "(unrestricted)" profile.
I did now and no it's not off it's the same.Have you checked the output average bitrate to see if it's a little different?Last edited by lagartixa; 5th Nov 2014 at 01:47.
-
You do know what bitrate viewer is don't you? It's one of the tools anyone serious in this business should know.
-
No, I don't, I'm a newbie. How is it so much better than just checking the bitrate with MediaInfo which is what I did?
-
BTW, the MediaInfo I'm referring to is not the one linked to here on VideoHelp, it's the one that comes with the K-Lite Codec Pack.
EDIT: Or is it? Sorry, it's just that I had a look at the screenshot at VideoHelp and it looked different than the one I have, but then I looked at another screenshot and I think it's the same.Last edited by lagartixa; 5th Nov 2014 at 02:21.
-
It will show you the running bitrate, the peaks and lows, all the variances for each gop/frame/second of the file, not just the overall bitrate.Originally Posted by lagartixa
It's just something that might come in handy (since you seem so obsessed with exact bitrates and file sizes). -
So I ran another encode, to test that, using the "(unrestricted)" profile. I still got a file of the same size, only about 10 KB bigger.It'd be interesting to discover if using a custom setup, with all the same settings as previously, minus any video buffer verifier settings, produces a different result.
Last edited by lagartixa; 5th Nov 2014 at 08:53.
-
Bummer.Originally Posted by lagartixa
I think I'm out of ideas. I'd hoped you could at least verify Xvid's video buffer settings were effecting the bitrate a little, but maybe they're not. You're certain the bitrate in the calculator and the output bitrate are identical? It does pay to check with Bitrate Viewer rather than MediaInfo. I just looked at a few AVIs using both programs and they did agree on the video bitrate each time, but that's not always the case. Maybe MediaInfo can obtained the biktrate info more accurately for AVIs than for other containers. I don't' know......
You've double checked the audio? It's the bitrate it's supposed to be?
That's one of the reasons you can't replace the version of Xvid which comes with AutoGK and expect AutoGK to work correctly. It knows how to configure Xvid 1.2.1 but once stuff is moved around, anything could happen. If the Xvid profiles have changed, AutoGK could use the wrong ones.One thing I noticed that stood out, is that the default profile in Xvid 1.2.1 is "(unrestricted)" whereas the default profile in Xvid 1.3.3 is "Xvid Home".
Sorry about the terminology mixup. The video buffer settings do restrict the bitrate, and I tend to refer to it as "rate control" (maybe incorrectly), but the video buffer settings are supposed to ensure the player's video buffer doesn't overflow, so they do control the bitrate, but not in the same way. I've never quite got my head around the way the video buffer settings work, but to be honest I've not really given it any thought, aside from the appropriate values to use.
I'm a little curious now, so in the next day or so I might try running some Xvid encodes courtesy of MeGUI (it uses a commandline version of Xvid). MeGUI has an "AutoEncode" option which can be used to over-ride the encoder configuration in respect to bitrate. You create a script for encoding and load it into the video section, select "AutoEncode", pick your desired output file size, add the audio, and MeGUI does the math for you. It sets the appropriate bitrate so you don't need to change it in the encoder configuration. In fact you can leave the encoder configuration in single pass mode and MeGUI will switch it to 2 passes if you specify a file size. As I rarely run anything other than single pass encodes these days I don't recall how accurate the output is likely to be, but I'll probably give it a spin at some stage soon. Or maybe you might want to try it yourself? There's probably nothing you're doing with VirtualDub which MeGUI can't do with the help of Avisynth, and I prefer it myself. You can even edit while encoding in much the same way you'd do it with VirtualDub. The process is a little different (you create a script first, then apply your edits to it) but it's all done with the help of a video preview with navigation buttons and sliders and frame numbers.... just like VirtualDub. -
That's OK, don't worry, I'm very grateful already for you trying to help me.Bummer.
I think I'm out of ideas.
I am not at the computer where the files are right now, but I'll try stuff later.
I tried MeGUI before but did not manage to do an encode successfully. I'll try again. -
Just one more contribution from me after hello_hello's comment above.
Since I upgraded this PC, I did not have xVID installed but I could still access autogk (without xVID) from my XP program folder. So I installed the latest xVID and ran a sample encode under autogk chosing the 1 CD option. The resultant avi was 699 mb as I would have expected. So autogk does not appear broken using 1.3.3 rather than 1.2.1
With autogk, 2-pass is the norm and is fully automatic and I do think that two-pass gives a slightly better result both in quality and slightly smaller file size. It's also more intuitive since it uses avisynth and vdubmod to do the hard work with audio being dealt with separately.
I did another encode this time using the OP's chosen tool bit only for one-pass and I also had a 704 mb avi. Two-pass with vdub is trickier (well it is for me) so I did not attempt it. But I would still expect that the second-pass to give a slightly smaller file. Maybe I will do that another day to see if the point is proven. -
It was a while ago and I'd need to read this thread again to refresh my memory, but I think one poster claimed AutoGK and a new version of Xvid was causing file size issues when one of the AutoGK hardware compatibility options was checked, and another said his file size problems occurred when they weren't, and I don't think that was ever sorted out, but we did establish Xvid was using the mobile profile instead of a home theatre profile at times which means it'd be using more restrictive video buffer settings. lagartixa said it appears the default Xvid profile is now "Home" whereas previously it was "unrestricted", so AutoGK may think it's using an unrestricted profile when it's not, and previously there were two home theatre profiles (NTSC and PAL) whereas now there's only one.Originally Posted by DB83
None of that might have any effect on achieving a target file size if Xvid still hits the target bitrate, but it may effect the quality at times.
You should be able to check the Xvid settings being used by opening the Xvid encoder configuration while AutoGK is encoding video. Whatever they are should be the settings for the current encode. I do recall AutoGK changes the min and max quantizers according the the result of the compression test, and it selects an appropriate Xvid profile and sets the bitrate.... and custom quantizers..... when the ESS compatibility option is selected it only uses the h263 and mpeg quantizers. If the other compatibility option is checked (MTK?), or neither are selected, it sometimes uses custom quantizers. And it enables Xvid's VAQ, which I think had it's named changed at some stage and may be enabled by default now. And AutoGK changes the i-frame boost/reduction settings....
Those are the places where something might go wrong if Xvid is upgraded. Or AutoGK might still be able to set them correctly. I'm not sure..... -
I'll confess that this was a quick'n dirty conversion - no hidden settings altered. More to illustrate that xVID can create a target size just as the OP discovered using FUW
But I would agree with you that if a version of a codec comes as part of an installation that is the one that should be used. Maybe I was just lucky
-
I tried Bitrate Viewer and got the same video btrate.
I triple checked the audio bitrate and it was correct.
I did an encode with AutoGK and got a 700 MB file.
I did an encode with MeGUI and got a 695 MB file.
It might be VirtualDub, or the overhead, who knows. -
Yes, there may exist a problem in VirtualDub.
Also, keep in mind that the video stream may contain a lot of "padding zeroes",
caused by the difference between the ACTUAL filesize and the TARGET filesize. -
I had a play with MeGUI and a couple of Xvid encodes. MeGUI's bitrate calculations must be a little out. I ran two encodes of the same movie, home theatre profile, one at a low resolution and one at a higher resolution (to see if maybe the video buffer restrictions would have an effect). MeGUI specified a bitrate of 704kbps in the command line and in both cases the resulting bitrate was 704kbps. In both cases the resulting file size was 696.9MB. I don't know why MeGUI's calculations are a little out but ideally the result would have been 700MB.
-
Yeah, 700 MB is ideal, but if the size is off I'd rather it be undersized than oversized.
Quote