Under "Video Save Options" / "compression" tab (mpeg files) does anyone check - Two-Pass encode????????? does it improve quality? does it greatly affect render times?
thanks,
bob s
Two-Pass encode........
Moderator: Ken Berry
Variable Bitrate encoding, and 2-pass encoding helps to maximize bit utilization. The first "pass" through your video takes "notes" about the scenes (hard, average, easy, etc...). The 2nd pass then encodes based on the notes from the first pass -- allocating more bits to the "hard", and less bits to the "easy" scenes.
What I have found (purely subjective) for my DV25 source video (miniDV or Digital-8), is that 6000kbps and higher doesn't really need VBR encoding (and one-pass CBR is fine).
Where VBR and 2-pass shows its benefits is when I am forced to use lower bitrates (like 4000 - 5000kbps).
Just my 2 cents
What I have found (purely subjective) for my DV25 source video (miniDV or Digital-8), is that 6000kbps and higher doesn't really need VBR encoding (and one-pass CBR is fine).
Where VBR and 2-pass shows its benefits is when I am forced to use lower bitrates (like 4000 - 5000kbps).
Just my 2 cents
George
Hi,
Did I misunderstand what I read about this, that VBR is just that, variable, and it won't use the say 8000kbps if not needed?
And thus if as you say it's overkill above f.i. 6000 it will simply not use the maximum bandwidth, whereas a fixed rate will spoil my disk space with unecessary data? I had concluded, maybe erroneously, that for higher data rates VBR was a good precaution against bloated data streams?
In the same vein dual pass would be even more efficient at this.
Alas my preliminary checks proved larger with two-pass! However, maybe the quality was improved, hard to judge on a PC when you output interlaced contents :)
Did I misunderstand what I read about this, that VBR is just that, variable, and it won't use the say 8000kbps if not needed?
And thus if as you say it's overkill above f.i. 6000 it will simply not use the maximum bandwidth, whereas a fixed rate will spoil my disk space with unecessary data? I had concluded, maybe erroneously, that for higher data rates VBR was a good precaution against bloated data streams?
In the same vein dual pass would be even more efficient at this.
Alas my preliminary checks proved larger with two-pass! However, maybe the quality was improved, hard to judge on a PC when you output interlaced contents :)
Regular VBR encoding usually has 3 bitrate variables -- Min, Average, Max.
You cannot put those values in using the Ulead implementation of MC's encoder -- the bitrate you enter is the MAX value. So, theoritically, the bitrate should not go any higher than the value you enter (but some encoders do have "spikes" above the specified MAX bitrates).
The encoder will attempt to maintain the "Average" bitrate, so given an "Average" bitrate in a VBR encode of 6000kbps, and a Constant Bitrate of 6000kbps in a CBR Encode, the resulting files sizes should be pretty close in filesize. I don't know how Ulead determines the "Average" -- it could be a percentage of the MAX. There was a thread here (or the old Ulead forums) where someone did some extensive VBR testing.
How long was your test video, and what were the resulting filesizes (one-pass vs. two-pass)?
You cannot put those values in using the Ulead implementation of MC's encoder -- the bitrate you enter is the MAX value. So, theoritically, the bitrate should not go any higher than the value you enter (but some encoders do have "spikes" above the specified MAX bitrates).
The encoder will attempt to maintain the "Average" bitrate, so given an "Average" bitrate in a VBR encode of 6000kbps, and a Constant Bitrate of 6000kbps in a CBR Encode, the resulting files sizes should be pretty close in filesize. I don't know how Ulead determines the "Average" -- it could be a percentage of the MAX. There was a thread here (or the old Ulead forums) where someone did some extensive VBR testing.
How long was your test video, and what were the resulting filesizes (one-pass vs. two-pass)?
George
As I said they were test so I tthrow everything away since.
But I just redid a small check for you
Video length 13sec16frames
Interlaced lower first
quality 100
VBR 8000
one pass
non-square
no audio (PCM 48000 selected)
DVD PAL 4:3 standard
test1p.mpg = 10.823.680 bytes
changed to two-pass and re-shared
test2p.mpg = 11.692.032 bytes (8% more than one-pass)
But I just redid a small check for you
Video length 13sec16frames
Interlaced lower first
quality 100
VBR 8000
one pass
non-square
no audio (PCM 48000 selected)
DVD PAL 4:3 standard
test1p.mpg = 10.823.680 bytes
changed to two-pass and re-shared
test2p.mpg = 11.692.032 bytes (8% more than one-pass)
OK same settings as before, two more details I did not specify :
anti-flicker filter selected (I think it applies to menus only),
and, I'm using the Trial version.
testB1p.mpg rendered in 10'24", size 351.858.688
testB2p.mpg rendered in 22'22", size 354.975.744 (only 1% more this time, but did it really re-encode a compliant mpg?)
anti-flicker filter selected (I think it applies to menus only),
and, I'm using the Trial version.
testB1p.mpg rendered in 10'24", size 351.858.688
testB2p.mpg rendered in 22'22", size 354.975.744 (only 1% more this time, but did it really re-encode a compliant mpg?)
Now this time we have
TestC1p.mpg one pass 30'37", size 504.672.256
TestC2p.mpg two pass 63'10", size 504.971.264
This file's contents is much more dynamic than the previous tests (constant pans and travellings, it's a game demo).
What I found strange is that the file in two-pass mode grows immediately as with one-pass, I would expect an analysis without writing first.
Instead it renders immediately AND writes a huge statfile.txt with the results and then compares on pass two with another method.
For instance in this file at 45%, when it traditionally starts over, the mpg file is at 394 MB and the stats file at 13+MB
Then, the mpg file is erased and restarted while it writes a statfile1.txt (growing again) and,
a pass2.txt with numbers in the 100,000.0 range,
a pass2_gop.txt with numbers in the 1000,000.0 range,
and a pass2_q.txt (a single numbers list between 1.0 and 6.0).
Those last three remain unchanged during step two and are small (126, 12 and 63 KB in this case). After rendering everything is deleted.
(Yes, I DO have other things to do, why?)
Bottom line George, you're right it looks like two passes is not helping much at 8000 kbps... except doubling rendering time.
In all cases, the file size was larger, even if marginally.
Of course the quality may be better...
Who wants to test it at 7000? 6000? 5000?
TestC1p.mpg one pass 30'37", size 504.672.256
TestC2p.mpg two pass 63'10", size 504.971.264
This file's contents is much more dynamic than the previous tests (constant pans and travellings, it's a game demo).
What I found strange is that the file in two-pass mode grows immediately as with one-pass, I would expect an analysis without writing first.
Instead it renders immediately AND writes a huge statfile.txt with the results and then compares on pass two with another method.
For instance in this file at 45%, when it traditionally starts over, the mpg file is at 394 MB and the stats file at 13+MB
Then, the mpg file is erased and restarted while it writes a statfile1.txt (growing again) and,
a pass2.txt with numbers in the 100,000.0 range,
a pass2_gop.txt with numbers in the 1000,000.0 range,
and a pass2_q.txt (a single numbers list between 1.0 and 6.0).
Those last three remain unchanged during step two and are small (126, 12 and 63 KB in this case). After rendering everything is deleted.
(Yes, I DO have other things to do, why?)
Bottom line George, you're right it looks like two passes is not helping much at 8000 kbps... except doubling rendering time.
In all cases, the file size was larger, even if marginally.
Of course the quality may be better...
Who wants to test it at 7000? 6000? 5000?
-
MikeGunter
Hi,
VBR isn't likely something that will help enough to use it at high bit rates.
Where it shines is by adding up easy frames and hard frames to decode and dividing the bit rate to put more good information on a disc.
CBR is constant bits, with inconsistant quality over all the bits.
VBR is constant quality with inconsistant bits over the disc.
When dropping below a certain level (in George's case 6000kbs), VBR will give one *consistant quality*.
Mike
VBR isn't likely something that will help enough to use it at high bit rates.
Where it shines is by adding up easy frames and hard frames to decode and dividing the bit rate to put more good information on a disc.
CBR is constant bits, with inconsistant quality over all the bits.
VBR is constant quality with inconsistant bits over the disc.
When dropping below a certain level (in George's case 6000kbs), VBR will give one *consistant quality*.
Mike
I get you Mike, but now the question remains does it have side effects?
We see we can rule out dual-pass for about 6Mbps or more by George's example, but is there an argument against VBR (or in favour of CBR) knowing it sometimes does nothing more?
I mean why not leave it there and hope for a possible improvement in either quality or file size, if any.
Or do we lose something by using it (compatibilty problems, rendering time or other)?
See, the same way as one may use 7-8000kbps, not knowing if it's useful, as a matter of precaution against too much artifacts. Just in the case we may someday need to edit the MPG video again, when the original AVI is long deleted.
We see we can rule out dual-pass for about 6Mbps or more by George's example, but is there an argument against VBR (or in favour of CBR) knowing it sometimes does nothing more?
I mean why not leave it there and hope for a possible improvement in either quality or file size, if any.
Or do we lose something by using it (compatibilty problems, rendering time or other)?
See, the same way as one may use 7-8000kbps, not knowing if it's useful, as a matter of precaution against too much artifacts. Just in the case we may someday need to edit the MPG video again, when the original AVI is long deleted.
-
MikeGunter
Headaches, cramping, and rashes.daniel wrote:I get you Mike, but now the question remains does it have side effects?
There are some applications for authoring that stutter and moan with VBR. Editing usually dosn't like VBR.
No foul to George, but that was *his* bit rate floor. The floor itself is a moving target. A lot of clothing is sold as "one size fits all" and to look at bit rates that way ends up being "one size fits none."We see we can rule out dual-pass for about 6Mbps or more by George's example, but is there an argument against VBR (or in favour of CBR) knowing it sometimes does nothing more?
And how that works is sometimes counter-intuitive.
I helped the National Guard Bureau as a technical advisor on a film they used for training and publicity. In some of the scenes in the desert, when the tanks fired their main guns, the smoke and the dust became blocky at 7000 CBR. What was happening is that there were many, many small changes in picture frame that the CBR wasn't encoding. We switched to VBR 2-pass and cleaned it up nicely.
There I disagree.
I mean why not leave it there and hope for a possible improvement in either quality or file size, if any.
Or do we lose something by using it (compatibilty problems, rendering time or other)?
See, the same way as one may use 7-8000kbps, not knowing if it's useful, as a matter of precaution against too much artifacts. Just in the case we may someday need to edit the MPG video again, when the original AVI is long deleted.
My video world is a bit different than most; I'm a trainer and teacher, and consultant and work with 3d graders and Network TV and the very, very big government and corporate customers.
In any of these worlds, I always want to keep the option to edit in the *least* compressed content if need be. The work I shoot is DV, the work I consult/produce sometimes is HD. In either case, I keep the original content on tape or hard drives (until the end of time
).In other threads, folks say that they see zip wrong with MPEG2 for editing content, and I think *I'd agree* as long as it isn't for broadcast and one could live with minor (if even noticable) artifacts. Reprocessing the MPEG2 is were problems will show up.
I use Canopus ProCoder (they have an Express version for under $70, that is just fantasic for converting content with a high-quality encode. And I think that is my point. You, me, and a Brazilian Tree Monkey could write a decent piece of software to encode content at *high bit rates*, but good encoding at low bit rates (and allowing for longer programs on the DVD) call for superior engineering.
One more thing to confuse us all. You can put any amount of content on a single DVD. That's all movies ever done in all time. Of course, you might have to define 50 or more movies in one bit. Silly and goofy as that sounds, it should bring something home. The more bits to define the content, the better it looks; and its partner, The better the engineering, the better content at lower bit rates.
Mike