Determining the bitrate of an MPEG file.

[PuzZLeR]

Greetings!

Is there any way to determine, within a reasonable level of accuracy, the bitrate of a .VOB or MPG(-2) file? If the source was encoded in CBR it's relatively quite easy, however if it came from a VBR device or encoder it gets tricky.

The reason is that I own a Pioneer DVR-520H to capture video from VHS, TV and camera, and then migrate it to my PC (via DVD-RW media) so I can add further editing and effects with Ulead VideoStudio, and personalized menus with Nero to permanently burn the final result with.

I would really love to know what exact bitrate my DVR encodes with at SP mode (and others) so that after I edit it, I can encode/render it at an optimal highest bitrate without making the file larger than necessary, and without losing quality either. (Yeah, I'm like that greedy investor who's looking to maximize his ROI, lol.)

These specs are not available anywhere and even Pioneer themselves were not helpful. Ulead gives me something like 9496kbps which I know is rather high because it's giving me the upper bound (maximum) and I tried logging the second-by-second readings from Nero Showtime with no confident conclusion.

I understand that there probably isn't any sure way to determine this exact number since it's all "variable". I also understand that SP mode is probably from 5000kbps to 5500kbps (with AC3 audio). Anyway, is there at least a "rule of thumb" when determining all this?

Especially, is there a better way to determine max/min or average bitrate or any reasonable clues to have a good idea to work with?

Any answers are appreciated. Thank you so much in advance to a great bunch of people on this site!

[manono]

Hi-

One way to get the exact video bitrate is to open the video in DGIndex and run the preview (File->Preview). It can take awhile, though, as it scans each frame.

A bitrate calc will give you a pretty good indication. I use the one in GKnot. Fill in the length, filesize, audio bitrate, overhead (just check the box) and it gives you the video bitrate.

[guns1inger]

bitrate viewer might also help

[PuzZLeR]

Thanks so much for your replies and help! I've run some tests so far the past few days with hours of video. This new info gives me some new data to work with to apply to projects.

In case anybody can benefit:

What I notice is that you can encode at, let's say 5500kbps, but still end up with an average bitrate of 4200kbps. I can assume that there are further parameters involved such as an upper bound, and a lower bound.

I find that I still don't have an answer because mathematically speaking, the upper and lower bounds can have an infinite number of posibilities.

However, I have a much better understanding. I am trying, and testing certain encoding combinations, and am getting closer and closer to the right "fit".

[guns1inger]

actually, upper and lower bounds in this case are finite.

Variable Bitrate encoding works from three figures, a maximum, a minimum, and an average.

The average is the bitrate around which the encoding will be based, as this is the figure that will govern output size.

Using your setup for the moment, the minimum will be somewhere between 0 (the absolute lower bound) and the average.

The maximum will be between the average, and 9800kbps - the maximum allowable bitrate for a single DVD video stream.

However simple math tells us that while there may be spikes at either end of the scale, to maintain the average bitrate the averager minimum and average maximum must be symetrical around it.

A good encoder will maintain the requested average bitrate, even if it means padding, unless there is not enough data to pad with - example : very small resolution with a very high bitrate. With DVD there is enough resolution to maintain the bitrates defined in the spec.

The "Right Fit" is found by using a bitrate calculator to tell you what bitrate will fill what space at what running time. That's it. It is not rocket science. The upper and lower bounds will then come from whatever the average is.

If what you are trying to achieve is the best bitrate for your own encoding by working backwards from what your recorder does, then you are probably making a lot more work for yourself that you need to. If you are learning from it, fine. But there is an easier way.

[manono]

Hi-

...but I just let DGIndex pump away overnight.

I said it takes awhile, but not that long. Go Options->Playback Speed and set it to Maximum. I can usually get the result for an entire film in 15-30 minutes.

You can load it with many gigabytes of video and let it do the rest. Cool!

It's the number of frames (or length of the video) that's important, and determines how long it'll take, and not the size of the file.

[PuzZLeR]

Thanks again for your input folks!

Yes, a bitrate calculator is wonderful, and should be all that's necessary when determining bitrates and "fits", etc. The calculators that I use all give me almost the exact same figures. Very accurate indeed!

However, this is all dandy when determining Constant Bitrate (CBR). The figures only work when there's a uniform flow of data. What about Variable Bitrate (VBR)?

What I'm saying is that if, with Ulead VideoStudio, you encode at a certain number kbps, at VBR, you will get an AVERAGE bitrate that is lower (obviously) after running it through something like DGIndex. You have no way of knowing in advance unless you encode and then find an average after the fact. I find it varies from video clip to video clip and that is why I'm running many of them through to get a good average.

I know that statistics work best in large numbers. You have to run many empirical tests to determine a close approximation of the theoretical mean.

Anyway, I feel I'm within a few percentage points of determining what my recorder outputs and what VideoStudio encodes at certain VBR settings and making a match.

Of course I could simplify my life by using CBR, but I do want to optimize my output as best as possible.

So, am I missing the boat somewhere? Let me know if that's the case. Thanks in advance.

Anyway, I'm still learning even though I've been with this hobby a few years now and appreciate all your input which has been helpful. If anybody is going through the same thing, I'm willing to share ideas in this thread if I can help.

[jagabo]

Uleads single pass VBR is different than most other encoders' multipass VBR.

With multipass VBR you set an average bitrate with a lower and upper bound. The file size comes out to the average bitrate times the running time. Some scenes will have more bitrate and some will have less. A bitrate calculater can tell you the average.

I'm not sure how UVS's single pass VBR works. I think you're setting the high limit bitrate and some scenes get less when it thinks it's OK. As a result there's no telling how big the file will turn out.

[PuzZLeR]

Uleads single pass VBR is different than most other encoders' multipass VBR.

I agree Jagabo,

I am suspicious of the way Ulead VideoStudio encodes. It seems to follow its own agenda. However, so far I haven't noticed anything bad about the video it yields. It's all very nice quality for its settings and I'm happy even though others in this forum said it wasn't a "true MPEG encoder".

Yes, I'm up in arms about it. I'm thinking of just doing CBR instead and saving myself the headaches, hoping the difference in quality isn't an issue.

I would love to encode using another application such as TMPGEnc, but I love the editing features of Ulead and the fact that it has AC3 audio.

Just curious anybody, is CBR well within DVD compliance? (Sorry if it's a stupid question.)

[jagabo]

is CBR well within DVD compliance?

Yes, as long as you stay within DVD limits. ~9800 max for the video, ~10000 total for video plus audio.

At the max bitrate you'll only be able to fit about an hour on a single layer DVD. If you encode at CBR ~4500 to put 2 hours on a DVD the quality will be significantly less than with a VBR encoding with that average bitrate.

[PuzZLeR]

Cool. Just to be sure:

The hardware playing the final finished video product doesn't "care" if it's CBR or VBR. It will just output the quality given and that's it. Right? None is really any closer to compliance than the other I assume. (Of course being withing the maximum and minimums obviously.)

And of course, just to snuff out a myth going around, the finished disc won't spin differently or play differently whether it's CBR or VBR I assume? I've actually heard that it applies physically as well, that if the video was encoded in VBR format, the disc will spin at different speeds inside the hardware.

Huh? I seriously doubt that.

Thanks in advance.

[jagabo]

The hardware playing the final finished video product doesn't "care" if it's CBR or VBR. It will just output the quality given and that's it. Right?

Yes.

And of course, just to snuff out a myth going around, the finished disc won't spin differently or play differently whether it's CBR or VBR I assume? I've actually heard that it applies physically as well, that if the video was encoded in VBR format, the disc will spin at different speeds inside the hardware.

I don't have a definitive answer to that but it wouldn't surprise me if the disk spins at different speeds for different bitrates. Note that there are constant linear velocity and constant angular velocity DVD drive designs (and variations in between). So the ability to spin at different speeds is part of some (CLV) hardware designs.

[BobK]

The reason is that I own a Pioneer DVR-520H to capture video from VHS, TV and camera, and then migrate it to my PC (via DVD-RW media) so I can add further editing and effects with Ulead VideoStudio, and personalized menus with Nero to permanently burn the final result with.

I would really love to know what exact bitrate my DVR encodes with at SP mode (and others) so that after I edit it, I can encode/render it at an optimal highest bitrate without making the file larger than necessary, and without losing quality either. (Yeah, I'm like that greedy investor who's looking to maximize his ROI, lol.)

You're wasting a lot of time if your re-encoding it. The 520 has 32 manual record settings. Decide how much time you want to put on the disk, then set it to record at the setting that gives you that much time on the disk. Bring that disk to your computer and you can just create a new menu and author without recoding. If you're editing out commercials and stuff then you might have to use 2 disks to get it all to the computer and then author to one disk, but that's still a lot faster than recoding everything.

[FulciLives]

Doesn't Ulead VideoStudio have a 2-pass or multi-pass VBR instead of a single pass VBR?

One would think so and if so that would work better than single pass VBR.

- John "FulciLives" Coleman

[PuzZLeR]

Yes I agree that the Pioneer 520 has several bitrate levels and so forth. When I dump video from it to my PC, I avoid re-encoding as much as possible. If it's only menus I want to add, then Nero does it for me no problem with minimal encoding. (I don't like the menus my 520 offers.)

However, I like to add text, filters, masks, audio, etc etc to some stuff where it applies, which I can't do on my 520. This leaves me with little choice but to re-encode the stuff all over again, which is why it would help to know what bitrate the original material was in so I can re-encode as close to that bitrate as possible.

Yes, Ulead does offer one-pass and two-pass VBR. I find two-pass takes much longer than the other, but there is very little difference in results, if any. (Maybe it may show in higher bitrates than the 4000kbps to 5000kbps range.)

Thanks for your input folks!

[manono]

Hi-

Since filesize directly correlates with bitrate, all you have to know is the size of the video and its length, in order to find out the bitrate to use to reencode for the same size.

[adam]

Bitrate has no effect on the speed at which the disc spins. Data is read off of a DVD at a constant rate and stored in a buffer. It doesn't matter if the bitrate jumps back and forth between 100kbits and 9800kbits, its still read from the buffer at the same speed. The disc does change spin rate based on where the data is being read from though (disc spins faster as approaches outside edges.)

If you use multi-pass VBR and your encoder is worth a lick than your average should always be exactly the same as what you set it to in the encoder. If you use 1-pass VBR than resulting bitrate can never be predicted exactly.

For bitrate analysis I prefer to use BitrateViewer. I've heard some say the trial version is inaccurate but the full version works perfectly. For bitrate calculation I use Fit2Disc (full version of FitCD.) If you fill in all of its variables than you can predict the final filesize to within less than 1 MB.

[andie41]

I have wondered for years as to the usefulness and accuracy of Bitrate viewer. I have been testing several Mpeg2 encoders, using similar options (6000 average/8000 max, 2pass VBR), yielding similar file sizes, and Bitrate viewer shows similar average bitrates, but the "Q" graph varies significantly. One example:

Quenc - average bitrate 4188 and "Q" average 4.23.

Hcenc - average bitrate 4456 and "Q" average 7.88.

I requested 6000 as my average, not 4188/4456; however when I run the files through DGindex, I get 5416 average for Quenc and 5788 average for HCenc, closer to what I would expect. I get similar results with Tmpgenc and Mainconcept.

So which is the real bitrate? and does the "Q" graph provide useful information. In the above example there is an approximate 6% difference in average bitrates and 46% difference in "Q" average.

[manono]

Hi-

but the "Q" graph varies significantly. One example:

Quenc - average bitrate 4188 and "Q" average 4.23.

Hcenc - average bitrate 4456 and "Q" average 7.88.

Well, that one's easy to answer. QuEnc (I think, although I've never used it) and just about every other encoder uses the Standard Matrix to encode with. The HCEnc is just about alone in using the less compressible (and better, although still not very good) MPEG Standard quantisation matrix as its default. The Q-Level is a function of several variables, not the least of which is the quantisation matrix used (any encoder or script filtering also). In addition, the Q-Level, as given by BitRate Viewer is also inflated, at least as compared to the Q-Scale as given by CCE. I don't care though, because I already know that, and allow for it.

So which is the real bitrate?

I know DGIndex is correct. However, are you PAL? The reason I ask is that for NTSC, the BitRate Viewer results are usually higher than what I set for the average in CCE.

For me, knowing the Q-Level is very useful. Before doing my encoding, I find the matrix used and the Q-Level of the original DVD video. This helps me choose the matrix for my reencode, which will give me the Q-Level I'm aiming for. If you check out good quality retail DVDs, you'll quickly learn that none of them use either the Standard Matrix (the CCE and most encoder default) or even the MPEG Standard matrix (default in HCEnc).

[adam]

The trial version of BitrateViewer isn't that accurate but the registered version is. The reported avg bitrate is just as I set it in CCE.

[andie41]

The different quantization matrix makes sense as to differing "Q" level numbers (I had overlooked that point). I used DGindex to get the matrix for Quenc, and it is using the same as Mainconcept. I know there are many factors involved in the encoding process, but setting as many the same, as I have access, I get a "Q" average of 4.23 for Quenc and 10.66 for Mainconcept. What do I learn from these numbers, and which would I use? So Quenc is compressing more - more efficiently, or just dumping data?

I am in NTSC country.

[FulciLives]

I played around with QuEnc a few months back and I was not happy at all with the quality of it's encoding. Recently I played around a bit with HCenc and it seems to work really well.

For reference I have used both TMPGEnc Plus and CCE many times over so I am very familiar with the quality of those encoders and I swear HCenc looks nearly as good if not as good as CCE does.

- John "FulciLives" Coleman

[dcsos]

No one mention the simpliest solution for BITRATE

Play the file in POWERDVD

RIGHT click the screen
CHOOSE "Show Information"

Bitrate and format anaylsis appears in GREEN SUPERSCIPT top right of screen

[FulciLives]

No one mention the simpliest solution for BITRATE

Play the file in POWERDVD

RIGHT click the screen
CHOOSE "Show Information"

Bitrate and format anaylsis appears in GREEN SUPERSCIPT top right of screen

I've done this myself sometimes but often wondered how accurate it is.

My Pioneer DVR-531H-s (a stand alone DVD recorder) has a DISPLAY option that gives a similar type of bitrate readout as does PowerDVD so sometimes I do that when I'm watching a DVD I've made be it on the Pioneer or on my computer.

- John "FulciLives" Coleman

[vhelp]

Hi everyone.

This topic was interesting, and I had a few comments and couldn't help but
to have a few questions come out of it. I'll post the questions in a
separate post. Hope this is not considered Thread-Jacking. Thanks.

Regarding this "Q" thing..
I've used BV (bitrate viewer) for years. I've found that part of the reason
for its (shall I say) drift, is due to such cases when the source consist of
3:2 pulldown. When the source MPEG-2 is 23.976 fps with 3:2 pulldown, BV will
show the source as 29.970 fps, but it is my guess that it is compensating by
adding more bits to the math, hence the drift. I could be wrong.

But, a short experiment -- FPS: [23.976 w/3:2* -vs- 29.970] showed two
different output reports. I think that mileage will vary from user to user,
though as long as the *original* source is the same.. ie, 29.970 fps and then
encoded as two projects, one as 23.976 w/ 3:2 pulldown, and the other as
29.970 fps, Interlace.

* - again, 23.976 w/ 3:2 pulldown (in most apps) will show as 29.970 fps.

-vhelp 4120

[vhelp]

These are my questions regarding the MPEG bitate, "Q" and so on.

-- Some day, I hope to complete an MPEG Encoder app, but for now,
I'm still well behind in this endeavor. Anyway..


Question 1..
( though I feel like a dummy for asking ) could someone please explain what
this "Q" is, pros/cons and a few examples of utilizing it to one's advantage.

( I've always heard that a smaller "Q" is better, but I was never should to
what extent, etc )


Question 2..
Is is possible to *obtain or retreave* the "Q" from a given source ??
( if its something simple, I'd like to write a tool to extract it, in hopes
for further Encoding optimimzation strategies )


Question 3 -- the hardest to get info on..
In an MPEG-2 file, how is the Bitrate *seen* and then (extracted) and/or
calculated ??
( also -- if its something simple, I'd like to write a tool to extract it,
in hopes for further Encoding optimimzation strategies )

-vhelp 4121