Has this problem been fixed with the new service pack?
Two-Pass Encoding
-
ando775
Two-Pass Encoding
I don't use two-pass encoding (MSP
because when I did I noticed some major blockiness, especially on darker colors. I think I saw a few forum posts of other folks seeing similar things.
Has this problem been fixed with the new service pack?
Has this problem been fixed with the new service pack?
You have to understand how these encoders work. With CBR, you set your bitrate and it keeps at that speed ±10% come wind, hell or high water.
With single pass, you have a max, min and average bitrates but, at the time of encoding, it doesn't have a clue what it will encounter, Smumi whizzing past in F1 races or a talking head, so it sets out at ~average and accelerates/decelerates according to what is happening. If it is really high action, after a minute or two, it will say to itself that it looks as if it will exceed well past the average and slows down again, so it constantly tries to average things out and generally makes for a reasonable average. Excursions to the extreme hi/lo limits are very rare.
With double pass, the first pass is just to analyse, by time, where the biggest differences are between putative I frames and B and P frames. This determines how it applies the bitrate on the second pass. Where are the biggest differences? Why, during transitions and this is usually where the max is applied, even when encoding your F1 race. The still scenes go right down to minimum bitrate, of course, and this is where the crunch lies; if you set the minimum too low, they will produce artefacts, especially if there is a slight camera movement. It is probably these that you describe as blockiness.
This is not a bug but a fact of life. There is therefore nothing to fix in SP1. I suggest you simply use a more judicious set of max/av/min bitrate values to reduce it. Better still, for SD projects <90-120 minutes long, use CBR, because you will gain very little by going to VBR, which is really useful only for average bitrates <~4500 kbit/s. Most Hollywood blockbuster DVDs average only 4000 - 5000 kbit/s, and they really do go to a wide range of extremes. However, they may be using a manually tweaked hardware/software encoder, with 20 or more passes, with encoding lasting a month or more. If you have a spare $50k - 100k, you may be able to buy a second hand encoder of this type.
With single pass, you have a max, min and average bitrates but, at the time of encoding, it doesn't have a clue what it will encounter, Smumi whizzing past in F1 races or a talking head, so it sets out at ~average and accelerates/decelerates according to what is happening. If it is really high action, after a minute or two, it will say to itself that it looks as if it will exceed well past the average and slows down again, so it constantly tries to average things out and generally makes for a reasonable average. Excursions to the extreme hi/lo limits are very rare.
With double pass, the first pass is just to analyse, by time, where the biggest differences are between putative I frames and B and P frames. This determines how it applies the bitrate on the second pass. Where are the biggest differences? Why, during transitions and this is usually where the max is applied, even when encoding your F1 race. The still scenes go right down to minimum bitrate, of course, and this is where the crunch lies; if you set the minimum too low, they will produce artefacts, especially if there is a slight camera movement. It is probably these that you describe as blockiness.
This is not a bug but a fact of life. There is therefore nothing to fix in SP1. I suggest you simply use a more judicious set of max/av/min bitrate values to reduce it. Better still, for SD projects <90-120 minutes long, use CBR, because you will gain very little by going to VBR, which is really useful only for average bitrates <~4500 kbit/s. Most Hollywood blockbuster DVDs average only 4000 - 5000 kbit/s, and they really do go to a wide range of extremes. However, they may be using a manually tweaked hardware/software encoder, with 20 or more passes, with encoding lasting a month or more. If you have a spare $50k - 100k, you may be able to buy a second hand encoder of this type.
[b][i][color=red]Devil[/color][/i][/b]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
-
rdenny
Well, compared with the Sorenson Squeeze encoder, set for the exact same bitrates and 2-pass VBR, the MSP encoder produces quite inferior final videos. I'd say there is a real problem with the ULead encoder, or "you get what you pay for"...Devil wrote:You have to understand how these encoders work...
Can't say, as I've never used the Sorensen product, but most of us are satisfied with the MC one, because it is able to convert DV to DVD very well. DV already has enough artefacts that nothing will improve on them!rdenny wrote:Well, compared with the Sorenson Squeeze encoder, set for the exact same bitrates and 2-pass VBR, the MSP encoder produces quite inferior final videos. I'd say there is a real problem with the ULead encoder, or "you get what you pay for"...Devil wrote:You have to understand how these encoders work...
[b][i][color=red]Devil[/color][/i][/b]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
But it will only go down to the minimum if the fast sections of the video eat up the bandwidth. If your footage is such that the minimum needs to be used, and the minimum is so low enough that it yields blocky video, there's a distinct chance that raising the minimum will cause the fast action scenes to lose quality.Devil wrote:...The still scenes go right down to minimum bitrate, of course, and this is where the crunch lies; if you set the minimum too low, they will produce artefacts...
I'm also surprised when you say CBR varies by 10%. Is it really so bad with the Ulead encoder? That's the sort of variation I'd expect from single-pass VBR.
Perhaps I should have said UP TO 10%! I have seen it do that. single-pass VBR depends on the settings but +/-25% is quite common, but don't believe that the max and min rates will be respected. On transitions (which are usually the most motion-intensive parts), I've seen 6000 max peak to nearly 7000 kbit/s.
And it's the same with all software encoders I've tried. IMHO, if zou want tight control, you need a dedicated hardware encoder ($$$$!)
And it's the same with all software encoders I've tried. IMHO, if zou want tight control, you need a dedicated hardware encoder ($$$$!)
[b][i][color=red]Devil[/color][/i][/b]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
Devil:
I hate to be the bearer of bad news but there *IS* a problem with 2 pass encode that was not addressed in service pack 1.
I raised this issue months ago during the beta - now that other users have comfirmed it I know I am not smoking something and it is not a settings issue as you stated. There is a Quantinization problem in the 2 pass VBR mode and excess "zero padding" is being used. This was confirmed by using Bitrate Viewer MPEG anaysis. It also explains how the file could be larger but look worse than single pass.
With a given file 2 pass encodes are supposed to be higher quality AND smaller files.... however with MSP8 ther reverse is true. 2 Pass encode is LARGER file AND Quailty is WORSE than single pass VBR. 2 Pass encode therefore is a complete waste of time in MSP8 as will will not benefit the user at all.
MSP7 was not this way nor should MSP8 be.... This is why I have basically given up on the beta test program.
Regards and Regrets,
Rob
I hate to be the bearer of bad news but there *IS* a problem with 2 pass encode that was not addressed in service pack 1.
I raised this issue months ago during the beta - now that other users have comfirmed it I know I am not smoking something and it is not a settings issue as you stated. There is a Quantinization problem in the 2 pass VBR mode and excess "zero padding" is being used. This was confirmed by using Bitrate Viewer MPEG anaysis. It also explains how the file could be larger but look worse than single pass.
With a given file 2 pass encodes are supposed to be higher quality AND smaller files.... however with MSP8 ther reverse is true. 2 Pass encode is LARGER file AND Quailty is WORSE than single pass VBR. 2 Pass encode therefore is a complete waste of time in MSP8 as will will not benefit the user at all.
MSP7 was not this way nor should MSP8 be.... This is why I have basically given up on the beta test program.
Regards and Regrets,
Rob
Athalon 64 X2 6400+, 1GIG DD2 PC6400, Asus M2NBP-VM CSM MB, ADS Pryo IEEE-1394, 260 Gig UDMA133 Hard Drive + 15 gig system drive, 18x DVDRW+/-, Windows XP SP2. 47" LCD HDTV / Monitor 1920x1080
-
rdenny
This seems to explain my results. I didn't test 1-pass vs 2-pass in MSP8, though, so I didn't observe the file size evidence. For now I render back to (huge) AVI and encode with Sorenson.robtywlak wrote:I hate to be the bearer of bad news but there *IS* a problem with 2 pass encode that was not addressed in service pack 1.
I should also add that Single Pass VBR can and does do an excellent job of encoding DV-AVI to DVD ready MPEG.
Here is how - Crank the quality slider to maximum.
in the advanced menu set Closed GOP=1 (better DVD player compatibility)
Enable motion pel search
Set bitrate to 8000 maximum instead of 6000. This helps a lot on the high motion content and gets rid of most gibs artifacts from the MPEG-2 DCT.
Until Ulead fixes 2 pass there is no advantage in using it as single pass with the above settings does a better job. My main point is that 2 pass VBR is broken right now but single is fine.
Regards,
Rob
Here is how - Crank the quality slider to maximum.
in the advanced menu set Closed GOP=1 (better DVD player compatibility)
Enable motion pel search
Set bitrate to 8000 maximum instead of 6000. This helps a lot on the high motion content and gets rid of most gibs artifacts from the MPEG-2 DCT.
Until Ulead fixes 2 pass there is no advantage in using it as single pass with the above settings does a better job. My main point is that 2 pass VBR is broken right now but single is fine.
Regards,
Rob
Athalon 64 X2 6400+, 1GIG DD2 PC6400, Asus M2NBP-VM CSM MB, ADS Pryo IEEE-1394, 260 Gig UDMA133 Hard Drive + 15 gig system drive, 18x DVDRW+/-, Windows XP SP2. 47" LCD HDTV / Monitor 1920x1080
-
rdenny
During beta testing msp8.0 (not SP1) I briefly did some 2-pass tests and found no problems other than those which have always existed. I have always advocated CBR for projects <~100 minutes simply because VBR, generally, is crappy, whether 1- or 2-pass. Why do I say that? a) because there is no visual improvement to the content of a DVD when using VBR from a DV source when viewed on a TV at normal viewing distance; b) because, as likely as not, the bitrates are never what you would expect; c) the highest bitrates are usually related to transitions, not to the picture content; d) with this kind of software, you have zero control over what is happening.
Over the past year, I think I've done one project where I used VBR (1-pass, 4000/3000/2500, if I remember correctly) everything else 6000 CBR, and the results have been perfectly satisfactory (and faster), with excellent viewing satisfaction by 3rd parties.
Over the past year, I think I've done one project where I used VBR (1-pass, 4000/3000/2500, if I remember correctly) everything else 6000 CBR, and the results have been perfectly satisfactory (and faster), with excellent viewing satisfaction by 3rd parties.
[b][i][color=red]Devil[/color][/i][/b]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
[size=84]P4 Core 2 Duo 2.6 GHz/Elite NVidia NF650iSLIT-A/2 Gb dual channel FSB 1333 MHz/Gainward NVidia 7300/2 x 80 Gb, 1 x 300 Gb, 1 x 200 Gb/DVCAM DRV-1000P drive/ Pan NV-DX1&-DX100/MSP8/WS2/PI11/C3D etc.[/size]
I'm surprised it says that. Better authoring program compatibility, perhaps, but not better player compatibility.robtywlak wrote:in the advanced menu set Closed GOP=1 (better DVD player compatibility)
Closed GoPs completely contain all the information necessary to decode the picture for each frame in that GoP. The I-frame from the following GoP is not used. This feature helps when producing multi-angle video (along with all the I frames needing to be in the same place for each angle) and for maintaining the integrity of motion menus when a selection is made.
The downside is that there are less I frames available for B and P frame reference, so the quality suffers. This is a fundamental part of the DVD spec, and players that don't support open GoPs should not have been certified to get the DVD logo on them.
Some older DVD authoring programs (I think SpruceUp might have been one of them) would only accept closed-GoP MPEGs, but I suspect there aren't any current programs with this restriction.
