...looking forward to.....???

John, the web video guide is still the same as it was. I will re-address it when I finally fix my quadcore and embark on multi-threaded QTGMC experimentation myself, as opposed to reporting what others have found. My levels article needs to be updated in light of what I've learned about camera levels. The 1080i-to-DVD method is rather left hanging, but I'll get around to finalising it. Hopefully I'll collect all these together on a new index page eventually.

Apart from the multi-threading aspect, one thing I think you are doing differently to me for web video is to frameserve in YUY2. I recall you started doing that because SET's multi-threaded build of AviSynth 2.6 would not read RGB24. Debugmode Frameserver uses Rec601 to map levels to YUY2 from Vegas' internal RGB. This results in (with apologies to any purists reading) a levels "squeeze". In the case of footage from your FX1, this is fine for bringing the highlights into legal range, but will take your blacks up from 16 to around 30. I have a feeling you're not putting that right anywhere, and so the blacks end up back at around 16 and not 0 when played back on YouTube etc.. And if you do reverse it with a ColorYUV statement (or whatever) later in the script, some information will have been lost as the dynamic range was squeezed and then unsqueezed.

So, one thing I think you might be able to improve is to frameserve out in RGB32 (which you said that version of AviSynth will read), and then to convert to YUY2 or YV12 in AviSynth with a "matrix" option that retains the full range of levels. The only concern is that you told me that RGB32 cuts performance in half. Don't know why that would be but it might still be an issue if you have to use RGB32.

For 720p web output

#Frameserve in RGB24 if possible. SET's MT 2.6 build may require RGB32

AviSource("d:\fs.avi")

ConvertToYV12(interlaced=true, matrix="PC.709")

#ConvertToYUY2(interlaced=true, matrix="PC.709") #Alternative to above line. May be slower

# ...etc...

For SD DVD output

#Frameserve in RGB24 if possible. SET's MT 2.6 build may require RGB32

AviSource("d:\fs.avi")

ConvertToYUY2(interlaced=true, matrix="PC.601") #YV12 gives chroma error with interlaced output

#...etc...

Nick,
Thanks for all your work on this. .

The thing that concerns me is something John and I have discussed over the last years and the developers notes for MVTools mentions this problem:

Of course, the motion estimation and compensation is not ideal and precise. In some complex cases (video with fading, ultra-fast motion, or periodic structures) the motion estimation may be completely wrong, and compensated frame will be blocky and (or) ugly. Severe difficulty is also due to objects mutual screening (occlusion) or reverse opening.

Just how likely that is to bite you with your footage I have no idea. I've slept on some thoughts about this, I had an idea that maybe there's some way the code could detect that estimation has lost the plot (high SAD values) and switch to an alternate method for a few frames but my idea I think is not going to work at all due to lots of false positives I think, darn.
Having to check the outcome frame by frame would be quite a task if you've got a lot of footage but I can think of no way to get MVTools to even flag frame sequences that could be problematic.

Bob.

Well yes Bob, it is possible that MVTools will make some interpolation errors and it will. I'm not going to go through the output frame by frame but I'll certainly be watching a DVD very carefully in real time to make sure nothing nasty happens. Based on what I've tried so far, this process is so far ahead of the old Vegas blend method that I'm willing to allow it a few glitches. Problem parts could always be manually patched with some footage done the old way. There are also slower presets for QTGMC which could help if things don't work right.

Nick,

Thanks for all the work you did on this. While I rarely do this conversion, the next time I do I will try it instead of using Procoder 3. Either way your work is truly appreciated.

John

"Based on what I've tried so far, this process is so far ahead of the old Vegas blend method that I'm willing to allow it a few glitches. "

That wouldn't be hard, the "old" Vegas method was good for the money at the time. With V10 and OFX we have more options though that are worth exploring.
The YADIF plugin is great but not relevant to your current quest.
Then there's Speedo, that is relevant. I should get back to testing it. Last look it seems way less prone to problems that AE's native time remapping. I haven't compared it to MVTools. The devs said something that leads me to believe it can detect that it should give up on using motion vectors and use an alternate method.
Speedo is slow and it sure will cost knowing GenArts.

Bob.

Ah, I'd forgotten about Speedo. It will be interesting to see what that can do. I've managed to resist the beta test so far

In the meantime, here's my script for converting 1080-50i to SD NTSC-for-DVD. I did a minute of some pretty challenging footage and the quality is flawless. I can't see any interpolation errors at all. In fact it might even look better than 1080-60i-to-NTSC, which might be due to some extra degree of "low pass filtering" as a by-product of the retiming. Anyway, it's a keeper.

1080-50i to SD NTSC

#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)



AviSource("d:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="PC.601")



Spline36Resize(720,height)

QTGMC("faster", sharpness=0, SubPel=2) #SubPel must match pel in MSuper below

super = MSuper(levels=1, pel=2)

MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)

Spline36Resize(width,480)



blur(0.0,1.0)

sharpen(0.0,0.75) #Adjust 2nd value between 0.5 and 1.0 to taste



separatefields()

SelectEvery(4,0,3)

Weave()

The interpolation error issue is an interesting question. I have processed a huge amount of footage through MVTools and the newer MVTools2. I've done slow motion, fps changes, dropped frame reconstruction (see my latest script for this over at doom9.org), denoising, etc.

What I have found is that, not surprisingly, the bigger the "jump" between adjacent frames (or fields, when doing interlaced video), the higher the likelihood of getting a really bad glitch in the resulting video. But here's the key point for this discussion: if you look at how "far" the video must be interpolated when going from 50 fields a second to 59.94, nothing has to move too much or too far compared, for instance, what it takes to interpolate new frames going from a 15 fps cell phone video to 59.97 fields per second.

As always, if you are looking for trouble (and that describes me ...), the place to look is where you have objects that cross each other in opposition (e.g., two people walking in opposite directions, pass each other in front of the camera). Pans past vertical objects (like picket fences) can produce some really wild results. And finally, always look at video of people walking past the camera. Watch their legs. The "structures" in the legs move in opposition to the general motion as the leg goes back, even as the person moves forwards, and the motion estimation often gets fooled.

Nick,

Just wanted to tell you how much I appreciate the fantastic results I got using your script. I got some excellent quality PAL video footage, but needed to put it on a NTSC DVD. I got near-perfect results using your script. I didn't know a standards conversion could look this good.

Thanks!!

Nick,

If you have a Sony HVR-Z1P, why don't you just shoot in 1080-60i instead of 1080-50i?

Or does the conversion produce better results?

John

John M, glad it worked out well! I didn't know a standards conversion could be that good either.

John (craftech), I think I will generally shoot 1080-60i from any new territories that I visit in the future. In the meantime I have a huge archive of existing footage, and it's split between PAL DV, 1080-50i HDV, and 1080-60i HDV. I don't think that the conversion produces better results, but I suppose in some bizarre sort of way it might help with typical HD>SD conversion artefacts. I doubt I would recommend it for that though!

That makes sense Nick.

Thanks for the follow-up.

Regards,

John

For the sake of completeness, here's a script for high quality conversion from 1080-50i to 1080-60i. i.e. No rescaling. Just resampling the frame rate. Someone might want to do this if they are mixing footage from two different framerates, or if they want to make a 60i Blu-ray that should be more compatible on players/TVs worldwide than a 50i one.

1080-50i to 1080-60i

#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)

AviSource("d:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="Rec601") #Rec601 is correct for encoding Ut Video Codec or Lagarith in Vdub



QTGMC("faster", SubPel=2) #SubPel must match pel in MSuper below

super = MSuper(levels=1, pel=2)

#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) #For very fast and quicker QTGMC presets

MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)



separatefields()

SelectEvery(4,0,3)

Weave()

Great discussion. Do not know if we have here something - but is there also some experience with the conversion 1080 50i/60i to 1080 24p?

At the monetn I'm trying out Speedo from GenArts for converting 29.970p to 25p.

Render times are HUGE but initial tests are looking good on quite bad foootage.
It seems pretty simple to use, just dial in source and required destination frame rates and render to target.

It is also nice and a pleasant change that we get a 12 months fully featured trial of this plugin.

Bob.

Good question Wolfgang! Here you are. Only tested briefly. This is for 23.976p. For true 24p use num=24, den=1. Now I'm wondering if this might be better than 1080-60i output to put on an internationally compatible Blu-ray derived from 50i or a mixture of 50i/60i.

1080-50i or 1080-60i to 1080-24p (23.976p)

#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)

AviSource("d:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="Rec601") #Rec601 is correct for encoding Ut Video Codec or Lagarith in Vdub



QTGMC("faster", SubPel=2) #SubPel must match pel in MSuper below

super = MSuper(levels=1, pel=2)

#super = MSuper(levels=1, pel=2, hpad=16, vpad=16) #For very fast and quicker QTGMC presets

MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=24000, den=1001)

That script and the previous ones in this thread are written for single-threaded use. Multi-threaded use of AviSynth/QTGMC is documented here. For anyone delving into multi-threading, I'm getting good stability with SEt's Avisynth 2.6 MT version 2011.09.13, QTGMC 3.32, and -Vit-'s updated modded plugins package from the first post of his QTGMC thread.

I've tested the last 2 scripts I posted a little more and found that for encoding Lagarith or Ut Video Codec in VirtualDub, and then bringing that file back into Vegas, the matrix needs to be Rec601, not Rec709, even though it's HD to HD. That's my most likely scenario so I've corrected both scripts above. But note that might not be right if you're taking the output of the AviSynth script into another program to render, or even back into Vegas. Always check against the original, preferably with color bars and scopes.

Any idea of why this error shows up

“Avisynth open failure
mt_lutxy: Unsupported colorspace, masktools only support (YV12,YV16,YV24)”
("C:\AviSynth\AVSFiles\QTGMC-3.32.avsi") line 395

===================================================
#1080-50i to 1080-60i
#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)
Import("C:\AviSynth\AVSFiles\QTGMC-3.32.avsi")

source=AviSource("C:\AviSynth\fs.avi").assumetff()
#fs.avi Timeline standard m2t PAL HDV file from tape source

#AssumeTFF()
ConvertToYUY2(source, interlaced=true, matrix="Rec601")
#Rec601 is correct for encoding Ut Video Codec or Lagarith in Vdub
QTGMC("faster", SubPel=2) #SubPel must match pel in MSuper below

==================================================

It would appear that ConvertToYUY2(,,,) is not outputting to the correct colorspace.

Geoff

Geoff, if you are using mt_masktools-26.dll then maybe try the older mt_masktools-25.dll. See this post. See the first post of that thread for the versions of AviSynth and all the plugins that the QTGMC author -Vit- is now recommending for multi-threaded use. They are working well for me.