What is "nominal bit rate"?

[Bully9]

I'm trying to re-encode an mkv using x264 in videodub.

I'm looking to produce around an 8gb file, and v calc says the required bit rate is c. 8446kbit/s,. So i enter 8446kbit/s in the x264vfw configuration dialogue box.

Trouble is, the file size produced is 3.6GB, and mediainfo tells me that the bit rate is 3949Kbps, although the 'nominal bit rate' is indeed 8446Kbps.

Could some kind person please explain the above, and how i can produce a file with an actual bit rate of 8446 and a size of 8GB?

Thanks in anticipation.

[MOVIEGEEK]

Nominal bitrate is usually the average bitrate for VBR, some programs use the term nominal to mean maximum. If you want a fixed file size use CBR.

[Bully9]

Thanks for the reply but i really don't follow you at all.

Surely on a two pass it should be possible to produce a given file size using VBR? How do you produce a CBR video using X264 anyway?

And are you saying that in mediainfo nominal bitrate means maximum bitrate?

And therefore also that on the x264vfw configuration, the "target bitrate" actually means maximum bitrate? That doesn't seem to make a lot of sense.

In any event, if anyone can tell me how to make an 8gb file using x264, i'd be very grateful.

[jagabo]

Yes, use 2-pass VBR with an average bitrate should deliver the average bitrate you request (and hence the specified file size). But other settings can keep the encoder from accurately hitting the specified average bitrate. Things like minimum and maximum quantizers, GOP size, etc.

[Bully9]

So if i understand you, 'target bitrate' in x264 means average bitrate, not 'nominal bitrate' - whatever that means.

My settings from vcalc were therefore correct (a 2hr film allowing for 1 audio track at 448bitrate) but for some reason i ended up with a file half the size it should have been,

You say 'But other settings can keep the encoder from accurately hitting the specified average bitrate.'

But surely it's not a coincidence that mediainfo reports a 'nominal bitrate' (whatever that is! - maximum bitrate??) of exactly what i specified as an average bitrate in x264.

In other words, in a sense, i did accurately and exactly hit the specified bitrate. Just the wrong "type" of bitrate. In any event, all the other settings were default and surely could not cause such the inaccuracy of 50% out?

[poisondeathray]

Not recommended to use x264vfw. Buggy and you get sync issues with b-frames in avi container. No offical support from developers

What version are you using?

The default settings are very poor to use.

Use the cli encoder or a GUI for it. e.g. ripbot264, xvid4psp, megui

[Bully9]

The dialogue box that opens in virtualdub/video/compression/x264...etc is headed up x264vfw configuration. No version number, but a build date of July 29 2009.

If i open windows/start/programs/x264/x264 command line interface encoder i get a dialogue box headed up MeGU! 0.2.3.2136.

Is the latter that which you are suggesting i should use? If so, do i integrate it with virtualdub? If so, how do i do this?

Sorry if these questions are a bit basic, but i'm not an expert as you'll have gathered from previous exchanges

[poisondeathray]

You don't integrate it with vdub, unless you frameserve out. There are several guides for frameserving and vdub if you search, on this site and others.

Vdub only exports avi directly - that's a bad idea for h.264 and b-frames. Not to mention x264vfw is quite buggy as you can see

Unless you need something specific to vdub like a filter , It's easier, faster, better to use avisynth and most filters have an equivalent or better version in avisynth

If it's a straight encode, you might find ripbot264 or xvid4psp or handbrake easy to use.

[jagabo]

My luck with h264vfw isn't as bad as poisondeathray's. I haven't seen any real problems with it. Yes, in order for VFW based applications to open and seek within the resulting AVI files you have to use the "Virtualdub Hack" option, but media players don't seem to have any problems with playing the resulting AVI files, with or without the hack.

Be sure you create a new stats file with each new project by running the Multipass 1st Pass option before running the Multipass Nth Pass option.

[johns0]

I use uncropmkv to re-encode mkv to different sizes

[Bully9]

Well, the original file was corruot which was clearly causing all sorts of problems. I tried more than one of the suggestions here, but without success.

Anyway, I'm grateful for all the responses - as usual, i've learnt a lot from those who took the trouble to reply.

[Bully9]

I finally managed successfully to reduce a large (uncorrupt!) mkv using megui (not the most intuitive of interfaces?). I could only get the x264 encoder to work if i set it to default and then chose just my mode (automated 2pass) and bitrate (8710). If i tried to do anything like increase the no. of reference frames, i got an error after the first pass (it took quite a while to work out what was going on!).

So, two questions:

1. Is it possible to encode in x264 using megui and to specify the no. of reference frames? Any other restrictions?

2. And (which takes me full circle to the original question) mediainfo showed the final video had a bit rate of 8530 (and a 'nominal' bit rate of 8710). So it was smaller than the 7.95 GB i was aiming for and that the specified 8710 would have given me.

Not a big problem, but can i find out how to specify a bitrate that will give me the exact size (DVD9) file i want?

[ehunter]

Nobody was really clear in answering one of your questions Bully...

Nominal Bit Rate is = the max bit rate allowable by the encoding process. The bit rate does not have has to be achieved in the encoding process. It is only a max ceiling to ever allow.

[Bully9]

Thanks for the unequivocal definition ehunter.

The problem remains of the X264 encoder producing a file with a NOMINAL (ie maximum) bitrate equal to that specified in the GUI as AVERAGE bitrate. Because the amount specified in the GUI as average bitrate is what should govern the size of the output file.

[jagabo]

I don't think ehunter's definition is fully accurate. From what I've seen MediaInfo only shows the Nominal Bitrate for MPEG 1 and MPEG 2 encoded files. It probably gets this value from the first MPEG header (the maximum_bitrate_descriptor field; there are many MPEG headers in an MPEG stream -- maybe one for each GOP? I'm not sure). This is supposed to be the maximum bitrate; so the decoder knows what to expect. But different encoders seem to put different values there. Some put the requested max bitrate (as ehunter points out, the encoder may never actually hit that), some put the actual max bitrate, some simply put 9800 (for DVD compatibility). And since MPEG containers usually allow you to append different segments with different properties whatever appears there won't necessarily be accurate for the entire video.

I wouldn't rely on that report from MediaInfo.

[jman98]

Not a big problem, but can i find out how to specify a bitrate that will give me the exact size (DVD9) file i want?

Your expectation is not realistic given your method of achieving it. If you want exact size, assuming you can even do that, you need to use CBR video. End of story. VBR has too many variables effecting it that can cause the final size to be anything from very close to what you wanted or more or less than what you wanted. I don't encode to X.264/H.264 so I can't comment on whether or not you can use CBR with it, but you can't get accurate final file sizes unless you use it.

You also are not looking at this the correct way. When your encoded size is smaller than you wanted, you win because it will fit on a disc with no problems. When the encoded size is more than you wanted, you lose for obvious reasons. People like you that try to hit an exact target with no deviation when encoding are just asking to be unhappy all the time. When your encodes are a little smaller than you wanted, just accept it and get on with your life. Do you really want to be one of those people who does encodes 10+ times on the same file until it finally gets close enough to your target size to not bother you?

[Bully9]

Well, jman, there are 1000s of X264 rips out there that are bang on 7.95GB. So if you're correct, then they must all be CBR, but i do find that a little difficult to believe. I don't know how to check if a video is VBR, but i assume there probably is an easy way.

As regards your philosophical point, i think you misjudge the type of person i am. The first four words of the quote ('not a big problem') are the real give-away. My life has not been ruined by my inability to encode to an exact size, but nevertheless i am always interested to learn from those more knowledgeable than me.

Thanks to you and jagabo for your comments.

[jagabo]

If your x264 encodes aren't meeting your average bitrate requirement, set the max bitrate higher (if that doesn't cause problems with your playback device) and set the min quantizers lower.

[poisondeathray]

Well, jman, there are 1000s of X264 rips out there that are bang on 7.95GB. So if you're correct, then they must all be CBR, but i do find that a little difficult to believe. I don't know how to check if a video is VBR, but i assume there probably is an easy way.

Very very unlikely any of them are CBR. Use bitrate viewer, or stream analyzer like streameye

[Bully9]

Well, that kind of undermines jman98's assertion that:

"you can't get accurate final file sizes unless you use (CBR)."

Unless i'm missing something.

[poisondeathray]

You should be able to hit the exact size (within a few kb) with a 2pass encode. I do it all the time, as do many others, and as your observations of "those rips out there". I'm not sure why you aren't hitting the targets.

If you used default settings and min quantizer settings, that is 10 and more than enough (ie.. you shouldn't be undershooting due to the high min quantizer limitation)

Some x264 builds have problems, maybe you have a bad one?
There's a few versions released each week, some fix bugs, some create new bugs...
What version of x264 are you using?

Are you using a recent build of MeGUI? There is a patched branch that is more stable and updated
http://forum.doom9.org/showthread.php?t=151159

[Bully9]

Thanks pdr. Actually this is quite an old thread just resurrected yesterday and there's no longer a pressing problem. I'm not even sure the version i had then is the same as i've got now. Nevertheless your input is appreciated as always, and i'll look in more detail at your suggestions next time i do an x264 rip.

[creamyhorror]

I don't encode to X.264/H.264 so I can't comment on whether or not you can use CBR with it, but you can't get accurate final file sizes unless you use it.

I don't think your explanations apply to x264. x264's 2-pass mode is a form of VBR that allows you to achieve accurate targeted file sizes..

With x264, using CBR simply to achieve a particular bitrate is just a mistake, because it wrecks quality. CBR is (more) suited to things like streaming video.