Log in

View Full Version : Upscale DV footage for use in Blu-ray project


ad25
7th November 2008, 18:07
I am creating a Blu-Ray disc using mostly DVC Pro HD material. Unfortunately, I also have a few segments of NTSC DV footage that I need to include. I am looking for suggestions regarding the method for upscaling the interlaced DV footage. Here is what I am thinking of doing.


AVISource("DVclip.avi")
AssumeBFF()

#Bob to 59.94 fps
LeakKernelBob(0)

#Resize to 1920x1080
Spline64Resize(1920,1080)

#Reinterlace to TFF
SeparateFields()
SelectEvery(4,1,2)
Weave()


My questions are as follows:

1. Is my general approach correct? (i.e. bob, resize, weave) If not, what alternate approach would you suggest?
2. If you do agree with my approach, what would you suggest for the bobber and resizer?

Thanks in advance.

vampiredom
7th November 2008, 19:11
You may want to check this out (something I created):

http://invertedhorn.axspace.com/hd2sd_sd2hd.zip

It contains functions for both HD->SD and SD->HD. In your case, see the sd2hd.txt file for usage instructions and parameters.

ad25
7th November 2008, 19:32
Thanks. I'll try it out.

Sagekilla
7th November 2008, 20:34
Also, if you want very quick and dirty resizing use this:

InterlacedResize(clip clip, int width, int height) {
fields = clip.SeparateFields()
upscaled = fields.Spline16Resize(width,height/2)
frames = upscaled.Weave()
return frames
}


It separates fields into half-frames, then resizes those to the specified resolution and weaves them back together.

Alex_ander
7th November 2008, 22:29
1. Is my general approach correct? (i.e. bob, resize, weave) If not, what alternate approach would you suggest?
2. If you do agree with my approach, what would you suggest for the bobber and resizer?

Your script should work correctly and it's the type I prefer to use myself. A small thing you can improve is color transition from BT601 to BT709 (for SD->HD).

AVISource("DVclip.avi")
LeakKernelBob(order=0)
ColorMatrix(mode="Rec.601->Rec.709")
Spline64Resize(1920,1080)
DoubleWeave().SelectEvery(4,1)#TFF

I removed AssumeBBF, since LeakKernelBob always ignores it (it's 'order=0' it takes field order info from). Its output is BFF independently of anything. The last line for interlacing (= to your 2 lines) inverts that BBF to TFF on interlaced output.

vampiredom
9th November 2008, 07:21
I don't think that LeakkernelBob() or SeparateFields() are very good options here: When you upsample the clip, it will also make jaggies more obvious -- especially if you are using SPline36, Spline64 or another sharp scaler.

If quality is an issue, consider using "smarter" bobbing. Personally, I like the Yadifmod + EEDI2 combination for this (which is the default in the sd2hd() function I posted earlier).

As for scaling, using interpolated methods (TDeint(field=0, mode=-1, type=3) for example) can do a nice job of doubling the resolution. EEDI2 and NNEDI are also good, but slower. Check out this example for scaling 720x480 -> 1920x1080 (assuming progressive input)


TDeint(field=0, mode=-1, type=3) # 720x480 -> 720x960
TDeint(field=0, mode=-1, type=3) # 720x960 -> 720x1920
TurnLeft()
TDeint(field=0, mode=-1, type=3) # 720x1920 -> 1440x1920
TDeint(field=0, mode=-1, type=3) # 720x1920 -> 2880x1920
TurnRight()
Spline36Resize(1920, 1080)


Now, this may be overkill.. but you can instead remove the second and fourth TDeint calls above to achieve 1440x960 and then let Spline36Resize scale it up the rest of the way.

Guest
9th November 2008, 15:04
I removed AssumeBBF, since LeakKernelBob always ignores it (it's 'order=0' it takes field order info from). Its output is BFF independently of anything. The last line for interlacing (= to your 2 lines) inverts that BBF to TFF on interlaced output. LeakKernelBob() outputs progressive video and so it makes no sense to say that it always outputs BFF, and that you have to convert it to TFF.

Gavino
9th November 2008, 20:08
I think what Alex_ander meant was that the output of LeakKernelBob (although progressive) is considered BFF by Avisynth (AssumeBFF has been invoked). Hence a different SelectEvery is required to re-interlace as TFF.

Alex_ander
9th November 2008, 20:50
Yes, I meant it was important to have BFF just before interlacing (not every bob filter will force BFF on output). And in that particular line with DoubleWeave() there even is no combination like SelectEvery(4,x) that would give output TFF from TFF (only inverse order).

Mug Funky
10th November 2008, 01:40
nnedi hasn't been mentioned yet?

it does a fantastic job of uprezzing, and the noisier the footage the more natural it looks.

and yadifmod + nnedi for deinterlacing is quite handy too.

also, NTSC DV needs "reinterpolate411" in it because it's chroma sampling isn't worth arse. i'm not sure where it is, but it should be findable with search (it's a small plugin, like a sideways deinterlacer for chroma).

so something like:

whateversource("NTSC_DV.bla") # make sure output is yuy2
reinterpolate411()

#deinterlacing
edi=last.nnedi(field=-2)
yadifmod(last,-1,mode=1,edeint=edi)

#uprezzing
nnedi(field=1,dh=true) #dh = double-height
converttoyv12()
turnleft()
nnedi(field=1,dh=true)
turnright()

lanczosresize(1920,1080) # you could use limitedsharpen's
# dest_x and dest_y here too, but sometimes that can make edges look quite strange, "painterly" when combined with nnedi

ColorMatrix(mode="Rec.601->Rec.709")

vampiredom
10th November 2008, 01:45
nnedi hasn't been mentioned yet?

I mentioned it, but it is slow. EEDI2 is (nearly?) as good and can be a bit faster with reduced maxd.

also, NTSC DV needs "reinterpolate411" in it because it's chroma sampling isn't worth arse.

That depends on which DV codec you are using.

Also: Why the ConvertToYV12() in the code you posted?

Mug Funky
10th November 2008, 03:05
the converttoyv12 is because there have been issues with turnleft/right in the past with yuy2. i can't remember if they've been fixed, but placing it here in the script does no harm as the vertical resolution has already been doubled. doing it before would be distastrous because it would reduce the input to 4:1:0 sampling, and doing it after would possibly incur turnleft/turnright issues.

btw, nnedi is far superior on natural images. eedi usually needed some kind of protection via masking to prevent noise being misconstrued as edge and causing a weird swirly effect.

vampiredom
10th November 2008, 04:08
Ahhh... Thanks for the info aboot NNEDI. I'll need to check it out more closely. It can be pretty slow, though, no?

It's also interesting what you say about Rotate with YUY2. I really need to test some things out with that, actually. How about keeping chroma as YUY2 and scaling that up conventionally?

#uprezzing
nnedi(field=1,dh=true) #dh = double-height
c = Spline36Resize(1920, 1080)

turnleft()
nnedi(field=0,dh=true, U = false, V = false)
turnright()

Spline36Resize(1920, 1080)
MergeChroma(c)

WorBry
10th November 2008, 05:26
MugFunky.

Quick question about Colour Matrix and Blu-Ray; I have a sizable volume of bob-deinterlaced (50p) PAL DV (16:9 anamorphic) home video footage archived in FFDShow-HuffYuv YV12 format that I`ve started converting to x264 (MeGUI SA-Blu-Ray profile) in readiness for (hopefully) soon purchase of a standalone BR AVCHD player (probably a Sony BDR-S350). The BR AVCHD format permits SD resolution (576), so I`m not doing any (pre) up-scaling. However, I`m now wondering if I should really be converting to Rec.709 before x264 encoding.

@Tron@
18th November 2008, 20:26
#uprezzing
nnedi(field=1,dh=true) #dh = double-height
c = Spline36Resize(1920, 1080)

turnleft()
nnedi(field=0,dh=true, U = false, V = false)
turnright()

Spline36Resize(1920, 1080)
MergeChroma(c)

Hi :)
Tried to do as you wrote but did not get - writes error:"nnedi: height must be mod 2!" only in (nnedi(field=0,dh=true, U = false, V = false)) help fix it

Dark Shikari
18th November 2008, 20:29
Sure, NNEDI is somewhat slow, but if you're making a Blu-ray, you should do it right the first time around.

Mug Funky
19th November 2008, 02:59
@ WorBry:

i haven't done any blu-ray authoring myself, but the only logical way to handle colour as far as i see it is that standard def should stay in 601 land and high-def should be in 709.

standard def is carried through the pipes (SDI) in 601, so encoding as something different would be a waste.

only way to know is to try :) report back :)

it's also possible that it's player-specific - perhaps some players do everything in 709, some might convert, some might even handle upscaling to HD differently to outputting in SD... if blu-ray proves to be anything like DVD there will be a lot of ambiguity among players and a lot of headaches for BD authors.

i know my upscaling DVD player handles the 601 to 709 conversion properly (possibly with a little banding though). i'd assume blu-ray players are the same as most handle regular DVDs as well.

WorBry
19th November 2008, 06:09
Thanks Mug Funky. I'll do some further tests when I actually get the player.