Register  |  Login  |  United States (change)
Forums

Vegas Pro - Video

Forums  |  Search  |  Login  |  Register  |  FAQ
Post New Topic Back to Vegas Pro - Video
Subject: Vegas to Youtube, Vimeo, Web -- A New Look
Posted by: musicvid10
Date: 1/12/2011 10:17:22 AM
 
This thread is intended to lead to a productive discussion. So feel motivated to offer constructive insight, rather than hen-pecking. Thanks!

Those who have been following the many discussions going back a year or so, know that a handful of us have become interested in using Handbrake as an output engine for the web. Finding an acceptable intermediate between Vegas and HB was a roadblock, until Laurence and I discovered that DNxHD in "709 mode" does not throw the colorspace error with x264 that almost every other YUV/YV12 codec we tried does. Note: Sony's mpeg-2 based MXF also works, and Cineform does not.* So, with that in mind, and based on the collective base of knowledge that has grown since, I have made a number of assumptions.

-- That x264 holds up better below 10Mbs than does Mainconcept AVC.
-- That 720p is currently a better upload medium than 1080i, from an upstream postprocessing standpoint, and playability on most consumer systems and connections.
-- That yadif is a more versatile deinterlace method than blend or interpolate, in most situations.
-- That lanczos3 resize is better than bicubic, with or without sharpening, in most situations.
-- That uploaded media must be strictly conformed to 16-235 levels, to prevent clipping at both ends. Includes generated text and media, and FTB levels!
-- That uploaded media should be streaming-ready.
-- That a DNxHD 220Mbs intermediate is probably overkill for 4:2:0 source, and is probably not worth the extra time and file size over 145Mbs.
-- That the time spent encoding the intermediate and again in Handbrake is reasonable, compared to say, 2-pass VBR in Vegas.

So, using material graciously provided by amendegw, stringer, and kimberly for this purpose, and input from laurence, Nick Hope, amendegw, farss, John_Cline, and many others, here is my second draft of sample video to be included in an upcoming tutorial this winter. Note that this footage has been conformed to 709 levels, and minor gamma tweaks have been applied, so it may not look "exactly" like the originals, but I tried to retain the shooters' intentions as closely as possible..

Be sure to view at 720p. The original uploaded mp4 will also be available at Vimeo, and the DNxHD 145 1080i intermediate (2.4GB) will hopefully be on MediaFire in a day or so.

vimeo.com/18690771

Youtube version is good, but no way to get around their splotchiness in FTB/FFB transitions. Be sure to view at 720p.

www.youtube.com/watch?v=4UfUIy5OSZY

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 10:37:59 AM
 
As far as the levels actually being returned by the Youtube Player, this looks pretty encouraging.

dl.dropbox.com/u/20519276/YTGrab.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 10:39:39 AM
 
musicvid,

Very Good! Can you post some screenshots of the settings you used in Handbrake? Particularly interested in the "Video Filter", "Video" & "Advanced" tabs.

If you need a site to host these images, email them to me & I can put them on my site.

Good Work!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 10:48:11 AM
 
Hmmm... I did notice some pixelization in the fade at the end of the stringer clip. Wonder why? All other fades looked fine.

www.jazzythedog.com/testing/images/stringer-pix.png

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 11:11:18 AM
 
That's totally due to Youtube's low minimum vbr and the sensitive flat nature of stringer's source. No way to get around it; it's not present in the uploaded mp4, and a higher bitrate in the upload doesn't fix it. Baaad Youtube!

dl.dropbox.com/u/20519276/stringer.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 11:21:02 AM
 
I love projects like this!!

You didn't say in your original post - I assume you rendered from Vegas to 1920x1080 and let Handbrake do the re-sizing to 1280x720?

Did I duplicate your render template correctly as follows?

www.jazzythedog.com/testing/images/DNxHD-Settings.png

...Jerry

Edit: Whoops, I think the framerate should be 29.97, correct?
Edit2: I've replaced the screenshot with the correct settings - just in case someone wants to use it as a reference.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 11:33:17 AM
 
Yes, my results are much better keeping the intermediate at 1080i, and resizing / decomb in HB.

Yes, that looks like my settings, EXCEPT I had the Vegas framerate at 29.97 (project setting).
Got to go do some work, but I will be around later this evening to post some Handbrake settings, also the levels for your poppies, which were tricky.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 12:26:23 PM
 
OMG, the Vimeo version rocks!
And no blocking in the transitions.
Vimeo-processed mp4 is available for downloading.
vimeo.com/18690771
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 1:53:03 PM
 
The Vimeo version is essentially flawless. Nice job.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 2:13:40 PM
 
"...also the levels for your poppies, which were tricky. "
Ha! I just followed the rules of the assignment - "The footage should be well-lit, not clipped, and contain motion as well as static detail. Tripod is a must. Prefer colorful subject material"

www.jazzythedog.com/testing/images/Flowers-Waveform.png

btw, one thing I noticed after I sent you the clip - my camera is searching for focus at full-zoom. Maybe no one else notices this, but I do. Hope no one attritutes this "glitch" to your test.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 8:05:33 PM
 
Jerry,
I knew I was going to have to tweak levels, but your poppies presented a challenge, although the luminance was within gamut.

dl.dropbox.com/u/20519276/poppies1.png

Youtube would have muddied the saturated reds and blocked up the shadows somewhat unless we brought the chroma into range as well. What I arrived at (after some failed attempts) worked well after upstream postprocessing, especially on Vimeo.

dl.dropbox.com/u/20519276/poppies2.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 8:57:40 PM
 
Man, Stringer's street scene looks familiar... is that Eugene, OR?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 10:09:40 PM
 
This is great - thanks guys for alle the work you have done that we all can benifit of.

/Ulf
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/12/2011 11:56:24 PM
 
A great forum posting! This is very useful for the YouTube crowd! A great example of workflow. Thanks musicvid and all others that worked on this!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 2:32:15 AM
 
musicvid,

I'm a neophyte in the area of color correction (but I want to learn!).

Did you use the Color Curves FX to make your adjustments? I was able to approximate your results using the Glenn Chan "Legal Colors Only" preset.

www.jazzythedog.com/testing/images/Flowers-ColorCurves.png

...Jerry

PS: I hope this is not moving this thread "off topic". If a discussion ensues, I'll start a new thread.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 3:24:50 AM
 
I'm not Musicvid, pardon my interruption.

You've somehow managed to clip the red and green channels, perhaps you somehow overexposed the shot to start with. The curve that you're using is probably not helping either.

Given that most camera today go over 100% by design it's oftenly better to roll the highlights off than to clip them. A curve such as the following may give better results

i192.photobucket.com/albums/z102/RobRoySyd/SCurve.png

Another thing I'm not 100% certain of given that your original footage is probably a bit overexposed is it seems to have too much edge enhancement. If your camera permits dialing down the Detail setting to a negative number might help.

Bob.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 7:13:57 AM
 
@farss: Thanks for the input. I've moved this discussion to a new thread: www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=745934

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 8:13:33 AM
 
Excellent thread musicvid. I'm trying to determine which, if any, or your assumptions apply to the way I shoot. In general, I shoot progressive rather than interlace, and don't usually resize unless downsizing for DVD.

Following are my questions and/or assumptions regarding the points you posted. I'm posting these in an attempt to better understand the applicability of your findings to my workflow. Perhaps there are other Vegas users who also follow a workflow similar to mine.

-- That x264 holds up better below 10Mbs than does Mainconcept AVC.

I have also assumed this and always encode web media and home streaming video using Sony AVC.

-- That 720p is currently a better upload medium than 1080i, from an upstream postprocessing standpoint, and playability on most consumer systems and connections.

I tend to agree. My assumption here is that, all else equal, you can use a lower bit rate on 720p than 1080.

-- That yadif is a more versatile deinterlace method than blend or interpolate, in most situations.

N/A - no interlace here.

-- That lanczos3 resize is better than bicubic, with or without sharpening, in most situations.

N/A - no resizing here.

-- That uploaded media must be strictly conformed to 16-235 levels, to prevent clipping at both ends. Includes generated text and media, and FTB levels!

This surprises me since I thought computer displays could handle 0-255 (or at least 16-255). I would like to learn more about this. What is "FTB levels"?

-- That uploaded media should be streaming-ready.

Why? If you are talking YouTube and Vimeo, don't they add the streaming flag when they transcode? I use SmugMug and they don't stream - the clip downloads then plays.

-- That a DNxHD 220Mbs intermediate is probably overkill for 4:2:0 source, and is probably not worth the extra time and file size over 145Mbs.

Glad to hear that. I am rendering straight from AVCHD - no intermediate.

-- That the time spent encoding the intermediate and again in Handbrake is reasonable, compared to say, 2-pass VBR in Vegas.

It isn't so much the time that bothers me, as the extra manual steps in going to intermediate and Handbrake. So my question is: Do you think the Vegas->Intermediate->Handbrake workflow would yield a significant benefit for the case where there is no deinterlace or resizing required?

Thanks again for sharing your findings on this.

/jerry



Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 8:48:15 AM
 
TeeTime,
Here are my impressions to your questions in order:

1. Holds up better than Sony AVC, too. Also, Sony is CBR, meaning larger files for a given source with or without motion.
2. Yes, 65% lower bitrate, all other things being equal. That figures into the playability piece on many systems and connections.
3, 4. If you are starting with 720p, the biggest advantages offered by Handbrake (resize, decomb) are off the table. I would probably just render in Vegas in this case, to save a couple of steps.
5. Youtube and Vimeo both do an automatic cRGB mapping, whether your footage needs it or not. Thus if you give them 0-255, it will chop them, destroying highlight and shadow detail, and give an unwanted increase in contrast. This is true with all upload formats. Getting wysiwyg from these services is something we've spent a lot of time investigating. See video link at bottom.
6. If you give them non-streaming source, the upload servers must do an extra preliminary pass to find the metadata, taking up more time and resources than is necessary. This has a cumulative effect on overall server response.
7. I am unable to see any difference, either in the intermediate or in the final mp4 output. (I don't have an objective method to determine this).
8. Probably not (see 3. above).

Thanks for the level of inquiry. Although I don't claim to be right on all my assumptions, if it serves to get others thinking about it, we are all bound to benefit.

www.youtube.com/watch?v=aYiUottj96U
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 10:53:51 AM
 
"Can you post some screenshots of the settings you used in Handbrake? Particularly interested in the "Video Filter", "Video" & "Advanced" tabs."

Here's a simple slideshow I put together in Irfanview. Few of the settings are etched in stone, and I invite refinements as we become more experienced with them.

Use the Normal profile as your starting point in Handbrake.

ovationplayers.com/yttut/Thumbnails.html
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 11:15:13 AM
 
Ah! Those are exactly the same settings I've been using - save one. I've found that if I set video encoding to 2-pass VBR, I can get away with ridiculously low bitrates (often < 1Mbps) as long as there is not continously fast motion in the video clip.

...Jerry

PS: Obviously, the audio settings can be varied as well - not much need for very high bitrates if music is not involved.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 11:26:57 AM
 
Yes, I noticed that 2-pass VBR (non-turbo) is better at very low bitrates.
But for Youtube and Vimeo uploads at 6-10 Mbs, Constant Quality is a lot faster render.
I appreciate your work in squeezing the most quality out of very low bitrates. Few of us own the server space to offer huge HD files, thus the move to embedded players for many.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 11:35:07 AM
 
"not much need for very high bitrates if music is not involved. "

What, people actually upload video without music? Pure heresy I say!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/13/2011 12:02:24 PM
 
"What, people actually upload video without music? Pure heresy I say!"
You're absolutely correct! What was I thinking? {grin}

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 8:31:59 AM
 
Message Deleted by User.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 8:52:39 AM
 
Hi,.

What about PAL video?
Should that also be uploaded as 29,97 fps?

It is originally 25 fps.

Original source:
Camera VX2000 (SD)
DV PAL, avi.

Clip size 3-6 minutes.

My current render settings for youtube:

Video: Mainconcept MP4

Profile: Baseline
Video 25 fps (PAL)
Frame size: 720 x 550 Progressive
Option x enabled x: Allow source to adjust frame rate
VBR: maximum (Bps) 6.000.000 - Average (Bps) 4.000.000


Audio: AAC

SR HZ 44.100
Bitrate 320

Does youtube accept this or does it rerender it as 29,97?

Thanks
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 9:18:39 AM
 
The Youtube site has an excellent Help library and many video tutorials that address basic uploading questions . . .
;?)

www.youtube.com/watch?v=QtRVAQd-kGs
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 10:15:06 AM
 
Youtube will always rerender but it usually does not touch the frame rate in cases where it is 24p, 25p, 29,97p or 30p.

Marco
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 12:57:32 PM
 
Thanks for that info!

I have uploaded two identical H.264 AVC/AAC test clips:

640x480 25 fps PAL

720x550 25 fps PAL

Just to see which one gets the '480p' view option.

Recenlty my videos are not getting that '480p' view option, they are all stuck at '360p' or below.

The last video that has got the '480p' option was an uploaded Mpeg-2 CBR 8000 MBPS clip (DVD setting) two months ago.

The others which are still 360P are AVC/AAC MP4 clips.
Maybe that has something to do with that.
It seems that it takes a long time for Youtube to release the 480P version so I do not know how long to wait.

VMP
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 3:06:14 PM
 
Hi v_gts,
Would you perhaps like to start a separate thread for these questions?

I think you will get more responses that way, because your uploading questions might get lost or overlooked in this thread, which is less general and more about DNxHD and Handbrake x264 encoding. We'd be glad to respond to your questions under their own topic, where they will get the attention they deserve.

I can see where my choice of title wording may have seemed like it was a general discussion thread, and I apologize for that.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/14/2011 3:16:39 PM
 
For comparison to the DNxHD / Handbrake version, I uploaded the same project rendered to Mainconcept AVC, 8Mbs VBR (2-pass), 720p, Interpolate, Best, in Vegas 8.0c.

[EDIT] It should be noted that newer versions of Vegas use an updated version of the Mainconcept encoder. Nick has indicated he will upload a similar render using Vegas Pro 10 at some point.

www.youtube.com/watch?v=X9DFEJz7Zb0&feature=mfu_in_order&list=UL

Not "everyone" may agree that the Handbrake version is better, but while comparing both at 720p, one should look for overall sharpness, static detail, motion detail, purity in subtle as well as saturated colors, and the indefinable "pop" factor.

Please understand that differences you see are not due to the codecs alone! Vegas uses blend or interpolate to deinterlace, while Handbrake uses modified yadif. Vegas uses bicubic resize, and Handbrake uses lanczos3.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/15/2011 3:41:40 AM
 
The Sony AVC version's really not so bad, and definitely the way to go for churning out "information" videos as opposed to something you want to look as perfect as possible. Great project Mark, and I'm looking forward to your full tutorial. It's going to get a lot of traffic! I hope to get around to doing more tests and a comparative tutorial for my Frameserver/AVISynth/TDeint/Lanczos/Mergui/x264/YouTube method at some point. Will be interesting to see how it compares. I must admit this colorspace stuff feels like doing A-level maths all over again!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/15/2011 10:41:15 AM
 
Nick, without your input (re PC levels in AVISynth) I never would have started investigating these colorspace issues in depth. So you are already a valuable contributor to this discussion.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/15/2011 10:48:22 AM
 
Here is a new set of Advanced settings in Handbrake that accomplishes a number of things:

-- Gets rid of some garbage that was only there for slight compression reasons
-- ENABLES THE HANDBRAKE FILES TO BE OPENED IN VEGAS
-- Better conforms the 709 levels in the output (b-frame spillover is reduced)
-- "Might" eliminate the frame corruption with HB discussed in another thread

I will add this to the previous tutorial once we are sure it's optimal [done]. Also note that these settings are optimized for quality, not necessarily compression.

dl.dropbox.com/u/20519276/hbytrev1.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 2:26:25 AM
 
Mark, where is the "previous" tutorial you mention? What default values have you changed those red-circled values away from?

FYI, Megui has a lot of templates that the developer works really hard on perfecting as the x264 codec evolves. The current one that I would probably base YouTube uploads on is called "x264: Unrestricted (DXVA) Very High Quality". (Edit: Actually it's from an old version of MeGUI and has been superseded). From what I can tell, that template's comparative settings to the ones you've changed in Handbrake are:

P-frame Weighted Prediction: "Smart" (as opposed to "Disabled" or "Blind")
B-Pyramid: "Disabled"
Deblocking Strength: 0
Deblocking Threshold: 0

The full x264 command line that template invokes is pretty short, so it's not far from x264 defaults. Note that it's quality-based (which I would change to bitrate-based for YT uploads):

Code Block:
program --crf 20.0 --b-pyramid none --trellis 0 --output "output" "input"


(Edit: I later remembered that this command line is only for the first pass of a 2-pass VBR. Up to date settings are further down the thread.)

I can upload screenshots of the x264 settings in this template if it would help.

The last Megui template I used for a YouTube HD upload was based on an older Megui template from a year or two ago (and older x264 codec). It had a little deblocking, along with some other mysterious differences that you can see in the x264 command line that it invokes:

P-frame Weighted Prediction: "Smart"
B-Pyramid: "Disabled"
Deblocking Strength: -1
Deblocking Threshold: -1

Code Block:
program --level 4.1 --pass 2 --bitrate 5000 --stats ".stats" --deblock -1:-1 --b-adapt 2 --b-pyramid none --ref 4 --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh --direct auto --subme 6 --trellis 2 --output "output" "input"


From what I remember, the videos in this playlist were based on this, but they're not very useful as references since I'm fairly sure I would have uploaded levels outside of sRGB in them.

Edit: Adding those useful bookmarks from the other thread in here so I can find them again later (lol can no longer find anything in my own browser bookmarks)...
Tutorial: x264 presets/tunes and HandBrake
X264 Settings
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 5:20:48 PM
 
Nick,
The original link to my HB settings got buried halfway up the thread. Here it is as revised.

Use the Normal profile as your starting point.

ovationplayers.com/yttut/Thumbnails.html

It will take me a while to get through your last post, but I'm sure I'll have some questions. Thanks as always!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 5:29:55 PM
 
Nick,
Two quick observations on your settings. Although p-weighting is supposed to help fades especially, having it "on" garbles lots of decoders, including Vegas, Apple, VLC, and even Youtube occasionally as Jerry found out, especially at higher bitrates. So it is "off" in my latest preset. I like to be able to bring x264 encodes back into Vegas to check levels and frame-by-frame comparisons and play them in VLC.

I agree with the choice to leave b-pyramid out of the soup. What it does is allow b-frames to become reference frames for new b-frames, and I think inbreeding is probably unhealthy even in this context. Removing them stopped some of the chroma spillage in my test renders.

One thing that Handbrake is doing differently than MeGUI is the decomb filter. It's using yadif, McDeint, and EED12 in some rather complicated way. I'm pretty much at a loss to find interlace artifacting with the default setting in 0.9.5

My big takeaway from the last week of tests is that so many of the x264 options are just for the sake of small compression gains, and do nothing for quality, save to compromise it in some cases.

I have run some tests today with the deblocking loop disabled (no-deblock=1 in Handbrake), and I can see no difference, even in near-threshold FTB, but having it off seems to give a slight sharpness increase. Note that every piece of literature written about x264 says turning off deblocking is "not recommended" (0,0 Deblocking is not zero, but the default level).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 8:37:06 PM
 
So the thing that fixed amendegw's garbled frames was turning off 'Weighted P Frames' and 'Pyramidal B Frames' as opposed to a change in the deblocking? (i.e. those values were ON in the previous iteration of your tutorial?) Sorry to be pedantic. Just making sure I understand because I missed the original settings.

Re deblocking, have you noticed any difference between 0,0 and -2,-1?

The Handbrake decomb filter does sound advanced, but I bet it could be more or less approximated in an AVIsynth script. I do like frameserving as opposed to rendering a DNxHD intermediate, so I'll be interested to put Handbrake's decomb filter up against TDeint etc. and see if there are any differences in output.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 9:01:19 PM
 
So the thing that fixed amendegw's garbled frames was turning off 'Weighted P Frames' and 'Pyramidal B Frames' as opposed to a change in the deblocking?
Yes, as well as being able to view in Vegas and VLC on my modest notebook.

Re deblocking, have you noticed any difference between 0,0 and -2,-1?
Yes, -2,-1 (which I kept from an earlier version) is slightly sharper. The higher numbers (3,3) are used for x264 animation preset and CG with solid colors.

The renewed interest in decombing since Donald Graft's work over a decade ago is going to benefit everyone, and the fact that the most progress is being made in open-source projects is encouraging.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 9:17:34 PM
 
Ah, I've just clicked that -2,-1 is LESS deblocking and therefore sharper (duh... what's a couple of little minus signs between friends anyway... need more coffee!)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/16/2011 9:37:08 PM
 
Enjoy your coffee, I'm going to bed now (14 hours behind you).
;?)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/17/2011 2:55:31 AM
 
"So the thing that fixed amendegw's garbled frames was turning off 'Weighted P Frames' and 'Pyramidal B Frames' as opposed to a change in the deblocking? (i.e. those values were ON in the previous iteration of your tutorial?) Sorry to be pedantic. Just making sure I understand because I missed the original settings."
The answer to that question is "yes", those were the only two settings that were changed to fix the garbling (is that a word?).

If it helps at all, here is the MediaInfo data for each render:
Garbled
Fixed

I used WinMerge to compare the settings; here's the changed items:
Garbled: Format settings, ReFrames : 4 frames
Fixed: Format settings, ReFrames : 2 frames

Garbled: Encoding settings : b_pyramid=2 /weightp=2 /keyint_min=30 /
Fixed: Encoding settings : b_pyramid=0 /weightp=0 /keyint_min=29 /

Does this help?
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/17/2011 9:08:33 AM
 
Thanks for documenting this, Jerry. It's valuable information.

"garbling (is that a word?)"
Sure, Jerry. Along with "garbleness" and "garblement."

We seem to be trying to balance quality, compression, and of course playability in different situations. For instance, iPod users will have to dumb down the settings even more. Although my interest is maximizing quality for upstream services, your goal of maximizing compression for site playback will have a different sweet spot, and please post your findings here. The documentation linked above and the presets that come with HB provide some salient starting points for individual situations.

On your settings -- umh rather than hex Motion Estimation might give a theoretical advantage in motion detail without adding much to the render time. I don't know if it's anything one could actually see, as my first uploads were done with hex.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/17/2011 10:22:02 AM
 
"I'll be interested to put Handbrake's decomb filter up against TDeint etc. and see if there are any differences in output. "

A search over at Handbrake indicates their is lots of interest among the developers about using TDeint/TIVTC instead of EED12 (which is by the same author). Perhaps this is going to be part of the much-awaited Decomb3. Will keep an eye on it and let you know.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/20/2011 8:51:35 AM
 
Well, Jerry (amendegw) has done us all proud.

www.jazzythedog.com/testing/dnxhd/getvideo.aspx

He is hosting the DNxHD Intermediate (1.9GB Zipped) used in this project, as well as links to the Vimeo version, his own Low Bit version (which isn't bad!), and my Handbrake settings tutorial.

RE the DNxHD -- it's less than an hour download on my "pretty fast" connection, and I would love to see others' best efforts for comparison, along with your methods and settings. To be fair, make it 720p, and around 8Mbs, plus or minus.

I am especially interested in seeng a MeGUI encode -- got time Nick?

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/20/2011 10:22:29 AM
 
"Well, Jerry (amendegw) has done us all proud."
Thanks, musicvid, but as I mentioned in our personal emails, you did all the creative stuff - my contribution was just to spend a couple hours whipping up a webpage.

That said, I have a question for the group. On this page, I could not embed musicvid's Vimeo video in HD. I Googled the issue and could not readily find a solution. Does anyone know how to embed a Vimeo video in HD?

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/20/2011 4:46:51 PM
 
That said, I have a question for the group. On this page, I could not embed musicvid's Vimeo video in HD. I Googled the issue and could not readily find a solution. Does anyone know how to embed a Vimeo video in HD?

I think embedded HD is only supported for pro Vimeo accounts. Is musicvid's account standard or pro?

/jerry

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/20/2011 5:10:14 PM
 
It's a standard account, and I'm not able to upgrade at this time. However, the original video is available for download, and I have no objection to someone hosting it on their Vimeo "Plus" account.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/20/2011 10:50:05 PM
 
>> I am especially interested in seeng a MeGUI encode -- got time Nick? <<

Nope, but when has that ever stopped me from procrastinating...

Downloading the zip file now. 6 hours to go (I'm in Bangkok). I have no idea if AviSynth will open the DNxHD file. Would be interested in frameserving off the Vegas timeline from the original footage. How did you get all of those clips and how could they be got to me? (I get the feeling I missed a thread where you asked for them... could you link me pls so I know how the project was born).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 2:45:08 AM
 
@Nick Hope:" How did you get all of those clips and how could they be got to me?"
musicvid,

If you could do a "Save Project with Media", zip it up and ftp it to the account I gave you; I'd be happy to put a download link on the webpage. That's gotta be much smaller than the DNxHD render.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 7:56:10 AM
 
Done. About 427MB zipped.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 8:53:34 AM
 
Mark, where's the thread where you were asking for footage for this? I want to see how the project got started and also want to be sure of permission to use the footage before I upload anything.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 9:29:15 AM
 
Nick, here is the first thread.

www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=742876

All of the footage used in the project came from Jerry (amendegw), Stringer, and Kimberly, and please feel free to check with them if you have questions.

Note that my tutorial is still in bits and pieces, and I will hope to have it complete by early spring. As always, your input is valuable and most welcome.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 9:47:44 AM
 
Thanks, I've sent them each an email to check. I'll try and get on it in the next few days, once Jerry's uploaded the bits.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 9:53:55 AM
 
And, if you want to add a HD clip of your own, with own credit of course, feel free to add to the project.
Just set video levels to strict 16-235, including text, overlays, and fades.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 11:47:20 AM
 
Okay, I've included a link on the project webpage to download musicvid's Vegas Project with source clips. Just to repeat the URL, it's here: www.jazzythedog.com/testing/dnxhd/getvideo.aspx

Enjoy!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 4:05:46 PM
 
A little OT:
How do I stop Handbrake from displaying the filename at the start?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 4:12:29 PM
 
Handbrake doesn't do that afaik.
Are you using VLC to play the video?
VLC displays the filename at the start.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 4:14:58 PM
 
"How do I stop Handbrake from displaying the filename at the start?"
Are you sure HandBrake is doing this? Are you playing in VLC as showing the filename is default there.

...Jerry

Edit: Ha! An over-posting. musicvid, you can type 2 minutes faster than I.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/21/2011 5:30:18 PM
 
Brilliant!!
Thanks a bunch guys.
I even found the preset in VLC to turn it off. Yay!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/23/2011 9:34:07 PM
 
Hoping to get to my MeGUI test shortly. I have some stuff to clear first.

Just thinking aloud... Is it worth someone trying a test using Mike Crash's Smart Deinterlace Vegas filter and the x264vfw codec? Presumably YouTube and Vimeo can read the AVI file it creates. Then everything is done within Vegas. Also it looks like there are 64-bit versions of both available for those using Vegas 64-bit.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/23/2011 9:44:31 PM
 
What you suggest would make an interesting test, but the x264vfw codec is not nearly as efficient as its mp4 counterpart (no b-frame support in AVI among other things).

I tested the Crash deinterlace against Handbrake with no resizing on 1080i source, and found Handbrake decomb to be sharper.

But now you've got my curiosity piqued so I'll give it a go this week sometime.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/23/2011 11:41:10 PM
 
Actually I might have made a sweeping statement that YouTube and Vimeo can read such a file. Wouldn't they specifically need the x264vfw codec installed on their server? Might be worth doing a tiny test first to check.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 12:07:32 PM
 
Nice work Laurence and Musicvid.

What is your latest technique for creating SD DVDs from HD camera footage?

Always looking for new suggestions to improve that.

John
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 12:23:53 PM
 
I should live so long as to solve that one . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 1:15:01 PM
 
>> What is your latest technique for creating SD DVDs from HD camera footage? <<

I know you weren't asking me, John, but anyway...

Well, a key aspect of all this H.264 jiggery pokery is the deinterlacing/decombing, which isn't so relevant for DVD.

Personally for SD MPEG-2 I swear by Cinema Craft Encoder Basic for speed and quality and I haven't used anything else for years. I always thought Vegas' MC encoder was poor. Last time I was churning out DVDs (NTSC from 1080-60i) I would frameserve to CCE from the timeline with the following project settings, compress at 8Mbps CBR, and the resulting DVDs looked great:

img.photobucket.com/albums/v290/bubblevision/HDV-DV-1.jpg

However I've since bookmarked Laurence's thread on this subject and will experiment more next time, in particular with the "zero sharpen". John Meyer's workflow is also useful where there's cropping to be done.

Sorry to derail the thread and I will get around to my MeGUI test, I promise.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 1:54:33 PM
 
My experiments with 0 sharpening tell me that it is a worthwhile addition to the process. What I'm still not completely sure about is whether the zero sharpen filter should be pre or post downrez. I thought it looked better pre, but others here recommend post. Either way is an improvement over downrezzing without it.

I can't see any advantage of adding the sharpen to each video event over just adding it to the video tracks. Theoretically adding it to events should keep the sharpening from being added to crossfades which would exaggerate artifacts, but in practice I don't see this happening.

Adding the sharpening filter to text or animated photos doesn't look good so I wouldn't add it to the master video bus.

My observations were originally based upon recommendations from people in this forum, but I always do experiments so that I can see for myself which approach I like best. I really recommend experimentation. Until you see it for yourself, you don't really know for sure what you like. My experimentation tells me that these things make significant differences in the final quality one is able to achieve.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 2:53:33 PM
 
Okay, this "shows to go you" that I have too much time on my hands. I decided to create a webpage that displayed musicvid's test clip in various MediaPlayers: JW Player, FlowPlayer, SilverLight (open MediaPlayer), embedded YouTube & embedded Vimeo. The results are here:

http://www.jazzythedog.com/testing/dnxhd/mediaplayers.aspx

I'm not sure that I can come to any exciting conclusions from this exercise, except that the local players keep up with the download better however the quality is not as great - makes sense because the local video clips are 1/8 the bitrate of the YouTube/Vimeo. Edit: That statement is misleading as the clip was 1/8 the bitrate prior to uploading to YouTube/Vimeo. These hosting services then process these files and reduce the bitrate to their standands. See the discussion a few posts down.

Enjoy!
...Jerry

PS: I'm ignoring the discussion on HD -> SD as we might just re-start the following thread: http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=738210 {grin!}
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 4:42:53 PM
 
So what makes Vimeo HD look so good?
Its processed video is 2Mbs VBR (7Mbs max), High@L3.1, and 4 ref frames (a clue?), 720p. I can't dig out any other information about its p's and b's.

Why no blocking in the transitions at that bitrate? Can this kind of clarity be duplicated in x264 at 2Mbs? If Vimeo can give us quality at this bitrate, from optimized 8Mbs uploads, why can't Youtube? I propose a local shootout against Vimeo.
vimeo.com/18690771
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 4:54:10 PM
 
And the bonus is - Vimeo buffers much better than YouTube. Much less waiting for your player to catch up with the download. What is their secret?

...Jerry

Edit: I'll try a render at 2Mbps and post it on this Webpage. We'll see how it compares to Vimeo.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 5:19:00 PM
 
The answer------- volume(number of users per second downloading). YouTube has massive server farms but the bandwidth becomes a problem as it routed through other network nodes. There are many processes, but in simple terms, large networks do a load balancing across it servers. There are network providers like Comcast that limit overall volume from sites like Youtube based on regionals,etc....
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 5:38:47 PM
 
Okay, I made a 2Mbps render and added it as another JW Player selection. To my old eyes it looks as good as Vimeo.

Try it here: http://www.jazzythedog.com/testing/dnxhd/mediaplayers.aspx

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/25/2011 8:33:20 PM
 
>> makes sense because the local video clips are 1/8 the bitrate of the YouTube/Vimeo. <<
Jerry, the YouTube video isn't really 8Mbps is it? Are you confusing the bitrate of the video you upload with the bitrate of the video that YouTube/Vimeo re-render it to?

Last time I looked, a YouTube 720p download was 2Mbps and a Facebook HD download was 2.5Mbps. I didn't check a Vimeo one. You can dig a YouTube video out of your cache. I find this easier on IE than in Firefox. Delete temporary internet files first, then watch the Youtube file, then go into temporary internet files and sort by file size. The YouTube video should stick out at the top of the list and you can copy and rename it somewhere else.

Incidentally, for inspecting the characteristics of H.264 files you can use AVInaptic. The interface looks like it belongs on a 1994 Sun workstation but it's actually very useful. It gives you more info than Mediainfo etc..

>> And the bonus is - Vimeo buffers much better than YouTube. Much less waiting for your player to catch up with the download. What is their secret? <<

Besides what apit34356 said, I think this also depends where you are and how "close" on host's CDN (content delivery network) to you the file you are downloading is coming from. I'm in Thailand, and if I was a YouTube video with very low views, I often have to wait, I guess because the file hasn't yet been farmed out to the Singapore node. Videos with higher and regular views seem to play faster because the videos have reached all the nodes (p.s. this is uninformed guesswork, so take with a pinch of salt).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/26/2011 2:36:43 AM
 
"Jerry, the YouTube video isn't really 8Mbps is it? Are you confusing the bitrate of the video you upload with the bitrate of the video that YouTube/Vimeo re-render it to?"
Absolutely, correct. It was 8Mbps before upload and YouTube got its mitts on the the clip.

Furthermore, I'm sure apit34356 comments about server workload are also correct.

What was I thinking? I know better than that - this cold weather must be freezing my brain!

...Jerry

PS: The bottom line is that 2Mbps local MediaPlayer clips look and stream "pretty darn good" when compared to both YouTube & Vimeo. At least, here in the eastern USA. Obviously, YMMV and I'm very interested in what others see.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 12:52:18 AM
 
Planning to do my MeGUI test tomorrow. Hopefully up on YouTube and Vimeo within 48 hours.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 7:30:25 AM
 
This is what Vimeo gives us back from HD uploads:

"General
Complete name : C:\Users\.......\[Vimeo-18690771] Vegas Pro -to- DNxHD -to- Handbrake -to- Vi.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 36.5 MiB
Duration : 2mn 21s
Overall bit rate : 2 169 Kbps
Encoded date : UTC 2011-01-11 20:11:09
Tagged date : UTC 2011-01-12 20:11:09

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 20s
Bit rate mode : Variable
Bit rate : 2 010 Kbps
Maximum bit rate : 6 963 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.073
Stream size : 33.8 MiB (93%)
Writing library : Vimeo Encoder
Encoded date : UTC 2011-01-11 20:11:09
Tagged date : UTC 2011-01-11 20:11:09

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2mn 21s
Bit rate mode : Variable
Bit rate : 156 Kbps
Maximum bit rate : 215 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 2.62 MiB (7%)
Encoded date : UTC 2011-01-11 20:11:09
Tagged date : UTC 2011-01-11 20:11:09 "


Based on that pretty limited information, I am trying to match Vimeo playback quality using high profile settings in Handbrake. Goal being to get as good a results at 2Mbs for local delivery. Results are pretty encouraging, but not quite there yet. Will send it up to Jerry's server along with settings when I am satisfied.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 7:51:18 AM
 
Hmmm... My 2Mbps render produced the following from MediaInfo:

Bit rate mode : Variable
Bit rate : 2 000 Kbps

Wonder why it doesn't tell me the max bitrate?

Also, musicvid, we've had some discussion on this before. My testing indicates changing the Deblocking from -2/-1 seems to make very little difference. The only thing that seems to really help the blocking is upping the bitrate.

Good Luck with your testing!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 7:55:53 AM
 
My high profile tests are showing less overall blocking and perhaps more response from the deblock setting, than did our main profile settings used for the 8Mbs version. Still in the beginning stages, more to come. About all I have to go on from Vimeo is

> High@L3.1, 4 ref frames, 2Mbs VBR.

Apparently, they're leaving a lot of information out of the tags for proprietrary reasons. If Youtube was going to figure out what Vimeo is doing with blocking, they would have done it by now. But like I say, I'm getting close.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 8:03:34 AM
 
Jerry, an afterthought:

If you render using CQ, and a finished bitrate around 2Mbs, what does the blocking look like? Better or worse than VBR?

Higher RF = Lower bitrate.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 8:16:04 AM
 
Give me an hour or two to test this. I will have to do trial and error to get CQ/RF to match my VBR bitrate.

In the meantime, did you ever visit my updated MediaPlayer testing page: www.jazzythedog.com/testing/dnxhd/Mediaplayers.aspx ?

I see almost no blocking the the 2Mbps encodes.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 8:35:44 AM
 
Yes, I have your 2Mbs encode and Vimeo's 2Mbs encode as benchmarks.
Using high profile settings at this bitrate as Vimeo's version suggests gives some improvement, but one needs to look for it.

At higher bitrates, high profile settings offer little or no advantage, and result in longer render times, so I left the 8Mbs version at main profile, also for playability reasons.

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 9:31:44 AM
 
Okay, I got a result I did not expect. I did my testing at 1Mbps because I could see almost no blocking at 2Mbps. And it turns out (to my old eyes) there doesn't seem to be a nickel's worth of difference between the VBR & CQ renders. I would have thought the VBR would be far superior. Edit: Turns out this IS expected. I confused CQ with CBR. See the comments a couple of posts down. I'm changing all references to CBR to CQ in this post - to reflect reality.

Because the blocking is most visible in transitions, the following screenprints are rather dark, illustrate the results of the test.

First the 1Mbps VBR:

www.jazzythedog.com/testing/images/Blocking-1MbpsVBR.png
Next the 1Mbps CQ:

www.jazzythedog.com/testing/images/Blocking-1MbpsCBR.png
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 10:11:19 AM
 
That is interesting. Did you also do a test using CQ (which is a form of VBR)?
If not, I can slip one into my tests. If it is at least equal to VBR at low bitrate it would make a much faster render.

Jerry - Quick note on the demo page. The Youtube-processed version is 2Mbs. The upload was 8Mbs.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 10:27:24 AM
 
musicvid,

What a dummy I am!! I've always done my renders using VBR/two pass and targeting a bitrate. When I saw the "CQ" (Constant Quality)setting, my mind registered "CBR" (Constant Bit Rate). My references above to CBR are incorrect. I'll change them after this post.

And now that I understand that we're taking Constant Quality, not Constant Bit Rate, my test results make perfect sense.

Incidentally, after some trial-and-error an RF=32.5 gave a video bitrate of 1035Kbps.

Is this the first sign of Alzheimer's?? {grin}

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 10:29:29 AM
 
No, but we've both definitely got Halfheimers.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 4:37:46 PM
 
So... I've made another render at 1.5Mbps and can only see very, very minimal blocking. I've swapped out the 2Mbps video with this new 1.5Mbps video, here: www.jazzythedog.com/testing/DNxHD/Mediaplayers.aspx

What I'm really interested in is how does this play on for users with lower bandwidth connections. Does the playback start/stop waiting for the download to catch up with the playback?

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/27/2011 8:36:44 PM
 
Jerry.
In my attempt to replicate Vimeo quality for local delivery, I have uploaded my current "best" 2Mbs effort along with advanced Handbrake settings to your server. Note that I used Constant Quality @ RF 28 (YMWV) and High Profile to the best of my ability to emulate Vimeo processing.

As a fellow old fart, I anxiously await your comparison with your own recent work
(and Vimeo's).

;?)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 12:02:39 AM
 
Working on my MeGUI test right now.

Any thoughts on Lanczos4 versus Lanczos3? I'm tempted to try Lanczos4 first, which is supposed to be sharper. But going too high can cause "ringing". Perhaps it is slower too, but I don't know. There is maths that can help you work out which is better depending on the resize ratio but it fried my brain. The AviSynth default is Lanczos3.

Another thing. If you were thinking of trying the Mike Crash smart deinterlacer Vegas plugin as we discussed further up the thread, I remembered that later versions of the standalone smart deinterlacer Virtualdub filter include an edge-directed interpolation option, which is allegedly better. Therefore in theory a better result would be obtained by framserving to Virtualdub and doing the deinterlacing and resizing in there. But if one is doing that then perhaps one may as well just go the MeGUI route. Would be cool if someone updated the Mike Crash plugin to include the latest smart deinterlacer.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 3:25:47 AM
 
"As a fellow old fart, I anxiously await your comparison with your own recent work
(and Vimeo's)."

Okay, I've moved your render up to the demo webpage: www.jazzythedog.com/testing/DNxHD/Mediaplayers.aspx

I've done a comparison and your clip looks very, very good. However, I think we've reached a point where we're trying to count the angels on the head of a pin. My favorite place to look for blocking is at frame 1453 (about 47.5 secs in). Your render looks very slightly better here, but the slight difference could well be because your video bitrate turned out to be 2,118 Kbps vs. my targeted 2,000 Kbps.

So, now that I've said that, let me open another "can of worms". Look at the white car at the 36 sec mark. Both JW Player (for that matter, all the other webpage based players) show a stutter in the motion. To my eyes (please confirm this), the Vimeo clip shows some stutter, but less. When I play the clip, locally on my laptop (WMP), all clips play smooth-as-silk.

I think this is the same issue I raised in the following thread: www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=745366 Unfortunately, no answers (or even replies!)

...Jerry

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 8:10:50 AM
 
The only versions that don't drop frames in high-motion areas on my lowly laptop are your 1Mbs version and the non-HD Vimeo version (600Kbs). I've learned to live with it until I get something a little spiffier. VLC occasionally drops frames on local playback, but it is not repeatable at the same spot.

I think when everything is finally on HTML5 protocol, we may see some improvement in browser based playback (and we may have to redo the tests)
;?O
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 8:34:28 AM
 
Been doing MeGUI stuff today, but before I share any of that I've made some interesting discoveries based mostly on what you guys have already done...

1. Musicvid's original Vegas project
2. you guys' DNxHD intermediate
3. the x264 video I made today in MeGUI
4. you guys' files downloaded from YouTube and Vimeo
5. Jerry's Flash/JW Player 2Mbps file

All the above files return this (more or less):

img825.imageshack.us/img825/1509/waveformvimeorender.png

However .png screengrabs of the video playing in Vimeo or in Jerry's JW Player in Firefox with Flash Player version WIN 10,1,85,3 (1920x1200 Nvidia Quadro FX 1600M) return this (video scopes set to 16-235 Studio RGB, ):

img823.imageshack.us/img823/6201/waveformvimeoscreengrab.png

This leads me to the conclusion that Vimeo is doing nothing to the levels on their servers, but that the 16-235 Studio RGB > 0-255 Computer RGB conversion is taking place in our browsers' Flash player. I don't know if this is default behaviour or if Vimeo are sending instructions to the Flash player to do this. From previous discussion I had assumed that the conversion was happening on YouTube and Vimeo's servers as they re-rendered our file, but that now seems to be an incorrect assumption.

Is this news to anyone, or am I just the last to work it out? (or am I talking codswallop?)

Should have known better than to expect the same result from YouTube... Again the levels are expanded to 0-255 on playback, but a screengrab of the video playing at full screen in Firefox returns a bent-up curve:

img814.imageshack.us/img814/6100/waveformyoutubefullscre.png

However a screengrab of the video playing in YouTube at 480p in IE8 returns a bent-down curve!!!:

img684.imageshack.us/img684/9027/waveformyoutube480piesc.png

So YouTube in conjunction with the Flash Player is messing with the gamma, but it's anyone's guess how or why.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 8:45:47 AM
 
Nick, I noticed a similar situation with downloaded files from Youtube. Gamma was bumped up. All I did was a straight remux so I could open the file in Vegas. I even came up with a preset to correct it locally. Here is a link to the original discussion Bob and I had about this:
www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=742114

dl.dropbox.com/u/20519276/YTCurve.jpg

But a screen grab right off the Youtube Player (fullscreen, 720p) gives me a straight line. So I decided to stick with that because that is what most people do -- view online rather than download.

dl.dropbox.com/u/20519276/YTGrab.png

Your thoughts? I'm definitely going to check this on Vimeo too, and see if it is the upload postprocessing server, the Vimeo Flash Player, or both contributing to the shifts.

"(video scopes set to 16-235 Studio RGB, ):"
I made that mistake also until I researched it. That checkbox is only for mapping MS DV. For all our HD 709 work, both boxes should be unchecked, giving the correct gamut endpoints. I checked this with about 30 YUV codec options, including HDV and AVC (and DNxHD), and they all came back the same.

dl.dropbox.com/u/20519276/scoperight.png
dl.dropbox.com/u/20519276/scopewrong.png

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 10:36:41 AM
 
>> Your thoughts? Your conclusion that it is not the upload server postprocessing but the Flash Players themselves doing the shift makes sense, and is causing me to rethink some previous assumptions I made. <<

My findings in that brief test indicate that the YouTube gamma shift is dependent on the browser model and/or the playback resolution of the file. It was the same 720p file and same Flash Player version in use but the gamma was bumped in opposite directions. Lots of variables involved here: Graphics card model and settings, Browser model and settings, Flash Player version and settings, Resolution of the YouTube file (240p, 360p, 480p, 720p), Playback resolution (360, 480, full screen at various resolutions). More testing required, methinks.

>> I made that mistake also until I researched it. That checkbox is only for badly mapped MS DV. For all our HD 709 work, both boxes should be unchecked, giving the correct gamut endpoints. <<

It seems to me it's more straightforward than that. The results are just scaled differently, so you can work with whichever settings suit your target levels or the workflow you're used to (disclaimer: I'm extremely inexperienced with scopes and have never used anything but a Vegas scope so I approach this with no preconceptions but I might be talking rubbish).

Anyway the conclusions are the same, re the Studio RGB to Computer RGB is happening in the browser and not in YouTube or Vimeo's encoder. Basically, if our target is Flash playback on the web then we have to behave just like we did with broadcast, and keep the levels legal.

.... HOWEVER, I'm thrown by this, that indicates the exact opposite of what I'm saying, since it looks like you've got the downloaded mp4 file in there and not a screengrab. Hmmm...

On another tack, quick question re Handbrake settings... Any particular reason why you've chosen "Uneven Multi-Hexagon" ME method rather than the default hexagon?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 11:05:58 AM
 
Another question, Mark... What version of Vegas did you do your MainConcept AVC encode in, and do you know what version of the MC codec was used?

I've just noticed that there's been a quantum leap in the version since Vegas 8...

Vegas 8.0c:
C:\Program Files\Sony\Vegas Pro 8.0\FileIO Plug-Ins\mcmp4plug\mch264vout.dll
Version 2.0.1889.0, copyright 2006

Vegas 10.0c:
C:\Program Files\Sony\Vegas Pro 10.0\FileIO Plug-Ins\mcmp4plug2\mc_enc_avc.dll
Version 8.5.0.14265, copyright 2010

So I'll add a Vegas 10.0 / Mainconcept AVC encode into my testing, unless you used the exact same version.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 11:24:17 AM
 
"What version of Vegas did you do your MainConcept AVC encode in"
8.0c. A comparison rendered in the newer MC would be most welcome.

"Any particular reason why you've chosen "Uneven Multi-Hexagon" ME method"
I like the motion detail in the peacock's back better with UMH. Purely subjective, and I recently noticed that setting is very slightly "blockier" at low bitrates and takes a bit longer to render. At 2Mbs, UMH with 0,0 Deblock is about the equivalent of HEX at -1,0 Deblock. Entirely a personal choice.

I'll dig deeper into the levels / gamma / player question when I get back home later in the day. I always like having my assumptions questioned.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 12:39:28 PM
 
"I think when everything is finally on HTML5 protocol, we may see some improvement in browser based playback (and we may have to redo the tests)"
Got a Google Chrome Browser? Watch the Peacock, Ducks and Octopus via HTML5 here: www.jazzythedog.com/testing/dnxhd/html5.aspx

It actually looks pretty good.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 12:49:32 PM
 
The MC codec version in Vegas 10 is even newer than the version in the 2010 Russian AVC codec comparison, in which it came 2nd to x264. Quite excited that SCS have finally updated it as I've been wittering on for years about how out of date it has been. Rendering a test file with it right now.

I did some other testing today and made some more interesting observations...

1. YouTube downloaded 720p files are substantially larger file-size than the Vimeo files, with higher bitrates in the video stream. Considering the quality is poorer than Vimeo, I was surprised by this.

YouTube:
Video: VBR, Average 3171 Kbps, High 7876 Kbps
Audio: VBR, 127 Kbps - 182 Kbps.

Vimeo:
Video VBR, Average 2017 Kbps, High 6156 Kbps
Audio VBR, 156 Kbps - 215 Kbps.

2. Believe it or not, YouTube is creating a file with a variable framerate. I remember noticing this in the past. From Mediainfo:

Frame rate mode: Variable
Frame rate: 29.970 fps
Minimum frame rate: 29.412 fps

I have absolutely no idea on how or why they might do this, and what might be gained from doing it. Does anyone know? In addition it makes comparison of files on the timeline difficult because the frames don't line up.

3. Your DNxHD render reduced the volume of the audio. Was that deliberate?

It's unlikely I'm going to get any of my tests online before Sunday. I did some encodes and uploads today but if I published them I think I would cause confusion. I made some small mistakes and I need more time to reduce the variables in order to make some meaningful comparisons. Watch this space.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 1:09:27 PM
 
"Your DNxHD render reduced the volume of the audio. Was that deliberate?"
Nick, are you speaking of the 2Mbps render I made? If so, the clip was speced at 48kHz/96kbps. I reduced the bitrate from the high quality musicvid recommended - just to help with buffering on web playback.

That said, I wouldn't have thought that would have any effect on volume.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 2:48:37 PM
 
"3. Your DNxHD render reduced the volume of the audio. Was that deliberate?"
Volume was reduced to conform loudness to ATSC A/85, which becomes US broadcast law in December 2011. Very similar to EBU R128 except the latter uses more complex gating. I am practicing this on everything I deliver because I am working on launching an outsource audio service to indie commercial producers before the law takes effect.

dl.dropbox.com/u/20519276/lkfs.png
www.nugenaudio.com/visLM_loudness-meter_VST_AU_RTAS.php

2. Variable Frame Rate is another little compression trick they are using to get the most out of non-motion frames or slideshows. Playback is not universally supported. I hate it.

1. How are you downloading the files from Youtube? The best I can get with DownloadHelper is 2Mbs at 720p, although I swear I could get a higher bitrate previously. Are your downloads coming from an Asian server?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 9:43:34 PM
 
>> Nick, are you speaking of the 2Mbps render I made? <<

Jerry, I am speaking of the DNxHD file I downloaded from you and all the other files that appear to have been derived from it.

>> Volume was reduced to conform loudness to ATSC A/85, which becomes US broadcast law in December 2011. Very similar to EBU R128 except the latter uses more complex gating. <<

Very interesting. This is new to me. When I asked about this three years ago, there was no mention of this.

Is that a free meter in your screen grab? Their site is not working at the moment. It looks better than the free Roger Nichols Inspector I currently use to roughly check loudness.

If this is becoming law, my guess (hope?) is that YouTube and Vimeo might also conform our audio to it at some point in the future. After such a time, if it ever comes, it might still not be a bad thing to upload louder audio to give them more dynamic range to work with.

Any chance of a quick tutorial to make the audio in the Vegas project you sent me conform so that we can compare audio as well as video?

>> Variable Frame Rate is another little compression trick they are using to get the most out of non-motion frames or slideshows. Playback is not universally supported. I hate it. <<

Me too! Seems pointless for YouTube, especially when the framerate is only changing by such a tiny amount.

>> How are you downloading the files from Youtube? <<

I am manually retrieving them from my browser cache. I find this easier in IE8 than in FF.

Tools > Internet Options > General tab > Browsing History > Delete > Temporary Internet files > OK > then load the video > Browsing HIstory > Settings > View files > sort by file size > copy and paste the big file at the top of the list and rename it. Note that drag and drop did not work for me. Also note that it's also worth manually emptying and refreshing the "Temporary Internet Files" window before you load the video, to make absolutely sure that old files have gone.

I have had various download helpers installed in the past, but disliked them all for one reason or another.

By the way, the YouTube 720p download from your embedded video at the top of this page comes in at 54.9MB for me.

>> Are your downloads coming from an Asian server? <<

I have no idea. A friend told me that YouTube downloads here in Bangkok come from Singapore but I haven't verified it. I highly doubt that different 720p versions would be existing on the YouTube net.

Anyway, on with the show... Using reports from Avinaptic I have just about finished reverse-engineering a MeGUI profile to match the settings you're using in Handbrake. I'm using hex in both, not multi-hex. Also I'm using Nero AAC in MeGUI because FAAC delivered a much lower bitrate than I selected. After a few more refinements I'm hoping to publish a 4-way test (Sony AVC vs MC AVC vs Handbrake vs MeGUI) on both YouTube and Vimeo.

By the way a VBR Mainconcept render in 10.0c looks very nice, but it was substantially slower than the other methods. I will time all the renders properly in my 4-way test.

One question... Can I just confirm with you guys that it shouldn't make any difference in Vegas 10.0 whether I call for the deinterlacing and resizing in the project properties dialog or in the render settings dialog? I assume not but I just want to double-check.

Also, any opinions on what I should be setting the maximum bps to in MC? I went with 12,000 Kbps in the first test (8,000 Kbps average).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/28/2011 9:53:22 PM
 
Oh, hey, and something else... The Vegas 10 MC render reports " Num ref frames: 5", whereas we're only using 2 in Handbrake, and "Weighted prediction: P slices - explicit weighted prediction", whereas that is off in Handbrake.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 4:46:14 AM
 
Okay, I loaded musicvid's untitled2.veg in Vegas 10c and rendered using the following settings:

www.jazzythedog.com/testing/images/mc-2Mbps-Rendersettings.png
imho, the results were good, but not as good as the Handbrake. Here's a screenprint of my favorite "blocking frame"

www.jazzythedog.com/testing/images/blocking-2mbps-mc.png
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 6:51:20 AM
 
I wonder how many more Mbps you would need to throw at it to bring it up to the same level as Handbrake.

Any idea of how long the render took in comparison to Handbrake? And roughly how long did the DNxHD render for Handbrake take?

10 Mbps seems quite high for the maximum, at 5x more than the average. I wonder how much of that it actually uses. Sadly Mediainfo and Avinaptic don't seem to report that. I think I would have gone for something like 4 Mbps, but that's just gut feel and not based on any theory.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 8:51:43 AM
 
One problem with VBR renders in Mainconcept and Handbrake is that we have no way to specify the Minimum bitrate, and that's where the blocking in trasitions occurs. By placing my faith in the CQ algorithm in Handbrake, I know that MinBR is at least being looked at, and at least partially optimized for quality.

Nick, the Nugen meters are wonderful, and you can download a free trial in exchange for your email (they won't bug you). They have been very generous with resetting the trial period because there is still a bug getting them to work on the 5.1 Master in Vegas. Here's the skinny on the recent standards development; ATSC A/85 is the new US standard, and EBU R128 is the proposed European standard:

Doubt it's going to find its way to internet video services anytime soon. Our FCC in the US has no control over what plays on the internet.
tech.ebu.ch/docs/techreview/trev_2010-Q3_loudness_Camerer.pdf
tech.ebu.ch/docs/r/r128.pdf
www.atsc.org/cms/standards/a_85-2009.pdf

"Any chance of a quick tutorial to make the audio in the Vegas project you sent me conform so that we can compare audio as well as video?"
I think the project file you got has the audio track gain set to -6.5dB. That's the point where the render conforms to A/85 assuming the stereo master is left at 0dB gain.

"I wonder how many more Mbps you would need to throw at it to bring it up to the same level as Handbrake."
At BluRay and AVCHD bitrates, it's very hard to tell them apart.

"Oh, hey, and something else... The Vegas 10 MC render reports " Num ref frames: 5", whereas we're only using 2 in Handbrake, and "Weighted prediction: P slices - explicit weighted prediction", whereas that is off in Handbrake."
Handbrake thinks 2-5 ref frames are "sane levels," with 4 or 5 good for high profie animation, etc. Weightp is off in Handbrake for playability -- don't know if it affects playability using MC. b-pyramid is the next thing to go if there are playability issues (esp. portable devices).

RE the rendering speed issue: In some very old tests of mine, Handbrake was 25% faster at 2-pass VBR using motion source than Mainconcept (Vegas 8.0c). It is so much faster using CQ that it almost negates the time spent rendering the DNxHD intermediate.

Nick, you're a very thorough guy. And this discussion (actually inquiry) is going to benefit immensely from your involvement.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 9:01:24 AM
 
"I wonder how many more Mbps you would need to throw at it to bring it up to the same level as Handbrake."
Okay, I've been testing - the issue is: there are two primary knobs to twiddle in the MC encoder (Avg bitrate & Max bitrate). And there's no good way to quantify the output quality other than to eyeball it. Here's what I did. Kept the Avg bitrate @ 2Mbps and kept bumping up the Max bitrate until I got to 14Mbps. At this setting, I looked at the 47.5 sec mark (where blocking appears most severe) and could see no blocking. In all cases (Max = 4Mbps-14Mbps) I could see no differences in the "normal footage" (i.e. where there were no transitions). So... a MainConcept render at 2Mbps Avg/14Mbps Max seems to be pretty close to HandBrake (via my old eyeballs).

"Any idea of how long the render took in comparison to Handbrake? And roughly how long did the DNxHD render for Handbrake take?"

Here's my render times (all on my Dell Studio 15 laptop; Vegas 10.0c 32 bit).:

Vegas render from "Untitled2.veg" to DNxHD Intermediate: 16:59 min.
Vegas render from "Untitled2.veg" to MC 2 pass 2Mbps: 24:01 min.
Vegas render from the DNxHD.mov to MC 2 pass 2Mbps: 21.08 min.
Handbrake 2 pass VBR, 2Mbps Target: 14:10 min
Handbrake CQ RF:28.5 (1.965Mbps): 7:10 min.

Phew!
...Jerry

Edit: musicvid, Ha! I think we overposted (once again). The good news is I think we said the same thing {grin}
Edit2: "And roughly how long did the DNxHD render for Handbrake take?"" In re-reading this, I think Nick is asking the question, "How long is the render from 'Untitled2.veg' to the DNxHD Intermediate?" I didn't test that, but will and re-post.
Edit3:Render time has been posted above.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 9:10:12 AM
 
It may not seem like much to the John Clines of this world, but this is my first 100-post thread (flame wars from the distant past notwithstanding).
Also 400+ combined views on Vimeo and Youtube, and new subscribers on both channels as a result. Thanks guys, this is fun!

And I probably won't rest well until I see Nick's 8Mbs MeGUI version after it's been uploaded to Vimeo.
Keep the responses coming!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 9:40:00 AM
 
This was a very useful thread, thanks Musicvid and everyone that took part in it! I don't post to youtube because I'm too lazy but this thread would definitely helps in posting a better finish product! I need to show my teenagers this thread and I need to get more "focused" on video.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 12:16:55 PM
 
very useful indeed - thanks to Musicvid, I was able to get DNxHD working in Handbrake.

Quirk: DNxHD files only work in Handbrake if I select a section of the TL and render the loop area to DNxHD. If I render the entire TL, no dice in Handbrake.

And I notice that when I put a rendered DNxHD from the entire TL on MediaInfo, it reports 3:2 aspect ratio, but when I put the loop-area-only rendered DNxHD on MediaInfo, it shows 16:9, as it should.

Obvious lesson for anyone who can't get DNxHD to work in Handbrake: Render a loop area instead of entire TL.

I'm using a newly-installed Win7-64 bits, with only Vegas and a few other programs installed. Vegas is very stable on this installation (as it was on my 3-year-old installation). Last time I ran Memtest overnight I found no errors; very disconcerting to find this quirk . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 12:53:18 PM
 
"Quirk: DNxHD files only work in Handbrake if I select a section of the TL and render the loop area to DNxHD. If I render the entire TL, no dice in Handbrake.

And I notice that when I put a rendered DNxHD from the entire TL on MediaInfo, it reports 3:2 aspect ratio, but when I put the loop-area-only rendered DNxHD on MediaInfo, it shows 16:9, as it should."

Strange, I'm not experiencing this quirk.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 2:53:16 PM
 
"It may not seem like much to the John Clines of this world, but this is my first 100-post thread"

It's not at all surprising that this thread has grown to over 100 posts, it has been very interesting with some excellent research and information.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 4:00:01 PM
 
Thanks for the kind words, John. With your tech brain and blockbusters like the original "Rendertest HDV" thread, I'm indebted.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 4:05:19 PM
 
LReavis,
I don't think that is anything that has been reported. Most of the "quirks" have been due to not configuring DNxHD correctly. Remember, MOV only supports 1.0 PAR and Handbrake only accepts 8-bit, 4:2:0. Handbrake 0.9.5 and Avid LE 2.3.2 are the latest versions.

www.jazzythedog.com/testing/dnxhd/DNxHDSettings.png

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/29/2011 4:40:38 PM
 
"Vegas render from "Untitled2.veg" to DNxHD Intermediate: 16:59 min.
Handbrake CQ RF:28.5 (1.965Mbps): 7:10 min.
Total: 24:09

Vegas render from "Untitled2.veg" to MC 2 pass 2Mbps: 24:01 min."


So my assumption that the total render times, even though they involve an extra step, are about the same. Good to know.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 3:33:54 AM
 
Mark, we should probably discuss loudness stuff outside this thread, but do you know how long the VisLM trial is, and whether is starts at download or installation or first use?

>> I think the project file you got has the audio track gain set to -6.5dB. <<

Ah OK, I missed that, and stupidly normalised it back to 100% in my early Nero AAC renders (which was the default). Fixed that now in my template for future renders.

>> One problem with VBR renders in Mainconcept and Handbrake is that we have no way to specify the Minimum bitrate, and that's where the blocking in trasitions occurs. By placing my faith in the CQ algorithm in Handbrake, I know that MinBR is at least being looked at, and at least partially optimized for quality. <<

For that reason I'm thinking something like a 10-12 Mbps CBR might be the way to go in MC. I've always done CBR uploads to YouTube in the past anyway, and what's wrong with a little longer upload time on quality-critical videos. After all, Vegas 10's default for a 1080p web upload is 16 Mbps! For important videos where I want the absolute best, I can imagine me even using 16 Mbps at 720p, just to make sure.

>> At BluRay and AVCHD bitrates, it's very hard to tell them apart. <<

So perhaps MC 10-12 Mbps CBR might match x264 CQ 20.0 (untested guesswork).

Incidentally in my first unpublished test the CQ 20.0 in MeGUI returns only 7519 Kbps, versus 8768 Kbps in Handbrake., so to truly match the Vegas 8000 Kbps outputs the MeGUI CQ needs to be bumped up (21?) and the Handbrake CQ needs to be dropped (19?).

>> Weightp is off in Handbrake for playability -- don't know if it affects playability using MC <<

For me...
Vegas 8.0c: no errors (but plays very steppily, as expected)
Vegas 10.0c: plays fine
VLC 1.1.5: reported an error but then played fine regardless
GOM (my favourite): plays fine
WMP 11: no video, only audio, even with ffdshow (libavcodec) enabled. But then again the Handbrake and MeGUi files without Weightp don't play either
Quicktime for Windows 7.6.2: Plays OK

Do any of you have these x264 files playing in WMP?

>> Nick, you're a very thorough guy <<

Thanks, but not thorough enough to read that ATSC document! O_O

Jerry, thanks for all that timing info. It will help with the conclusions of this project. It's worth stating here that my interest in this project now is 99% in getting the best YouTube quality, because that's where all my videos are going (because, as a partner, they pay me Edit: but not for the account where I'm uploading you guys' footage to). Whereas your interest seems mostly in optimising quality for self-hosting.

>> And I probably won't rest well until I see Nick's 8Mbs MeGUI version after it's been uploaded to Vimeo. <<

Today, I hope! It's the weekend and my girlfriend is vying with my laptop for my attention lol.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 3:38:17 AM
 
Mark, so you found my "testing" account in Vimeo. Well, if you're interested, that test was with a MeGUI template that gave substantially different x264 settings from Handbrake. And it used Lanczos4. And I accidentally kept the wrong title at the start of the video. So by all means have a quick look at it to judge the deinterlacing, but don't read much more into it than that. I will delete it when I have more controlled tests online.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 3:55:44 AM
 
"Do any of you have these x264 files playing in WMP?"
I have no problems with any x264 / h.264 playback in WMP.

www.jazzythedog.com/testing/images/WMP-Codecs.png
...Jerry

PS: If I may make an editorial comment, "**** the laptop, your girlfriend has priority!!"
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 4:34:09 AM
 
Jerry, where is that WMP output from?

In the meantime I just increased the x264 CQ from 20 to 21(in MeGUI) and it decreased the bitrate from 7.5 Mbps (max 19.9 Mbps) to 6.3 Mbps (max 17.2 Mbps). Weird.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 4:54:38 AM
 
"Jerry, where is that WMP output from?"
Launch WMP, Help->"About Windows Media Player"->"Technical Support Information"

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 7:58:56 AM
 
do you know how long the VisLM trial is, and whether is starts at download or installation or first use?
They've been so generous with the beta trials, I haven't noticed. But now that it's in production, it's worth checking because my trial is bound to check out at some point. Email info@nugenaudio.com . Jon is a nice guy and will reply to your emails.

So perhaps MC 10-12 Mbps CBR might match x264 CQ 20.0 (untested guesswork).
Encoder differences aside, my biggest reason for going to x264 is the resize and decomb superiority for 1080i->720p. The options in Vegas are no match for lanczos and yadif, etc. As I mentioned, if my source is already 720p, I probably wouldn't bother and just render it in Vegas.

The CBR question is an interesting one. Since Youtube and Vimeo are going to process everything VBR anyway, I didn't consider a CBR upload. But it's worth a try. My prediction is it won't have much of an effect on transition blocking at Youtube.

Regarding bitrate, there is a point of diminishing returns. My target upload rate of 8Mbs was just math -- all of the original AVCHD I got is 16Mbs, so figuring the real estate factor between 1080i and 720p, the target bitrate becomes .44 x 16 = ~7Mbs. I upped it to 8Mbs to keep it at more than 50% of the adjusted HDV bitrate; which is considered about right for the comparative efficiency of the AVC codec to MPEG-2. Rendering 10Mbs ABR or CBR may give a "little" more headroom (mainly for HDV), but I don't foresee any advantage from going above that. I know there is some suggestion on the Movie Studio forums for going above 10Mbs at 720p, but frankly I haven't seen the logic. However I am now curious (a major shortcoming) and will try a 10Mbs CBR upload to see if it makes a difference, esp. on Youtube.

Do any of you have these x264 files playing in WMP?
I have an older WMP and rarely use it. No mp4 support.

It's worth stating here that my interest in this project now is 99% in getting the best YouTube quality,
Me too. That is where I started down this path, and is still my main interest. Once we had agreed on a "best quality" workflow, I shifted my attention to Jerry's "best compression" for local playback question, and have learned a lot about h264 high profile settings as a result. Nevertheless, I'm still mainly interested in embedding the YT player rather than hosting files on my ISP account.

In the meantime I just increased the x264 CQ from 20 to 21(in MeGUI) and it decreased the bitrate from 7.5 Mbps (max 19.9 Mbps) to 6.3 Mbps (max 17.2 Mbps). Weird.
Yes, plenty of documentation on why that is, yet it still confuses a lot of Handbrake users. The higher the RF number, the higher the compression is how I look at it.

Today, I hope! It's the weekend and my girlfriend is vying with my laptop for my attention lol.
At my age, my laptop is my girlfriend. Sad but true ;?(
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 8:37:49 AM
 
Yep, I now realise that the CQ values are "in reverse". Rendering one at 19.6 now, which I reckon should be right on the nose at 8Mbps. If I haven't dropped any more clangers and if Vimeo are nice to me it should be live within an hour or two.

I'm still seeking confirmation that the luma expansion is happening in our browsers, and I'm still puzzled by your demo that indicates otherwise. Can you shed any light on this?

Also, Mark, it might be an idea to edit your MC post wayyy above, and also the video description on YT/Vimeo, to add that you rendered in Vegas 8.0c, as there's likely to be a significant difference from 10.0c. If nothing else it will confuse us in years to come when we need to get our heads around this topic again!

Can't work out why my WMP on my laptop won't display H.264. The same version on my other computer will. In any case it seems to me that the "Weighted prediction: P slices - explicit weighted prediction" in the 10.0c MC render does not affect playability. In my experience, Quicktime for Windows is about the fussiest relevant player, and like I say, it's OK in there. This might be an indicator that it's OK to enable weightp in x264 renders.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 8:50:50 AM
 
"Can't work out why my WMP on my laptop won't display H.264"
FFDShow/Haali Media Splitter?

www.afterdawn.com/guides/archive/how_to_play_mp4_files.cfm

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 9:08:08 AM
 
I'm still seeking confirmation that the luma expansion is happening in our browsers, and I'm still puzzled by your demo that indicates otherwise.
Ignoring the gamma question, my downloads from YT and Vimeo all show the expanded levels in the files themselves, regardless of what types of files were uploaded. It should be noted that all my local players, browser or desktop, expand YUV files similarly. I "think" it is a flagging thing with the players, but I haven't devised a test for that yet. One logical conclusion is that the expansion occurs both places, but probably not simultaneously.

This might be an indicator that it's OK to enable weightp in x264 renders.
As Jerry and I were able to confirm in another thread, turning off weightp (in Handbrake anyway) fixes garbled playback in all of our players as well as Youtube and Vegas. Running Vista 32. I suspect more processor power would make a difference, but I want to remain inclusive in playability.

Also, Mark, it might be an idea to edit your MC post wayyy above, and also the video description on YT/Vimeo, to add that you rendered in Vegas 8.0c,
Done.

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 9:44:56 AM
 
>> my downloads from YT and Vimeo all show the expanded levels in the files themselves <<

So what exactly is that file you have in that demo, that represents a YouTube download? If I so much as click on a YouTube downloaded file in the Vegas 8.0c explorer window, it crashes, so assuming you're seeing the same behaviour, then it must be something you've converted the YouTube mp4 to. I would have assumed it's a screen grab still, except for the fact it looks like there's audio under it. My luma comparisons were done in 10.0c, which accepts the downloaded YT files fine.

>> turning off weightp (in Handbrake anyway) fixes garbled playback in all of our players as well as Youtube and Vegas <<

OK! It's staying off!

Vimeo upload is horribly slow this time I'm afraid. 1:37 remaining, plus the rendering wait. After this upload I'll probably also throw up the file I'm sending to them for you to take a look at if you like.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 9:52:39 AM
 
To open YT and Vimeo downloads in Vegas 8.0c, I do a straight-through MP4 remux in AVIDemux first. That does not affect levels or flags (tested it). Here is how Vegas sees the levels from the latest Vimeo download (the 36MB one). Upload was the same 8Mbs 16-235 version done in HB. The file gamma seems to be exactly 1.125 (not very much).

To summarize, the only differences between the downloaded files and fullscreen player grabs are the gamma bumps Bob and I discussed previously, which their native players seem to negate. Level endpoints are the same. I've usually done visual comparisons to known good stills as well. Like everyone else, I don't know why the gamma game exists, but maybe there is some miniscule streaming bandwidth advantage.

dl.dropbox.com/u/20519276/VimLevels.png

If you view one of the downloaded files in Vegas 10.0c with both scope options unchecked, what do you get? Do you get consistency between the Histogram and Waveform? Are you getting exactly the opposite results in 10.0c as in 8.0c? Are we talking about a difference in scoping between 10.0c and 8.0c? If so, let's start another thread and figure out what's going on. For this tutorial I don't think that there is a question about the need to upload 16-235, because the net result always seems to be 0-255, even with Jerry's local player as well as Youtube and Vimeo.

Vimeo upload and processing times have gotten horribly sucky as of late. They want me to upgrade to $10/month or $60/year to "fix" this.

Isn't it about 1 AM where you're at?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 11:07:22 AM
 
Funnily enough I downloaded AVIDemux a couple of weeks ago to make a YouTube video useable in Powerpoint. I did a remux of your file (from http://vimeo.com/18690771) with it and got the same result as you in Vegas 8.0c.

HOWEVER, in Vegas 10.0c, all the downloaded files are giving me this:

img208.imageshack.us/img208/1229/levelsmismatchvegas8and.png

Confused?

Before we blame the scoping, could it be that the older MPEG-4 decoder in Vegas 8.0c is expanding the luma (and changing the gamma?), but the one in in 10.0c isn't?

>> Isn't it about 1 AM where you're at? <<

2am now, and my mind is just about blown.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 11:32:36 AM
 
WOW!

For any confused uploaders at this point, the original advice to upload 16-235 to Youtube, Vimeo, and local JWPlayer is still correct.


However, if this turns out to be a decoder or scopes or player thing rather than a processing thing, I may have a lot of old posts to go back and edit.

I see yet another long thread in our future, and we can only pray for a Glenn Chan visitation . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 12:32:21 PM
 
Nah, it's just that crappy old mp4 decoder in Vegas 8.0. Time to upgrade Mark! ;)

As for confused uploaders, I think they've probably all long since tuned out.

Actually, in all fairness, I'm liking Vegas 10.0 more and more and it's probably worth that discounted upgrade price I paid just as an extra tool for stuff like this and for the elastique audio stretching etc., even if I end up still using 8.0c as my main editor (didn't really push 10.0 yet).

I wonder how it was in Vegas 9.0. It's at times like this that I wish someone from SCS could quickly chime in and say yes, we changed the luma of decoded mp4 files, or otherwise. Oh well...

OK, so here's the link to my "TEST 1" on Vimeo, but they say they ain't gonna start rendering it for another couple of hours:

vimeo.com/19356182

A copy of the file I uploaded to them is available here (but I make take it off in the future). Apparently you can also grab the uploaded file from Vimeo for the first week so please do that if you can and save my bandwidth.

I will post the YouTube version tomorrow. Currently uploading.

Here's the recipe...

Programs Used:

Sony Vegas 10.0c
Debugmode Frameserver 2.7
AviSynth 2.5.8.5
Tdeint 1.1
MeGUI 1911
x264 1867
Nero AAC Encoder 1.5.4

AviSynth Script:

Code Block:
AviSource("d:\fs.avi") ConvertToYV12(matrix="PC.709") TDeint(order=1) LanczosResize(1280,720)


MeGUI settings:

x264 command line:

Code Block:
program --profile main --level 3.1 --crf 19.6 --deblock -2:-1 --keyint 300 --min-keyint 29 --bframes 2 --b-pyramid none --no-weightb --ref 2 --weightp 0 --qpmin 3 --subme 6 --trellis 0 --no-mixed-refs --output "output" "input"


Nero AAC audio, AAC-LC profile, Adaptive Bitrate @ 320 kbit/s

Render time:

34 mins on my core 2 duo T7800 @ 2600 MHz with 4GB RAM

Playback of uploaded file:

Vegas 8.0c: OK (but opens slowly and plays steppily)
Vegas 10.0c: OK
VLC 1.1.5: OK
GOM: OK
WMP 11: no video, only audio, but I think this is unique to my laptop.

Jerry, thanks for the FFDShow/Haali Media Splitter link. For some bizarre reason I have a K-Lite codec pack installed on this computer (yes, I know, I'm a very naughty boy), which includes FFDShow and Haali. I should probably attempt to uninstall first to see if that fixes things. Either that or a full reinstall of Windows, which is overdue.

So, let me know how this looks against the Handbrake version (and please don't hold back regarding criticism of the AviSynth TDeint against the Handbrake Decomb). Perhaps now, with everything else even, I can brave the doom9 forums and look at some other decombers to try in my AviSynth script. But next I'm going to get a Vegas 10 / MainConcept render online. 2-pass VBR with 8 Mbps average. Any thoughts on max bitrate? Since this MeGUI render has gone all the way up to 21 Mbps max, I'm thinking at least 16 Mbps (double the average).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 1:35:12 PM
 
First reaction to your 8Mbs upload version:
Static detail excellent, about the same, motion detail slightly soft (many people prefer this).
Unable to see any interlace artifacts.
Unable to see noticeable transition blocking.
Levels are the same (thankfully).
Playability as good or better than HB encode.

Get some sleep!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 2:01:11 PM
 
Yes dad, but before I go, here's the YouTube version of my "Test 1".

www.youtube.com/watch?v=ot3teAOcd2s?fs=1&hl=en_US&showinfo=0&rel=0

Goodnight!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 2:19:39 PM
 
In the YouTube video (at the 49sec mark), I see the same blocking as seen in musicvid's YouTube (see third post from the top). As explained, by musicvid, this is a YouTube processing problem.

Certainly not seen in Nick's Vimeo video.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 2:44:55 PM
 
I think the slight difference in motion blur is that Nick use HEX Motion Estimation (the x264 default), and I used UMH. Again, all a matter of personal preference. Sharper is not always better. Nice of x264 to publish all the settings in the encode.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 2:54:13 PM
 
As an aside, with the proliferation of this video clip, if my wife ever discovers it, she's going to insist on scale (she's the one feeding the peacock). {grin}

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 2:57:05 PM
 
Heck, I want a cut from the poppy harvest!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 3:25:11 PM
 
Can't sleep. Head full of Mbps...

>> I think the slight difference in motion blur is that Nick use HEX Motion Estimation (the x264 default), and I used UMH. <<

I'll render a Handbrake file with as identical settings as possible to my MeGUI file so we can compare.

>> As an aside, with the proliferation of this video clip, if my wife ever discovers it, she's going to insist on scale (she's the one feeding the peacock). {grin} <<

Facebook comparison version on the way (uploading now). She's going to be famous!

Can you guys suggest a frame or two and possibly a specific portion of the frame to take some standardised screengrabs from the files we are uploading to illustrate the differences in resizing/deinterlacing/decombing etc.? I'm thinking a frame from stringer's highway clip for starters, with a fast moving car and a moving sloping white line.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 3:38:50 PM
 
My favorite place to look for blocking is frame 1453:

content.screencast.com/users/amendegw/folders/Snagit/media/7284cb03-627f-4c50-b874-1399c088999e/01.30.2011-18.35.21.png

This was from a 1Mbps Handbrake render.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 3:59:04 PM
 
"Heck, I want a cut from the poppy harvest!"
In case anyone cares, the poppies were from Longwood Gardens in Chadds Ford, Pa. The peacock calls the Fountain of Youth in St. Augustine, Fl home.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 4:07:39 PM
 
Nick, since you're up, try a quick test for me.
Take the remuxed download and open in Vegas 10. Do the scopes match your un-remuxed download (is that a word)?

I noticed the AVIDemux version, although the levels appear and play exactly the same, did not keep the 709 flag. If that affects both versions of Vegas, it explains our paradox.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 4:25:32 PM
 
Jerry, that frame is perfect for the blocking. We need a similar standard frame for the deinterlacing/decombing, but not a whole frame so that we can see the image at 1:1 here on the forum. Max 750px wide. Mark, where are you looking to judge this stuff?

>> Take the remuxed download and open in Vegas 10. Do the scopes match your un-remuxed download (is that a word)? <<

Sure it's a word, and yes, the scopes match precisely. Um.. struggling with the last bit.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 4:58:33 PM
 
"Jerry, that frame is perfect for the blocking. We need a similar standard frame for the deinterlacing/decombing, but not a whole frame so that we can see the image at 1:1 here on the forum. Max 750px wide. Mark, where are you looking to judge this stuff?"
Wow, that's a tough one. I see no deinterlacing/decombing issues anywhere. However, if I were to look for them I would look for mouseteeth/jaggies in a diagonal line with motion. That said, frame 1735 catches a diagonal blade of grass in the midst of a pan. I cannot see any deinterlacing artifacts - even in my 1Mbps test. Maybe I'll test at a very low bitrate and see what happens - a test for tomorrow (I sleep!).

dl.dropbox.com/u/20447760/01.30.2011-19.48.41.png
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 5:14:47 PM
 
Jerry, at the moment I'm looking for a frame specifically to study Handbrake decomb vs Tdeint vs Vegas interpolate in the versions already created.

For those interested, Facebook upload of the same MeGUI "Test 1" render is here. You need a facebook account to view it. I'll embed a version for non facebook members on my site later. Vimeo version also now live.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 5:43:26 PM
 
Wow, the Facebook render is really nice. Possibly even better than the Vimeo, which still gives hints of that infamous Vimeo stutter.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 5:49:36 PM
 
'Jerry, at the moment I'm looking for a frame specifically to study Handbrake decomb vs Tdeint vs Vegas interpolate in the versions already created."
As I mentioned earlier, I can see no deinterlace issues anywhere. So, I decided to do a test and see if my theory about diagonal images with motion was a good predictor of deinterlace issues. I intentionally tried to create a problem clip by turning deinterlace off, and render at 4Mbps 640x360 using the Sony AVC encoder. I think my theory is correct - note the deinterlace artifacts!

dl.dropbox.com/u/20447760/01.30.2011-20.37.55.png
So... the good news is: frame 1735 (or 1732 in my second test - was my mouse shakey when I placed the clip in the timeline?) is a good predictor of deinterlacing problems.

The bad news is... I can see no deinterlacing artifacts in any of our test clips.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 5:57:12 PM
 
"Wow, the Facebook render is really nice. Possibly even better than the Vimeo, which still gives hints of that infamous Vimeo stutter."
I concur - watch the white car at the 36 sec mark. Not as smooth as playing locally via WMP, but better than YouTube, Vimeo and JW Player.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 6:18:53 PM
 
"The bad news is... I can see no deinterlacing artifacts in any of our test clips."

That's bad news? A year ago I couldn't get away from it.

For the deinterlace shootout, I suggest a separate clip -- 1080i of an acoustic guitar player. Can one of you shoot it?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/30/2011 6:29:10 PM
 
I guess that is kind of an oxymoron isn't it? It's only bad news if you're looking for a frame that contains artifacts and can't find one.

A deinterlace shootout? You are a sadist, arn't you?

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 12:43:46 AM
 
I did a render in Sony AVC in Vegas 10.0c to the "Internet 1280x720-30p" template. The template specifies 8 Mbps bit rate but the render is actually only 5.8 Mbps (16.0 Mbps max). I'll try one at 11 Mbps and see what it delivers. The other interesting thing is that Avinaptic reports "8x8dct: Yes" for the Sony AVC render.

Now here is the YouTube version of my MainConcept AVC render from Sony Vegas 10.0c. I'm calling this "Test 2".

Video: 29.970 fps, 1280x720 Progressive, 2-pass VBR, Ave. 8,000 Kbps, Max. 40,000 Kbps. Best.
Deinterlace Method: Interpolate Fields
Audio: 320 Kbps, 44,100 Hz, 16 Bit, Stereo, AAC
Render time: 52 mins on my core 2 duo T7800 @ 2600 MHz with 4GB RAM

(I decided to raise the max really high and let the MC encoder do whatever it likes around the 8 Mbps average)

A copy of the file I uploaded is here. I can't upload anything to Vimeo until Saturday so if anyone has a Plus account or a clean upload slate, please feel free to upload it there.

If you're using 10.0 then please render your own and save my bandwidth. Thanks!

www.youtube.com/watch?v=Dr-L-hbm1fo?fs=1&hl=en_US&showinfo=0&rel=0
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 5:39:14 AM
 
Nick, I am uploading to Vimeo now. Will edit this message to add the URL when it is done.

Edit:
Looks like this will be it:
www.vimeo.com/19388499

You folks are doing a sensational job of experimentation and testing. Thank you so much.

Fred


Fred
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 7:16:26 AM
 
Thanks a lot Fred! That's very helpful
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 7:49:37 AM
 
"Now here is the YouTube version of my MainConcept AVC render from Sony Vegas 10.0c. I'm calling this "Test 2"."

Your x264 version appears quite a bit sharper, but I see almost no difference in color. I tend to be more suspect of bicubic and interpolate as the culprits, rather than Mainconcept itself at that healthy bitrate.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 10:55:21 AM
 
Apart from Jerry's blocky frame and slopey grass frame, I've been making judgements using the following frame in particular, which shows differences in detail, deinterlacing/decombing (and also a loss of orange in the car's indicator light in x264):

img52.imageshack.us/img52/9346/test1megui.jpg

I was going to post a bunch of stills from different versions but really the only way to judge these is to get them all lined up on the timeline at best/full/unscaled and compare by muting tracks.

Round-Up So Far

I'll be off the forum from tomorrow until next weekend, so, for anyone still awake, here's a round-up of my observations so far. Note that my testing has been all about uploading to 3rd-party video hosts, not rendering finished files for self-hosting. Note also that I tweaked each method to be as near as possible to 8 Mbps video stream and 320 Kbps audio stream in order to make meaningful comparisons.

1. Uploaded videos should conform to Studio RGB, 16-235, because their luma will be expanded to Computer RGB 0-255 on playback.
2. Vegas 10.0c does not expand the luma of an AVC video it decodes, whereas 8.0c does.
3. In Vegas 10.0c, Sony AVC 8 Mbps (as per internet template) is actually only 5.8 Mbps. You need to ask for 11 Mbps to get 8 Mbps. It's fast (14 mins) and actually pretty good. My feeling (based on memory) is it's better than the old version in Vegas 7/8 but I haven't tested them side-by-side.
4. Quality comparisons in files downloaded from YouTube are extremely difficult. The framerate is variable so the frames don't quantize on the timeline. Plus, the quality is just too woolly to make precise judgements.
5. In Vegas 10.0c, MainConcept AVC 2-pass VBR is no better to my eyes than Sony AVC (very possibly worse), and much slower (52 mins). May as well use Sony AVC. From memory, the same applied to Vegas 7/8
6. TDeint/Lanczos3/x264/CQ19.6 done in AviSynth/MeGUI gives more detail and very slightly smoother deinterlacing than the Vegas AVC encoders with "Interpolate Fields" deinterlacing. Medium render speed (34 mins). Worth using ahead of Sony AVC for better quality if you have the time and patience.
7. Decomb/Lanczos3/x264/CQ20.5 done in Handbrake gives similar detail to the MeGUI method and very slightly smoother deinterlacing/decombing again. Render is pretty fast (14 mins) but the preceding DNxHD render would likely be around 30 mins on my machine, so the total workflow is relatively slow. Probably just has the edge over MeGUI for quality-critical material.
8. "Uneven Multi-Hexagon" motion estimation in Handbrake is little different from "Hexagon" and not really sharper. I did a like-for-like test.
9. Facebook gives marginally my favourite quality, but can only be embedded at low res, and without a facebook account, that's all you can watch. Good for private videos.
10. Vimeo gives the next nicest quality (it's close) and in my experience, fast download, but slight stuttering for some viewers.
11. YouTube gives poorest quality. Every YouTube version so far is horribly blocky in transitions. It seems there's no avoiding this.

Copies of my UPloaded files (available for a while):

Test 1 (MeGUI TDeint x264) - https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test1-MeGUI-TDeint-CQ196.mp4
Test 2 (Vegas 10 MainConcept AVC) - https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test2-MC-8-40Mbps.mp4
Test 3 (Vegas 10 Sony AVC) - https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test3-SonyAVC-11Mbps-DELIVERS-8Mbps.mp4
Test 4 (Handbrake x264) - https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test4-Handbrake-CQ205-Hex.mp4

Comparison spreadsheet of the uploaded files (info from Mediainfo and AviNaptic).

Online (lots of details about the render method in the online video descriptions):

Test 1 (MeGUI TDeint x264):
Facebook - www.facebook.com/video/video.php?v=497394492745
Vimeo - vimeo.com/19356182
YouTube - http://www.youtube.com/watch?v=ot3teAOcd2s&hd=1

Test 2 (Vegas 10 MainConcept AVC):
Vimeo - vimeo.com/19388499
YouTube - http://www.youtube.com/watch?v=Dr-L-hbm1fo&hd=1

Test 3 (Vegas 10 Sony AVC):
Vimeo - vimeo.com/19411685
YouTube - http://www.youtube.com/watch?v=8jzhF3E8Ij4&hd=1

Test 4 (Handbrake x264):
Vimeo - vimeo.com/19413015
YouTube - http://www.youtube.com/watch?v=3_lGIJxHAsU&hd=1

Still to do:

1. Get tests 3 and 4 up on Vimeo.
2. Try Vegas/Framserver/VirtualDub/Smart Deinterlace (edge-directed interpolate)/Lanczos3/x264VFW.
3. See if CBR can help the blockiness in YouTube transitions (but only MC seems to have a CBR option).
4. Maybe try the Mike Crash smart deinterlacer inside Vegas with Sony AVC.
5. Maybe try Lanczos4 instead of Lanczos3 in AviSynth script.
6. Maybe experiment with x264 deblocking values.
7. Attempt to match Handbrake's decomb in an AviSynth script for MeGUI (Tough! Mr Meyer Sir, are you around?).
8. Publish my MeGUI tutorial.

OK, I need a break now.

By the way, the guitar player deinterlace shootout is a great idea! But we need to squeeze my underwater CC challenge in somewhere too!

p.s. I suggest no more linked YouTube vids in this thread, to keep it usable. I may go back and unlink mine.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 3:08:39 PM
 
Nick, I will post tests 3 and 4 to Vimeo tonight. Thanks again for what you are doing.

I will edit this post to give the Vimeo URLs.

Edit:

Vimeo Render test 3:
vimeo.com/19411685

Vimeo Render test 4:
vimeo.com/19413015

Fred
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 1/31/2011 7:13:58 PM
 
Thanks again Fred. I edited my post to add those links.

Anyone agree, disagree, or add to my observations? I don't have the best monitoring situation here at the moment, so my judgements might not be as clear as others'.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/1/2011 4:41:51 AM
 
"Anyone agree, disagree, or add to my observations? I don't have the best monitoring situation here at the moment, so my judgements might not be as clear as others'."
Nick, first let me compliment you on the excellent job of analysis you've done on this project (worthy of comparison to a JohnMeyer analysis!!).

Now, to answer your question. You make the following statement: "5. In Vegas 10.0c, MainConcept AVC 2-pass VBR is no better to my eyes than Sony AVC (very possibly worse), and much slower (52 mins)." I'm sure this is a true statement at the high bitrates you've used when rendering, however, my tests indicate that the MainConcept encoder wins hands-down at low bitrates. Here's a screencapture.

www.jazzythedog.com/testing/images/Peacock-MC-vs-Sony.jpg

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/1/2011 8:39:43 AM
 
Nick, Let me be the second to congratulate you on a scholarly look at this. You have taken the discussion to the next level, and those who care to dig below the surface will benefit immensely.

8. "Uneven Multi-Hexagon" motion estimation in Handbrake is little different from "Hexagon" and not really sharper.

Having used my original 8Mbs Handbrake settings, the differences in motion detail (not static detail) are noticeable to me, moreso during actual playback. As I mentioned a couple of times, sharper is not necessarily better, and some people prefer the smoother motion that hex ME offers. Personally, I prefer the sharper motion detail that umh offers, at least for web delivery. Look at the grass in the upper corners, as well as the bird's back.
NOTE: Although both are the same frame, the bird on the right actually appears "fatter" because of greater lateral motion blur.

1:1, no sharpen added. Right-click and "View Image"
dl.dropbox.com/u/20519276/umh-hex.png

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/1/2011 9:57:14 AM
 
Somebody straighten me out! Two posts above I compared the MainConcept and Sony AVC encoders at 1Mbps. I made an assumption with the Sony AVC encoder: since I was not able to specify VBR and I was able to specify a single bitrate, that my render would a Constant bitrate (CBR). However, the following is what MediaInfo reports:

Video
ID : 2
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=15
Muxing mode : Container profile=Baseline@3.1
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 21s
Bit rate mode : Variable
Bit rate : 866 Kbps
Maximum bit rate : 16.0 Mbps

Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.031
Stream size : 14.6 MiB (87%)
Language : English
Encoded date : UTC 2011-02-01 11:16:07
Tagged date : UTC 2011-02-01 11:16:07


"What gives with the variable bitrate?"

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/1/2011 10:02:41 AM
 
"7. Decomb/Lanczos3/x264/CQ20.5 done in Handbrake gives similar detail to the MeGUI method and very slightly smoother deinterlacing/decombing again. Probably just has the edge over MeGUI for quality-critical material."

That -- is a remarkable statement.

The Handbrake devs are going to post their preset numbers for 0.9.5 in the wiki soon; I will be sure to post them here. They use three different deinterlace methods (mod yadif, EED12, and McDeint) in combination and in a specific order, but not TDeint yet.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/1/2011 6:30:16 PM
 
Just a note to those who may tend to interchange the terms "luma" and "luminance".

Luma is gamma weighted. Luminance is not.
Vegas reports Luminance in its scopes because it converts everything to linear RGB.
That's the best of my understanding at this time.
Still waiting for a Glenn Chan visitation . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/2/2011 8:30:58 AM
 
FWIW, here is the current Handbrake default decomb parameter string.
If you click "Custom" a box comes up where you can input your own number string.
But you'd best know what you're doing first (I don't).

Code Block:
-5, --decomb Selectively deinterlaces when it detects combing <MO:ME:MT:ST:BT:BX:BY:MG:VA:LA:DI:ER:NO:MD:PP:FD> (default: 7:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1)

Code Block:
12 /***** 13 Parameters: 14 Mode : Spatial metric : Motion thresh : Spatial thresh : Block thresh : 15 Block width : Block height 16 17 Appended for EEDI2: 18 Magnitude thresh : Variance thresh : Laplacian thresh : Dilation thresh : 19 Erosion thresh : Noise thresh : Max search distance : Post-processing 20 21 Plus: 22 Parity 23 24 Defaults: 25 7:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1 26 *****/ 27 28 #define MODE_YADIF 1 // Use yadif 29 #define MODE_BLEND 2 // Use blending interpolation 30 #define MODE_CUBIC 4 // Use cubic interpolation 31 #define MODE_EEDI2 8 // Use EEDI2 interpolation 32 #define MODE_MCDEINT 16 // Post-process with mcdeint 33 #define MODE_MASK 32 // Output combing masks instead of pictures 34 35 /***** 36 These modes can be layered. For example, Yadif (1) + EEDI2 (8) = 9, 37 which will feed EEDI2 interpolations to yadif. 38 39 ** Working combos: 40 1: Just yadif 41 2: Just blend 42 3: Switch between yadif and blend 43 4: Just cubic interpolate 44 5: Cubic->yadif 45 6: Switch between cubic and blend 46 7: Switch between cubic->yadif and blend 47 8: Just EEDI2 interpolate 48 9: EEDI2->yadif 49 10: Switch between EEDI2 and blend 50 11: Switch between EEDI2->yadif and blend 51 17: Yadif->mcdeint 52 18: Blend->mcdeint 53 19: Switch between blending and yadif -> mcdeint 54 20: Cubic->mdeint 55 21: Cubic->yadif->mcdeint 56 22: Cubic or blend -> mcdeint 57 23: Cubic->yadif or blend -> mcdeint 58 24: EEDI2->mcdeint 59 25: EEDI2->yadif->mcdeint 60 ...okay I'm getting bored now listing all these different modes 61 32: Passes through the combing mask for every combed frame (white for combed pixels, otherwise black) 62 33+: Overlay the combing mask for every combed frame on top of the filtered output (white for combed pixels) 63 64 12-15: EEDI2 will override cubic interpolation 65 16: DOES NOT WORK BY ITSELF-- mcdeint needs to be fed by another deinterlacer 66 *****/
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/9/2011 3:45:24 AM
 
Guys, I'm totally snowed under with other stuff at the moment. Will try and get back on this topic in a few days when things calm down. Cheers
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/9/2011 8:33:34 AM
 
Snowed under in Thailand?

Here is the view from my front door this morning. Car hasn't started in two days.
dl.dropbox.com/u/20519276/snow.jpg

Will look forward to your return to the forum.
;?)

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/11/2011 2:33:09 AM
 
Hi all,
Source footage : 1440 x 1080, 50i, 25 mbps
I want to prepare some them for my future website!

Which one to chose??
mp4, 720p
mp4, 1920 x 1080, 25p
mpeg2, 1440 x 1080 but low bitrate??
maybe divx?

or any other advice please:)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/11/2011 4:14:19 AM
 
"or any other advice please"
First, if the following response results in several questions, I would suggest creating a new thread (as much as I'd like to see the post count get to 200!!).

That said, the first thing I'd suggest is to (eventually) get your from interlaced to progressive for web broadcast. As a general rule, I'd try to keep the framerate the same as your source (25fps?).

That said, there several questions you should ask your self. Want to take the easy way out? Upload the video to YouTube or Vimeo or ?? and embed the video in your website. Seems like consensus is that Vimeo produces better quality. Suggest you go to their websites for recommended render params.

If you want to host your own videos, then you should ask yourself some further questions. What is the framesize you will display your video? Will users want to view the clips in high quality fullscreen? What about the bandwidth of your user community?

Once you've answered those questions, I've found that rendering your Vegas Project to an interlaced format with same rez as the source, then downrezing & deinterlacing (while retaining the framerate) using HandBrake does a great job of minimizing filesize while retaining quality. You'll want to trial-and-error the bitrate/CQ depending upon how you answer the questions above.

Just my experience and my humble opinion,
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/11/2011 6:06:27 AM
 
I've started using a paid-for video streaming service called "Bits On The Run" that is run by the developers of the JW Player. I upload MP4's created using Handbrake. BOTR will re-encode the video into multiple resolutions that will be offered up based on the viewer browser limitations. But, they also offer the option of just streaming the original video file as uploaded, with no additional encoding.

The only thing that became evident, if streaming the original MP4, is that by default the original MP4 produced by Handbrake isn't optimized for web streaming in that the frame index (moov atom) is at the end of the file, so that the entire file has to download before it starts to play. Just check the "web optimized" option and you should be good to go.

If you have an MP4 file that has already been encoded, but has the index at the end of the file, you can use a free AIR application called "QTIndexSwapper 2" to move the index to the beginning of the MP4.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/11/2011 8:30:07 AM
 
Thanks for the heads up, will be checking out that service in coming weeks.

RE: The "web-optimized" checkbox in Handbrake: That is highlighted in the original tutorial we put up a while back.
A look at those settings may offer other useful hints as well.
www.jazzythedog.com/testing/dnxhd/getvideo.aspx

dl.dropbox.com/u/20519276/webopt.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/11/2011 9:14:25 AM
 
@Ogul,
The first post in this thread shares my thoughts about your questions.
If you are going to host the video on your own server space, follow Vimeo and Youtube's lead and encode at 2Mbs.
Jerry has had success all the way down to 1Mbs.
Settings for my compression-optimized 2Mbs 720p version are below (at CQ RF 28, but yours will vary).
Very closely matches Vimeo quality.

dl.dropbox.com/u/20519276/HB2Mbs.png

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/12/2011 7:59:58 PM
 
Hey guys,
A clarification question regarding the Handbrake settings. From the screenshots, it says that an 8MBps is optimal. Is this the bitrate or the final size? If it's the bitrate, shouldn't I just use the Avg Bitrate to 8000 Kbps?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/12/2011 8:04:38 PM
 
Clarification:

8Mbs (average) bitrate is optimal for 1080i AVCHD or HDV source rendered to 720p for Vimeo or Youtube. It's just math.

Constant Quality RF was designed to give you the same quality in about half the time.
The disadvantage is that the final average bitrate cannot be calculated, only approximated.

Using 8Mbs 2-pass VBR to render is just fine if the considerable extra time spent rendering it is of no issue to you . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/12/2011 8:55:46 PM
 
Thanks for your prompt response. So, if I render at CRF: 20 and end up with a file that's 12Mbs bitrate, should I decrease the CRF until it's closer to 8? I'm reading that you're recommending 8 Mbs as the best size/performance ratio for 720P.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/12/2011 9:01:02 PM
 
No, this is where it is confusing (at first)..
Increasing the RF increases the compression.
So you would raise the RF (maybe to 22) in order to lower the bitrate.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 3:58:57 AM
 
Apologies for my absence.

>> Personally, I prefer the sharper motion detail that umh offers, at least for web delivery. Look at the grass in the upper corners, as well as the bird's back. <<

Personally I'm really struggling to see the difference Mark, even on a playing timeline, but that may well be my eyesight. I'll bear this hex vs umh consideration in mind for my final tutorials. Sticking with hex for now to keep as many variables equal as possible.

>> "What gives with the variable bitrate?" <<

This doesn't surprise me. I actually assumed Sony AVC would be doing a CRF/ABR/one-pass-VBR as opposed to a CBR. I suspect the max bitrate of 16.0 Mbps may be just a ceiling that they've put on the bitrate, rather than a bitrate that is actually reached in the encode. My 11 Mbps render also showed a 16.0 Mbps max bitrate. 866 Kbps isn't so far off the bitrate of your MC render and would indicate that MC is the better choice of the pair for low bitrate self-hosted videos.

>> That -- is a remarkable statement. <<

Meaning that you do or don't agree with it? If you are saying that you are surprised that my TDeint method didn't match the Handbrake decomb, well, I only used it in its most simplest way, whereas the HB decomb seems to be combining more than one filter. I'm about to try combining TDeint with NNEDI. Maybe that will be better.

>> Luma is gamma weighted. Luminance is not. <<

So I should be using "luminance", rather than "luma", as in "luminance will be expanded to Computer RGB 0-255", right?

>> FWIW, here is the current Handbrake default decomb parameter string. <<

I guess this info might give us a sporting chance of replicating the Handbrake default decombing in an AviSynth script. Sounds HEAVY or even impossible but I'll add it to the things-to-do list!

>> Here is the view from my front door this morning. <<

Very pretty!

>> I've started using a paid-for video streaming service called "Bits On The Run" that is run by the developers of the JW Player. <<

jdw, you're not actually Jeroen Wijering of JWPlayer fame, are you? Well, if anyone can link us to an HD file that has been rendered by BOTR I would be very interested to compare the settings they've used with what the other services are doing.

OK, so on with the show...

TEST 5

I managed to (I think) replicate our Handbrake/MeGUI x264 8 Mbps upload settings in x264vfw. I like the VirtualDub workflow so I wanted to see if we could do as well or perhaps even better for quality/bitrate than the Handbrake/MeGUI workflow.

Rendered (uploaded) file at https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test5-VirtualDub-CQ191.avi
Vimeo version at vimeo.com/20011719
YouTube version at http://www.youtube.com/watch?v=8noI9WIkawk

Programs Used:

Sony Vegas 10.0c
Debugmode Frameserver 2.7
VirtualDub 1.9.11
Smart Deinterlacer Filter 2.8 beta 1
x264vfw 112r1867bm
Lame ACM mp3 encoder 3.98.4

Smart Deinterlacer Settings:

Detailed help for the filter is available in the Smart.html file that comes with the zip download. I went with these settings (and would welcome suggestions for improvement!):

img46.imageshack.us/img46/9532/smartdeinterlace.png

I did a Lanczos3 resize to 720p in VirtualDub.

x264 settings:

img687.imageshack.us/img687/6634/x264vfwconfiguration.png

AviNaptic is still reporting "8x8dct: Yes", despite me specifically disabling it. I'm not sure if it's telling the truth since Mediainfo is reporting 8x8dct=0.

I couldn't find an AAC encoder for VirtualDub so I used Lame MP3 @ 320 kbit/s CBR.

Render time:

29 mins on my core 2 duo T7800 @ 2600 MHz with 4GB RAM

Playback of uploaded file:

Vegas 8.0c: No errors but plays very steppily
Vegas 10.0c: No errors but it really struggles. It opens extremely slowly and plays very steppily (even with the aviplug.dll hack, which I have reversed as it seems to have become redundant in 10.0b)
VLC 1.1.5: Plays fine
WMP 11: Plays fine
GOM Player: Plays fine

What do you guys think? It's difficult to compare still frames with the other tests because objects won't line up on the timeline because the smart deinterlacer is keeping the bottom field whereas the other methods kept the bottom field. Also we're not doing ourselves any favours here by attempting to assess deinterlacing, resizing, and compression all at the same time. We should really judge the deinterlacing on a 1080p file with no temporal compression. Anyway I think this is a valid contender, the workflow is pretty nice and the rendering time is not too bad.

I updated my comparison spreadsheet of H.264 files, adding in the new x264vfw render and also adding in the files I downloaded from YouTube, Vimeo and Facebook. For anyone optimising x264 for self-hosting, the Facebook settings are well worth a look at. They are using x264 and the parameters are all available in Mediainfo, although their x264 version is old now and some parameters are different. They obviously need to be highly compatible with various available Flash platforms, so there might be something to be learnt. Incidentally, here's an oldish interview with Chris Putnam who set up their encoding.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 5:09:47 AM
 
">> I've started using a paid-for video streaming service called "Bits On The Run" that is run by the developers of the JW Player. <<

jdw, you're not actually Jeroen Wijering of JWPlayer fame, are you? Well, if anyone can link us to an HD file that has been rendered by BOTR I would be very interested to compare the settings they've used with what the other services are doing."

fwiw, I've cobbled together a webpage that compares various versions or musicvid's clip and various MediaPlayers click HERE I'd love to include a "Bits on the Run"/JW Player version here if someone can give me the URL of a BOTR version.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 7:45:09 AM
 
Nick,
I am quite impressed with your x264vfw version. I would have said "no b-frames means less compression efficiency," but at first glance I don't see a lot of difference.

"If you are saying that you are surprised that my TDeint method didn't match the Handbrake decomb,"
I was surprised that you didn't think it was as good. After looking closely, I tend to agree with you. Since TDeint is from the same author as EED12, mod yadif, etc., I assumed it was better. But maybe it's just more efficient under the hood.

As far as the hex/umh debate, I am splitting hairs; I only see a very slight difference in horizontal motion detail, and one might easily prefer either over the other. Hard to make a quantifiable case for either method, esp. at 8Mbs.

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 9:35:29 AM
 
Message Deleted by User.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 9:37:43 AM
 
>> I would have said "no b-frames means less compression efficiency," but at first glance I don't see a lot of difference. <<

Not quite with you here Mark. All of these x264 tests are using 2 b-frames.

>> Since TDeint is from the same author as EED12, mod yadif, etc., I assumed it was better. <<

Yes but in that test I only used TDeint on its own. From what I can make out, Handbrake's current decomb default is mode 5, which is to do a cubic interpolate and then process the output of that with yadif. In other words more sophisticated than just yadif or TDeint on its own. And it seems one can get more sophisticated by using mode 9, which does an EDI2 followed by yadif. I read somewhere today on the Handbrake forum the developer saying that, if rendering speed is not of great concern, mode 11 could be the best all-round choice, i.e. Switch between EEDI2->yadif and blend.

If any of that is wrong or out of date, please tell me, as you're more up to date with the Handbrake development than me.

I've now got an AviSynth script working that processes with NNEDI3 and TDeint. It seems like the Handbrake devs want to port NNEDI, which is apparently superior to EEDI2 but can't because it's closed source. I ran a few seconds through it and the result was awesome. I'll do the whole video and upload TEST 6 tomorrow.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 9:40:52 AM
 
AVI wrapper does not accept b-frames at all afaik. We are both talking about x264vfw?
Please correct if I'm mistaken.

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 10:11:17 AM
 
I think they must have implemented this hack (found via here) to make it work.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 11:01:38 AM
 
I sent YouTube a 10-second MainConcept CBR file at an OTT bitrate of 20 Mbps, spanning the transition, to see if it might improve the blockiness (which just might have been caused in other renders by a relatively low bitrate through the transition). Sadly not, but no surprises.

http://www.youtube.com/watch?v=dkZ2Fo7C9Bs

Edit: Oops, I had the level 16 "black" underlay track muted when I rendered that, so the transition is a little darker than the others, but that shouldn't make any difference to the blockiness.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/16/2011 12:27:31 PM
 
Well, that pretty much answers that question. Bottom line: Youtube pretty much sucks when it comes to fades.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 5:02:40 AM
 
TEST 6

With a lot of help from tritical I think I may have beaten Handbrake. Well, maybe :)

Rendered (uploaded) file at https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test6-MeGUI-NNEDI3-TDeint-Lanczos3-CQ197.mp4
YouTube version at http://www.youtube.com/watch?v=04DtypC1Wp8
Vimeo version vimeo.com/20059771

Programs Used:

Sony Vegas 10.0c
Debugmode Frameserver 2.7
AviSynth 2.5.8.5
NNEDI3 0.9.2
Tdeint 1.1
MeGUI 1911
x264 1867
Nero AAC Encoder 1.5.4

AviSynth Script

Code Block:
AviSource("d:\fs.avi") ConvertToYV12(matrix="PC.709") AssumeTFF interp = nnedi3() TDeint(order=1,edeint=interp) LanczosResize(1280,720)


x264 Command Line

Code Block:
program --profile main --level 3.1 --crf 19.7 --deblock -2:-1 --keyint 300 --min-keyint 29 --bframes 2 --b-pyramid none --no-weightb --ref 2 --weightp 0 --qpmin 3 --subme 6 --trellis 0 --no-mixed-refs --output "output" "input"


Video bitrate: 7987 Kbps
Render time: 44 mins

This 2-stage deinterlacing method does better at smoothing out jaggies than the Handbrake default decomb, and doesn't seem to be particularly inferior in any other way. Look at this frame:

img638.imageshack.us/img638/492/test4handbrake.jpg
img268.imageshack.us/img268/368/test6megui.jpg

Still looks crap on YouTube (although it's badness is probably now exaggerrated in my brain because of looking at so many better versions). Of slight concern is that YouTube's encoder has a brainfart with the MeGUI version for 2 seconds for no apparent reason from this frame until the end of the transition. A red herring, I hope. Will be interesting to check if Vimeo hiccups there too:

img217.imageshack.us/img217/8115/test6downloadedyoutube.jpg

What do you think? Is this a winner? Other thoughts?

I went further and tried umh and Lanczos4 instead of hex and Lanczos3. umh costs an extra 5% encoding time over hex. Lanczos4 costs an extra 13% encoding time over Lanczos3. In both cases I really struggled to see a benefit. Parts of the frame were just slightly different but not necessarily sharper or "better". IMO not really worth the extra render time. I've read that Lanczos4 is better for upsizing, but might slightly over-sharpen when downsizing and introduce compression artefacts later.

Before writing my tutorial and putting this to bed, I'm wondering about a final (I hope) test to try Handbrake in mode 9 or mode 11 (assuming these are not now the default instead of mode 5). Does anyone know exactly how to do that (before I spend time finding out)?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 5:28:20 AM
 
Vimeo Link

YT-Vimeo-Nick-Test6-MeGUI-NNEDI3-TDeint-Lanczos3-CQ197.mp4

http://vimeo.com/20059771
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 5:38:24 AM
 
Hmm... the x264vfw render (test 5) also fell apart on YouTube at exactly the same frame, but none of the others (test 1-4) did. Strange.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 7:35:53 AM
 
Thanks Fred! I've edited my post with your Vimeo link.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 8:23:16 AM
 
Nick, I'm impressed that you know tritical. Truly a legend among editors and content producers.
I'm even more impressed with your "Test 6." Looks like the tortoise (MeGUI) may have nosed out the hare (Handbrake), but it's still a photo finish.
I did notice some interlace "shimmer" in the peacock's back in the Handbrake version that is not present in your MeGUI "Test 6."

At some point (maybe spring break) I'm going to produce a video tutorial using my original Vegas->DnxHD->Handbrake method; it will be a relatively simple step-by-step approach. Your tutorial(s) will probably be more complex in nature, and I will plan on linking to them as a resource for those wanting to dig deeper.

And thanks for taking this to a level I had never expected when I started with this question. Everyone here has benefited as a result, and so will Youtube and Vimeo uploaders everywhere.

P.S. I agree that we are probably bumping our heads on the "quality vs. render time" ceiling with x264. One thing is certain; no one is going to say VP8 is any better, so until the next "greatest" free Flash codec makes its appearance . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 11:46:12 AM
 
Oh, I don't know tritical personally. I just meant his help as in the fact that he wrote these great filters.

Now then, this is really interesting. Look at the contrast of the x264vfw render after it's downloaded as an AVC mp4 from YouTube (note that the uploaded avi shows 16-235 in Vegas Pro 10.0):

img405.imageshack.us/img405/4783/x264vfwcontrastreductio.png

Vimeo does the same thing. I checked a still image from the file playing on YouTube and it's only expanded by the Flash Player to 16-235, not 0-255. So if you're sending YouTube or Vimeo an x264vfw avi file then you should send it at full range 0-255, not 16-235.

Now I wonder if that applies to all avi files, and I also wonder what happens with other formats that people might send to them. Seems dangerous now for us to tell everyone to send everything at 16-235. Mark, your test here seems to indicate that m2t, at least, is behaving the same as avc/mp4.

My guess is that they're using ffmpeg or similar to decode everything they're sent and that it reduces the contrast of avi files but not avc/mp4 or m2t files. It looks like my ffdshow-powered WMP is also reducing the contrast of the x264vfw avi file. I'd like to put a screengrab on the Vegas timeline to check but print screen won't copy the videos playing in my media players.

I'll look into uploading just the REC 709 gradient to YouTube/Vimeo in some more flavours of avi and other formats. I'll start with an Xvid. Any requests/suggestions for other formats? Also, is that REC 709 gradient the best thing to upload for analysis, or something else?

Tomorrow I'm going to go and read Glenn Chan's articles again and see if they shed any light on this stuff.

What's the betting that Adobe decide to leave the contrast of avc alone with the next release of Flash Player and all our stuff comes out wishy washy.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 12:52:06 PM
 
" . . . but print screen won't copy the videos playing in my media players."

I just confirmed that the Dread Moon Linux distribution of Ubuntu running in VMWare as a virtual machine within Win7-64 will capture a frame from video playing in YouTube when the Print Screen key is pressed.

VMWare Player is free, as is Dread Moon Linux (bagside.com/bagvapp/index.html).

To use it, just install VMWare Player from https://www.vmware.com/tryvmware/?p=player&lp=1&source=web&cd=1&ved=0CCgQqwMoADAA&url=www.vmware.com/go/downloadplayer/&rct=j&q=vmware%20player&ei=LIddTZ6-AY6osAOnneTrCg&usg=AFQjCNH1Wx2_2jFhdO7dowNA8gCkOwMaiw&sig2=x96r5Ntdapso9IJtx_Mrww.

Then unzip the Dread Moon Linux download with 7z, free from www.7-zip.org/download.html. Put the unzipped Dread Moon Linux anywhere on any hard disk - as you please.

Finally, double-click the .VMX file in the unzipped Dread Moon Linux folder in order to get it to play in the VMWare Player.

The necessary flash player, etc., already has been installed in Dread Moon Linux, so you'll only need to open all the windows full-screen, go to YouTube or ??, and press Print Screen while the video is playing. You can save the resulting .PNG to your Dread Moon Lunux desktop. And from there, just drag'n drop the .PNG into any folder on a real hard disk on your Windows machine. I presume that the Flash player in Linux behaves the same as within Windows in regard to color (my limited eyeball scrutiny seems to indicated that it does; but I could be wrong).

I only use Linux, running within Windows XP-32 or Win 7-64, for getting on the web - in order to avoid virus and other malware . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 1:04:37 PM
 
"but print screen won't copy the videos playing in my media players"[/]
I've been using Snagit www.techsmith.com/snagit/default.asp?gclid=CO2us_SKkKcCFUdN4AodoXuIeA based on someone in this forum's recommendation - can't remember who, but thanks! Snagit will grab a MediaPlayer screen just fine, however much better quality if the player is paused.

The link above is for the 30day / full function free trial.

...Jerry (who used the free trial, but liked Snagit so much he bought it)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 1:06:14 PM
 
Nick, did you have the
Code Block:
ConvertToYV12(matrix="PC.709")
line in when you did the x264vfw render?

Any way to tell if x264vfw calls itself 709 or RGB? Since it's an AVI wrapper, I wonder . .

[EDIT] I found the download link for your x264vfw AVI, and although it reads 16-235 on my Vegas Pro 8.0c scopes, it plays flat locally too on VLC. That says to me the file is not telling the world it is YUV, but RGB. So one would have to render or frameserve 0-255 instead.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/17/2011 9:28:35 PM
 
@ RLeavis - Thanks but I can capture YouTube videos no problem. It's my local players, WMP11, VLC, GOM that can't be captured. I've just reinstalled everything on this computer and I'm rather wary of installing a whole Linux emulator just to grab a couple of screenshots.

@ Jerry - I downloaded the free 7.2.5 version of Snagit that blink3times linked to in this old thread. The bad news is that it doesn't capture locally-played videos. The good news is that it is free and still allows one to upgrade to the latest version at half price, $24.95. Does capture of videos work in all snagit profiles or is there a specific one for media players?

@ Mark - No AviSynth at all in that workflow. Just VP 10.0 > Frameserver (RGB24) > VirtualDub > x264vfw

I'm going to try an Xvid shortly and see what that does, and I'll try a render to x264vfw straight from Vegas too. x264vfw probably isn't going to end up as anyone's method of choice for this. The doom9 folk probably have very good reason to despise it. I mostly did it to check out edge-directed-interpolation deinterlacing within Smart Deinterlacer, and because I like VirtualDub.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 1:44:54 AM
 
In the meantime....

By default, Handbrake decomb default mode is 7, which means it switches between doing a cubic-interpolation-passed-to-yadif, and a blend (depending on how much motion/combing there is). So I set it to mode 11, which does an EEDI2 interpolation instead of cubic, before passing it to yadif. I left everything else in the decomb custom string at defaults, as far as I can tell from reading their forum. This is what I put in the decomb custom field:

Code Block:
11:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1


At first it was saying that it was going to take 4 hours or something. WAY slow. So I just did a few seconds and came out with the best decombing yet on that street marking:

img4.imageshack.us/img4/9303/test8handbrakeeedi2.jpg

This might be the perfectionist's option, but we're talking seriously slow, overnight-or-more rendering. Mode 25 might surpass it (also does MCdeint after EEDI2>Yadif) but would be even slower. Decomb3 is also interesting but only available in nightly builds. I'm not planning to try either for the time being. However since the NNEDI3 I used in my MeGUI version is allegedly superior to the EEDI2 used here, I'm wondering if Yadif(mod) might do better than TDeint in my AviSynth script.

p.s. We need a forum upgrade for multiple pages in a single thread!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 2:17:26 AM
 
"Does capture of videos work in all snagit profiles or is there a specific one for media players?"
Ha! I just discovered something - Snagit does not support recursion. I could not capture my Snagit profile page using Snagit (I was going to post it here). That said, I'm not doing anything special - Snagit 10.0.0 using the All-in-One profile.

I'll repeat what I said earlier - you must pause the MediaPlayer to get a good capture, otherwise the capture looks like this:

dl.dropbox.com/u/20447760/MediaPlayerCapture.png

Good Luck!
...Jerry

btw: I'm finding that Snagit works nicely in combination with Dropbox - just save the screenprint to the Public folder, right click to get the URL and paste the URL back to your posting.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 10:24:07 AM
 
"Decomb3 is also interesting but only available in nightly builds."

Actually it's still just a patch, uncommitted. Looks like the interest in it stalled out last summer when the core devs turned their focus to 0.9.5. Hope someone resurrects it.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 1:06:37 PM
 
So I upgraded Snagit to version 10 and set up Dropbox. What a great pair of programs and workflow! Especially when you update an edit in Snagit and the change appears almost instantly at the same URL. That was a laugh out loud moment. Thanks for the tip Jerry! However... it still won't capture videos correctly. They are offset horizontally and vertically and therefore cropped, similarly to how they were when I was using Zscreen. I assume this has something to do with overlays and my graphics card (NVIDIA Quadro FX 1600M)??? Anyway never mind. It's something I'd very rarely want to do.

I've been trying to nail down this colorspace/levels palaver, so I rendered a whole bunch of REC 709 gradients, checked the scopes on them in Vegas Pro 8.0c and 10.0c, uploaded them to YouTube, scoped full-screen png screengrabs of each of them, and finally downloaded the corresponding AVC files from YouTube and scoped those too. All the files were written in Vegas Pro 10.0 except for the WMV9 and Cineform which were done in VP 8.0 and the x264vfw done in VirtualDub. Results...

dl.dropbox.com/u/21489814/19-02-2011%2002-17-26.png

If anyone wants to see the videos they're all under my www.youtube.com/bvfavorites channel.

So the conclusions of this endeavour are:

1. Most things should be uploaded to YouTube at 16-235 except for WMV and some flavours of AVI such as Xvid which should be uploaded at 0-255 (probably DivX too but I didn't want to install the codec).
2. YouTube doesn't support Cineform, Lagarith, or sometimes x264vfw. I'm kicking x264vfw into touch for any of this now anyway.
3. The WMV decoder in Vegas Pro 10.0 does a computer-RGB->studio-RGB conversion that Vegas Pro 8.0 didn't.
4. YouTube accepts Sony MXF and Quicktime M-JPEG. Such intra-frame (no temporal compression) codecs might be a valid choice if your video is short and you've got plenty of time/bandwidth. It's a little crazy but feasible. With Sony MXF HQ 35 Mbps you can squeeze an 8-minute video into YouTube's 2Gb upload limit. However I did notice that my video over-ran the audio by 3 seconds, so it would require more testing.

I also just want to revisit one thing we talked about way back up there on 31/01/11, when I blamed the old mp4 decoder in 8.0 for the levels expansion. Actually in 8.0 the remuxed YouTube files get decoded by the Quicktime decoder, qt7plug.dll, so that's the codec that seems to be confused or at fault. "Normally" AVC files get decoded by mcmp4plug.dll in 8.0, and mcmp4plug2.dll or compoundplug.dll in 10.0.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 2:31:38 PM
 
"I can capture YouTube videos no problem. It's my local players, WMP11, VLC, GOM that can't be captured."

hmmm; Print Screen on my Win7-64 bit system captures from WMP and VLC without introducing any artifacts that I can see (I just compared a high-motion frame captured in WMP by means of Print Screen key - expanded to full-screen in Photoshop - with the same frame in Cineform @ 1920 progressive (I only shoot progressive now). I can see no difference at all.

Since your system profile shows you, too, are using an nVidia graphics chip, I can only presume that Print Screen doesn't work the same in Win XP as it does in Win 7.

In any case, I just want to thank you and the others again for the outstanding work you've done on this topic. I'm just getting ready to upload some of my work to these video-sharing sites and certainly you have save me an immense amount of time and frustration. Best wishes - Larry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 6:14:32 PM
 
Nick,
I downloaded your 8Mbs MeGUI (Test 6) from Vimeo, and comparing it to my 8Mbs Handbrake, yours appears slightly sharper. As we have already seen, there are smoother diagonals in the MeGUI as well.

One thing I found surprising -- there is slightly less saturation in the greens in the MeGUI version. This shows up in the Vectorscope as well. Since they are the same encoder and bitrate, I wonder what is causing this?

Right click to view/DL the full res version
dl.dropbox.com/u/20519276/hb-megui.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 8:53:42 PM
 
I agree with Nick. The MeGUI version looks sharper. Did I miss the MeGUI settings from one of the previous posts? The current 'tutorial' link only has Handbrake settings. I'd like to do my own comparison too.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 8:56:50 PM
 
Nick's MeGUI settings for "Test 6" are already posted above. It's a rather lengthy post, so you shouldn't miss it.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/18/2011 10:07:00 PM
 
@ Mark - I've no idea about the greens. Busy today but will check on my machine later.

Here's a commented version of my Test 6 AviSynth script. I still haven't totally got my head around how NNEDI3 and TDeint are working together, so I've done my best in the comments...

Code Block:
# Open frameserved source. AviSource("d:\fs.avi") # Convert to YV12 so TDeint will work. # Use Rec.709 coefficients, keep full range [0,255] ConvertToYV12(matrix="PC.709") # Assume footage is top field first. If it's not then use AssumeBFF. AssumeTFF # Intra-field only deinterlacer with edge-directed interpolation. # "interp" is only the name of the variable and could be anything. interp = nnedi3() # Deinterlace the output of nnedi3 with bi-directionally, motion # adaptive (sharp) deinterlacer. TDeint(edeint=interp) # Lanczos3 resize to 1280x720 LanczosResize(1280,720)


Here are a few more that would be worth trying (shooting from the hip a little here)...

yadifmod instead of TDeint

Code Block:
# Open frameserved source. AviSource("d:\fs.avi") # Convert to YV12 so yadifmod will work. # Use Rec.709 coefficients, keep full range [0,255] ConvertToYV12(matrix="PC.709") # Assume footage is top field first. If it's not then use AssumeBFF. AssumeTFF # Intra-field only deinterlacer with edge-directed interpolation. # "interp" is only the name of the variable and could be anything. interp = nnedi3() # Deinterlace the output of nnedi3 with yadifmod deinterlacer. yadifmod(edeint=interp) # Lanczos3 resize to 1280x720 LanczosResize(1280,720)


TDeint without nnedi3 but with vinverse to smooth out residual combing (faster???)

Code Block:
# Open frameserved source. AviSource("d:\fs.avi") # Convert to YV12 so TDeint will work. # Use Rec.709 coefficients, keep full range [0,255] ConvertToYV12(matrix="PC.709") # Assume footage is top field first. If it's not then use AssumeBFF. AssumeTFF # Deinterlace with bi-directionally, motion adaptive (sharp) deinterlacer. TDeint() # Reduce residual combing vinverse() # Lanczos3 resize to 1280x720 LanczosResize(1280,720)


NNEDI3 by itself (no conversion to YV12 needed)

Code Block:
# Open frameserved source. AviSource("d:\fs.avi") # Assume footage is top field first. If it's not then use AssumeBFF. AssumeTFF # Intra-field only deinterlacer with edge-directed interpolation. nnedi3() # Lanczos3 resize to 1280x720 LanczosResize(1280,720)


As I said earlier, these different deinterlace methods should really be assessed at 1080p before resizing and compression.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/19/2011 3:19:20 PM
 
As Nick mentioned, setting level 9 or 11 decomb in Handbrake caused ridiculously long renders for the test project, 3 to 5 hours in fact. I'll stick with the defaults or try learning MeGUI again.
;?)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 1:40:32 AM
 
>> One thing I found surprising -- there is slightly less saturation in the greens in the MeGUI version. This shows up in the Vectorscope as well. Since they are the same encoder and bitrate, I wonder what is causing this? <<

It's because of different decoders being used in Vegas Pro 8.0 to read the files. MeGUI version is qt7pllug.dll and Handbrake version is mcmp4plug.dll. In Vegas Pro 10.0c they are all read by compoundplug.dll so no problem. The decoder used by 8.0 seems to depend upon the mp4 profile (not the AVC profile) of the file. MeGUI is writing Base Media / Version 2 / isom, while Handbrake is writing Base Media / mp42. This is presumably a result of the way the streams are muxed, and may be affected by slightly different types of AAC audio stream, or by the device options in MeGUI (all of which is probably tweakable to match them up if anyone is bothered).

dl.dropbox.com/u/21489814/20-02-2011%2015-52-02.png

Scopes in 10.0c for the downloaded versions match up nicely, so thankfully it looks like YouTube and Vimeo (unlike VP 8.0) are decoding the MeGUI and Handbrake files the same way. I have no idea if the browser Flash Player treats them differently locally but I expect (and sincerely hope) not.

Incidentally, besides colour differences, I would say trying to compare sharpness etc. of the MeGUI and Handbrake files in Vegas Pro 8 is dangerous, because of the different decoders used. In Vegas Pro 10 the difference between Test 4 (Handbrake) and Test 6 (MeGUI) is really marginal. Overall I think my preference is just in favour of Test 6, but in some frames and parts of frames I question it. The decision essentially comes down to speed and workflow preference.

>> I'll stick with the defaults or try learning MeGUI again <<

It's really not difficult. I'm only using a few basic functions of it. But hold your horses anyway. Tutorial coming in the next few days!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 3:02:56 AM
 
Just noticed that the new TMPGEnc Mastering Works 5, an update from TMPGEnc Xpress 4 (and now a little NLE all in itself), has switched from MainConcept to x264 for AVC.

In addition to this, TX4 (and presumably MW5) has motion-adaptive deinterlacing, Lanczos-3 resizing, and can accept a frameserved file.

This might very well prove to be the "easy life" method of choice, but at a price ($100, or $60 for an upgrade from TX4). There is a MW5 trial available.

Some TX4 deinterlacing methods:

...
Interpolation - Adjusted: Interpolates the interlace stripes by referring to the previous and following frames of the clip.
Interpolation - Animation: Interpolates the interlace stripes by referring to the previous and following images of the clip and searches for the parts where interlacing appears.
Interpolation - Animation 2: Interpolates the interlace stripes by referring to the previous and following images of the clip and searches more thoroughly for the parts where interlacing appears. Because of the analysis method, opposite interlace stripes may be missed.
...


Also see Tom Roper's old post on dvinfo.net (presumably referring to an older version of TX).

I really like TMPGEnc software. Would be interesting if they made a full-blown NLE.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 8:23:29 AM
 
"It's because of different decoders being used in Vegas Pro 8.0 to read the files."

Just to clarify, the grabs I posted were fullscreen frames from VLC saved as PNG -- presumably VLC is using the same decoder for each. Files compared were my Handbrake and your MeGUI x264 versions, both 8Mbs, in fact the settings used were very nearly identical and I can see nothing in them that would cause the shift in the primaries. I "suspect" that one is actually encoding the MP4 (or decoding the DNxHD) as 601 primaries, which is rather common in practice, but of course I have no way to prove that. These old color corrector's eyes (and the scopes) see a <2% shift in the greens, which most casual viewers wouldn't notice.

Speaking of the DNxHD intermediate, I'm in the middle of some interesting research on which intermediates actually will work in Handbrake without the levels shift (I've found a couple of others) and comparing them by grayscale accuracy, file size, and rendering time from Vegas. Not likely to change my first choice, but interesting to compare. Will post my results here.

That brings up a glaring omission in my test footage -- facial flesh tones. If someone has 20 seconds of good "Shirley" footage they'd like to share with the world, I'll look forward to including it in the next incarnation.
[EDIT]: I think I've found it in some GH2 test footage on a Japanese site. But will still like to see suggestions from others.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 1:57:42 PM
 
Ah sorry, I assumed you were comparing in the Vegas 8 preview window.

I think I've now beaten NNEDI3+TDeint for quality and speed using the QTGMC Deinterlacing Script.

Code Block:
# Open frameserved source. AviSource("d:\fs.avi") # Convert to YV12 so EEDI2 will work. # Use Rec.709 coefficients, keep full range [0,255]. ConvertToYV12(matrix="PC.709") # Assume footage is top field first. If it's not then use AssumeBFF. AssumeTFF # Deinterlace with QTGMC script. QTGMC( Preset="fast" ) # Add this line to keep original frame rate, leave it out for smoother doubled frame rate. SelectEven() # Lanczos3 resize to 1280x720. LanczosResize(1280,720)


That's for single-threaded usage. I tried a multi-threaded setup too but it was actually slower on my Core 2 Duo. There are quite a few bits to install but the results are great. I'll render the whole project tomorrow. Out of interest I'm also going to chuck YouTube a 1080p version to see what they do with it.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 3:31:32 PM
 
Nick, Welcome to OCD Anon (I read your other post).

I've done a new set of tests on just the intermediates between Vegas and Handbrake (and presumably AviSynth).

There was one big surprise -- that old warhorse, Helix I420 (remember when we used to do everything in VDub?) won the grayscale and rendering time test.19% faster than DNxHD and perfect grayscale reproduction. Unfortunately, the files are 5 times larger than the DNxHD counterpart. DNxHD was only a hair off the mark on the grayscale, while Sony MXF (smallest file) was visibly worse.

So, DNxHD is the best compromise between quality and file size, and Helix I420 is the best for both quality and rendering time.

[EDIT] Helix wants to default Handbrake to Blend fields, so use this custom preset to decomb. 5:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1

Note: Top four ordered by relative render time in Vegas (not the final x264 render).
Note that "I420" starts with an "i", not a "one".
Note that Helix has been updated, so presumably honors REC 709 Luma.
Working on a new upload for Vimeo Vegas->HelixI420->Handbrake. Also will have a Shirley test.

dl.dropbox.com/u/20519276/HBint.png

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 6:57:02 PM
 
Very thorough Mark!

But trust me to find one you might have missed...

For HDV projects with just the odd title or transition, I'm really interested in Sony MXF-in-an-MP4-container as an intermediate for Handbrake (much faster to smart render to than Sony-MXF-in-an-MXF-container, or HDV). You can do it in 10.0 and probably 9.0, but not in 8.0. It's blisteringly fast and more faithful to the original in the non-smart-rendered parts than an MC HDV render. See this thread. Would be interesting to see if Handbrake can open that and how it compares with your other intermediates. What version are you on? If you don't have 9.0 or 10.0 I could benchmark it here against DNxHD and AVI Helix I420.

Also, if you make your Shirley source footage and an updated project available I could run it through MeGUI if you like.

p.s. Quick question... Is Sony MXF always long-GOP and DNxHD always intra-frame? I'm still trying to understand where these codecs fit in the grand scheme and which is the more appropriate Cineform substitute.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/20/2011 7:47:55 PM
 
Sony MXF is mpeg-2 based, so long-GOP. I don't have the ability to rewrap it on Vegas Pro 8.
May be good for quick HDV renders the way you described, but I've never cared for the bluish whites when doing full-recompress renders.

I'm having a pulldown problem with my Shirley footage. Maybe you could respond in my new thread and set me straight.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 2:53:34 AM
 
Test 14 (a few went by the wayside...)

QTGMC is looking very promising indeed. Basically the developer has already done most of the hard AviSynth deinterlacing work for us. I had to go as far as the "very fast" preset to keep the rendering time competitive with Test 4 (Handbrake) and Test 6 (NNEDI3+TDeint). Those 2 took around 44 mins (inc the DNxHD render in the first case). This takes 56 mins. But I'm only running it single-threaded on my laptop. I tried multi-threading but it was a little slower because I only have a Core 2 Duo. On a quadcore or better there could be good time savings to set it up multi-threaded, and there are loads of "slower but better" modes to eek more quality out of it. There are also 3 "faster but rougher" modes as well.

This is pretty new stuff and, from what I can tell, about as state-of-the-art as it gets for freeware tools. The "people who know" on doom9 seem to be behind it.

How do you think this one compares to Test 4 and Test 6? I haven't uploaded it to YouTube or Vimeo just yet in case we decide a slower preset would be better. I'd appreciate a second look or 2.

Test 14 render

Code Block:
# Open frameserved source. AviSource("d:\fs.avi") # Convert to YV12 so filters will work. # Use Rec.709 coefficients, keep full range [0,255]. ConvertToYV12(matrix="PC.709") # Assume footage is top field first. If it's not then use AssumeBFF. AssumeTFF # Deinterlace with QTGMC script. Preset default is medium. QTGMC( Preset="very fast" ) # Add this line to keep original frame rate, leave it out for smoother doubled frame rate. SelectEven() # Lanczos3 resize to 1280x720. LanczosResize(1280,720)


Also I'm rendering a 1080p for YouTube right now using QTGMC (just curious), and I'll also do a little benchmark of DNxHD vs. AVI Helix I420 vs. Sony-MXF-in-MP4 to see how 10.0 compares with your findings in 8.0.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 9:38:27 AM
 
Here is a very preliminary version of Untitled3.veg on Vimeo. Original uploaded 176.8MB file can be downloaded for about a week I think.

vimeo.com/20190131

-- Used Helix I420 as an intermediate. The intermediate plays relatively well on the timeline considering it is 746Mbs! As expected, grayscale rendition is slightly better. Also renders pretty fast in Handbrake.

[EDIT] Helix wants to default Handbrake to Blend fields, so use this custom preset to decomb. 5:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1

-- Please do not use this for direct comparison with the earlier version. Black levels have been tweaked. I realize I need to upload an I420-intermediate version of Untitled2 for direct comparison, and will do so when Vimeo allows it.

-- Included some Shirley tests. Girl by tree is slightly jerky because I rendered 1-2-3-4-4 (no resample) from 24p. Am looking for a better solution. I am going to replace the Fujifilm test card with a better one in the next trial.

-- Overall, I am very impressed with I420 as an intermediate. However, a 15 minute render would take up 62GB! A separate empty render drive is almost a necessity if one is going to get serious about using this.

-- Also, when rendering directly from the .veg files, it will help if the event lengths are not changed. That way, different renders will line up frame-for-frame for scope comparison on the timeline. After further tweaks, I will make Untitled3.veg and new media available on Jerry's ftp server.
;?)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 11:20:24 AM
 
As it appears from watching the video, I420 is sharper than DNxHD 145.

dl.dropbox.com/u/20519276/eye.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 11:59:32 AM
 
Firefox is stretching and blurring images on the forum, making it impossible to make judgments on stuff like this without downloading the images. That "eye" image is displaying at 620px wide instead of 560px. Is anyone else seeing this, or know why it happens?

Will take a look at your Vimeo upload tomorrow.

Would really welcome your opinion on my Test 14 render when you get the chance. Hoping to start writing my tutorial tomorrow and will probably go with that one, but would really like a 2nd pair of eyes on it.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 12:53:40 PM
 
"Eye" image is displaying in correct aspect in Firefox 3.6.13
Uploaded eye.png is 560x280.

I'll definitely look at your Test 14 when I get home later tonight.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 12:54:36 PM
 
@musicvid: "After further tweaks, I will make Untitled3.veg and new media available on Jerry's ftp server." Once you do, either post back here or send me an email. I'll update the webpage.

@Nick Hope: "Firefox is stretching and blurring images on the forum, making it impossible to make judgments on stuff like this without downloading the images"Strange, I don't see this in my Firefox.

@musicvid & Nick Hope: I've read this Thread every day, and frankly you guys have gone well beyond what I'm able to absorb. Give some thought about how I should redesign our host webpage once the project is complete. What should we link to? What should be title wording be? How should the graphics be laid out? More than one page needed? Maybe even a domain name? Come up with some ideas & I'll be happy to implement.

btw: congrats on the 200+ posts!

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 7:25:32 PM
 
WRT Test 14 -- Very crisp!
dl.dropbox.com/u/20519276/thumbsup.gif
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web --Workflow?
Date: 2/21/2011 9:24:15 PM
 
Okay I'm going to say right off the start that I haven't read all 200+ posts so since I'm a lazy lurker, what is the current workflow and settings that you would recommend ? Some screen shots would do nicely.

Thanks
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web --Workflow?
Date: 2/21/2011 9:29:36 PM
 
The current tutorial is here:
www.jazzythedog.com/testing/dnxhd/getvideo.aspx

It works great. There will be updated settings from Nick and I later in the winter or spring.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 10:57:27 PM
 
Mark, in haste before I reply to the other stuff, in case you're still up. Any new version of the project... can you please chuck in a couple of seconds of black/white/black/white 1080 horizontal comb... or anything else you guys were using to test whether YouTube 1080p is actually just 540p with the vertical resolution doubled. The stuff I'm doing now needs this. More later...

Edit: As per A. Grandt's test at www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=684155.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/21/2011 11:12:33 PM
 
Yes, I think I have A. Grandt's original files somewhere. Will dig them off the archive disk sometime tomorrow and upload somewhere for you.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/22/2011 4:11:36 AM
 
>> WRT Test 14 -- Very crisp! <<

Glad you liked it. As I said, that was only at "very fast" preset. If you've got time to wait for the render then there are plenty of higher quality slower presets.

>> frankly you guys have gone well beyond what I'm able to absorb <<

Apologies for using this thread as my personal notepad, but at least if I write stuff down here, I know where to find it in the future. And it forces me to at least think a bit before I write a conclusion down.

>> Give some thought about how I should redesign our host webpage once the project is complete <<

In the next few days, when I've finally nailed down my preferred method in detail, I'll be writing a tutorial that will appear on my site, bubblevision.com. Just a text-and-pics tutorial at first, not a video one. Then the best thing may be for the three of us to just put in reciprocal links to each other?

Incidentally, at the start of my tutorial, how should I recommend to people to conform the project to 16-235, as a general guide? Do it on each event, or run a filter on the whole project, or both depending on the project? What do you guys think?

Today I revisited A. Grandt's excellent work and confirmed that YouTube are still discarding the even lines of a 1080 upload before rendering any of their files (including the 720p version):

1080p test: http://www.youtube.com/watch?v=1mK04_sYWb0
1080p original png file

Here's a 500% magnification taken from the 1080p file downloaded from YouTube, showing what they do to hard edges:

dl.dropbox.com/u/21489814/YouTube-resolution-test-1080p-downloaded-from-YouTube-1080p-500-percent.png

YouTube are not discarding any lines from 720p uploads:

720p test: http://www.youtube.com/watch?v=Sz_OPOxjXuo
720p original png file

Mark, maybe you can include a few seconds of that 1920x1080 png file in your future test .veg, but I'm thinking that it might be useful if we put some thought into a few seconds of footage that might help us understand how various interlace methods are working and be a bit more "scientific" with some of our judgements. I'm thinking hard-edged solid and combed shapes floating around the screen for a few seconds at various speeds. e.g black circle, static single-line combs, thin lines at very acute angles etc.. I'm useless at creating that sort of stuff in Vegas though because I've hardly ever done it.

I also uploaded a 1080p version of our project using QTGMC "faster", crf 19.5 (avg bitrate = 15.5 Mbps). Here it is: http://www.youtube.com/watch?v=Zp3IWx6IwSU

The interesting part is in comparing the 720p version encoded from that 1080p (Test 17 - http://www.youtube.com/watch?v=Zp3IWx6IwSU) against the 720p version encoded from the equivalent 720p upload (Test 14 - http://www.youtube.com/watch?v=ACPnB_6kb7g). There's really not much in it. The first has, effectively, 1920x540 pixels to encode from, the 2nd has 1280x720 pixels to encode from. I would be interested in your opinions on how they compare to your eyes.

So then I started thinking that I may just upload everything to YouTube at 1080p and just embed the 720p versions of those. So I did further testing with embedding and discovered that as long as we keep the embedded size (including player) below 1770x1026, YouTube will serve the 720p version of the video. Above that you get the 1080p version.

This doesn't affect Vimeo, because we're limited to 720p there for now.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/22/2011 5:07:51 AM
 
Nick,

First I want to thank you and musicvid for this very interesting topic I lurk since its beginning.

Incidentally, at the start of my tutorial, how should I recommend to people to conform the project to 16-235, as a general guide? Do it on each event, or run a filter on the whole project, or both depending on the project? What do you guys think?

It depends of the nature of the project and the footage.

In my humble opinion, running the filter a bus level is the "newbie-all-purposes" straightforward solution but people serious about color grading may choose to conform at event or media level.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/22/2011 10:16:41 AM
 
Nick, I can see the sense of including a line rez example in our tutorials to illustrate what YT does to 1080i uploads, however including it in this project video presents some technical problems.

Since one of the starting assumptions is that our 1080i project intermediate will be rendered to 720p for upload, a 1080i line rez chart in the project will get garbled in our final render prior to upload. Likewise, a 720p line rez chart in the project would get uprezzed to 1080i in the intermediate (by Vegas), then downrezzed again in the render.

So the usefulness of including it in this project would seem to be:
For those wanting to see how 1080i holds up in the 720p render prior to upload; or,
For those wanting to test the assumptions stated in the first post by uploading 1080i, as well as the fact that Youtube will interpolate 1080i anyway.

Right-click to view full resolution image in your browser.
dl.dropbox.com/u/20519276/vrez1080-720.png

I could easily include the ISO chart in the project, but the one I have is reverse engineered, and I would have to see if that content is protected.

So I am thinking that testing 1080i uploads is probably beyond the original scope of this project, and might be a better topic for a separate one, although as I said we should mention and example YT's handling of 1080i in our tutorials.

BTW, I sent you all of A. Grandt's material as well as my collection of rez charts.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/22/2011 10:47:58 AM
 
@ LotN - Re the levels, that's basically what I was thinking. I'm not planning to go into great depth with it. I'll basically explain about the level 16 underlay track, the level 235 max for titles etc. etc.. And also explain how a filter could be run on the whole project instead. Then I'll link to a couple of places to find out more.

@ Mark - I hear you. The stuff I'm thinking of is really beyond the scope of this project. I just got to thinking of it because of my foray into 1080p with that YouTube upload. It belongs really in a 1080i>1080p deinterlacing comparison. Anyway thanks for the files.

In my last post I forgot to put in the link of my Test 14 file now on YouTube...

Test 14 (QTGMC/720p): http://www.youtube.com/watch?v=ACPnB_6kb7g
Test 17 (QTGMC/1080p): http://www.youtube.com/watch?v=Zp3IWx6IwSU

Ideally they would both have been at the same QTGMC preset, but they're one quality-preset apart. Nevertheless there's not much between those 2 presets. I'm interested in any feedback comparing the 720p version of each of those against each other.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/22/2011 10:52:21 AM
 
Incidentally, at the start of my tutorial, how should I recommend to people to conform the project to 16-235, as a general guide? Do it on each event, or run a filter on the whole project, or both depending on the project? What do you guys think?

As Bob and I discussed some time back, a stock Studio RGB filter, is a one-size-fits-all, safe, WYSIWYG solution. It does not optimize levels for a particular source, only ensures that what comes back is what was sent.

The intricacies of optimal leveling and gamma adjustment of different delivery content is an advanced art, and probably will only be mentioned in my Handbrake tutorial, not illustrated. Since your MeGUI tut will be more technical than mine, you may want to delve into it a bit deeper.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/23/2011 4:10:12 AM
 
Test 18 was supposed to be my pièce de résistance but it's stuttering quite badly here in Firefox, even after fully buffering. How does it play for anyone else?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/23/2011 4:24:56 AM
 
Nick, Test 18 looks very good to me. I see a small amount of stuttering in both Firefox & IE9, but it appears less than the "normal" web delivered stutter - certainly no worse and maybe better than any of the other attempts.

btw, it's one of my pet peeves that videos can play "smooth as glass" locally via WMP or VLC, but the same clips delivered via the web will show stuttering, even with no dropped frames. Maybe someday this will be fixed.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/23/2011 8:00:42 AM
 
No differences in playback with any of the other versions including mine.
Plays smooth in the small player. I always pause and let the video load completely from the 'net before starting playback. Also, turning off Windows Sidebar and Vista screen enhancements helps.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/23/2011 10:08:33 AM
 
"1 hour 8 mins on my core 2 duo T7800 @ 2600 MHz with 4GB RAM"

The combined render times (I420 + Handbrake) on my T2390 laptop (1.85 GHz) are 41:30. Even adding in a couple of minutes to set it up in Handbrake, Frameserve->MeGUI with your settings is rendering ~65% longer. As I mentioned, the sharpness using your method is better than Handbrake's.

Lacking any huge differences in our settings and bitrate, I assume it's the deinterlacer eating up the time. May explain why decomb development bogged down at Handbrake . . .
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/24/2011 11:48:42 PM
 
>> btw, it's one of my pet peeves that videos can play "smooth as glass" locally via WMP or VLC, but the same clips delivered via the web will show stuttering, even with no dropped frames. Maybe someday this will be fixed. <<

This is where YouTube have an advantage over Vimeo. For all their butchering of the video quality, YouTube videos never stutter (for me), whereas Vimeo ones often do. In my tests the downloaded stream from Vimeo is only 2022 Kbps, compared to 3061 Kbps from YouTube, so something fancy in the encoding that allows them to get better quality at a lower bitrate (e.g. Weighted prediction), is overly challenging the browser's Flash Player on some systems.

Mark, over here MeGUI with QTGMC with "faster" presets is taking twice as long as I420+Handbrake...

I420 + Handbrake = 20 + 14 = 34 mins
QTGMC faster = 68 mins

But there are faster QTGMC presets taking us all the way down to 37 mins for "ultra-fast". I figured that if someone is bothered enough about the quality to go through all this, then they're probably patient enough to wait a bit longer.

Here are some benchmarking notes and results. The main ones we're interested in are highlighted in yellow:

dl.dropbox.com/u/21489814/25-02-2011%2014-35-41.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/25/2011 8:11:01 AM
 
Nick, can you tell me more about QTGMC?
I found out it's an Avisynth script, but little about what's under the hood.
Does it use a combination of tritical's deinterlacers, or is it its own unique code?
Is it something that could be emulated by setting custom decomb numbers in Handbrake? Is it better than TDEint / EED12 / NNED13 / whatever, or just more convenient?

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/26/2011 4:49:41 PM
 
Release Candidate for Handbrake Tutorial

As Nick pointed out, it is always good to have other eyes on these tests, lest we be lulled into self-delusion:

-- Tweaked blacks and colors slightly for uniformity.
-- Added skin tone test and color chart.
-- Added end credits
-- Used Helix I420 as the intermediate
-- Original HB settings same as before

[EDIT] Helix wants to default Handbrake to Blend fields, so use this custom preset to decomb. 5:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1

I learned one thing this week -- color correcting HDV seems to be much more difficult than AVCHD; don't know what the reason for this is.

I will zip and upload the new project files to Jerry's server and begin working on the "real" Handbrake tutorial vid once everyone has checked in on this version. I'm feeling ready to put this project to bed, but still want to continue learning from Nick's branch of the project.

vimeo.com/20190131
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/26/2011 10:02:29 PM
 
>> color correcting HDV seems to be much more difficult than AVCHD; don't know what the reason for this is. <<

Possibly differing behaviour caused by the different decoders used in Vegas 8.0? You may see more uniform behaviour correcting AVCHD and HDV in 10.0, where they are both decoded by compoundplug.dll.

>> vimeo.com/20190131 <<

I'm seeing loads of motion blur in this one compared to your first one, in both the uploaded and downloaded file, when viewing stills on the timeline, almost as if it wasn't quantized to frames when you rendered it. Is it deliberate?

dl.dropbox.com/u/21489814/vimeo18690771cropped.jpg
dl.dropbox.com/u/21489814/vimeo20190131cropped.jpg

Been busy for a couple of days but will come back with an attempted explanation of QTGMC, later today hopefully.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/26/2011 10:35:37 PM
 
No, that wasn't intended. I'll look at the renders and the new project tomorrow.

Good catch!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 5:55:00 AM
 
>> can you tell me more about QTGMC? <<

Deep breath... I'll do my best.

First, if anyone needs a deinterlacing primer, look here (somewhat outdated but still good), here (by Donald Graft, author of Smart Deinterlacer), here, and here.

From those it's worth remembering that "weave" means do no deinterlacing, and "bob" means separate the fields, restore the height by doubling it, and display one field after the other (giving double framerate of the source).

QTGMC is something I stumbled upon in the Doom9 forum. It's not an AviSynth plug-in filter as such but rather a script that uses a combination of others' filters to make a very nice job of deinterlacing. Before talking about QTGMC, I'll backtrack through some of the things I tried before it. A lot of the following is directly quoted from authors' descriptions, with a few explanations added by me.

Motion-Adaptive Deinterlacers

These analyse motion in the video and only deinterlace where necessary. They weave (= do nothing) in areas of no motion and interpolate in areas of motion.

TDeint
TDeint is a bi-directionally, motion adaptive, sharp deinterlacer by Tritical. It can adaptively choose between using per-field and per-pixel motion adaptivity, and can use cubic interpolation, kernel interpolation (with temporal direction switching), or one of two forms of modified ELA (Edge-Based Line Averaging) interpolation which help to reduce "jaggy" edges in moving areas where interpolation must be used.

Yadif
"Yet Another DeInterlacing Filter" ported from MPlayer. It checks pixels of previous, current and next frames to re-create the missed field by some local adaptive method (edge-directed interpolation) and uses spatial check to prevent most artifacts. Handbrake uses Yadif, amongst other things (Edit: ...and the author explains its operation here).

When I tried either TDeint or Yadif alone, at default settings, the result was pretty good but some jaggies were left. They were relatively fast (see table above in my previous post). Yadif was slightly faster than TDeint. TDeint alone (Test 1) was my method of choice (out of ignorance of better methods) before this project started.

Smart Deinterlacer
Donald Graft's VirtualDub filter provides a smart, motion-based deinterlacing capability. In static picture areas, interlacing artifacts do not appear, so data from both fields is used to provide full detail. In moving areas, deinterlacing is performed. Mike Crash's Vegas filter is a port of an early version of this.

Edge-Directed Interpolaters

Well, I'm not even going to try and explain what Edge-Directed Interpolation (EDI) does. I scraped an E grade in A-level maths. Happy Googling! Likewise for neural networks.

EEDI
"Enhanced (I suppose) Edge-Directed Interpolation" by Tritical. EEDI2 resizes an image by 2x in the vertical direction by copying the current image to every other line in the resized image and then interpolating the missing field. It is intended for edge-directed interpolation for deinterlacing. EEDI3 works by minimizing a cost functional involving every pixel in a scan line. It is slow.

NNEDI
"Neural Network Edge Directed Interpolation". NNEDI is also by Tritical and generally more recent than EEDI. nnedi is an intra-field only deinterlacer. It takes in a frame, throws away one field, and then interpolates the missing pixels using only information from the kept field. It has same rate and double rate modes. Tritical says he personally sees nnedi2 as completely superseded by nnedi3.

So, EEDI uses an edge mask, while NNEDI uses a neural network. EEDI smoothes edges (and the whole image) more, NNEDI is sharper and thus enhances detail (and noise) more. I tried them both. The result was pretty good. EEDI gives an extremely smooth result which I suppose would make it good for cartoons.

Smart Deinterlacer
Version 2.8 beta 1 beta adds DCDi-like edge-directed interpolation. It can significantly reduce stairstepping ("jaggies") in deinterlaced picture areas. I've read on doom9 that it's not as sophisticated as Tritical's EDI filters.

Edge-Directed Interpolater + Motion-Adaptive Deinterlacer

Tritical allows TDeint to take the weave/interpolate reasoning from EEDI or NNEDI as opposed to itself. He also modified Yadif to do the same thing, and called it Yadifmod. NNEDI3+TDeint used in this way gives a fantastic result (Test 6), and was my preferred choice before I discovered QTGMC, and may still be useful for some jobs.

QTGMC

To quote the first line of the script itself, QTGMC is a Deinterlacer using motion-compensated temporal binomial smoothing. QTGMC is written by Vit and is based on an earlier script, TempGaussMC ("TMGC") by Didée. Didée is a Doom9 stalwart and wrote MCBob which is a highly regarded deinterlacing filter. He says, regarding TGMC with most-fast and most-basic settings, versus YadifMod with NNEDI2 interpolation, "TGMC was much faster, still it let Yadifmod/NNEDI2 stand with egg in their face."

Under the hood, QTGMC uses and requires these AviSynth plugin filters:

MVTools2
MVTools is collection of functions for estimation and compensation of objects motion in video clips. Motion compensation may be used for strong temporal denoising, advanced framerate conversions, image restoration and other tasks. This is the same plugin John Meyer uses for noise reduction and slo-mo, so it must be good ;)

RemoveGrain + Repair
RemoveGrain is a purely spatial denoiser. However, in combination with Clense and the Repair plugin more powerful spatio-temporal denoisers and Deinterlacers can be built.

MaskTools v2
MaskTools is a set of AviSynth filters filters designed to create, manipulate and use masks.

NNEDI3
See above.

The core algorithm of QTGMC is this:
0. Bob the source clip. Temporally smooth the bob to remove shimmer then analyse its motion.
1. More accurately interpolate the source clip (e.g. NNEDI3). Use the motion analysis from previous step to temporally smooth this interpolate with motion compensation. This removes shimmer whilst retaining detail. Resharpen the result to counteract any blurring.
2. A final light temporal smooth to clean the result


The "Preset" used selects sensible settings for a given encoding speed. I drew up a reference table of which settings change according to the preset, with "faster" as the benchmark:

dl.dropbox.com/u/21489814/QTGMC-presets.png

The QTGMC3.11.avsi script itself is very well commented, so much of the explanation and options are covered in there, so I won't repeat them. I haven't really experimented beyond the presets, but I guess it might be possible to achieve a lot of what QTGMC is doing by using custom settings in Handbrake's "Video Filters" fields. But that's not something I'm personally planning to pursue.

It may well be that a major reason for any preference for the output of QTGMC over, for example, TDeint+NNEDI3 or Handbrake's default decomb is simply the sharpening. So it might be worth some experimentation in Handbrake settings to enhance that.

In my tests using single-threaded 32-bit versions of programs, my QTGMC/MeGUI workflow can only match the I420/Handbrake workflow at the "ultra fast" setting. At "faster" setting it takes twice as long. However, enabling some of the programs/plugins in multi-threaded or 64-bit mode should allow slower/higher quality presets to match the I420/Handbrake speed. When I have my quadcore desktop machine back in action I will test that.

Note that retaining all the frames (60p/50p) of the QTGMC output by commenting out the "SelectEven()" line in the AviSynth script gives a stunningly life-like result. I was amazed when I tried that on Stringer's driving clip. Great for offline playback and also possibly, as bandwidths improve, for self-hosted videos where you have control of the framerate. I'm assuming YouTube/Vimeo etc. all limit the framerate to 30p, but I would definitely consider QTGMC 50p/60p if I was using JWPlayer etc., especially at lower resolutions.

One more thing about QTGMC. The author says: "I would advise against source-match/lossless on 1080i material. It will make a difference, but a very small difference at that resolution.

I hope all that helps! Tutorial soon...
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 8:25:44 AM
 
I just noticed an alternative GUI for Handbrake. VidCoder. Discussed here. It's in active development. Developer just released 0.8.2 today. Haven't tried but it seems to be well-liked. Requires .NET Framework 4. Might be worth a look.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 10:10:29 AM
 
WRT the motion blur,

Well, this is interesting. I took the original project and rendered just Stringer's clip to DNxHD and I420, both at project settings, 1080 29.97i. Put both intermediates back on the timeline, and they are indistinguishable both at the frame and field level, as I had expected.

Rendered both clips in Handbrake, using the identical original settings, and they came out the way you illustrated. Seems Handbrake is choosing "Blend" for the I420 clip and a fancier option for the DNxHD. Absolutely no idea why, but I will post the render logs on the HB forum and see if someone knows.

In the meantime, I may have to retract my accolades for I420 as an intermediate to Handbrake, not because there's anything wrong with it, but if I wanted to Blend fields, I could do that just as easily in Vegas.

https://forum.handbrake.fr/viewtopic.php?f=11&t=20249&p=93427#p93427

Actually, I had looked at the lane line in my tests, and noticed that it was smoother with I420, and immediately thought that was a good thing. It goes to show how easy it is to overlook stuff when I get tunnel vision over one particular aspect of the project.

Thanks again, Nick. Looks like our good-natured critiques are keeping us both alert.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 2:16:36 PM
 
UPDATE:
Well, using "5" as the first number in the HB decomb string fixed it, taking "Blend" out of the soup.

5:2:6:9:80:16:16:10:20:20:4:2:50:24:1:-1
dl.dropbox.com/u/20519276/i420noblend.png

Looks like I've got a lot of posts to update, here and at Handbrake. But I'll wait until I see what their devs say about the cause, before editing all of my posts that mention I420.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 9:19:43 PM
 
Latest upload is fixed. Because of the deinterlace problems, I may just leave I420 out of the tutorial and just include DNxHD.

vimeo.com/20190131
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 11:09:33 PM
 
OK guys as usual something went right over my head!~

can you please tell me generally what the best codec/setting to use for:

Vegas SD 16:9 destined for playback on my own website, not youtube (must play on iOS and web)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/27/2011 11:52:32 PM
 
@ JHendrix - I'm not familiar with what will play on iOS but generally I would say AVC (which is the same as H.264). If you have Vegas Pro 10.0 then you can do a pretty good (and fast) job using the Sony AVC codec. Go with a 360x640 or 432x768 resolution (with square pixels), or choose another resolution from here. Base your settings on one of the "internet" templates. Here's the "Internet 640x360-30p" template from 10.0.

dl.dropbox.com/u/21489814/Sony-AVC-internet-640x360-30p-template.png

If your footage is interlaced then set deinterlace method as either interpolate or blend in your project properties. Render a bit with moving footage and see which result you prefer.

That's the easy option. If you want to keep more quality, especially if your footage is interlaced, then you can use one of the more complicated workflows that we've been developing in this thread, involving better deinterlacing/resizing and the superior x264 codec. I'm hoping to publish my tutorial for a MeGUI-based workflow in the next couple of days. Musicvid is also working on a tutorial for a Handbrake-based workflow. The argument for using one of these fancy workflows is stronger if you have an older version of Vegas Pro such as 8.0, which had inferior Sony AVC and MainConcept AVC codecs. I do not know if they were improved at 9.0 or 10.0 as I never bought 9.0.

In any case don't forget to conform your levels to Studio RGB before you upload (which can be done by adding a Sony Levels filter to the video output and choosing the "Computer RGB to Studio RGB" preset).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 3:18:55 AM
 
JHendrix says: "Vegas SD 16:9 destined for playback on my own website,"

Nick Hope says: "If you have Vegas Pro 10.0 then you can do a pretty good (and fast) job using the Sony AVC codec."
First my caveat: This thread has gone places where no man has gone before, and Nick Hope has forgotten more about this subject than I will ever know.

That said, here's my experience. If someone wants to play video from their own website, I've found that rendering to an intermediate (DNxHD or Sony MXF) and then using HandBrake to Deinterlace / Resize the video does a far superior job than rendering directly from Vegas - at bitrates needed to adequately avoid continuous buffering.

Using DNxHD->Handbrake, I've found that I can get an adequate quality 1280x720 resolution with 1.2Mbps which seem to avoid buffering fairly well on today's high bandwidth connections (us musicvid's settings except VBR 2 pass - 1200kbps). Here's the comparisons.

First the Vegas->Sony AVC 1280x720 @ 1142Kbps:

dl.dropbox.com/u/20447760/Sony-1500Kbps.png
Next the Vegas->DNxHD->HandBrake @ 1200Kpbs:

dl.dropbox.com/u/20447760/HandBrake-1200kbps.jpg
You can see further testing here: www.jazzythedog.com/testing/DNxHD/mediaplayers.aspx

Good Luck!
...Jerry

Edit: Just noticed an abnormality. MediaInfo reports 1Mbps for the video produced using the Sony AVC encoder, even though the I set it for 1.2Mbps. Trying a render at 1.5Mbps. Strange.
Edit2: Okay, I rendered at 1.5Mbps and MediaInfo now reports 1142Kbps - close enough. Replaced the screen print above and the test clip in the above link.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 4:29:18 AM
 
I hadn't realised how big the difference is at that low bitrate. I was still thinking in terms of higher bitrates for upload to YouTube/Vimeo.

>> MediaInfo reports 1Mbps for the video produced using the Sony AVC encoder, even though the I set it for 1.2Mbps <<

This will be the same glitch with the Sony AVC encoder that delivered 8Mbps when I set it for 11Mbps.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 9:21:57 AM
 
"Vegas SD 16:9 destined for playback on my own website, not youtube"

EDIT: I just noticed that you said SD. I'll leave my reply (for HD) below intact, but you should be doing 853x480 (1.0 PAR NTSC) at around 1Mbs instead.

So as Jerry has abundantly researched, compression and file size are key to hosting your own video. 1280x720 is a nice size, agreed. DNxHD to Handbrake is a good route, agreed.

As far as bitrate for delivery, I would tend to follow the lead of Vimeo and Youtube, and encode around 2Mbs. This helps the blocking and motion detail more than one would expect.

I came up with my own advanced settings for Handbrake that maximizes compression efficiency at such low bitrates, whether you choose 1, 1.5, or 2 Mbs as your target. The other advantage to Handbrake is you can set the streaming flag in the front panel, rather than having to do it in a separate step as with the encoders in Vegas.

As mentioned in my reply to Ogul above, these settings very closely duplicate Vimeo quality at around 2Mbs. A CRF of 28 is used as a starting point, but YMMWV. You could just as easily use 2 pass VBR and choose your target bitrate or file size in Handbrake.

dl.dropbox.com/u/20519276/HB2Mbs.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 11:31:59 AM
 
"I just noticed that you said SD"
Whoa! I, also, have been so focused on HD, that I overlooked that as well. As such, 1280x720 surely is overkill. 853x480 would be a good choice (or maybe 640x360) and experiment with the bitrate (start with 1Mbps) to get the lowest bitrate you can with acceptable quality. High motion footage will probably require higher bitrate, whereas if you just have a talking head with no transitions, you can probably "go low". Don't forget to check the "Web Optimized" checkbox.

Good Luck!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 11:48:58 AM
 
Jerry, Nick,
Are you both OK with most recent version on Vimeo (untiled4.veg)?
http://vimeo.com/20190131
If so, I will zip it, upload to Jerry, and put the Handbrake tutorial together over spring break.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 12:27:48 PM
 
I'd be interested to see how JHendrix gets on with the Sony AVC settings I mentioned. The result might not be too bad. Depends if he's as insane about quality as we are.

Re. the resolution, encoding boffins are always banging on about keeping resolutions at mod16, or failing that, mod8 etc., which is why I suggested downscaling to 360x640 or 432x768. 853x480 obviously doesn't fit this, but on the flipside there is no resizing going on in the Y direction (assuming he shot 480 lines). Ideally he would try these 3 resolutions out in Vegas and in Handbrake or MeGUI and see which result suits him.

Mark, I'll check out http://vimeo.com/20190131 tomorrow morning. Been engrossed in writing my MeGUI tutorial all day. Hopefully I'll publish it tomorrow.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 12:40:03 PM
 
musicvid, That's quite amazing!!!

This is really picking nits, but the only "thing" I see is a slight stuttering in the moving cars in the stringer clip. I'm sure that's a Vimeo / IE problem as I see the same stutter in all clips. Interesting, the stutter is substantially reduced when viewing it in Chrome.

I downloaded the mp4 and there's absolutely no stutter when viewing in WMP.

Earlier, Nick Hope saw better online performance with Facebook compared to Vimeo. With your permission, I'll upload it to my Facebook account. I think I can configure it for public view - we'll see.

Great Job!
...Jerry

PS: Here's an interesting observation, when I downloaded the clip, the source of the download was http://s3.amazonaws.com/videos.vimeo.com/413/367blah-blah-blah
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 12:43:15 PM
 
I forgot to mention, that when I must encode for 16 macroblocks with SD NTSC widescreen, I encode to 864x480, which is actually 9:5 SAR. The slight stretch is not noticed unless there is a circle in the picture. Some older QT players may need 4x4, and not even the newer ones respect PAR flags afaik.

With modern AVC encoders, conforming to 16x16, 8x8, or 4x4 isn't nearly as important as it used to be, although purists will still say they find pixel inconsistencies at the very edge of the frame.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 12:44:12 PM
 
musicvid,

One more thing. Have you posted this to the Vimeo forums? I don't read them often, but I'd be interested to see what the Vimeo community thinks of your excellent work.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 12:56:11 PM
 
>> I'll upload it to my Facebook account. I think I can configure it for public view - we'll see. <<

Viewers will need a Facebook account to view it in Facebook itself. Only low resolution is allowed in embedded Facebook videos.

>> the source of the download was http://s3.amazonaws.com/videos.vimeo.com/413/367blah-blah-blah <<

That is interesting because I thought Vimeo were using Bit Gravity for their CDN, which is what I thought was the reason for the fantastic buffering speed of their videos. Maybe they just use Amazonaws for the original clips to download. Incidentally I'm using Amazon Cloudfront (the CDN add-on for Amazon S3) for a lot of the media on my website, including the last couple of old videos that I'm self-hosting in JWPlayer. Here's one.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 1:03:36 PM
 
>> With modern AVC encoders, conforming to 16x16, 8x8, or 4x4 isn't nearly as important as it used to be, although purists will still say they find pixel inconsistencies at the very edge of the frame. <<

Just been reading that you can more or less forget about mod8 and mod4 for H.264. They like mod16 and if you can't do mod16 then the important thing is for the resolution to be as few pixels below mod16 as possible. How important this is can only really be determined with some testing.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 10:09:59 PM
 
>> Are you both OK with most recent version on Vimeo (untiled4.veg)?
http://vimeo.com/20190131 <<


Sorry, I think I misunderstood. I thought you were looking for approval of the result of a new upload using that decomb custom command line, but isn't this the same one with the motion blur that I've already looked at? Or are you somehow managing to replace videos under the same Vimeo URL? Or are you looking for approval for the updated veg project? Well, the project's fine, although I must say I enjoyed the version (which, confusingly, I now can't find) with the moving shot of the model. Much as I like Kimberly's ducks, I enjoyed looking at her more :) I guess you took it out because of the framerate difference.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 2/28/2011 10:52:17 PM
 
Nick, if you're still seeing blended fields, the Vimeo server you are accessing probably hasn't updated yet. I have actually replaced the video at that URL three times, and the one I uploaded last night plays decombed, not blended on this side of the planet.
dl.dropbox.com/u/20519276/vimnew.png

As far as the model footage, I can include a smart-rendered clip in the zipped project folder if you can figure out a way to use it. I just couldn't find a satisfactory frame rate conversion. Resampled played the smoothest, but the individual frames were terrible (I'll have to try HB). The full sample video was downloaded here:
av.watch.impress.co.jp/video/avw/docs/408/918/sample.mpg

Anything else, as far as the color tweaks, etc.? If not, I'll consider it a go. BTW, great catch on the frame blending problem.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/1/2011 1:36:13 AM
 
I didn't know that you could replace a Vimeo video at the same URL. I really really really wish you could do that on YouTube. I request it every time their partner suggestions initiative comes up.

The latest version looks fine. I prefer the tweaks you have made to the levels/colours. Looks like you're now keeping the opposite field from your previous version (http://vimeo.com/18690771) and my attempts, which makes it difficult to compare stills on the timeline, but that doesn't matter.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/1/2011 8:11:53 AM
 
I'll upload a version of the new untitled4.veg using DNxHD.
That should sort out any lingering field issues.

I'm about resigned to just making the tutorial using DNxHD anyway.
Probably continue using I420 for my own stuff. I set out to make the tutorial relatively simple to follow, and having to load custom deinterlace settings every time one renders makes it seem counterintuitive.

In any event, I'll upload the new project with media to Jerry's server late this week. I'll include the pretty girl clip.

Since Youtube allows advertising and revenue sharing, I think that is one of the reasons they don't allow swapping videos. It could open up a whole new game for self-promoters (like Richard Heene).

Looking forward to your tutorial. I'm actually thinking about installing MeGUI on my notebook and trying again over spring break to learn it.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/1/2011 10:24:23 PM
 

I've had a chance to preview Nick's tutorial and it is world class. Enough content to massage the inner geek for many moons. Well done Nick, and look for his forum announcement in the coming days.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/2/2011 5:37:26 AM
 
Thanks a lot.

I finally published my tutorial and here is the new thread.

I made a few updates since the version you saw yesterday, so be sure to reload your page. Specifically the resizing in the AviSynth scripts was wrong.

Let's still use this thread to discuss details of the Handbrake workflow, and some of the topics that we've touched on that are not directly related to my tutorial.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 4:54:24 PM
 
OK I am about to start testing based on you suggestions.

only thing i don't get is:

"In any case don't forget to conform your levels to Studio RGB before you upload (which can be done by adding a Sony Levels filter to the video output and choosing the "Computer RGB to Studio RGB" preset)."

so is that only if you are uploading to youtube?

because I actually use Levels on many of my clips and I use this preset to bring in needed contrast.: Studio RGB toComputer RGB
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 6:41:45 PM
 
JHendrix,

To condense everything that has been said about levels sofar:

You must send Youtube, Vimeo, JWPlayer, SMPlayer, GOMPlayer, FLVPlayer, FlashPlayer, and all other Flash-based players 16-235 RGB levels, in order to play back at 0-255 RGB.

This is called "What You See Is What You Get." Simple enough?

www.youtube.com/watch?v=MNSBC8_3vB0

www.youtube.com/watch?v=C4ZqMOnNCfw
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 7:25:33 PM
 
To condense everything that has been said about levels sofar:
You must send Youtube, Vimeo, JWPlayer, SMPlayer, GOMPlayer, FLVPlayer, FlashPlayer, and all other Flash-based players 16-235 RGB levels, in order to play back at 0-255 RGB.


this is when using H.264 codec, right?
but if an RGB codec (photo-jpeg, png) was used, wouldn't rendering to 000-255 be the correct range?

tia
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 8:17:48 PM
 
Rob,
In my initial trials, almost a year ago, I tested over 30 codecs at various settings, and of the ones that were accepted by Youtube, all returned the same results, IOW levels were mapped [16,235]->[0,235] in every single case. See the thread:
Youtube Mangles cRGB
If any of this has changed in the meantime, or if I have missed one that does not follow this behavior, I will be interested in the results of your testing.

Now, taken in the context of this discussion, every YUV intermediate codec tested followed the exact behavior I indicated, though most threw the infamous x264 colorspace bug that has been abundantly documented in other discussions on the internet. This bug can be corrected in the AviSynth command line (refer to Nick's thread), but unfortunately cannot be compensated in Handbrake.

Please see the condensed results contained in my spreadsheet ~55 posts up.

Thanks for your question, and please read the very first post in this thread to see how I have defined this workflow as Vegas->DNxHD->Handbrake, which maintains a REC 709 / YUV space door to door. If you would like to start your own inquiry using Photo JPEG or another RGB codec as an intermediate pathway to x264, or even as an upload candidate for Youtube, feel free and encouraged to do so, maybe in its own thread.
;?)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 9:37:50 PM
 
@ Musicvid - Not sure why you are including GOM Player in the list. It's an offline media player with its own built-in codecs (which you can disable). It doesn't expand levels.

@ JHendrix & robwood - This might help. Rob, I've never heard of png as a video format.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 9:45:42 PM
 
Nick, GOM Player gives exactly the same behavior on my system as the others I listed. 16-235 maps to 0-255. If it doesn't technically fall into the same class as the others (VLC and SMPlayer), the output is the same.

dl.dropbox.com/u/20519276/gomplayer.png
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 10:06:17 PM
 
My computer apparently has special needs. Whatever is messing with the Flash Player plugin is apparently also messing with GOM Player. The key might in overlays. Will follow up in the other thread.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/11/2011 10:10:50 PM
 
Something in me thinks Flash doesn't use the video overlay surface. But I sure could be wrong. In any event, your computer marches to a different drummer. Do you have an older ffdshow installed at the system level by chance? I had to do a cold install to get rid of it.


(PNG is a valid MOV format. Lossless, but s-l-o-w).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/27/2011 11:08:29 AM
 
Jerry,
Your new draft page with all the tutorials and tests is coming along nicely, and is going to be tour de force.

I have already directed one interested individual on the HB forum over to it. Although not a Vegas user, he uses both HB and MeGui for his work.

Even though I need to finish up my video Handbrake tutorial, I don't think it's too early to post a link on the Vegas forum, if you see fit. Your ability to organize all of the divergent branches of the project into one page is remarkable.

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/27/2011 11:24:11 AM
 
Okie Doke, Here's the link - remember this is still a work-in-progress:

www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx

I'm interested in any and all constructive criticism. Particularly, near the bottom, I've listed contributors to this project. If anyone feels they should be included in this list, use this forum to send me a personal e-mail. I certainly don't want to slight anyone.

Enjoy!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/28/2011 3:38:52 PM
 
On a related note, I'm trying to use the DNxHD codec and after downloading the 2.3.2 codec and installing it, I still don't see it listed under the QuickTIme .mov selection. Has anyone else seen this problem?
I'm using Windows 7 Enterprise 64-bit version with Sony Vegas Pro 10.0c? I have a desktop that installed the codec and shows up just fine.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/28/2011 3:57:27 PM
 
"I still don't see it listed under the QuickTIme .mov selection."
Please excuse me if I'm stating the obvious, but you are aware you need to create your own, new custom template?

dl.dropbox.com/u/20447760/DNxHD-Configure.png
The settings for this template are on the project webpage.

Good Luck!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/28/2011 7:09:32 PM
 
Jerry - that's what I missing, thanks for pointing me in the right direction!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/30/2011 6:32:12 AM
 
Okay, here's a question for the group - or maybe specifically for musicvid.

What about 1920x1080 60p? More cameras are beginning to shoot to this format and I'm not able to find a good intermediate render as a source for HandBrake. Neither DNxHD or MXF will allow me to match the 1920x1080 60p project/source clip settings (am I missing something basic here?).

So, I my conclusion is to render using MainConcept AVC/AAC encoder to a high bitrate mp4 and use that as the source for HandBrake.

On the other hand, maybe the way to do this is to let Vegas reduce the fps to 30p, then DNxHD & MXF are options. After all, the end-result will be 1280x720 30p. (although it would be nice to host "action shots" via JW Player at 60p).

So, what's the best practice here?

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/30/2011 9:16:53 AM
 
Jerry,

Select one of the DNxHD Progressive presets, then select 59.940 or type in 60 (depending) in the Vegas custom video tab.

I haven't tried this specifically, but it is how I get true 30p from dslr source and project.
Let me know if it works for you.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/30/2011 9:47:06 AM
 
musicvid,

You are the man! Worked great. Because there was not a 59.94 fps Progressive option in the DNxHD config, I thought it was not allowed. I chose the 1080p 25fps option in the DNxHD config & 59.94 fps in the "Quicktime 7" panel - and it worked like a champ! All the way thru a HandBrake Render @ 59.94 fps.

The following screen capture is for anyone else who needs to solve the same issue:

dl.dropbox.com/u/20447760/DNxHD-1080-60p.png
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/30/2011 10:11:31 AM
 
Did you have to select "Same as Source" frame rate in Handbrake to get that 59.94?

I ask that because not all devices (iPad for one) do not fully support VFR yet, from what I read on the HB forum.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/30/2011 11:46:53 AM
 
"Did you have to select "Same as Source" frame rate in Handbrake to get that 59.94?

I ask that because not all devices (iPad for one) do not fully support VFR yet, from what I read on the HB forum"

Yes, I did select "Same as Source". I'm not sure I understand your comment about VFR, but it's interesting that somehow the Frame Rate got changed from constant to variable in the HandBrake render.

First the DNxHD render:

dl.dropbox.com/u/20447760/MediaInfo-DNxHD-60p.png
Next, the HandBrake render:

dl.dropbox.com/u/20447760/MediaInfo-HandBrake-60p.png
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/30/2011 11:51:46 AM
 
Right, "Same as Source" is variable frame rate (realtime scan). It's been a problem for encoding to some devices (Apple).
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 4/20/2011 12:15:10 PM
 
my project:

1920x1080
29.970
progressive


--


I am a bit confused about DNxHD settings


it has been mentioned "use project settings for DNxHD"


I dont see my project settings as option.

--

also in Vegas i am confused about deinterlace method setting


Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 4/20/2011 12:49:38 PM
 
JHendrix,

Starting with the post 8 posts up, the process is explained (although the question was for 1080 60p rather than 30p). Specifically here's a screenprint.

dl.dropbox.com/u/20447760/DNxHD-1080-30p.png

This might be worth a challenge from others, but I think your deinterlace settings should be set to "none" - no deinterlacing is being done. You're not de-interlacing.

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 4/20/2011 1:05:25 PM
 
"This might be worth a challenge from others, but I think your deinterlace settings should be set to "none" - no deinterlacing is being done. You're not de-interlacing."
Replying to my own post, I've set up a new thread to discuss this here: Resizing on Render

...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 4/20/2011 1:42:33 PM
 
thanks

i look pretty darn good with the setting you suggested. but the mp4 is 60MB for roughly 3 min video?

is that about normal in this workflow or would i be able to reduce that size (assuming in handbrake settings) and keep about the same quality?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 4/20/2011 2:12:21 PM
 
On the HandBrake "Video" tab, you can increase the CQ:RF or decrease the Avg Bitrate to reduce your file size. You will probably have to go thru some trial & error to get the smallest file with the best quality. Hint: start at an RF=30 and reduce from there if you're looking for as small, low bitrate media file.

Good Luck!
...Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 4/20/2011 3:12:40 PM
 
Hint: start at an RF=30 and reduce from there if you're looking for as small, low bitrate media file.

I will give it a shot, I actually had it at the default RF20 and got the 60MB

update:

Looks like RF-25 was the magic number on this clip. Got it down to 22MB

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/24/2011 8:44:38 AM
 
Can someone shed a little more light to how the Constant Quality RF settings compares to the Bitrates I'm used to?

I just rendered a music video at Constant Quality RF: 20 and got a file the size of 60MB and it looks VERY similar to an AVC encode from Vegas at 6000kbps. But that renders file size is 160MB!!!

This is awesome!

Sami
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/24/2011 9:00:30 AM
 
The one disadvantage of Constant Quality is that there is no accurate connection between the CQ setting and conventional variable bitrates, nor can one predict the final average bitrate. The biggest advantage is that it optimizes quality in half the time and more efficiently than conventional vbr.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/24/2011 9:14:00 AM
 

Is there advantage of feeding Vimeo an even higher quality video at CQ RF 15 for example?

So is it a question of giving Vimeo what it needs or giving it the best possible file to do it's own compression from?

I don't mind extra 15 minutes time to encode nor do I mind a filesize of 150MB vs. 60MB.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/24/2011 9:21:41 AM
 
There is not advantage of going below RF 19 for anything. Lots of documentation on the Handbrake forum and wiki.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/24/2011 9:29:44 AM
 
Sami,
Check your email.
;?)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 4:26:49 AM
 
Thanks Musicvid!

So how do I get better quality? I have a video that is full of fades and it looks really bad when compressed. Or is simply impossible to get it to look good when compressed to mp4 for playback on my computer (with CQ RF slider)? Or are you only referring about uploading it to Vimeo or Youtube?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 9:30:56 AM
 
My note about fades applies only to Youtube, and I don't know anything that can be done about that. Uploading higher bitrate, even CBR, doesn't help.

Fades should look fine on your PC after following the Handbrake tutorial.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 10:47:19 AM
 
Nothing you can do about it for YouTube. Time to get creative with the transitions! But unfortunately when you start trying to replace dissolves/fades with anything else, things get cheesy very quickly. Anyone got any suggestions for a classy substitute for a dissolve/fade, that won't generate into a mess of blocks and pixellation on YT?
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 12:48:32 PM
 
Hahaha! I was doing exactly that, getting creative with transitions!

I shot a music video where the lights go on and off every three seconds. It's essentially a fade in and fade out, about 200 of those in the video ;)
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 1:04:03 PM
 
Try it on Vimeo instead. They are much better about blocking in fades.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 1:52:03 PM
 
Yes it's on Vimeo at the moment (private as it's not released yet). It's not bad at all if you look at it without going full screen. Just was wondering if there was anything more that could be done to enhance :) I don't use Youtube that much anymore due to the bad quality.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 2:24:20 PM
 
"Just was wondering if there was anything more that could be done to enhance"
You could always host the video yourself. Click HERE for a 2Mbps version of musicvid's test video.

....Jerry
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 5/25/2011 6:49:22 PM
 
Sami,
You are using RF19, right?
I've not heard many complaints about Vimeo using that upload quality.

But if you really want to immerse yourself in eking out highest quality delivery for the web, Nick's Sony Vegas Pro > Debugmode Frameserver > AviSynth/QTGMC > MeGUI/Nero-AAC/x264 tutorial is here:

www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 6/4/2011 8:28:08 PM
 
Well A. Grandt's revelation that Youtube had fixed the 1/2 resolution bug with 1080i, although welcome news, nearly took the wind out of my sails. Having engaged several others, sometimes annoyingly, in my mission to achieve a high-quality workflow in spite of Youtube, all seemed for naught (I learned that word from Alistair), until I actually uploaded Jerry's original peacock clip AVCHD 1080i) to YT and played it back at 1080p. As you can see, deinterlacing and motion compensation are nothing short of horrid!

dl.dropbox.com/u/20519276/yt1080i.png

Either Nick's or my 720p work easily puts Youtube's processing to shame at any resolution.
You can see the whole ugly mess here (select 1080p and full screen):
dl.dropbox.com/u/20519276/yt1080i.png

So that's the long way around of saying that my tutorial is nearly complete and is going up this week as planned. Disclaimer: The tutorial is going to be announced on the Movie Studio forum, where it will reach its target audience -- those who think you see the zebras at the zoo, and who think REC 709 is the local gym. IOW, not you guys who have scopes and a clue how to use them. But as a step back from Nick's excellent but intricate workflow, it may make for informative (and lightly entertaining) viewing for you informed editors.

Jerry, Stringer, Kimberly, Nick, Alistair, and the many here who contributed indirectly, you are the best!

Now, after a full year of work on this, I've got a couple of spinoff projects to begin work on. Look for the tutorial link here in the coming days.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 6/15/2011 11:13:26 AM
 
Tutorial is up, also posted on the VMS forum.
www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=766645&Replies=0

Thanks to all who contributed to this megathread!

www.youtube.com/watch?v=rWMX5lSvEgY

Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 6/15/2011 1:03:09 PM
 
nice! thx musicvid
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 6/15/2011 8:17:12 PM
 
Nice. Really nice. Sony should pay you for your work. It's really appreciated.

BTW - the dropbox address for the HD Levels chat is "404"
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 6/15/2011 8:32:17 PM
 
Glad you liked it Steve.
As far as Sony paying me, I'm not holding my breath.

Try the url in the video:
dl.dropbox.com/u/20519276/dualgray1.png

Seems to be working now. Dropbox has had some issues from random outages.
The reason this grayscale is tuned for Vegas is it uses 128 as a median, rather than 127 like most of the rest of the world. Put it in the RGB parade in Vegas.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/28/2012 1:22:50 PM
 
Hello,
Sorry to resurrect this thread, but I just found it yesterday!

I use a Sony HDR-HC7 camcorder, which shoots HDV.
I watched tutorial on this link for the "Better" method with Handbrake:
http://www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx

My question is this:
The video says that "HDV can be used without any alterations".
However, the project settings shown near the beginning are for an AVCHD camcorder (1920 x 1080, 29.970 fps).
The video shows:
Full-resolution rendering quality=Best
Deinterlace method=interpolate

I use Vegas 10e, 64-bit, on Windows 7 Pro 64-bit, Core i7 2600K (just built it!!!), and it has a box that says "Adjust source media to better match project or render settings".

See these the default project settings for HDV in Vegas:
http://www.flickr.com/photos/dadu007/7024448075/in/photostream
HDV Default
<a href="http://www.flickr.com/photos/dadu007/7024448075/" title="Default_HDV by dadu007, on Flickr"><img src="http://farm7.staticflickr.com/6044/7024448075_9acee07e7c.jpg" width="357" height="500" alt="Default_HDV"></a>

For the best YouTube quality, do I use these settings unchanged as an HDV user or do I change rendering quality to "Best" and Deinterlace method to "interpolate"?
What about the "Adjust source media..." box? Checked or unchecked?

(One last comment: in Handbrake (0.9.6), with HDV footage, you cannot keep the "Keep aspect ratio" checked in order to end up with a 1280 x 720 resolution.)

Thanks for any answers, and thanks for ALL the research you guys put in to this!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/28/2012 2:59:00 PM
 
prairedogpics,

Let's see if I can help you out.

First, I think I was able to extract your project properties from the flickr paste, and it looks good to me, except that "Full Resolution Rendering Quality" s/b "Best". The tutorial indicates DeInterlace method s/b "Interpolate". The conventional wisdom is that you should use "Interpolate" for fast moving footage, "blend" for slow moving footage. Frankly, I've not seen much difference.

You do not need to check "Adjust source media to better match project or render settings" (you've already matched your project to the source).

Re: the HandBrake issues, you should specify "Anamorphic=none"

dl.dropbox.com/u/20447760/HandBrake-Anamorphic.png

Did that catch all your questions?
...Jerry

btw: nice workstation
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 3/28/2012 4:18:16 PM
 
Yes, you did. Thanks Jerry!

(As for my workstation, it's replacing an 8 or 9-year-old Pentium 4/3.0 GHz machine.
It's a true pleasure to have HDV playback on Best>Full with no hiccups whatsoever! CPUs have come a LONG way...)

Thanks again, Dan
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 6/26/2012 3:03:12 PM
 
I just wanted to extend my thanks to musicvid and everyone who helped with the making of this great workflow.

I've been using the "Better Method" from the tutorials and all I can say is wow!
I've had files that were 8gigs (mov) and after following the steps, it was down to 183 megs with almost no loss. Simply brilliant.

I've posted about 15 video on vimeo using this method all with excellent results.

Thank you!
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 12/5/2013 6:14:09 PM
 
Just found this thread again, and worked through the process. Have to say, the output using Handbrake looked just amazing. Noticeably better than anything else I've encountered.

Some updates:
Vegas 12 has different rendering settings. You'll have to work through them, but using the YT video link here, you should be able to do it.
example: I can only choose a Quicktime 7 3Mbps video setting as the highest setting in Vegas 12 and then change it.
This thread and video is mainly oriented towards 1080i while I have progressive.
My Audio settings default to QDesign Music 2 when I choose this rendering setting. My audio on the first pass was not good quality. I'm assuming it's because I didn't boost the settings in Handbrake to 320bps. I think the default was 160. It did not sound as good as original
I assume that QDesign Music 2 is a decent rendering codec for music?

In handbrake, you must carefully follow the instructions. Height for example, under the Picture tab, when everything is chosen properly, is greyed out but I just went with it, and with all else correct, it was fine.

So follow the instructions. Get the AVID codec and output your *final* video to it (not worth doing before you are done with the film in it's entirety). Once there the instructions here still seem to be working with minor tweaks. Thanks guys. Great work.
Reply   |  Report Abuse
Subject: RE: Vegas to Youtube, Vimeo, Web -- A New Look
Date: 12/5/2013 9:50:30 PM
 
No doubt the tutorial is due for an update, but it'll probably be next summer before I find a block of free time to reassemble the team and work on it.

In order of your points:

1. The default template in Vegas was eliminated, which is a shame because it prematched many of the project settings for you.
2. Progressive video, esp. those not needing resizing are just as well handled door-to-door in Vegas. No real advantage to the extra steps, except when smaller file size is an issue.
3. The important step to choose PCM audio from the QT render settings was initially left out, but is annotated on Youtube. QDesign should not be used, it's horrible.
3a. Handbrake currently has the fdk-aac audio encoder, which is vastly superior to faac, all that was available at the time.
4. Anamorphic=None and checking Keep Aspect exposes all the right controls in Handbrake. You shouldn't use Autocrop for Youtube. They have an excellent Wiki / User Guide on site.
6. Recent Avid LE versions (2.3.8 and 2.3.9) have far more templates, greater stability, and Handbrake (libav) now accepts 10 bit DNxHD, a boon for high-bit Vegas editors.

For now, consider the video tutorial a guide, and adapt to suit your needs. Thanks for gathering some of the important changes in one place. This is not only the 300th post in this thread, the video is right at 25,000 views from all sources.
Reply   |  Report Abuse

Post New Topic Back to Vegas Pro - Video
 
Sony


 
Follow Us Online Facebook Twitter YouTube Email Sign up:  Submit
 
Sony Creative Software inspires artistic expression with its award-winning line of products for digital video, music, DVD, and audio production.

Sound Forge, ACID, and Vegas software have defined digital content creation for a generation of creative professionals, amateurs, and enthusiasts.

© 2003-2014 Sony Creative Software Inc. All Rights Reserved.
Software
ACID Pro
ACID Music Studio
Photo Go
Sound Forge Pro
Sound Forge Audio Studio
Vegas Pro
Vegas Movie Studio
Vegas Movie Studio Platinum
All Software
Royalty-Free Content
Loops & Samples: Premium
Loops & Samples: Standard
Loops & Samples: Classic
All Loops & Samples
Artist Integrated Loops
Sound Effects
Vision Series
All Content
Download
Free Downloads
Trials and Demos
Updates
Manuals
Whitepapers
Utilities
Development Kits
All Downloads
Other
Product Support
Customer Service
Affiliate Program
Register Software
Training & Tutorials
Press Releases
Newsletters
Showcase
Site Map
 
McAfee SECURE sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams Sony.com