View Full Version : XviD Filesizes (n00b question)
gizmotech
12th June 2003, 18:20
Heyo,
I've got a very n00bish question. I've been using xvid for a while, and I find it quite useful for my encodes. Up until my most recent encode I had been able to set 196054k in the final size of the second pass -int and always been able to get a proper 196054k encode. However something interesting happened with my most recent encode which resulted in a 137000k file. Now I've examined the file and it "looks" ok picture quality wise, and because of the low amount of scene changes, and long drawn out low movement scenes I believe this might be the correct size for the video.
Now here's my n00b question. Should XviD have not padded out the video stream to acquire the 196054k file size? If not (which can be a good thing), is there any way to have XviD pad out the file size?
GizmoTech.
EDIT: for reference using 14/05/2003 XviD. (koepi build)
Settings match closely settings in Snowbeach guide from Newbie thread.
Imperial Llama
12th June 2003, 18:58
Can I ask why you why obtaining a minimum file size is important? Anyway assuming you have a good reason for this the most sensible way to increase the video size is to increase the amount of detail so the encoder needs to use more bits in order to reach maximum quality. Try:
Using MPEG quant
Using a higher resolution
Using a sharper resize filer
Disabling any filters you normally use that remove noise or detail
A less sensible method would be to make the encoder less efficient so it wastes more bits. Suggested methods:
Disabling B frames
Disabling VHQ
Reducing the maximum I-frame interval
Alternatively if you are adding audio to your video you could encode this at higher quality instead. There is nothing to stop you from using uncompressed PCM wave in an avi if you really want to waste space. :D
gizmotech
12th June 2003, 19:18
The reason is all the other episodes were all of that minimum, but rather in their case, maximum file size, to enable 3 episodes w/ dual audio to fit on one 700MB cd. (190MB vid + 20MB x2 audio = 230ish)
I'll try disabling b-frames and VHQ... that'll probably get it back upto size :P
Thanks (If it weren't for n00bs who would think it's a LQ vid at a lower size I wouldn't even be asking this question).
Gizmotech FYI: I'm encoding anime so removing noise is a bad idea.
Prettz
13th June 2003, 01:34
Originally posted by Imperial Llama
A less sensible method would be to make the encoder less efficient so it wastes more bits. Suggested methods:
Disabling B frames
Disabling VHQ
Reducing the maximum I-frame interval
I thought that when b-frames were used, quality will usually be decreased some, even if an insignificant amount. Has that changed with the latest version?
@Prettz
Not necessarily, if you use low enough quant ratio and quant offset they can look as good as or even better than P-frames. Experiment and choose values that you like.
@gizmotech
Does it matter that much what stupid assumptions these n00bs of yours make about your encode? There's no point shooting yourself in the foot because of their misconceptions :)
- Soc
gizmotech
13th June 2003, 04:04
Actually I found out later that if I just turned off the b-frames and VHQ that the file size came out just shy of 5MB where I wanted it to be...
Quite silly really, but it work :)
GizmoTech.
Imperial Llama
13th June 2003, 11:19
Originally posted by Prettz
I thought that when b-frames were used, quality will usually be decreased some, even if an insignificant amount. Has that changed with the latest version?
To the best of my knowledge using b-frames still theoretically reduces the quality but unless you are using very aggressive b-frame settings the quality loss is very hard to detect, although the file size reduction is usually significant. Therefore you will probably end up with a better looking video if you use the space saved on something else rather then disabling b-frames.
xospecialk
13th June 2003, 13:35
since this thread is about xvid file sizes, im going to ask my question here rather than start a new thread
I have the 5/3/2003 keopi xvid build.
my quantizers are 2-3-2-3
and my vids are coming out 200-400 megs over the size that i want them to be.
im running gordianknot 0.28b w/ virtualdubmod
bilu
13th June 2003, 14:16
Originally posted by xospecialk
my quantizers are 2-3-2-3
and my vids are coming out 200-400 megs over the size that i want them to be.
The answer lies in your own words. Why do you use such low quantizers? You're not letting the codec do its work... :rolleyes:
Do you know this thread?
http://forum.doom9.org/showthread.php?s=&threadid=53136
It's a start, I recommend it.
Of course there is a possibility that you couldn't achieve the size you want just with Xvid settings and you would need to decrease resolution.
Also if you aim at a size don't do 1-pass encodings.
Bilu
xospecialk
13th June 2003, 14:23
thanks for the help. i had a suspicion that the quant values were doing it.
i am doing two pass encodes, and those values were the recommended values. its funny tho because all other times i have used 2-3-2-3 the video comes out just fine. but the last 2 times, encoding 2 different anime, it came out way bigger than it was supposed to.
Try using quants 2-5-2-7. The thing is, if you tweak the video via noise removal or lower the size a bit, you can get near constant quant 2 (I forget what the option is to turn on debug info in the output frames) in the product. To answer your question xospecialk, I think that your quants are okay IF you remove more noise and make it easier to compress.
IMO, b-frames look REALLY BAD in anime.
xospecialk
13th June 2003, 16:43
what do you mean by removing more noise? and im not using b-frames---whew
Use some sort of spacial-temporal softening filter(noise removal is a result). DustV5, Convolution3d, what have you; though I would recommend trying dust first. Or, if your using them, increase the strength of the settings.
As one anime man to another, I found that using Convolution3d in conjunction with pixiedust (one of the dust filters) results in some impressive compressability gains. Just keep in mind that using convolution3d, you need to A) use the avisynth 2.0 version in YUY2 cause its better at noise removal and B) add a sharpening filter afterwards cause it tends to blur.
EDIT:I would also recommend playing with chroma motion and set VHQ to 4.
bilu
14th June 2003, 01:07
Any anime encoder here used Deen("a3d")?
I use it all the time, but never did anime. Like it better than C3D.
Bilu
Asmodian
14th June 2003, 01:13
I have encoded a bit of anime with Deen("a3d") in YV12 and I liked it better then convolution3d (it was faster!). I also want to mention that I had to turn up the thresholds compaired to convolution3d.
Right now, Im using a combination of C3d and pixiedust on a very noisy anime. Going for 1 CD, and its a 52 minute movie, 640x480, dual audio ogg (~45MB each track), the quants are comming out to be 2 for the entire movie save for a occasional 1 frame spike to 3. Personally, I think it looks better than the DVD source ^^.
EDIT: Bilu, should I call you Kitsune (from your avatar)
Teegedeck
14th June 2003, 15:14
Hmmm, there's nothing inherently good in having quant=2 all over a movie. I know that most anime-encoders swear by softening the image very much, but have you considered trying it with less filtering? Even though there's noise, the noise contains some picture information, and XviD copes with noise quite nicely. Pure quant=2 sounds like a complete waste of XviD's capabilities to me (though of course your B-frames will still use quant=4 - and yes, B-frames are a good idea in anime ;)). Just a thought.
Originally posted by bilu
Any anime encoder here used Deen("a3d")?
Bilu
Yep. I use it cause it has temporal influence. With temporal influence set at 50, it managed to filter out analogue anime noise pretty well (kare kano), but it just left risidual noise around edges which no filter known to me could manage to remove without screwing up the rest of the picture :D.
@Teegedeck:Im only doing the minimum noise removal, and when I say noise, I mean NOISE. Like the image is alive noise. True, I am losing some detail, but Id rather lose some detail than have to deal with extremely noisy images. BTW, most people I talk to who are hardcore anime encoders say that bframes look bad in anime. Yeah, your gonna get some compressability gains, but most say that the loss in quality versus the gains is not worth it. I have not done any comparisions on my own, but it is the general consensous that b-frames are bad for anime, good for movies.
Teegedeck
14th June 2003, 20:28
Yeah, can't help it but filter it out if the noise is that bad.
For the B-frames:
Unfortunately then hardcore anime encoders don't seem to follow the codec's development very closely it would seem.
B-frames have been tuned to not occur in still images for quite a while, now. Which should help anime encoders problems with them a bit. I'd also think that even if you set B-frame ratio to 100% and offset to 0% (meaning B-frame quantizer=P-frame quantizer), you'd gain something out of it because nowadays B-frames dump some coefficients and thus are still smaller than P-frames even if they have the same quantizers. + the B-frames (if you can spot them at all) should have a 'smoother' look than the P-frames and I understand that could be a desirable effect for anime. For the amount of B-frames in an anime there's also a B-frame threshold to tweak.
Interesting... ill look into it, but as of right now, im not having compressability issues to warrent using b-frames. Ill keep it in mind.
For anime, there is a problem with b-frames in motion scenes where the macroblocks are more visible compared with a non-b-frame encode (amoung other 'errors'). I have tried 2/125/100/50 to lower the bframe quant, but it still comes up. I haven't tried setting b-frame ratio to 100% and offset to 0% though...
Not something the average leecher can probably detect, but it's there, it bugs me (since I would love to use b-frames in my encodes) and I can't QC pass it for release.
--
Comparison made between two visually identical frames during a motion scene, one being a P of Q=3 and the other B of Q=4. ffdshow was used with OSD to display frame type.
Teegedeck
15th June 2003, 17:17
Originally posted by K_R
Comparison made between two visually identical frames during a motion scene, one being a P of Q=3 and the other B of Q=4. ffdshow was used with OSD to display frame type.
Could you spot the blocks during playback? Or just when comparing stills?
A shame anyway. If you try it with p-frame-quant=b-frame-quant someday please let us know, OK? ;)
Usually only when comparing stills... But there are some times where you can see 'b-frame errors' while watching the video at normal playrate. For example, when a line occurs on the edge of a macroblock, the b-frame will have that bit of line missing... I can't really post a clip or screenie anywhere, so this example is a bit useless.
When I get round to running some test encodes I'll give pf-q = bf-q a go.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.