Vegas to the Web for the Videophile - A Tutorial

NickHope wrote on 3/2/2011, 5:30 AM

Over the past few years I have been using the following workflow for rendering videos for the net, whether they be destined for self-hosting or a site like YouTube, Vimeo or Facebook.

I found this technique gives a higher quality than is possible with the tools in Vegas Pro. The Sony and MainConcept AVC codecs in Vegas Pro 10.0 have caught up a bit, but we are still limited to rudimentary blend or interpolate deinterlacing, and bicubic resizing.

In the course of this mammoth discussion instigated by Musicvid, I have refined some aspects of my workflow, in particular the deinterlacing, which I am now doing with the amazing QTGMC deinterlacing script. But much of the workflow is useful with progressive footage too.

I have written a tutorial explaining how to do it. For the time being this is written with upload to Vimeo/YouTube/Facebook in mind. I hope to add a branch for rendering for self-hosting, where lower bitrates and slightly different x264 settings will be used. I may also split the tutorial up into a number of pages (any thoughts on that?), and I also have a site redesign in the pipeline which might help readability.

This is a workflow for videophiles who are prepared to spend time and effort getting the best quality:bitrate ratio they can. With interlaced footage it is SLOW. Much slower than just using Sony AVC. But there are presets which can make it faster (or slower). If speed is your priority, just use the Sony AVC codec, but do visit the section about conforming your video's levels, which applies to all AVC/H.264 videos destined for the web.

If anyone has any comments on the workflow or the tutorial, or has success or failure with it, please let us have some feedback in this thread.

Musicvid has been using Handbrake to achieve a very similar result, and I believe he is planning to publish a tutorial for that soon.

Many thanks to Musicvid and amendegw for that engrossing discussion. Thanks to amendegw, Kimberly and Stringer for permission to use test footage, and to dxdy for hosting test renders on his Vimeo account. Thanks to Laurence, farss, A.Grandt and the rest of you who gave insight which helped with other aspects of this workflow. And thanks of course to the geniuses who write these amazing free tools that make this possible.

Back to post

Comments

amendegw wrote on 3/2/2011, 1:10 PM

@Nick Hope: "Jerry, have you jazzed up any of the x264 parameters for low bitrate/self-hosting? Could you please post a snagit of your advanced settings so I can mimic them in MeGUI? Also are you using CQ or Avg bitrate? And is your test (1) done with your latest settings?"Nick, I've done nothing special beyond musicvid's recommendations. As a matter of fact, he may have made some recent mods that I haven't caught up with. Here's the pertinent screen captures for my 1200kbps render:

...Jerry

musicvid10 wrote on 3/2/2011, 1:18 PM

Other than using CQ RF 18.75, and UMH, neither of which should make any measurable difference, my settings are identical to Jerry's.

Also, I left most high profile stuff out of my 8Mbs preset for playability and because it does not positively affect quality at that bitrate, only increases rendering time. My 2Mbs template does use b pyramid and 8x8 transform, because of their positive effects on compression.

Here are my 2Mbs settings, which very closely emulates Vimeo delivery quality.

johnmeyer wrote on 3/2/2011, 2:06 PM

OK, here are the results of a couple of hour's worth of fooling around (most of it spent getting QTGMC to work multi-threaded, and also discovering what you guys already knew, namely that different versions of Vegas treat levels differently). I can't possibly add to all the work that's been done trying to get the best quality. You folks are way ahead anything I could do there.

Therefore, my purpose in this post is two-fold:

1. Improve the speed of rendering.
2. Eliminate the Handbrake/MeGUI steps for those who don't want to install and learn these tools, or who can't see/appreciate the differences in quality.

I have an 8-core Intel i7 computer. I found that this script could not utilize more than four cores. I recommend you try setting the core number (in the first SetMTMode call) to half the number of cores that you have. Also, I was not able to improve speed at all by changing the EdiThreads value from the default zero (0). So, in the end, other than limiting the number of threads, this is a straight-forward application of the multi-threaded version of AVISynth (and, just to remind everyone, you have to use this "hacked" version of AVISynth in order to use the following script).

Bottom line, I was able to more than triple the speed by using the multi-core version of AVISynth. Not as good as 8x, but still a huge improvement.

I then used VFAPIConv to serve back into Vegas 10.0a, and I then rendered using the single-pass Mainconcept AVC codec in Vegas. Before I rendered, I manually over-rode the settings for the imported VFAPIConv AVI file so that it was set to no resample, and the field order was set to progressive. I also set the project properties to this same value. My input video was some HDV footage from my Sony FX1 camcorder. I rendered to 1280x720 at 29.97 with a PAR of 1.0, at 4,000,000 VBR (10,000,000 max).

So, I frame-served out of a first instance of Vegas (using Vegas 7.0d), into the following script, and then from that script through VFAPIConv into Vegas 10.0a. I had 5.0 seconds of video on the timeline and the render took 46 seconds, so about 1/10 real-time. Without the multi-core AVISynth rendering, it would have been less than 1/30 real-time.

#Script to deinterlace video based on QTGMC deinterlacing script



loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")

loadplugin("C:\Program Files\AviSynth 2.5\plugins\Film Restoration\Script_and_Plugins\RemoveGrain.dll")

Import("E:\Documents\My Videos\AVISynth Scripts\QTGMC3.11.avsi")



#Serve out from Vegas in RGB24

SetMemoryMax(1000)

SetMTMode(5,4)

source=AVISource("e:\frameserver.avi").KillAudio().assumetff().converttoYV12(interlaced=true)

SetMTMode(2)



output=QTGMC(source, Preset="Very Fast", EdiThreads=0, ShowSettings=false ).SelectEven() 



return output

#stackhorizontal (source,output)

LReavis wrote on 3/2/2011, 2:08 PM

somewhere someone asked if the Sony AVC in Vegas 10 would give OK results at low bitrate if all the clips on the TL were progressive. I tested that and the answer is a definite NO!

I had some low-motion video that looks pretty decent using the Handbrake settings shown in the last musicvid post (except that I prefer deblocking settings of -2 and -1). I set the average bitrate for 500, both in Handbrake and in Vegas, and verified the resulting .MP4s with AVInaptic.

The Sony output was so sorry that I didn't even do any more experiments with it. One slight advantage that Handbrake might have had in this comparison was that I set the audio to Mono - not an option with the Sony render.

Even though I started with progressive (except for one downloaded looping background) and I had to encode the DNxHD file as interlaced and then de-interlace and decomb in Handbrake, the far superior quality of the Handbrake output left no doubt for my plans: I'll be using Handbrake.

I'll try to post both tomorrow - or later today - after I have time to really look at all my settings and make sure I got it right.

farss wrote on 3/2/2011, 2:14 PM

My approach is very simple for when I've shot 1080i.
I use Mike's Smart de-interlacer, adjust levels and feed 720p into the Sony AVC encoder and encode at 6Mbps. I could afford to bump that upto 10 or 20Mbps, my bandwidth is essentially free and I use a dedicated PC running bandwidth management software for uploading. This approach is reasonably fast and the whole process is done inside Vegas, no intermediates required.

I must point out though that much of what I shoot is shot with effectively locked off cameras on solid tripods, I do make an effort to reduce the amount of noise the camera records. So effectively the majority of the frame can be de-interlaced with a simple field merge. The parts that do move are well handled by interpolation in the de-interlacer.
I've read through how the YADIF de-interlacer works. It does seem like it'll take considerable time to do it's work, it would be a waste of time for me. One thing I've found with the smart de-interlacer and I think will also apply to YADIF is noise can really screw it up. YADIF is using pixel by pixel tracking on the alternate field and it's impossible to track noise.

For content that doesn't have to look as good as it can I just de-interlace using Vegas's interpolate i.e. drop a field. Sure this halves my vertical resolution and yes, I can see the difference but darned if anyone else seems to care these days :(

Bob.

johnmeyer wrote on 3/2/2011, 4:51 PM

I'm probably being stupid, but did someone post a link to the original "peacock" footage? I'd like to get 5-10 seconds of the original footage and see what I get. I assume that I am supposed to upload the results to Vimeo for comparison.

I tried to get Handbrake to encode, but as I suspected, it was going to take some time (an hour or so) to figure it all out, and I just didn't want to spend the time on that. However, the quality of the Vegas encode looked awfully good to me, when using the excellent deinterlacing provided by Nick's AVISynth script. I used a relatively modest 4,000,000 bps. I did use 2-pass encoding with the MC AVC encoder. I assume that everyone has been using that. If not, that would certainly account for a lot of problems at low bitrate. The single-pass low-bitrate encoding is not pretty.

amendegw wrote on 3/2/2011, 5:12 PM

"... did someone post a link to the original "peacock" footage?"You can find it here: http://www.jazzythedog.com/testing/DNxHD/peacock.zip

or, if you need the entire project, it's here: http://www.jazzythedog.com/testing/DNxHD/getvideo.aspx

Good Luck!
...Jerry

musicvid10 wrote on 3/2/2011, 7:00 PM

There is a new, "improved" project with media on the way (by this weekend).
Includes skintone test and color chart, some minor color tweaks to the footage, and credit splash. Will let you know on both threads when it's been uploaded.

Preview here: http://vimeo.com/20190131

farss wrote on 3/2/2011, 7:30 PM

Can I suggest you include a standard res chart such as the ISO 12233 chart. You can download a copy from here. If you want a copy of the standard ARIB Multiformat Color Bars I can record one from my camera, hopefully tonight and send you a short MXF clip of it.

Bob.

musicvid10 wrote on 3/2/2011, 8:19 PM

That was suggested in the other thread, and if we were keeping everything at the same resolution, it would indeed be helpful.

However, since I started with the premise of a 1080i to 720p workflow, I'm not sure what a standard rez chart would show us. Maybe how well the horizontal resolution held up after resizing? The belle-nuit chart I included has some very interesting responses to chroma subsampling at various vertical and horizontal resolutions even in the intermediate render, which may be even more useful (once I am sure how to interpret them).

NickHope wrote on 3/2/2011, 9:07 PM

Laurence said: ...you have to set Vegas up with a deinterlace method of none...

You're right. Late night schoolboy error on the project properties. I just did it properly and YadifVegas is a little nicer than plain Vegas interpolate but takes 186% as long (to Sony AVC). So ignore what I said about blur. Nice plugin. Later I'll check it against Yadif done in AviSynth.

Anyone who is using and liking the Mike Crash Smart Deinterlacer, please post its settings that you would use for 1080-60i. I'd like to compare it with YadifVegas.

These are the YadifVegas settings I used to get parity with Vegas' interpolate:

farss wrote on 3/2/2011, 9:30 PM

The trumpets might be useful for looking for aliasing problems.
I did have a go at using that chart and struck some alarming problems getting it encoded out of Vegas. I created at rasterized copy in PS at 4K and then 8K, 8K was as far as I could push PS before it fell over. Once I took it into Vegas I got wierd problems with aliasing on the trumpets that didn't really make any sense to me and no matter how I tried the encoded video was different to what I got on the preview so I gave up thinking using it was going to be very confusing. Maybe you can get to the bottom of what's going on.

I've also got an A3 sized res chart that I could shoot with my EX1 in just about any format. At least with the camera the OLPF might tame things down a tad.

If you want a rather nasty test for encoders try this one: http://www.sendspace.com/file/s4h34e
from Papassarts.

Bob.

TeetimeNC wrote on 3/3/2011, 4:29 AM

>To perhaps state the obvious it's long been my view that to get the best results out of YT or Vimeo you have to shoot the very best video in the first place and to do that you need to shoot progressive. That has left me with one major headache. How to get high resolution 25p onto a SD 50i DVD without massive issues with line twitter and how to avoid the overt problems of judder at such low frame rates. For once I'm jealous of those who can shoot 30p.

Bob, that has been my view as well, with a slight twist. A lot of my work goes to the web AND DVD. So far, very little goes to Blu-Ray. For this work I shoot 720p60. This lets me easily render to 720p30 for the web, and 480i60 widescreen for DVD with no interlacing or deinterlacing required. I've been satisfied with the quality out of Vegas for my needs. But I have found these "Vegas to the Web" threads very informative, if not over my head in some places.

/jerry

Laurence wrote on 3/3/2011, 7:28 AM

I just wanted to mention here that (to my eyes at least) the whole point of fine tweaking this process is only really noticeable when you watch your videos on Youtube or Vimeo in the fullscreen mode. If I do a Vegas h264 render and upload to Vimeo, it really looks fine in the initial window. It's when you expand out to fullscreen that you see the night and day difference that the tweaking we are discussing makes.

LReavis wrote on 3/3/2011, 10:57 AM

I am almost ready to post the results of my test - starting with progressive clips from my camcorder, then comparing the Handbrake renders with the ones available in Vegas - played from a server with JW Player (instead of Youtube or Vimeo). However, I realized that I don't have a utility to get the Vegas renders to start playing immediately, nor can I remember the ones that others have used (and I'm sure no one will want to wait for the entire files to download before playing starts).

Can anyone please suggest a good utility that will make the Vegas MP4s start playing immediately?

musicvid10 wrote on 3/3/2011, 11:08 AM

MP4 FastStart

MP4Box

LReavis wrote on 3/3/2011, 2:23 PM

@musicvid:
Thanks so much - this is the second time in the last few weeks that you've gotten me over a bump . . .

I chose MP4 Fast Start. I really like the fact that no installation is required. I used it for my Main Concept test, but don't have it up on the web yet to see how it works.

Because it looks like this thread also could get pretty long, I'll put my tests comparing shots from a progressive camera on a new thread - since it appears that most participants on this thread are starting with interlaced shots.

Thanks again - Larry

johnmeyer wrote on 3/3/2011, 2:50 PM

I did a few experiments, using the deinterlaced footage served back into Vegas (as I described above), encoding in Vegas 10.0a using both the Sony AVC and the Mainconcept AVC encoders.

Maybe I am doing something wrong, but using the Main profile, and a low 1,000,000 bps data rate, the Sony AVC encoder produces results that are completely unacceptable when encoding the 1920x1080 peacock footage to 1280x720 (720p) MP4 files. The results are, quite frankly, unwatchable. The Mainconcept encoder produced watchable results, but with blockiness in the shadows, regardless of whether I enabled the de-blocking filter.

So, I guess I need to try these other external encoders.

amendegw wrote on 3/3/2011, 3:02 PM

"Maybe I am doing something wrong"Not at all, you're seeing the exact same thing I'm seeing.

Here's the 1.2Mbps test: http://www.jazzythedog.com/testing/dnxhd/mediaplayers2.aspx (see my post several posts up - 3/2/2011 3:30:58 PM)

Here's the 200kbps test: www.jazzythedog.com/testing/lowbitrate.htm (See separate thread HandBrake - Very Low Bitrates (200kbps) Compares Handbrake, Sony AVC & MainConcept renders @ 200kbps.

IMHO, the HandBrake rendering engine is quite amazing!

...Jerry

johnmeyer wrote on 3/3/2011, 5:28 PM

Nick,

First, I want to thank you again for the amazing tutorial. I've now installed MeGUI and followed every step of your instructions. Your guide is perfect, and MeGUI is vastly superior in every way to either the Sony or MainConcept AVC encoders built into Vegas.

Also, MeGUI encodes a great deal faster than my method of frameserving back into a second instance of Vegas. I used 4 cores for the multi-core version of your AVISynth script and 4 "workers" for MeGUI. I ended up with an average fps encode rate of about 10.2 fps.

One quick question: why did you use the Constant Quality encoding rather than 2-pass VBR? I always thought the latter would give better quality, although obviously at the expense of speed.

musicvid10 wrote on 3/3/2011, 6:01 PM

Constant Quality (CRF) is almost 2x faster encode, with no measurable or visible loss of quality compared to 2-pass VBR of the same average bitrate. It was actually better at reducing blocking in FTB transitions in my initial tests last year. The drawback of doing it all in one pass is that it is impossible to predict the rendered bitrate or file size; it will vary (sometimes dramatically) from source to source.

http://mewiki.project357.com/wiki/X264_Settings#crf

johnmeyer wrote on 3/3/2011, 8:59 PM

musicvid, thanks for that clarification. I'll use the constant quality preset.

In December, I uploaded a short promo for the Nutcracker DVD I created for the local ballet company. I used the MainConcept encoder, 2-pass, and rendered directly from Vegas. This is the result (don't forget to change playback resolution to 720p because the &fmt=22 switch doesn't seem to be working):

I always thought it looked soft and somewhat blocky, even when viewed at the YouTube 720p setting, and so was not entirely pleased.

I still had the project on my computer, so I rendered using the tutorial, using exactly the settings provided. The resulting MP4 file was within 10% of the size of my original MP4 file, so they are both approximately the same bitrate, and both are 1280x720 progressive.

Here is the result of the video created by following Nick's tutorial. As you will see in about two seconds of viewing, the difference is astounding, although I'm still not sure the levels are correct (although maybe they were incorrect on the original upload):

[edit] You will see several posts later on in this thread about two problems I had: the video was playing twice, the second time without audio; and after I fixed that, the first few seconds of video were corrupted after uploading to YouTube. The problem was that I deviated from the tutorial and didn't use the Nero audio encoding. You can read more in this post later in this thread:

musicvid10 wrote on 3/3/2011, 9:09 PM

John,
Besides looking like a delightful production (have seen it performed dozens of times), I thought the camera technique was excellent. Nice job of leading the dancers. What cameras were used?

Grazie wrote on 3/3/2011, 9:46 PM

Enchanting work John!

Watching on my iPhone and the encode looks and sounds great.

Is there a reason why the 2nd half has no audio?

Thanks for sharing

Grazie

1 2 3 4 … 7

of 7