Target Bitrate... I beg of thee

[Tiribulus]

Hi Folks,
I've been using Divx for a while, but have recently been so impressed by the results I've seen with Xvid that I've decided to switch. However, all day today I've been trying to use a target bitrate of 1000 and all my encodes land at 5 to 6000. I don't care so much how big the files are, I need 1000 or so as the bitrate.
Settings Are:
AS@L5 = mpeg, adapt quant, b-vops checked, but unchanged with packed and closed checked. Other 2 tabs defaults.
Advanced = motion 6, vhq 1, use chroma yes, turbo no, all else defualt except min I frame quant @ 2.
1st pass = all defaults
Second pass = target bitrate @ 1084 all else defaults.
While glancing through this again for this post I saw the target bitrate/filesize button and had this thought "are these to be used together or are we choosing one or the other?". In other words I thought that by changing to bitrate I'm getting that bitrate and the filesize option is disabled. MAYBE this is wrong. I'm using Koepi's newest BTW.
Thank you for your help,
>>>--Tiribulus->

[mikeX]

In other words I thought that by changing to bitrate I'm getting that bitrate and the filesize option is disabled. MAYBE this is wrong.

Nope, this is not wrong. You either set 'Target bitrate' or 'Target size'.
Are you sure there's no mix up with the 'video.pass' stats files?
You should give more info, what's your source, what encoding application you use etc...

[Tiribulus]

Thanks for your time,
I was using Vidomi (an often very misunderstood app imho) which has been a Godsend with Divx forever, but I think that's the problem. It hasn't been updated in awhile and when I went back in to the codec through the Vidomi interface I discovered that it was insisting on using Xvid's 1st pass settings as it's own second pass and vice versa. The Xvid vbr option (in Vidomi) had the second pass greyed out and I was using normal 2 pass, though because I haven't used Xvid with it before, maybe that's how it's supposed to be and I'm still doing something wrong? I left a pm with the local Xvid guru over there asking him too. I know he's been using 1.0 with it. The good news is I got the results I need with Vdubmod, but the bad news is it takes like 8 hours for both passes to complete on a 2 hour movie, Vidomi is about a quarter of that on the same machine. I also can't figure out if you you can splice several files during the encode. With Vidomi/Divx I would just add say 8 files that made up an episode of a tv show minus commercials and I could either encode them as a single file or seperately in one operation. I also am a little dismayed that Vdubmod appears to make you keep the first pass and delete it manually later even if you tell Xvid to delete the 1st pass. Lemme ask if it matters where you tell the stats files to be and if it matters what you name them aside from the .stats or .pass extension? Also does it append to that file with each new encode or should you make a new one each time? Oh yeah I'm doing tv captures, dvd rips and HI 8 camera captures all with a Happaugue winTV PVR 250 in program packeted mpeg2 @ 8000, or did I say that already? Anyway, making progress and I do appreciate your reply. Any light you could shed would certainly be more than I have now.
Thanks,
>>>--Tiribulus->:D

[chilledoutuk]

if you insist on using vidomi with xvid i recomend you try the modified version by alexo here: -

http://www.alexander-oelmaier.de/

however the way vidomi runs two pass encodes is that it controlls the bitrate itself outside the VFW interface this is not optimal for XVID.

if you want to use Vdub & Avisynth to encode then here is a little guide I done as a project.

http://www.aoul98.dsl.pipex.com/chilledoutuk/

hope this helps

[mikeX]

I 've never used Vidomi, but it appears that that's what causing this problem.
Concerning VirtualDubMod, I really don't think there should be such a difference in encoding speed given that you sellect 'Fast Recompress'.
VirtualDubMod can also 'append video segments', so you could use that feature to encode multiple files into a single clip.
More on VirtualDubMod here:
http://www.doom9.org/gknot-main5.htm (DVD backups using Gordian Knot & VDubMod & XviD)
http://www.doom9.org/xvid-vdub-final.htm (Manually encoding Avisynth files with VDubMod to XviD)
Of course instead of avisynth files (.avs) you can use your .avi file (captures, etc). But you can still use avisynth for filtering/denoising etc (usually faster than using VDubMod's filters)

About the stats file:
Extension and/or filename/location doesn't make a difference as long as the same name/path is specified in first and second pass configuration. The file (if it's location remains unchanged) gets replaced everytime you start a first pass.

[Tiribulus]

Thanks for your help guys,
@chilledoutuk:
Actually I am using his version of the encoder and .dll for Vidomi with Xvid. I will check your guides,thanks, but keep in mind my captures are mpeg2 and not avi if that makes any difference.

@mikeX:
The majority of what I'll need to encode will be tv captures that are mpeg2/program stream so manual would be better most of the time. DVD rips haven't been an issue. Here's the deal. I got a Phillips DVP462 which is unspeakably kick@$$ except that many of my old mpeg2 capture Divx encodes are at too high a bitrate for it too handle without stuttering. On a computer they're fine, which is what they were originally done for. DVD rips all seem to come out low enough to provide spectacular quality without stuttering. I was just using one pass quality based encoding with Divx. A friend gave me a DVD rip done in Xvid they got from someone at work (a movie I already had :] ) and it's subjectively 95% of DVD quality on the Phillips player @ only 700 megs and a little change. That's what I'm trying to approximate for my captures from now on. I really need to keep the bitrate under like 12 or 1300 or it starts stuttering on the standalone. One more thing: is it even possible to use CBR with multipass encoding? That just occurred to me while I was typing this. One more more thing. I was NOT using fast recompress, but full processing mode. What's the diference and will I lose any quality using fast recompress?
Thank you so much for your patience with my lengthy posts.
>>>--Tiribulus->:D

[mikeX]

is it even possible to use CBR with multipass encoding?

No. Multipass is a mechanism to achieve better VBR, there's no point in it if you have CBR.


What's the diference and will I lose any quality using fast recompress?

Full Processing mode internally converts the input video to the RGB colourspace (because all of virtualdub's filters work in the RGB colourspace).
XviD (and all other MPEG-4 codecs) use the YV12 colourspace.
MPEG-2 video usually uses YV12 too.
So you end up with something like this:
YV12 --> RGB --> YV12
However, best conversion is no conversion, and that's what Fast Recompress does (as you'll notice you can't use any filters in Fast Recompress).
So you gain (by not losing) both quality and speed with Fast Recompress ; )

[chilledoutuk]

My guides are for encoding from mpeg2 DVB and DVD

The idea behind two pass encoding is to have VBR whilst still being able to hit an average bitrate or filesize.

Using constant quality or fixed quant creates VBR streams but the resultant bitrate or filesize is unpredictable.

CBR should only be used if you are making video to be streamed over networks or the internet which have a limited bandwidth. Otherwise VBR encoding is much better as the bitrate is distributed according to the varying compressibility of the video sequence.

[Tiribulus]

A quick reply for now:
I don't want to sound ungrateful or whiny because I really do appreciate the help. However judging from MikeX's site avi-synth, or probably frame serving in general, is way beyond the level of dedication I'm going to be able to give to this. Which probably means I'm stuck with lousy quality encodes from my tv captures. I got really spoiled with Vidomi, load files, select single pass quality based in Divx and click start. In a couple hours I have a really good quality movie or commercial-less tv shhow I captured from digital tv, BUT no control over the bitrate which didn't matter then because all my computers played them fine. Now with this player anything over about 1300 gets iffy and I have to control the bitrate if I don't want stuttering. The two pass Xvid encode I started this morning before work( and before I read your guys posts ) looks good, but somehow Gspot tells me it's 570ish bitrate. Also the file is 2.6 gigs @ that bit rate if someone can explain that and took 8 hours to encode. I've been fiddling all night with vdubmod and Xvid. So far I'm at excruciating encode times with unpredictable file sizes or bitrates. Or single pass which hits my bitrate close every time, but looks horrible. I figure whoever did this encode of KillBill1 which looks unbelievable @ 714 megs @ 873 bitrate is skilled beyond my abilities. I'm still open for suggestions, but am becoming discouraged fast. It's not that avi-synth scares me I've got plenty of computer skills generally, I just don't have the kind of time it looks like it would take to learn it properly. Especially since it needs changing for different sources.If one of you guys knows how to splice several files into one, as in segments of a tv show minus commercials. I would be grateful once more. So much for the short reply.
Thanks agin, I'm not giving up just yet, but am on my way.
>>>--Tiribulus->:confused:

[Tiribulus]

http://gregnmary.zapto.org/capstats.bmp
This is the info on my troublesome sources if this gives any clues.
>>>--Tiribulus->

[Tiribulus]

OK, I just discovered that the audio was saving as uncompressed pcm which accounts for the humongous finished file size even though I was using direct stream copy for audio and the original was 224k/48/16 mp2. The audio file was 1500 plus a second!!!! I ran a test using full process on the audio and specifying 128k/48/16 mp3 and not only did it astronomically reduce the audio portion it also allowed the video bitrate back to close to what I specified. I'm guessing that Vdubmod didn't know what else to do with mp4 layer2 as a source without being told and just spit it out as uncompressed pcm. The encode time per pass for this 133 minute movie capture is about 2.5 hours which is ok except that with two passes that makes 5 hours total. I think that's just the way it is with two pass and I'll have to live with it.
>>>--Tiribulus->

[mikeX]

You don't have to master AviSynth to do what you want.
A simple script, like

mpeg2source("your_file")

and maybe a resize filter, should be adequate.

I don't really understand that 'splicing' thing you wanna do.
If you mean take out the commercials from a clip, then you can just use

trim(startFrame, endFrame)

accordingly.

[Tiribulus]

I'm not opposed to giving a shot I suppose, however I'm beginning to conclude that my source mpeg2 files are probably not going to give me the same small files and eye popping quality that can be had from a ripped DVD. I'll look at your guides again and I'm sure will have some questions. Those are very well done BTW and I was impressed by your skills. What I mean by splicing is I usually use M2Edit Pro to edit the commercials out of my captures (I guess mentioning that before would've been helpful) which gives me say 8 mpg2 files with very clean frame accurate cuts. I would load all 8 into Vidomi at once. If I start the encode right there Vidomi automatically joins them as a single file with no A/V sync problems and the fades from the show itself work beautifully and they look and sound great. also it usually only takes like 2 hours. The only problem with this is that the bitrate can vary by 100% from job to job and I have to keep it relatively low for it to work on my new standalone. One show may finish @ 2000 and the next @ 4000. If I manually force it low enough they look blocky and nasty. This is all with Divx. It may just be my captures, which look great before recompression, but are mammoth in size. A 2 hour flick is like 7 gigs plus @ 8000/720x480 video and 224/48/16 audio. Maybe they cannot be made as small and sweet as a dvd rip. The screenshot is from one of these capture which mysteriously shows the bitrate @ -601 even though I capped it @ 8000.
>>>--Tiribulus->:D