Postby alosada on Sun Feb 20, 2005 8:57 am

It doesn't, George. Rather, In now see that VS in fact switches back to its stiff defaults, which do not seem to be the best you can get from VBR.

On the other hand, you're not blind, Rends. In order to be able to see the Advance button you must previously "activate" it. Its very simple: close VS if it's open, find the uvs.ini file in your \Document and settings\All users\Program data\Ulead Systems\Ulead VideoStudio \8.0\ directory, open it in Notepad and write a new line reading Advance=1 after the last entry in both the [MPEGVIO] and [VIODRIVER] sections. Save the file, restart VideoStudio, place a videlo clip in the Timeline and select Share > Create Video File > Compression tab. The Advance button should be there now.

Thank you two and Maddrummer for your feedback. I will be replying to some of your previous comments as soon as I have finished my test runs with VBR.
alosada
 

Postby Rends on Sun Feb 20, 2005 12:05 pm

alosada,
ok i found it.
Yes i´ve the same entries

Maximum = 8264
· Average = 8181
· Minimum = 5784


Rends

PS: How did you find it out to activate the advanced mpeg codec settings?
And are there any documentations about it? Looks interesting but i´m not sure if i will ever need it.
Rends
 

Postby alosada on Sun Feb 20, 2005 5:20 pm

Thank you, GeorgeW, for confirming my suspicions: VS sticks to its own defaults and ignores your choice of Max-Ave-Min values. It simply takes in your Max and sets 99% Max as Ave and 70% Max as Min.

As regards documentation about the advanced video creation settings, a pdf manual and a fully functional demo of the Mainconcept encoder (of which Ulead's MPEG.Now appears to be a limited version) can be downloaded here:

http://www.mainconcept.com/mpeg_encoder.shtml

Don't forget to make a copy of uvs.ini before you experiment with the advanced settings and don't touch anything unless you know what you are doing. You might be in for some nasty surprises in later renderings. That's why I have only played about with the VBR settings (and in vain so far).

In any case, many of the settings are greyed out, others can be modified in the main dialog box itself and the rest simply cannot be altered (as wilth the VBR values, you can make a different choice but VS will simply reject it).
alosada
 

Postby jchunter on Sun Feb 20, 2005 5:47 pm

More food for thought: I used the bitrate viewer to analyze some of my completed project video files, which contain a mixture of video and still jpegs. The video was captured with Capwiz to Mpeg2 at 8 Mbps Variable. Video Studio did all the edits and final video file creation. Bitrate shows peak bitrate at 9081 Kbps, avg. at 6707, and minimums estimated between 1400 and 2450 Kbps (for the still pix).

Conclusion: Visually scanning the bitrate shows VS IS doing some serious compression with the still pictures, which don't change for their duration (3 sec). The video clips show much less variation, which is consistent with your observations.
jchunter
 

Postby alosada on Sun Feb 20, 2005 9:14 pm

Thank you, JC. From the low bitrates VideoStudio gave to your stills I suspect you used version 7 rather than 8 for your rendering. Did you?
alosada
 

Postby jchunter on Mon Feb 21, 2005 3:24 am

I used VS 8.01 to edit and produce the video files. The stills are jpegs dropped into the timeline at 2048 X 1536 pixels. They display with much better resolution then the video (naturally).
John
jchunter
 

Postby alosada on Fri Feb 25, 2005 4:15 pm

I started this thread seeking reassurance that my VideoStudio 8 copy was not faulty —it wouldn't let me choose my own VBR settings. Some replies, however, aroused my interest in finding out what one might be missing by having to make do with its VBR defaults and what could be done to overcome this limitation. The results of the tests I made to this end can by no means be taken as benchmarking figures for VideoStudio; however, they have helped me answer these questions and I hope they can be of use to others, too.

This is what I used for testing:

Hardware. Pentium 4 2.4 GHz processor, 1 GB RAM, 2 7200 rpm IDE HDs (80 and 120 GB), AVermedia analog capture card

Software. Windows XP with SP1, VideoStudio 7.01 (VS7), VideoStudio 8.01 (VS8), MainConcept Mpeg Encoder 1.04 Demo (MC), Bitrate Viewer (BV), VirtualDub_MPEG v. 1.5.10 (Vdub), MediaStudio Pro 7.0 Trial and MovieFactory Disc Creator 3 Trial —the last two only to check their VBR compression defaults.

Source. An AVI file 272 seconds long and 1.04 GB in size that was captured from an 8 mm camcorder tape using VS8 with MainConcept's MJPEG codec at quality level 19 and its associated default settings.

Output. More than forty mpeg files rendered from the source AVI by using a variety of constant and variable bitrate compression schemes in VS7, VS8 and MC.

Data. File size; peak, average and minimum bitrate (BV); maximum, average, minimum and total I, P and B frame size (Vdub).

This is what I found:

Continuous versus variable bitrate
First of all, I set to find out whether using VBR instead of CBR at the same bitrate level would actually be effective towards saving space in VideoStudio. To this end, I compared the sizes of the files obtained by rendering the source AVI with both CBR and VBR at 8264, 6000 and 4000 kbps —these numbers represent the Maximum value used by VS in the latter case.

The differences in size between the CBR and VBR rendered files were as follows: 10.3%, 9.4% and 8.9% for VS7 at 8264, 6000 and 4000 kbps, respectively; and 2.5%, 2.3% and 2.2% for VS8 at the same bitrates. Therefore, the space saved by using CBR instead of VBR would translate into time savings of 6.2 to 5.3 minutes per hour in VS7, but only 1.5 to 1.3 min/h in VS8 —to convert any percentage here into minutes, please multiply it by 0.6.

How important being able to fit 66 min of high-quality video rather than 60 on a DVD obviously depends on your specific requirements. In any case, using VBR as opposed to CBR will invariably save you at least 4 times more space in VS7 than in VS8. Why? Read on, please.

VS7 versus VS8

In the following test batch I compared the compression abilities of the current and previous version of VS by rendering the source AVI both at CBR values of 8264, 6000 and 4000 kbps, and at the same Max VBR values in combination with the default Aver and Min settings in VS7 and VS8 —no choice here.

Size-wise, VS7 and VS8 performed on a par at CBR: the largest difference between the files they produced at identical bitrates was only 0.05%.

VBR was a different matter, however. Thus, the VS7 files obtained at 8264, 6000 and 4000 kbps Max VBR were 8.1%, 7.3% and 6.9% smaller, respectively, than the corresponding VS8 files.

Therefore, VS7 appears to be more capable at VBR mpeg compression. This is most probably a result of its using a more aggressive —and also, possibly, more balanced— compression scheme (Max/90% Max/192 kbps in VS7 versus Max/99% Max/70% Max in VS8). In fact, version 8 uses much closer Max and Ave values (only 1% apart) and a much higher Min value (5784 vs 192 kbps at VBR = 8264 kbps).

Subsequent tests with MC revealed that the motion window of my source file fell in the medium-to-high bitrate region. Had I used a source file with slower scenes, the gap between VS7 and VS8 would probably have widened as the former could have taken advantage of the very low Min setting it uses (192 kbps).

Capturing versus rendering
This test compared the compression efficiency of Ulead's MPEG capturing and rendering engines (i.e. Ulead's MPEG.Direct and MPEG.Now encoders) by using VS8's 8264 kbps VBR template to capture the same video employed to obtain the source —albeit in mpeg format. The resulting file was 6.6% smaller than that rendered from the source AVI at the same maximum VBR (8264 kbps). However, re-rendering the captured file at VBR = 8264 kbps caused it to expand to a size only 0.05% smaller than that of the mpeg file initially rendered from the AVI.

Therefore, re-rendering a previously captured mpeg file in VS8 —which is eventually unavoidable towards making a DVD— offsets any gain resulting from the aggressive compression scheme used by Ulead's own (capture) encoder (8264/7437/3719 kbps) relative to its borrowed MC encoder (8264/8181/5784 kbps).


Confronted with the inability to alter the VBR settings, I set to test the following potential alternatives to efficiently reducing the size of mpeg files:

Using longer GOPs
The purpose here was to check whether using the standard PAL GOP sequence (15 frames) rather than the default VS sequence (12 frames) would improve matters. It didn't: size differences were only 0.2–0.3%. As revealed by the Vdub figures, this was a result of the gain in reducing the number of I frames —the least compressed ones— by 20% being offset by the increased number of P frames (6.7% more) and by both types of frame receiving more bytes in the files containing the longer GOPs.


Using audio compression
Ulead's AC3 (Dolby) audio plug-in is an efficient tool for saving space. In order to estimate any gains in using it instead of VBR video compression, I transcoded the VS7 and VS8 files obtained at VBR = 8264 kbps to AC3 audio from their original, LPCM format, using Ulead's default bitrate (256 kbps) in addition to 192 and 384 kbps.

The 192, 256 and 384 kbps transcoded files were shorter than their parent LPCM files by 13.7%, 13.1% and 11.8%, respectively, both in VS7 and in VS8. The equivalent time gains are 8.2, 7.9 and 7.1 minutes per hour. However, because, the space saved by the plug-in is constant in terms of bytes, the actual gain in time will depend on the particular bitrate used to compress the video —it increases with decreasing bitrate (e.g. from about 8 min at 8264 kbps to 14 min at 4000 kbps). In any case, these savings will add to any size gain one may obtain by compressing the video too.


I would like to finish this rather lengthy post by drawing several Conclusions:

1. Ulead seemingly uses four different VBR compression schemes:

· Max/90% Max/45% Max for captures (with Ulead's own, MPEG.Direct encoder)
· Max/90% Max/70% Max (Movie Factory)
· Max/90% Max/192 kbps (VideoStudio 7 and MediaStudio Pro)
· Max/99% Max/70% Max (VideoStudio 8 only)

Based on these numbers, you can expect VS8 to be least efficient of all Ulead video processing programs in terms compression —and it certainly is judging from the results.

2. You can only experience the real edge of VBR by using high enough Max values and low enough Min levels in combination with medium Ave values suited to the quality of your source and its length. Unfortunately, no Ulead program seems to let you choose a custom combination such as 8264/6000/4000, for example, with which MC produced a file 22.9% smaller than that obtained with CBR = 8264 kbps (a saving of nearly 14 minutes in 1 hour).

3. The lack of flexibility of VBR compression in Ulead's MPEG.Now encoder is probably the reason why some advanced users prefer to frameserve AVI files to an external encoder for rendering and then author the resulting mpeg files in their Ulead programs. Obviously, MainConcept would hardly ever sell a copy of their standalone encoder at $149 if anybody could get it bundled to a self-contained video editing program such as VideoStudio for less than $100. Some usage restriction in VideoStudio's implementation of the MC encoder must therefore have been introduced to avoid unfair competition with the parent product.

4. The fact that VS7 is a better performer than VS8 at compressing files makes VS8 more of a downgrade than an upgrade from its predecessor. This is probably a discouraging conclusion, but also, probably, one easy to reverse. What should we do?

· Buy the Dolby audio plugin and forget about VBR.
· Spend extra money on an external encoder —with or without a frameserver.
· Ask MainConcept to develop an enhanced mpeg plug-in for VS and price it reasonably.

· Wait for double-layer DVD blanks to get cheap and dependable enough to make this debate futile.
· Ask Ulead to correct VBR stiffness in VS8 if it is a bug or make its defaults more similar to those of VS7 otherwise —if only to honour the following statement in their VS8 product description brochure: “Ulead MPEG.Now codec maximizes picture quality and minimizes file sizes”.
· Other

Any suggestions and comments are welcome.

Thank you all for your patience.
alosada
 

Postby Rends on Sat Feb 26, 2005 7:34 pm

alosada,
i have one question. Is there a image quality difference if you compare VS7 with VS8?

I remember when using VS7 if i set the (direct mpeg2capture)) mpeg quality slider from 70 to full there was no difference in image quality, coding time or anything else.
IBut with VS8 there is a difference at least in coding time wich means that my AMDxp2000 isn´t fast enough for directmpeg2 capture with VBR8264 and quality slider set to full.
I´m able to capture direct in mpeg2 with VBR8254 and quality slider set to default (70percent) at a 80percent CPU usage.

Rends
Rends
 

Postby maddrummer3301 on Sat Feb 26, 2005 9:47 pm

Rends,
The quality slider affects the amount of motion search for the
encoder.
Set the quality slider to 70
Click on Advanced Tab for Mpeg Output Settings
and look at the
"Advanced Video Settings" (3rd Tab) - Motion search should be 8
Then exit and change to 50
Motion search will change to 6
A setting of 100 will equal a motion search of 11
A setting of 0 will equal a motion search of 0

MD
maddrummer3301
Senior Member
 
Posts: 2514
Joined: Fri Dec 10, 2004 10:24 pm
Location: US

Postby alosada on Mon Feb 28, 2005 5:25 pm

Thank you, MD, for clarifying the purpose of the quality slider and its equivalence in Motion Search units.

I ran a few more tests involving rendering the source AVI at VBR = 8264 kbps and the quality slider at 20, 70 or 100% in both VS7 and VS8. This is what I found:

· The difference in size between the files rendered at 70 and 100% was only 0.05% in VS7 and 0.03% in VS8 (i.e. less than 2 seconds in an hour at most).

· The difference between the files rendered at the two extreme Q values (20 and 100%) was 0.5% (16 sec/h) in VS7 and 0.9% in VS8 (32 sec/h). Interestingly, the file rendered at Q = 20% was larger than that obtained at Q = 100% in VS7, but smaller in VS8. In any case, the differences were all negligible.

· Rendering at Q = 100% took 1.8% less time (equivalent to 65 seconds more for 1 hour of footage) than rendering at Q = 70% in VS7, but 9.1% (5.5 min per hour of footage) more in VS8.

· On the other hand, encoding at Q = 100% took 37.9% more time (equivalent to 22.7 minutes per hour of footage) than encoding at Q = 20% in VS/, and 39.0% more (23.4 min per hour) in VS8.

Although, again, the results may not apply to other bitrate levels or CBR and, indeed, to other source videos, they suggest that there is little to be gained in terms of file compression by using a Q setting of 100% rather than the default Q = 70%.

Also, if one wishes to use the highest setting in order to ensure the best possible quality (in Ulead’s words), then the encoding time will not be much longer than with Q = 70% (less than 5 min/h in these tests). On the other hand, using rather a low setting such as Q = 20% can make the video more “fluent” in motion (Ulead’s words again) and the encoding time substantially shorter.

I’m afraid I have not yet developed a trained eye to identify slight differences in video quality, so I can’t say much about how different the rendered videos look. However, because the two extremes of the scale are Quality and Speed, perhaps the Peak, Average and Minimum actual bitrates of the files as determined in Bitrate Viewer may be of some help here. This is what I found in this respect:

· The actual Average bitrate obtained with Q = 70% and 100% differed by only 0.07% in VS7 and 0.04% in VS8 (hence the highly similar file sizes). Also, the differences in Peak and Minimum bitrate ranged from 0.08 to 0.75% (very small again).

· Rendering at Q = 20% instead of 100% produced files with a 2.6-2.8% higher Peak bitrate and a 11.35-15.39% lower Minimum bitrate.

Based on these results, which may or many not be valid (they were confirmed by replicating each test), I think using Q = 70% or 100% is virtually indifferent. On the other hand, using a setting below 70% to save encoding time only seems to make sense if you drag the slider to rather a low level.

The Q setting may be more influential on captures than on renders. In fact, like Rends, I remember getting tons of dropped frames if I pushed the slider past the 90% mark when directly capturing mpeg files in VS7. I suppose my system was not fast enough to allow VS to efficiently cope with data acquision and rendering at that level on the fly. I therefore guess using 100% is simply not viable for everybody.
alosada
 

Postby BogieV on Wed Mar 16, 2005 2:30 am

This is very good thread - thank you alosada!

I found some of your observations using UMF 2.5SE after enabling the Advanced Tab before to see your post.

Reading your findings I returned my quality settings for all presets back to 70%. With me it seems mainly affects the CPU usage (without actually making any tests to confirm it).

What I want to say is in my case the Default presets for MPEG2 encoding are with setting NoFrame, while if you add New Preset it becaomes with Lower Field First. I try to change to Upper field but after closing the Manegar and reopenning it always has reset back to Lower field (or No frame for the 3 default presets). Anybody can coment on which setting for the field is best and how can we 'fix' it in the Advance Tab?

About the encoding rates in my case the Max rate is always leading. For egsample if I set Avg to 6000, Max to 8000 and Min to 1000 kbps it always reset to Max 8000, Avg 7200, Min 192!

In my case I can't alter the Min (it always stayes 192kbps) and the Avg is always 90% of the Max.

One more thing - in the Multiplex settings when having CBR encoding the multiplex type is still Variable. Is it better to uncheck this box?
Also Time stamp is I frame only be def - is it better (to reduce out of synch issues durring encoding/multiplexing) to make it to I & P frames? (the setting actually remains - doesn't reset)

Many things at once but I hope we can discuss about the details in the Advance settings! Anyone?!
BogieV
 

Postby alosada on Wed Mar 16, 2005 5:40 pm

BogieV:

If your Min VBR is 172 kbps and your Ave value is 90% of your Max, then you must be using Movie Factory or VideoStudio 7 as version 8 uses the much more conservative compression scheme Max/99% Max/70% Max. That’s why VBR is virtually useless in VS8.

For this reason, among others, using anything higher than the default 70% when encoding an mpeg file makes little sense.

Don’t worry about the Variable box being checked in the Advanced, Multiplexer settings. Ulead programs will use CBR if your mpeg was encoded that way unless your Project Settings at the time of muxing include VBR.

And don’t worry about field order either. VideoStudio will use whichever you choose in the Create Video File dialog box, General tab.

Unfortunately, forcing VS to place timestamps on each frame doesn’t seem to correct OOS issues. Nor does closing all GOPs. Only muxing with the proper files in the shared Ulead Systems\DVD folder does.

If you really want to have free access to all advanced encoding settings you’ll have to spend $149 on the full-featured standalone encoder from MainConcept. The Advanced button was made invisible by default probably because it was intended for use by Ulead developers only.
alosada
 

Postby BogieV on Thu Mar 17, 2005 3:03 am

Alosada, thanks a lot for the details!

Yeah, I'm sorry but I don't use actually VS7 but rather capture with Leadtek WinFast PVR that seems to use same settings like the Ulead encoder.
Whatever I do it's strange! For example CBR 8200 and VBR at same rate is almost same size files.
Thus I went in the MF and plyed with the Advanced settings which confirmed for me the strange implementation of the encoder used by Ulead and Leadtek.

So in general we do not need quality setting different from the default. I also shouldn't worry for the Field Order and Multiplexing settings I guess (at least the DVDs that I produced doesn't seem to have any problem).

Only if the quality of the encodes was a bit higher... I mean even at 9000kbps (no matter CBR or VBR) direct capture from the TV tuner card I'm not very content.

Anyway the conclusion is one - don't be fooled by the value for the VBR setting in Ulead products. Set high rate even for VBR as the actual Average rate would be close to that.
On the negative side you never can predict fair enough the final size of your encoded files.
BogieV
 

Postby Ronald Pierce on Thu Mar 17, 2005 6:16 am

I have been following this very interesting thread. I have VS8 and like the editing. The DVD conversion has not been great with high-motion sources. The DVD module for layouts has been fairly limited - but I have not used it much due to not liking the MPEG converfsions. Maybe this question should be it's own thread, but here goes...

What to do to get the best quality DVD's without spending a fortune (but not being cheap)?

1) Spend the $30 on the VS8 AC3 pluggin.
2) Buy DVD Factory Content Creator 4 upgrade $69 w/ AC3 and better DVD support - is the MPEG encoder different? or more flexible?
3) What about DVD Workshop Express or std? upgrade for $150 - More power? Is the MPEG encoder better? more flexible?
4) Purchase the Full MainConcept encoder $150? do stand-a-lone encoding?
5) continue using TMPGEnc DVD Source Creator/DVD Author for preparing/authoring DVD's using VS8 to edit?
6) upgrade to TMPGENC Express3 for MPEG encoder w/AC3? ~$70
7) Wait for VS9 in another month or so and see what options are there?
Upgrade Cost?

Other suggestions? Don't want to spend a fortune, don't want to cheap out. You get what you pay for - What is the happy medium to get a good, quality DVD encode? Your thoughts?
Ronald Pierce
 

Previous

Return to VideoStudio

Who is online

Users browsing this forum: AhrefsBot [Bot], Bing [Bot], Google Feedfetcher and 7 guests