Interlaced HD to DVD AGAIN - some test renders

Comments

PeterDuke wrote on 7/8/2011, 5:39 PM
"Now that I have BD player, I've started practicing with BD format material on DVD-RW disks. The disks play fine on my new BD player; not sure about other players."

You are lucky that you are able to play BD on DVD. Not all BD players will do that and some are picky about the precise format. For instance, BD on DVD created with DVDA requires patching before it will play on my BD player, yet several other applications will create playable discs directly.
bsuratt wrote on 7/8/2011, 8:04 PM
"How does it look on CRT and did you burn the latest DVD to compare?"

I have not tried CRT as yet.
My video source material is about the worst case for downscaling... water skiers on an elliptical course. I have millions of riplets in the water, multiple ropes, horizontal and at every conceivable angle, fast movement of many objects. Downscaling produced a "shaggy" picture with artifacts all over. Water looks like fluff, ropes jagged and with diagonal lines through them. And this is viewing the DVD on a Sony XBR LCD!

VirtualDub with smartdeinterlace, Lanzcos resize, sharpen filters, produced progressive output which except for a bit of judder, was very clean. Your script brings me back to interlaced output with none of the perceived jumpiness and an extremely clean picture. I will next take a look at CRT but I first needed to get the DVD looking good on an LCD,

It's such a shame that NO NLE mfg has taken this problem seriously and even more that the problem can be solved with FREE software. What a sorry state of affairs!
NickHope wrote on 7/9/2011, 12:19 AM
musicvid wrote: >> You are smart-bobbing to 60p, then using those frames after downsizing to recreate new fields for 60i (29.97) output, is that right? At least that makes sense. <<

Is correct, with a blur>sharpen sequence thrown in as well.

@Kimberley: I should probably do another tutorial soon, but in the meantime you can follow my web tutorial to learn about and install Debugmode Framserver and AviSynth. Ignore all the part about MeGUI/x264/NeroAAC and use your MPEG2 encoder instead. If that is Vegas, there are instructions here about how to get the video back into a 2nd instance of Vegas for rendering.

@craftech: I took a look and again am struggling to see differences in the 4 renders, but my DVD viewing options here are limited. A 40 inch Samsung LCD that spent a couple of years displaying chicken and fries ads in the local KFC, and a Samsung CRT TV which is pretty small, especially after letterboxing.

Incidentally I read somewhere (I think on these forums) that CRT TV production has now stopped. Well, not here in Bangkok. Yesterday I looked in Tescos and there were LOADS of CRT TVs on sale from LG, Samsung, Sharp etc..
craftech wrote on 7/9/2011, 4:42 AM
Incidentally I read somewhere (I think on these forums) that CRT TV production has now stopped. Well, not here in Bangkok. Yesterday I looked in Tescos and there were LOADS of CRT TVs on sale from LG, Samsung, Sharp etc..
=====================
I don't disagree that they are slowly disappearing especially in the US, but is everyone throwing them away that buys event DVDs? I already know the answer.

No.

Several TVs in the home. The newest are usually HDTVs But if they have four TVs in the house, they often keep the CRT sets.

I just finished that Dance Recital that I used a clip from in those last three downloads I provided. The Dance Studio has it playing for the parents in the waiting room on a CRT. So for additional sales, those watching it are watching it and deciding base upon how it looks on the studio's CRT TV.

John

craftech wrote on 7/9/2011, 4:52 AM
I have not tried CRT as yet.
=================
Wow!

I'd really like to see how those scripts handle that stuff on a CRT. Has to be in a league with Jerry's Hula Doll Horror Video.

John
bsuratt wrote on 7/9/2011, 6:24 AM
As soon as I get past my current crunch I will upload a DVD iso with comparative clips.
Kimberly wrote on 7/10/2011, 10:05 AM
@craftech, Nick, and others ~

Thanks for the step-by-step instructions! I'm reading up on AVIsynth and scripts so will give it a try very soon.

Regards,

Kimberly
musicvid10 wrote on 7/10/2011, 10:34 AM
"Is correct, with a blur>sharpen sequence thrown in as well."

Good.
Glad I understand at least a little bit of what's going on here. Where would this world be without neuron2
;?)
diverG wrote on 7/11/2011, 6:38 AM
@Nick/Musicvid

Having a senior moment here.

Loaded avisynth & debugmode and a valid script. Fire up VP10 and render out via debug. Nothing happens until I open WMP and select the fs.avi file. At this point the file is rendered out frame by frame & looks OK.. Likewise I can run fs.avi in a second instance of VP10 instead of WMP.

Question: How can I recreate a file that can input to say DVDA for burning.?

Thanks for your patience.

Geoff

Sys 1 Gig Z-890-UD, i9 285K @ 3.7 Ghz 64gb ram, 250gb SSD system, Plus 2x2Tb m2,  GTX 4060 ti, BMIP4k video out. Vegas 19 & 122(194), Edius 8.3WG and DVResolve19 Studio. Win 11 Pro. Latest graphic drivers.

Sys 2 Laptop 'Clevo' i7 6700K @ 3.0ghz, 16gb ram, 250gb SSd + 2Tb hdd,   nvidia 940 M graphics. VP17, Plus Edius 8WG Win 10 Pro (22H2) Resolve18

 

NickHope wrote on 7/11/2011, 7:14 AM
Geoff, think of AviSynth as another frameserver, but one that can do processing along the way. The AviSynth script opens the framserved avi file (e.g. "fs.avi"), and the MPEG-2 compression program in turn opens the AviSynth script. So for example you need to actually open "script.avs", not "fs.avi", in the compression program, assuming it supports direct opening of AviSynth scripts. In the case of CCE Basic, Procoder or TMPGenc, they do, but Vegas will not, so you either need to render to a lossless intermediate (e.g. Lagarith, in Virtualdub), then load that into Vegas, or use the Vfapi converter program (yet another converter/frameserver) to load the output of AviSynth back into a 2nd instance of Vegas. You can adapt the instructions here to learn how to do that.
diverG wrote on 7/13/2011, 5:26 AM
As I said ‘Senior Moments’.

Great write up. Clearly I need to do a lot more reading. Some of the scripts are reporting errors but maybe my media is at fault. For example ‘YUV requires YUV input’. I'm starting with HDV (m2t) . Certainly not typo’s as I cut & pasted the . PAL land may also be part of the problem. Took a while whilst I located the TDeint function. However I can now go from VP10 via VirtualDub to create the new files.

Geoff

Sys 1 Gig Z-890-UD, i9 285K @ 3.7 Ghz 64gb ram, 250gb SSD system, Plus 2x2Tb m2,  GTX 4060 ti, BMIP4k video out. Vegas 19 & 122(194), Edius 8.3WG and DVResolve19 Studio. Win 11 Pro. Latest graphic drivers.

Sys 2 Laptop 'Clevo' i7 6700K @ 3.0ghz, 16gb ram, 250gb SSd + 2Tb hdd,   nvidia 940 M graphics. VP17, Plus Edius 8WG Win 10 Pro (22H2) Resolve18

 

NickHope wrote on 7/13/2011, 6:34 AM
I am also starting with HDV in both 60i and 50i flavours so that shouldn't be the problem. The typical method I am using is to frameserve out of Vegas in RGB24 format. The AviSynth script should accept that and then convert it to YUY2. I'm wondering at what point exactly you're getting that YUV error message.
craftech wrote on 7/13/2011, 7:03 AM
Some of the scripts are reporting errors but maybe my media is at fault. For example ‘YUV requires YUV input’.

That's not in Nick's simplified script Geoff.

If you are referring to the script with this line:

ColorYUV(levels="TV->PC")

That script requires that you frameserve from Vegas in YUY2 not RGB 24.

If that's not the problem state which scripts you are using and the error messages.

John
diverG wrote on 7/13/2011, 7:12 AM
1st post script for Test 3

#ColorYUV(levels="TV->PC") #Expands levels if frameserved in YUY2
AssumeTFF
TDeint(mode=1)

error
Avisynth open failure
TDeint: YV12 and YUY2 data only!
\Framserved in YUY2.avs line12

Pretty sure fault is at my end.

Sys 1 Gig Z-890-UD, i9 285K @ 3.7 Ghz 64gb ram, 250gb SSD system, Plus 2x2Tb m2,  GTX 4060 ti, BMIP4k video out. Vegas 19 & 122(194), Edius 8.3WG and DVResolve19 Studio. Win 11 Pro. Latest graphic drivers.

Sys 2 Laptop 'Clevo' i7 6700K @ 3.0ghz, 16gb ram, 250gb SSd + 2Tb hdd,   nvidia 940 M graphics. VP17, Plus Edius 8WG Win 10 Pro (22H2) Resolve18

 

NickHope wrote on 7/13/2011, 9:15 AM
The script in the first post, test 3, does not support RGB frameserving, only YUY2.

Better to use the script in my post of 7/7/2011 7:23:33 PM, and frameserve in RGB. The script (instead of the frameserver) does the conversion to YUY2 and retains the full range of levels.
diverG wrote on 7/13/2011, 11:49 AM
Found script 7/7/2011 1:23:33 PM not at 7/7/2011 7:23:33
Time zones?

Ran it via virtualdbub yields Extra wide screen

Project Properties (from virtual dub file output file)
Template: custom (720 x 240, 100.00fps)
par: 1 (square)

Geoff

Sys 1 Gig Z-890-UD, i9 285K @ 3.7 Ghz 64gb ram, 250gb SSD system, Plus 2x2Tb m2,  GTX 4060 ti, BMIP4k video out. Vegas 19 & 122(194), Edius 8.3WG and DVResolve19 Studio. Win 11 Pro. Latest graphic drivers.

Sys 2 Laptop 'Clevo' i7 6700K @ 3.0ghz, 16gb ram, 250gb SSd + 2Tb hdd,   nvidia 940 M graphics. VP17, Plus Edius 8WG Win 10 Pro (22H2) Resolve18

 

johnmeyer wrote on 7/14/2011, 3:08 PM
I just had reason to re-visit this topic, and ended up re-doing many of the tests that John & Nick have done, but using my own HDV video. The bottom line is that Nick's 7/7/11 (I like that numerology) script produced some very excellent results.

However -- and this is the reason for posting -- I actually got slightly better detail, while still killing some horrendous line twitter (which is the reason I re-did all the tests) by using a script that I posted in one of the threads which preceded this one.

and Nick also posted near the beginning of the this thread

The script is something I picked up over at doom9.org, and only modified it to add a slight sharpening (something that took me half an hour to add because I forgot that the AVISynth "sharpen" command only works on progressive video and wrecks havoc if you apply it directly to interlaced footage).

The script below tested about 20% faster than Nick's script (70 fps vs. 58 fps, multithreaded) using AVISynth 2.5.8 MT.

So, here is one more script for you to put in your "HD to DVD" bag of tricks.

#Re-size function
#Serve out of Vegas using RGB24, and use 2.5.8.5 MT AVISynth (8/16/2009 version)

SetMTMode(5,0)
source=AVISource("e:\frameserver.avi").assumetff()
SetMTMode(2)

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

IResize(colorcorrected,704,480)
#IResize(source,720,480)

# Use this level shift, if needed with MainConcept MPEG-2 encoder
#Levels(16, 1, 235, 0, 255, coring=false)

function IResize(clip Clip, int NewWidth, int NewHeight) {
Clip
SeparateFields()
Shift=(GetParity() ? -0.25 : 0.25) * (Height()/Float(NewHeight/2)-1.0)
E = SelectEven().Spline36resize(NewWidth, NewHeight/2, 0, Shift)
O = SelectOdd( ).Spline36resize(NewWidth, NewHeight/2, 0, -Shift)
Ec = SelectEven().Spline36Resize(NewWidth, NewHeight/2, 0, 2*Shift)
Oc = SelectOdd( ).Spline36Resize(NewWidth, NewHeight/2, 0, -2*shift)
Interleave(E, O)
IsYV12() ? MergeChroma(Interleave(Ec, Oc)) : Last

#Next line is optional
sharpen(0,.5) # Adjust 2nd value between 0.5 and 1.0 to taste

Weave()
}
NickHope wrote on 7/15/2011, 2:54 AM
Yes, that's effectively the same as the original "Test 2", but with a bit of added sharpening. The "Test 3" method that we have been developing was generally preferred, but that preference was definitely influenced by the challenging nature of the Belle Nuit test chart and Jerry's hula doll clip. In the real world this Test 2 method may be fine or even preferable.

For anyone into AviSynth, SEt has just released a new multi-threaded build of AviSynth 2.6, based on the CVS version of AviSynth which is newer than 2.6 alpha 3. See here. Should in theory be a good bet for stability with QTGMC etc., and should contain tons of fixes/updates since the various other MT versions which are based on sources that are a couple of years old.
craftech wrote on 7/15/2011, 5:33 AM
John,

In Test 2 that script used source video frameserved to it in YUY2. Your modification of that script uses an RGB24 source and has the script itself convert it to YUY2.

Why is that preferrable?

John
NickHope wrote on 7/15/2011, 5:56 AM
The Debugmode Frameserver uses Rec601 coefficients to convert from Vegas' internal RGB format to YUY2. This means that 0 is mapped to 16 and 255 is mapped to 235. Then we had to stretch that colorspace back to 0-255 by using ColorYUV(levels="TV->PC"). So actually we lost a bit of quality as the dynamic range was temporarily reduced from [0-255] to [16-235] and then back.

Now, if we frameserve in RGB, the Frameserver does no conversion since RGB is the format that Vegas uses internally. Then by using the option matrix="PC.601" when we convert to YUY2 (which the plugins require), we can retain the full dynamic range because 0 is mapped straight to 0 and 255 is mapped to 255, and therefore we retain more quality.

Note that the default for ConvertToYUY2 is actually matrix="Rec601", which we don't want because it does the lossy "squeeze", same as the Frameserver does.

But to add another level of confusion, if we are frameserving footage that already uses the full 0-255 colorspace (e.g. footage from most stills cameras), and hasn't been conformed to 16-235 on the timeline, then we might actually want the "squeeze", in which case frameserving in YUY2 or converting with matrix="Rec601" is the right thing to do.
craftech wrote on 7/15/2011, 6:16 AM
Thanks Nick.

John
johnmeyer wrote on 7/15/2011, 10:34 AM
The "Test 3" method that we have been developing was generally preferred, but that preference was definitely influenced by the challenging nature of the Belle Nuit test chart and Jerry's hula doll clip. In the real world this Test 2 method may be fine or even preferable.I had meant to mention this in my post above. That doll test was almost a pathological test and was useful to help push everyone towards understanding all the subtle problems that need to be addressed when resizing interlaced video. However, it also meant that some of the solutions ended up reducing sharpness a tad too much in order to kill all that horrific twitter in the cloth behind the doll.

I have uploaded a small (32 MB) package of test files: my original HDV m2t from my FX1; an MPEG-2 created with Nick's 7/7/11 script; an MPEG-2 created with the IResize script I posted above; and an MPEG-2, also using IResize, but serving out of Vegas using YUY2 instead of RGB. I have included a Vegas 8.0c VEG file which puts these clips on a 1440x1080 timeline so you can A/B/C between them. You cannot really tell too much about jaggies and twitter unless you burn a DVD and watch on a real TV (the Vegas display is progressive and will show jaggie lines where none in fact exist on an interlaced display). What you will see is that the two scripts do a similar job killing the line twitter on the garage doors as the camera zooms in (Nick's does a slightly better job). However, the IResize seems to me to have definite edge in sharpness.

Here's a link to the upload:

Test package


In Test 2 that script used source video frameserved to it in YUY2. Your modification of that script uses an RGB24 source and has the script itself convert it to YUY2. Why is that preferrable?The YUY2 chain introduces a subtle, but important color shift. If you download the test package posted above, and A/B between the two IResize results, look at the white garage door and note that the result created by serving YUY2 out of Vegas has a definite reddish-pink hue that is not present in the original. The two results, with Nick's script and the IResize script that were both created by serving out of Vegas in RGB24, do not have this shift.

I have tried every trick I can think of, including the various "601" and other corrections, and have found nothing that will eliminate this. So, I always try to serve out of Vegas using RGB24.
NickHope wrote on 7/16/2011, 12:19 AM
First of all, I am also getting a slight shift towards pink on that garage door if I frameserve in YUY2, although it doesn't look quite as severe as the shift that you are getting. Anyway I think we're all agreed it's best to avoid frameserving in YUY2 for that reason and the reason in my previous post.

John M, I'm not sure why you've gone back to rendering to 704x480. I know it's a valid resolution and I know it makes the aspect ratio exact, but it seems to create problems in some playback scenarios, such as Laurence found when playing that resolution back in WMP. If doing that, it seems like a good idea to pad it down the sides to 720x480. I've done some testing here with your weightlifting clip, but my regular MPEG-2 encoder, CCE Basic, won't even encode to 704x480, so I've decided to stick with 720x480 to keep the number of variables managable.

On the weightlifting clip the output of my 7/7/11 script is a pretty close match with the original IResize script (with no sharpening). So naturally if you then add 0.5 vertical sharpening, the output of the IResize script is going to be sharper. To try and match it with the 7/7/11 script I first tried increasing the single vertical sharpen to 1.0, which is the maximum value allowed, but that wasn't enough. I found I needed a 2nd instance of sharpen. In the end I found that the following puts it roughly in same ballpark.

blur(0.0,1.0)
sharpen(0.0,0.5)
sharpen(0.0,1.0)


However the character is slightly different. The ringing/halos seem narrower than on the IResize-sharpen render, and there seems to be more perceived detail. Not sure if those are necessarily good things in terms of CRT playback though.

My conclusion is that both are valid alternatives, and sharpening can be tweaked in either script to give a good result.
diverG wrote on 7/20/2011, 7:41 AM
First of all thanks for an interesting topic. Your tutorial and the doom9 forum were most informative.
Once I’d got my head round the workflow I had no trouble working with avs files. I ‘m in PAL land so have altered the test scripts to 72 x 576 to match. Used HCgui and TMPEG 4xpress as the encoders on XP. Could not find a legal copy of CCE basic.
I then switched over to W7 and downloaded a trial of TMPEG 5. ( It was easier than uninstalling from XP). For some reason TMPEG did not like Spline36*** with PAL sizing but was fine accepting 704 X 560 followed by addborders(8,8,8,8). No real logic for this other than your NTSC script ran so concluded there was a problem with 720X576. The black border is well outside the safe viewing area.
Not problems at all the IResize methods.
All the NTSC sized scripts worked with TMPEG 5

Geoff

Sys 1 Gig Z-890-UD, i9 285K @ 3.7 Ghz 64gb ram, 250gb SSD system, Plus 2x2Tb m2,  GTX 4060 ti, BMIP4k video out. Vegas 19 & 122(194), Edius 8.3WG and DVResolve19 Studio. Win 11 Pro. Latest graphic drivers.

Sys 2 Laptop 'Clevo' i7 6700K @ 3.0ghz, 16gb ram, 250gb SSd + 2Tb hdd,   nvidia 940 M graphics. VP17, Plus Edius 8WG Win 10 Pro (22H2) Resolve18