Converting HDV footage to DVD

[stooky]

Hi!
I am the owner of a HV30 HDV-Camcorder!
Because i don't own a Bluray burner yet, I want to convert the footage to DVD with the best quality possible.
Therefore I have written a Avisynth script, which I load into HC Encoder. Source is the frame-served *.m2t footage (used DebugMode frameserver).

This is the script i use until now:
AVISource("C:\...\frameserve.avi",audio=false)
ConvertToYV12()
FieldDeinterlace()
BicubicResize(720,576,0,0.5)

Up to now, I'm not very satisfied with the result, as the motion scenes don't look very good... I think there could be an improvement by changing the deinterlace filter? The result also could be a bit sharper...
What do you think about the script?

Here is the link to the original footage:
http://rapidshare.com/files/159927311/test-2008_10_01-05_51_39.m2t.html

Thanks in advance for your help!

[thetoof]

You can give TempGaussMC_beta1 a try. http://forum.doom9.org/showthread.php?p=1158000#post1158000
If you have trouble finding the plugins, they are all in the requirements.7z archive of animeivtc.
However, since you're converting to DVD, you shouldn't double your framerate. So either add selecteven() (progressive output) or weave() (interlaced output) at the end of your script.

To sharpen, limitedsharpenfaster is something worth trying.

[mikeytown2]

Give this a shot
#load source
MPEG2Source("cam.d2v")
#bob deinterlace
TDeint(1)
#Resize
BicubicResize(720,576,0,0.5)
#interlace
Separatefields()
Selectevery(4,0,3)
Weave()

Make sure to set the 16:9 bit when encoding. Also try BlackmanResize()

[stooky]

Thank you very much for your answers!
I'll give them a try tomorrow!

[2Bdecided]

You can give TempGaussMC_beta1 a try.18 hours for 2.5 minutes of HDV on my (admittedly low spec 2GHz) machine. Pointless, timewasting overkill for interlaced HD > interlaced SD conversion.

Lots of people here seem convinced that the way to do this conversion is to deinterlace as carefully as possible. However, in the thread where it was really tested, it was found that even dumb bob of HD interlaced is too sharp for SD interlaced and needs to be softened! So why waste time with smart bobbing?

This is one interlaced resize method...
http://forum.doom9.org/showthread.php?p=1161524#post1161524

This is another...
bob()
spline36resize(704,576)
limitedsharpenfaster().Blur(0.0,1.0).Sharpen(0.0,0.5)

assumetff()
separatefields().SelectEvery(4,0,3).Weave()


Hope this helps.

Cheers,
David.

[stooky]

Thanks for your answer!
But I'm a bit confused now...
I thought that I have to use selecteven() for progressive output.
You use weave() in your scripts. Does this mean that you generate interlaced SD-Material?
Til' know I thought that progressive output is better for downsizing...

[Blue_MiSfit]

The content becomes progressive after bobbing (with bob() or tdeint(1)). Then the scaling happens, then you re-interlace with separatefields.selectevery(4,0,3).weave.

You want to burn it on a DVD, right? Then your only good option is to keep it interlaced, since the NTSC DVD standard calls for 480i60, and doing anything else means losing motion fluidity.

~MiSfit

[Alex_ander]

it was found that even dumb bob of HD interlaced is too sharp for SD interlaced and needs to be softened! So why waste time with smart bobbing?

Dumb bob is 'too sharp' because the initial image is too sharp for dropping half of lines at turning a field into frame - the image cannot be represented properly (sample frequency too low) or restored after this. I agree that those slow sophisticated scripts are waste of time here, but with what I tested for comparison, conventional smart bobbers like LeakKernel or TDeint work more correctly (since they use all the lines for stationary parts of image) and are fast enough. To avoid extreme sharpness before final re-interlacing, different resizing methods can be used for vertical / horizontal operations and this is well-combined with horizontal resizing (it can be sharper) before bob, which reduces job for it, and vertical resizing (less sharp, even filtering if necessary) afterwards.

[stooky]

Hi!
I've tested some of your scripts!
Generally I've to say that diagonal lines look very noisy...
I have packed 3 different version with the scripts in the following rar file:
I would be interested what you experts think about the results!
I think the version with LeakKernel looks best...
Judge on your own:
http://rapidshare.com/files/160098378/files.rar.html

[vampiredom]

Try this (you'll need ColorMatrix, Yadifmod and TomsMoComp)


#########################
# INPUT
#########################

AviSource("signpost.avi")

AssumeTFF()
(isRGB()) ? ConvertToYUY2() : ColorMatrix(mode="Rec.709->Rec.601", clamp=false)

#########################
# DEINTERLACING (Bobbing)
#########################

# padding for mod16 width and height
w16 = ceil(float(width()) / 16.0) * 16
h16 = ceil(float(height()) / 16.0) * 16
bL = (w16 - width()) / 2
bR = (bL % 2 != 0) ? bL - 1 : bL
bL = (bL % 2 != 0) ? bL + 1 : bL
bT = (h16 - height()) / 2
bB = (bT % 2 != 0) ? bT - 1 : bT
bT = (bT % 2 != 0) ? bT + 1 : bT

(bL > 0 || bR > 0 || bT > 0 || bB > 0) ? AddBorders(bL, bT, bR, bB) : last

yadifmod(mode=1, edeint=Interleave(TomsMoComp(-1, 0, 0), DoubleWeave().SelectOdd().TomsMoComp(-1, 0, 0)))

(bL > 0 || bR > 0 || bT > 0 || bB > 0) ? Crop(bL, bT, bR * -1, bB * -1) : last

#########################
# CROP / RESIZE
#########################

# crop a little from the top and bottom to allow fullscreen with accurate PAR (assuming 1080i source)
Crop(0,14,0,-14)

Spline36Resize(720, 576)

######################
# OUTPUT OPTIONS
######################

# Uncomment only one of the lines below below

# This produces interlaced YV12 output
AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF().ConvertToYV12(interlaced=true)

# This produces progressive YV12 output, with blending
# Merge(SelectEven(), SelectOdd(), weight=0.5).ConvertToYV12(interlaced=false)

# This produces progressive YV12 output, without blending
# SelectEven().ConvertToYV12(interlaced=false)

Limiter(16, 235, 16, 240)

[Blue_MiSfit]

:D nice script!!!

~MiSfit

[vampiredom]

Thanks... I'm very impressed with the Yadifmod + "TomsBob" method here: It not perfect for 1:1 stuff, but it is ideal (and extremely fast) for scaled-down stuff like HDV->DVD. I have never able to get close to its quality with Tdeint, Leak, etc.

Ther seems to be some issue on older CPUs with TomsMoComp: Things get funky when the dimensions are not mod16, so that's why I add the temporary borders and then crop them off. It's the "safe way" to do it :)

Only EEDI2 seems to do a "better" job (most of the time?) than TomsMoComp in this situation, but the rendering is way too slow on HD sources (unless you're running MT and the MT version of EEDI2 on a killer machine, of course).

In which case, you can replace the DEINTERLACING section above with:

WhichField = (GetParity()) ? 3 : 2
Yadifmod(mode=1, edeint=v.SeparateFields().EEDI2(Field = WhichField, maxd = 12))

@stooky:

What program are you frameserving from with DebugMode?

[2Bdecided]

Dumb bob is 'too sharp' because the initial image is too sharp for dropping half of lines at turning a field into frame - the image cannot be represented properly (sample frequency too low) or restored after this.I didn't mean that though. The aliasing in any_HD_content.bob() is irrelevant when the target is SD.

I agree that those slow sophisticated scripts are waste of time here, but with what I tested for comparison, conventional smart bobbers like LeakKernel or TDeint work more correctly (since they use all the lines for stationary parts of image) and are fast enough. To avoid extreme sharpness before final re-interlacing, different resizing methods can be used for vertical / horizontal operations and this is well-combined with horizontal resizing (it can be sharper) before bob, which reduces job for it, and vertical resizing (less sharp, even filtering if necessary) afterwards.In the thread I linked to, the "necessary filtering" was so strong that any advantage to using a better bobber at the HD stage was completely wiped out. You're left with less than 300 lines of effective vertical resolution - it doesn't matter whether you start with 540 (from bob), 1080ish (from TGMC), or something in between (from another) - it all looks the same afterwards.

(Of course I agree that the separate H and V resizing before and after any_smart_bob is very useful, when a smart bob is required.)

Cheers,
David.

[NerdWithNoLife]

What is your original framerate? That camera shoots 30p/30i/24p, I believe. You may want to try 24p frames, and have the encoder apply soft pulldown, like in most commercial DVD's. The framerate is a different issue from the resizing method (though you should deinterlace before resizing). Progressive frames tend to compress well, at the expense of smoothness of motion.

[KR]

stooky: I would try not to deinterlace. Only downsize. I know it sounds weird, but at least try it. (The easy way to see the effect is with VirtualDub's Resize function, with preview.)
I'd recommend Lanczos3 resize. (some other modes will introduce weird artifacts). Do not activate interlace mode.

Such downsizing will blend the fields.
You will save processing time, and there won't be deinterlacing artifacts.

(make sure any prior processing respects the interlace nature of the video or you will get artifacts. Separate fields if necessary. Another possibility would be to downsize before processing for more speed)

P.S.:
Why do you frameserve the m2v and then convert it to YUV2 ??? Is the frameserve RGB-only ? If so, you lose quality in YUV-->RGB-->YUV conversion. Personnally I convert m2v to mpeg (lossless muxing) then convert mpeg to avi with Fast recompress in VdubMod, encoding in Huffyuv. That way I have easy to edit, YUV avi files without any loss in quality.

[Blue_MiSfit]

That's a terrible idea! You can't properly resize interlaced content without deinterlacing!

~MiSfit

[KR]

I knew others would disapprove, lol.

Blue_Misfit: Try it also, you'll see it isn't so bad. In fact the result is very good.

Let's say we have 960 lines (interlaced). If we were to resize it with a bilinear transform, to 480 lines, without prior deinterlacing, we would obtain the exact same result as having done a simple deinterlace (blend fields) followed by the resize. That's because the resize ratio is a perfect 2:1.

In his case, the ratio is not so perfect. That's why I recommend using a different resizer (Lanzcos3). The end result looks like mid-way between deinterlace-blend and deinterlace-interpolate.

I did it myself for resizing 1080i to 720p and the result is still very good while processing is much faster.

Of course if he doesn't like the look of blended fields he will have to deinterlace before resizing.

In any case, before criticising, try it. Or try thinking outside the box... There are no golden rules, only the end result's quality matters.

[Leak]

Let's say we have 960 lines (interlaced). If we were to resize it with a bilinear transform, to 480 lines, without prior deinterlacing, we would obtain the exact same result as having done a simple deinterlace (blend fields) followed by the resize. That's because the resize ratio is a perfect 2:1.

In his case, the ratio is not so perfect. That's why I recommend using a different resizer (Lanzcos3). The end result looks like mid-way between deinterlace-blend and deinterlace-interpolate.
If you're going to do it this way, at least do a bilinear resize from 1080 to 540 vertically and *then* use lanczos to get down to the final size - directly resizing from 1080 to 480 will give you windowblinds-like artifacts everywhere there's movement because it blends more than 2 lines (with combs) together...

[2Bdecided]

Why blend the fields together when the output is DVD?!

I did it myself for resizing 1080i to 720p and the result is still very good while processing is much faster.The result is an abomination! As for "much faster" - bob() isn't exactly slow, neither is re-interlacing.

You might as well save time by only processing the first half of the video - "much faster"!

Cheers,
David.

[KR]

If you're going to do it this way, at least do a bilinear resize from 1080 to 540 vertically and *then* use lanczos to get down to the final size - directly resizing from 1080 to 480 will give you windowblinds-like artifacts everywhere there's movement because it blends more than 2 lines (with combs) together...

I thought about it too, but didn't do it this way because in VDubMod, I only get the windowblinds with Nearest Neighbor, Bilinear and Bicubic resize. There are no artifacts with Precise bilinear, Precise bicubic and Lanczos.

Nearest neighbor, no prior deinterlace
http://mydriaz.com/download/direct nearest neighbor.png

Deinterlace - Blend before Lanczos3
http://mydriaz.com/download/deintblend, lanczos3.png

Lanczos3, no prior deinterlace
http://mydriaz.com/download/direct lanczos3.png

Why blend the fields together when the output is DVD?!
True, retaining 60i is better in this case.


You might as well save time by only processing the first half of the video - "much faster"!
lol

[mikeytown2]

@KR
Deinterlacing , for viewing on a PC is fine, most people will encourage that... deinterlacing before burning to a DVD: "The result is an abomination" - 2Bdecided, which you agree with :). TV's work best when fed interlaced video. PC's work best when given deinterlaced video. U want Interlaced video on a DVD if the original footage was interlaced. I'm just driving this point home and locking the door.

As for your results, my guess is VDubMod is detecting the interlaced material, bobing before it resizes and blending the fields. Use DGMPGDec (http://neuron2.net/dgmpgdec/dgmpgdec.html) to load the m2v files directly into AviSynth, no frame serving, no color conversions, no 60GB file; overall a better way of doing things then what you suggested.

[KR]

lol thanks mikeytown2 I wasn't aware of DGMPGDec...
I had found a way to not lose quality but it sure was tedious in file manipulation and resulted in approx 100GB per hour of video.

Thanks again

[Sagekilla]

@mikeytown2: That depends on the display and it's hardware. If you're using a CRT based TV, which inherently works well with interlacing, then I'd say yes. Otherwise, if it's a standard TV I'd say be wary because some have some really poor deinterlacers so the quality might not be so great.

[vampiredom]

@sagekilla: I totally agree. I have come to realize the fact that progressive footage looks better on interlaced displays than interlaced footage on progressive screens -- especially at SD resolution on HD sets. I say 24p, 25p, 30p and the ways to go for most DVD projects these days. It's a shame, but it's simply a reality that most 720p or 1080p displays don't play nicely with true interlaced NTSC or PAL.

That said, a good deinterlacer is key. With all respect to their author(s), I believe that tools such as TempGaussMC, MCBob, MVBob, et al. are probably impractical (and often overkill) for processing large amounts of HD footage. Try Yadifmod + TomsMoComp (very fast) or EEDI2 (not so fast). Good quality at reasonable speeds.

DGMpgDec/DGIndex is great for this process. I just finished batching 200 or so source clips friom HDV60i->DV 30p. However, in support of frameserving via DebugMode: I use DMFS in Premiere Pro CS3 all the time. It works fabulously. It lets the editing program help you edit efficiently, while letting AviSynth, VirtualDub, and HCEnc handle post-processing, conversion etc. This allows you to ge the best of both worlds, so to speak.

A lot can also be said for the ability to color correct clips in a nice graphical environment. Then, when you output HD (in YUY2 or RGB) via DebugMode and scale it to SD, it will "smooth" some of the gradients, etc. that were perturbed by the limits tweaking an of an 8-bit source. In other words, it's benficial to do CC on the HD source, rather than the SD output. DebugMode facilitates the process nicely. Now you can let AviSynth excel with its excellent deinterlacing and scaling abilities (way better than Premiere).

And for any other Premiere Pro users, you can actually use DGIndex as a sort of replacement for DebugMode. Using Adobe Media Encoder you can export 4:2:2 MPEG2 I-frame (150Mpbs or so) and then index that with DGIndex. Actually, FFMpegSource seems to work well on I-frame-only .m2v elementary streams also, from what I've seen.

[2Bdecided]

@sagekilla: I totally agree. I have come to realize the fact that progressive footage looks better on interlaced displays than interlaced footage on progressive screens -- especially at SD resolution on HD sets. I say 24p, 25p, 30p and the ways to go for most DVD projects these days. It's a shame, but it's simply a reality that most 720p or 1080p displays don't play nicely with true interlaced NTSC or PAL.While this is undoubtedly true*, the 25 images per second of 25p look dramatically different from the 50 images per second of 50i (on any TV!). 25p stutters. 50i gives realistic fluid motion.

(The same goes for 30p vs 60i, and the difference between 24p and 60i is even greater.)

If you want the look of 25p, fine. However, if what you wanted (and therefore what you started with) was 50i, then dropping it to 25p is a far bigger change to the image than any amount of artefacts arising from interlaced MPEG-2 encoding and subsequent poor deinterlacing of 50i.


25p vs 50i/50p isn't such a dramatic difference on most PCs, because few PCs display 50p properly anyway - 50p still stutters on a PC - just less than 25p. However, on a real TV, 50i is butter smooth, while 25p is stutter stutter stutter.

(To get 50i/50p to look equally smooth on a PC requires specific hardware and drivers, and a lot of hard work.)

Cheers,
David.

P.S. * - decent TVs play everything properly - even SD interlaced content. It's at the "cheaper" end of the market where you find panels which make HD look rather good, and interlaced SD look even worse than it should. Using a good upscaling DVD player can help such a TV realise the best from SD DVDs.

[vampiredom]

Using a good upscaling DVD player can help such a TV realise the best from SD DVDs

Yes, but most film DVDs progressive anyway. Nearly all film titles that I've seen are either NTSC 23.976 fps (on which the DVD player adds pulldown for interlaced displays, or plays progressively on progressive scan setups) or PAL 25p (often sampled as interlaced, but progressive nonetheless).

Like most things, this is totally subjective -- and the results will vary depending on the type of content. I believe the reason why film titles look OK on DVD is because they were shot with 1/48 shutter speed. Film was designed to be shot and viewed at (or around) 24p, so filmmakers mind these limitations as they shoot and edit.

I am not judging my opinion based exclusively on cheap HDTV -- I've seen some really nice ones that do horrible things to interlaced SD content, such as broadcast TV.

[Comatose]

Well, many times broadcast TV is a disaster, so don't blame it on the TV right away.
You can only really blame the TV if you have the source to analyze later.