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.

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

AVI wrapper does not accept b-frames at all afaik. We are both talking about x264vfw?
Please correct if I'm mistaken.

I think they must have implemented this hack (found via here) to make it work.

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.



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.

Well, that pretty much answers that question. Bottom line: Youtube pretty much sucks when it comes to fades.

TEST 6

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

Rendered (uploaded) file at [url=https://s3.amazonaws.com/bubblevision/YT-Vimeo-Nick-Test6-MeGUI-NNEDI3-TDeint-Lanczos3-CQ197.mp4]
YouTube version at
Vimeo version [url=http://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

AviSource("d:\fs.avi")

ConvertToYV12(matrix="PC.709")

AssumeTFF

interp = nnedi3()

TDeint(order=1,edeint=interp)

LanczosResize(1280,720)

x264 Command Line

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:




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:



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

Vimeo Link

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

http://vimeo.com/20059771

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.

Thanks Fred! I've edited my post with your Vimeo link.

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

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



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.

" . . . 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 (http://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=http://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 http://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 . . .

[i]"but print screen won't copy the videos playing in my media players"[/]I've been using Snagit http://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)

Nick, did you have the

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.

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

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:

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:



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!

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



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.

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

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



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.

"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

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