>> 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).

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.

Okay, I loaded musicvid's untitled2.veg in Vegas 10c and rendered using the following settings:


imho, the results were good, but not as good as the Handbrake. Here's a screenprint of my favorite "blocking frame"


...Jerry

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.

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.
http://tech.ebu.ch/docs/techreview/trev_2010-Q3_loudness_Camerer.pdf
http://tech.ebu.ch/docs/r/r128.pdf
http://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.

"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.

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!

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.

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 . . .

"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. Strange, I'm not experiencing this quirk.

...Jerry

"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.

Thanks for the kind words, John. With your tech brain and blockbusters like the original "Rendertest HDV" thread, I'm indebted.

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.

"Vegas render from "Untitled2.veg" to DNxHD Intermediate: 16:59 min.

So my assumption that the total render times, even though they involve an extra step, are about the same. Good to know.

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.

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.

"Do any of you have these x264 files playing in WMP?"I have no problems with any x264 / h.264 playback in WMP.


...Jerry

PS: If I may make an editorial comment, "Damn the laptop, your girlfriend has priority!!"

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.

"Jerry, where is that WMP output from?"Launch WMP, Help->"About Windows Media Player"->"Technical Support Information"

...Jerry

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 ;?(

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.

"Can't work out why my WMP on my laptop won't display H.264"FFDShow/Haali Media Splitter?

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

...Jerry