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

NickHope wrote on 3/9/2011, 12:21 PM

No worries, it was my fault for bringing up SmugMug. When you're ready to publish your Handbrake tutorial I would start a new thread too as it will sink without trace on that other one. Then I'll be all over the new one with my MeGUI stuff ;)

Anyway let's raise the level... I've been looking at MeGUI presets with a view to getting back nearer to the defaults again, as opposed to a mimic of your Handbrake settings. In MeGUI's latest "DXVA-High Def." preset (the one, in theory, that I guess I should base my own HD presets on), most of the settings are almost identical to the x264 defaults, but two settings they have changed are these:

--vbv-bufsize 50000 --vbv-maxrate 50000

There's not much about these settings in the x264 settings wiki but the help tooltips in MeGUI say this:

VBV Buffer Size

Obviously the MeGUI devs found a reason to specify these settings rather than leave them on automatic. Specifying them might just help anyone doing encodes for self-hosting if they are getting stutter, although it's a little complicated as the players also have settings for buffering.

Also, here the MeGUI dev says you should do 2-pass VBR if you're going to restrict the VBV.

It doesn't look like these are accessible in Handbrake.

I wouldn't be surprised if this is the sort of thing that makes Vimeo stutter. i.e. They have vbv-buffsize really small for super-fast startup, which they achieve, but it gives some stuttering too.

Facebook have vbv-buffsize at 11294 and vbv-maxrate at 2710 in their 720p encode.

amendegw wrote on 3/9/2011, 2:00 PM

@Nick Hope: Check out my FaceBook Wall. I uploaded the 8Mbps HandBrake export from musicvid's latest Version (4). imho, it looks superb! I only see one very small stutter on the moving cars - could even be from the source clip.

...Jerry

johnmeyer wrote on 3/9/2011, 4:26 PM

Nick,

Try instead this page from the Wiki:

X264 Encoding Suggestions

I think it provides quite a bit of help in answering your questions.

Pay close attention to example 3.

NickHope wrote on 3/9/2011, 10:25 PM

@ Jerry - Facebook version ([url=http://www.facebook.com/video/video.php?v=1678603484926]) is stuttering badly here on my laptop, in the same way as Musicvid's Vimeo version ([url=http://vimeo.com/20627058]). They stutter whether or not I have hardware acceleration ticked. The older versions are behaving the same. YouTube 720p version (

is not stuttering. This might be due to Flash Player 10.2, but I'm a bit averse to rolling it back after that funny business with levels the other day.

Looking forward to seeing it in JWPlayer at 720p. Jerry, why not just go with 2 Mbps and keep the quality pristene instead of trying to get much lower than that?

Also looking forward to seeing it in SmugMug if TeeTime has time to upload it.

@ John - Thanks for that link. I'm definitely leaving the vbv stuff off (auto) for my YouTube upload recommendation. Not sure yet regarding self-hosting recommendation. In the past I went with 50000 for each for HD and had no problems.

amendegw wrote on 3/10/2011, 2:18 AM

"Facebook version (www.facebook.com/video/video.php?v=1678603484926) is stuttering badly here on my laptop, in the same way as Musicvid's Vimeo version (vimeo.com/20627058). They stutter whether or not I have hardware acceleration ticked. The older versions are behaving the same. YouTube 720p version (Strange!? I've always been plagued (and really annoyed) by stutter in video playback on the web. Finally, I'm beginning to see major relief from this problem. Is it the new Flash? Or changes to the hosting environment? Or the quality of this new paradigm of creating web content? Who knows? Even the Vimeo version shows low stutter - whoda thunk?

The answer to your specific question is, "Yes, the FaceBook clip is the same as musicvid's Vimeo upload - Version 4" The only minor differences are 1) I rendered the DNxHD intermediate on Vegas 10.0c, and 2) I rendered the 8Mbps .mp4 from HandBrake with VBR - 2 pass 8000kbps (to force the bitrate). Also I set the 'Motion Estimation Method' to hex rather than umh.

So I am befuddled by your stutter problems.

Attn: FaceBook Users I set the privacy settings to the reference video to "everyone" So, if you have a FaceBook account, you should be able to view it. Can others take a look at the clip and comment on the quality/stuttering? here: www.facebook.com/video/video.php?v=1678603484926 Other pertinent info to post back here are 1) Browser, 2) Flash version, 3) Video card make/model & 4) Hardware Accel on/off. The following screen capture shows how to get the Flash info. Right click on the video clip ("Settings" will give you the hardware accel).

...Jerry

TeetimeNC wrote on 3/10/2011, 3:42 AM

>Also looking forward to seeing it in SmugMug if TeeTime has time to upload it.

Here is the SmugMug version: http://takeonesolutions.smugmug.com/Other/Vegas-Tests/16139692_rg8FL#1211789553_winJF-A-LB

I haven't followed all the details of this discussion thread so I'm not sure what I should be looking for, so I'll look forward to hearing your assessment.

EDIT: I do notice some type of strobing that looks weird.

/jerry

amendegw wrote on 3/10/2011, 3:46 AM

"Looking forward to seeing it in JWPlayer at 720p. Jerry, why not just go with 2 Mbps and keep the quality pristene instead of trying to get much lower than that?"Okay, you can find the JW Player tests for version 4 here: http://www.jazzythedog.com/testing/dnxhd/MPV4.aspx

A word of caution - unless you have an extremely fast internet connection, the 8Mbps version will not stream very well. You'll probably have to pause play an wait for the download.

...Jerry

amendegw wrote on 3/10/2011, 3:54 AM

/jerry,

First, thanks for posting this clip on Smug Mug. I still see the same stuttering I see on my local JW Player test. Bummer!

Next, I apologize for further confusing the issue. The clip I asked you to post was from a stutter test I did a month or two back. I think the clip that Nick Hope was interested in is here: DNxHD-HB-8Mbps.zip Caution: it's large.

Sorry for the confustion,
...Jerry

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

IN SD MODE, Facebook video is not stuttering here. That's the good news. The bad news is the quality - really low quality = blurry. After the beautiful Vimeo versions, this is hard to watch. (Vimeo versions did stutter. I would rather have the crystal clear image and the stutter, if I had to choose. My 2 cents...)

IN HD MODE THE PICTURE IS CLEAR, BUT IT STUTTERS.

HP Portable (about 5 years old) INTEL T2400 at 1.73 GHz
Connected via Uverse 802.11g wireless
NVIDIA GeForce Go 7600
Flash 10.2.152.32
Hardware acceleration allowed
IE 8.0.6001.18702

In case you are looking at GPUs, here is the detail

256 MB Vram,
driver nv4_disp.dll
Driver version 6.14.10.8454
Resolution 1440 x 900 x 60
32 bits/pixel
Win XP 32 bit SP3, patched up to date

http://www.nvidia.com/object/go_7_series_techspecs.html

Edited to add link to GeForce tech spec and Memory size etc.
Edited again to clarify SD vs HD performance (IN CAPS)

amendegw wrote on 3/10/2011, 4:13 AM

"The bad news is the quality - really low quality = blurry"Did you view the high-def version? There should be an "HD" icon in the lower right. You may need to click it.

...Jerry

dxdy wrote on 3/10/2011, 5:02 AM

Oops. I didn't have HD selected in my first look at the facebook video. Indeed, in HD mode the picture is sharp, and it stutters.

Fred

amendegw wrote on 3/10/2011, 5:34 AM

"Indeed, in HD mode the picture is sharp, and it stutters."Hmmm... I've done some more testing. I have two desktop computers - both Intel Quad Core. One has a motherboard based Intel GMA 3100 display adapter (256mb). The other has an nVidia GeForce 9500 GT (512mb). Both display the annoying stutter. However, my laptop which has an ATI Mobility Radeon HD 545v (512mb) plays very smoothly (however, this smooth play has just started recently).

Could it be that ATI intergrates better with the latest Flash?

Is there another FB user with an ATI card that can confirm (or deny) this? Or maybe someone with an ATI display adapter that can look at the Vimeo Video?

...Jerry

NickHope wrote on 3/10/2011, 6:51 AM

Today I did a pretty big overhaul of my tutorial.

- I incorporated information and resolutions for rendering SD as well as HD.

- I incorporated recommended settings for rendering for self-hosting as well as upload to hosting sites.

- I decided to do the levels change in the AviSynth script with a ColorYUV(levels="PC->TV") command instead of doing it as a C-RGB to S-RGB master filter in Vegas. So I took out all the stuff about levels and made a separate "YouTube Levels Fix".

- Instead of mimicking Handbrake for the x264 settings, I changed the recommendations to be much closer to the x264 defaults. For upload I'm now recommending constant quality crf 19.0. For self-hosting I'm recommending 2-pass VBR at max bitrates of 1280x720 HD video: 2000 Kbps; 854x480: 1000 Kbps; 640x480: 800 Kbps (lower for plain background/locked down shots). The only other differences from x264 defaults are to disable B-pyramid and P-frame Weighted Prediction, and to set the deblocking to -2:-1.

- I'm now recommending CBR 320 Kbps Nero AAC audio for upload and ABR 156 Kbps for self-hosting.

I absolutely welcome feedback on these changes, in particular my self-hosting x264 recommendations.

About to take a look at your 1200 Kbps versus 2000 Kbps comparison Jerry. Loading now...

TeetimeNC wrote on 3/10/2011, 8:05 AM

>Could it be that ATI intergrates better with the latest Flash?

I just tested the Facebook version at HD fullscreen on my i7 920 Windows 7 64 bit notebook with Flash 10.1 and ATI Mobility Radeon 4670 and there is no stutter.

I tested the same on my i7 940 Vista 64 bit desktop with Flash 10.2 and ATI Radeon HD 4800 and there is stutter.

This is opposite what I would expect.

/jerry

amendegw wrote on 3/10/2011, 9:31 AM

Darn! I was hoping we could narrow down the cause (or cure) for the stutter. So far, it looks like the common denominator is laptops with ATI cards don't stutter - that makes no sense at all.

...Jerry

NickHope wrote on 3/10/2011, 11:33 AM

Jerry, at the risk of spamming the whole place with our web video stuff, I think it might be worth you starting a separate stutter survey thread. My feeling here on my Nvidia Quadro FX 1600M, XP SP3 is that things have got a bit more stuttery since Flash Player 10.2.

amendegw wrote on 3/10/2011, 11:52 AM

Nick, You're absolutely right! Sometimes it gets easy to drift on a subject and before you know it, you've hijacked a thread. I plead guilty!!

So, I've created an new thread, Web Based MediaPlayer Stutter Issues for anyone wishing to post replies to the stutter issue.

Apologies,
...Jerry

NickHope wrote on 3/10/2011, 9:21 PM

I wasn't complaining about thread hijack at all. More thinking you'd get more feedback on a new thread since it seems like a bit of a survey is what's required. i.e "Tell us your Flash Player version, browser, graphics card etc.".

Anyway, let's talk bitrates for self-hosting. After I saw [/url=http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=752907]that you successfully pulled off a 720p talking head at 200 Kbps[/url] so to speak, I realise that I need to modify my self-hosted bitrate recommendation of 2000 Kbps for "busy" 720p videos and "half that or even less" for locked-down/plain background videos.

So I'm actually thinking of recommending CQ for self-hosting as well as YT/Vimeo upload, instead of 2-pass VBR and then checking the bitrate of the rendered file to make sure it falls between say 200 and 2000 Kbps. Good idea?

So, my question is, have you guys done any testing to indicate what sort of crf value would be required to bring us into the right sort of bitrate range? I'm thinking of somewhere around 22-26, but I didn't do any testing yet.

amendegw wrote on 3/11/2011, 2:27 AM

Nick, I'm going to have to defer to musicvid on the VBR vs CQ question.

Call me a masochist, but my workflow has always been to us VBR, render my clip, look at my quality, adjust, repeat. My only real experience with CQ has been to run tests for Mark.

But, since you've brought up the question, I think I'll do some testing. Although it might be 'til Sunday 'til I have some time (plans for today & tomorrow it will be 60°F - so the golf course beckons!).

...Jerry

PS: Stay away from the coast - I hear there are tsunamis coming.

NickHope wrote on 3/11/2011, 6:27 AM

I'm getting garbled frames on YouTube again. This time rendering according to the current tutorial, but no audio so no muxing. Just sending the mp4 video file direct.

and

I'll debug it by a) trying with audio too, b) mkv container instead of mp4, c) dumbing down the x264 settings again.

Apologies to anyone who is following the current tutorial method. I'll update a.s.a.p..

musicvid10 wrote on 3/11/2011, 7:57 AM

My thought on VBR vs. CQ with x264 is that if we are trying to zero in on a specific bitrate (or file size), then use 2 pass VBR as Jerry is doing. If we do a render at a given RF, and it doesn't come in where we would like, then rendering a second time eats up any time advantage gained from doing it that way.

However, it's a fallacy to think that if one render comes in at 8Mbs using RF19, and the next project renders at 7Mbs, that there is something "wrong" with the second because the bitrate isn't high enough. They are both the same perceptual quality; the second one just needed fewer bits to achieve it.

amendegw wrote on 3/11/2011, 12:43 PM

Okay, I've done my testing. After mucho trial & error, I've determined that as low as I can go with acceptable playback quality for the "Peacock" video is 1200kbps. The same trial & error resulted in a 200kbps for the "Talking Head". To my amazment, both bitrates correlated to a CQ RF=32.

Obviously, beauty (or in this case "acceptable") is in the eye of the beholder.

...Jerry

NickHope wrote on 3/11/2011, 1:02 PM

Jerry, that's great info. Thanks!

I'll do a few tests in a similar vein and see if CQ gives enough bitrate consistency for self-hosting. For my taste, 1200 Kbps is a little low for the peacock and 200 Kbps was pushing it a bit for the talking head. So I'll mess around with crf numbers in the 20s.

The MeGUI workflow was giving a lower crf than Handbrake for the same bitrate anyway for 8 Mbps. Might be down to differing x264 versions, or maybe just the superior pre-processing (*wink*).

I thought you were on the golf course anyway.

amendegw wrote on 3/11/2011, 1:12 PM

"I thought you were on the golf course anyway."Ha! The golf course is tomorrow - you know the older I get, the better I used to be. [grin]

My plans this morning were done early, so I got to play with HandBrake renders this afternoon.

...Jerry

1 … 4 5 6 7

of 7