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

# 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

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

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

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

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

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



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!

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:

...

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.

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

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.

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

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.

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.

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.

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

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

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.

http://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.
;?)

As it appears from watching the video, I420 is sharper than DNxHD 145.

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.

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

@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

WRT Test 14 -- Very crisp!

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

The current tutorial is here:
http://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.

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 [url=http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=684155].

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.

>> 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:
1080p original png file

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



YouTube are not discarding any lines from 720p uploads:

720p test:
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:

The interesting part is in comparing the 720p version encoded from that 1080p (Test 17 - against the 720p version encoded from the equivalent 720p upload (Test 14 - 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.

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.