HDV (50i) to Pal Anamorphic (50i) problems with Avisynth (sample included)

[VooD]

Hi, I'm trying to downconvert a HDV (50i) home video from my Canon HV10 to anamorphic 16:9 pal 50i video (so I can keep the 50 interlaced frames and burn it into standart dvd).

I used this script in Avisynth 2.5:

LoadPlugin("dgdecode.dll")
Mpeg2Source("londres1.d2v")
SwapFields()
SeparateFields()
LanczosResize  (720,288)
Sharpen (0.5)
Weave ()
ConvertToYUY2 ()

Seems correct to me (except for I have to swap fields or else the deinterlacing won't work properly). First I separate the fields, resize every field to the proper 16:9 interlaced anamorphic size, then I apply a little sharpen (this is not really neccesary, but I like more in that way), I weave both fields and finally I convert the frames to YUV2 so CCE accepts the data.

But, when I play the final mpeg2 video either using bob deinterlacing in mplayer classic or in a dvd player on my old Trinitron Wega CRT tv, the video sometimes looks blocky, I have tryed many different scripts I found on the the internet for doing the job, but all produces similar results.

What I'm doing wrong?

Here's a sample:

http://www.gigasize.com/get.php?d=9njmtlzvx7b

The video is 50i, but too blocky, just take a look at the egiptian sculpture and the text on the posters.
Thanks in advance.

[Soopafresh]

Have a look at this thread

http://forum.doom9.org/showthread.php?s=&threadid=74906&highlight=interlaced


I'm envious that you got to go to the Hadrian exhibition!

[VooD]

Ok, I will give a chance at that guy's method.
Thanks a lot.

[jagabo]

Swap fields should only be used for sources that are captured with the scanlines in the wrong order. You probably want to use AssumeTFF() instead.

[VooD]

Swap fields should only be used for sources that are captured with the scanlines in the wrong order. You probably want to use AssumeTFF() instead.

When I use AssumeTTF() instead of swapfields I get jerky playback using bob deinterlacing.

[Soopafresh]

Post a small clip of your ORIGINAL file if you want. DGindex should also tell you if your video is TFF or BFF. It's almost certainly TFF, however.

Also, you can Bob Deinterlace through Avisynth, creating a beautiful progressive video which you won't need to bob deinterlace in your Windows Media Player. That wouldn't work on your DVD player, obviously.

Also, try LimitedSharpenFaster for a much nicer sharpener than the built in sharpener found in Avisynth.

[jagabo]

You can be pretty sure your camcorder doesn't need SwapFields(). The only devices I've ever seen that produces frames with the fields swapped are very old Matrox eTV and Rainbow Runner cards. Using FieldSwap will reverse the field order, and reverse the position of pairs of scanlines. The result is very ugly.

Assuming your camcorder shoots bottom field first you should modify your script to:

LoadPlugin("dgdecode.dll")
Mpeg2Source("londres1.d2v")
SeparateFields()
LanczosResize  (720,288)
Sharpen (0.5)
Weave ()
ConvertToYUY2 ()

Then encode that as bottom field first MPEG2 in CCE. Do not enable the "Output top field first stream" option and set the "Offset line" to zero.

If you want your MPEG file to be TFF, enable the "Output top field first stream" option and set the "Offset line" to one.

I couldn't download the file you posted. I got a "file has been deleted" message. But the field swap issues wouldn't really explain blocky results. What kind of bitrate were you using? CBR or VBR?

[VooD]

I've used this function:

LoadPlugin("dgdecode.dll")
LoadPlugin("kerneldeint.dll")
Mpeg2Source("test.d2v")
interlacedscale(720,576,5,0)
ConvertToYUY2 ()


function interlacedscale(clip a, int w, int h, int "th", int "order")
{	th=default(th,5)
	ord = getparity(a) ? 1 : 0
	order = default(order,ord)

	a=a.addborders(0,4,0,4)
	f=a.kerneldeint(order=ord, sharp=true, twoway=false, threshold=th) 
	e=a.separatefields.trim(1,0).weave.kerneldeint(order=1-ord, sharp=true, twoway=false, threshold=th)
	interleave(f,e).assumeframebased
	crop(0,4,0,-4)

	lanczosresize(w,h)
	separatefields()
	(order == 0) ? selectevery(4,0,3) : selectevery(4,1,2)
	weave()
}

And now it looks a lot less blocky, there still is a little of blockyness in fast movement, but I guess that's normal. Anyway I'll make some tests and I'll try to upload a clip of the original video.

[VooD]

You can be pretty sure your camcorder doesn't need SwapFields(). The only devices I've ever seen that produces frames with the fields swapped are very old Matrox eTV and Rainbow Runner cards. Using FieldSwap will reverse the field order, and reverse the position of pairs of scanlines. The result is very ugly.

Assuming your camcorder shoots bottom field first you should modify your script to:

LoadPlugin("dgdecode.dll")
Mpeg2Source("londres1.d2v")
SeparateFields()
LanczosResize  (720,288)
Sharpen (0.5)
Weave ()
ConvertToYUY2 ()

Then encode that as bottom field first MPEG2 in CCE. Do not enable the "Output top field first stream" option and set the "Offset line" to zero.

If you want your MPEG file to be TFF, enable the "Output top field first stream" option and set the "Offset line" to one.

I couldn't download the file you posted. I got a "file has been deleted" message. But the field swap issues wouldn't really explain blocky results. What kind of bitrate were you using? CBR or VBR?

I used your script and just disabled "Output top field first stream" and let offset line to 1 and the result was pretty acceptable. No more blockyness and a lot faster than the previous script I used, though the video produced with that other script looks a bit more sharper (and flicky some times), so now I have two possible solutions, and I just need to decide which one is the best

Thanks a lot!!

p.d.: I'm uploading a segment of the original video, in case you want to make some tests.

[VooD]

Have a look at this thread
I'm envious that you got to go to the Hadrian exhibition!

He, he :P British Museum is great (unfortunatly I thought I had seen the entire museum just to discover 1500km away I only visited about 50%...is too big lol)

[VooD]

Here's the original clip: http://www.layouts.xbox-scene.com/test.mpg

But I think I've finally decided to use this:

LoadPlugin("dgdecode.dll")
Mpeg2Source("test2.d2v")
SeparateFields()
LanczosResize  (720,288)
Sharpen (0.3)
Weave ()
ConvertToYUY2 ()

and then just fix the top/bottom fields problem disabling "Output top filed first stream" in CCE. Neither AssumeTTF() or AssumeBTF() solved the problem (according to DGIndex the video is TTF).

Anyway this method produces very good results, no blockyness, and no flicky lines. That's enough for me at the moment :P

Thank you all for your time and help.

[jagabo]

Your MPEG file appears to be TFF, not BFF.

Here's what I came up with:

MPEG2Source("test.d2v")
AssumeTFF()
ConvertToYUY2(interlaced=true)
SeparateFields()
LanczosResize(720,288)
Weave()
ColorMatrix(mode="Rec.709->Rec.601")
ColorYUV(gain_u=25, gain_v=35, gain_y=-8)

Which is very close to your last script. LanczosResize() is a sharpening filter so I wouldn't use any additional sharpening. Most TVs will do some sharpening too and you'll end up with halos around sharp edges. And sharpening will increase noise which will increase the bitrate requirement.

The AssumeTFF() isn't really necessary in this script. SeparateFields() and Weave() are complimentary operations and there is nothing between them that is order dependent. I would put it in as a reminder and in case you did add something order dependent later.

I added ColorMatrix() because the source is rec.709 (DgIndex tells you this) and you're going to rec.601 for SD DVD. And I did a bit white balance adjustment. I used the big "Donations" text near then end of the video as a guide for the white balance since I figured that was probably white.

That should be imported into CCE and encoded interlaced TFF+offset 0, or BFF+offset 1.

I encoded with CCE in 1 pass VBR with min bitrate 1000, max 9000 and the quality set to 20. The result turned out with an average around 6000 kbps and was very clean (no macroblocks).

[Alex_ander]

BTW, simple separatefields->resize->weave is not good due to vertical shift errors at resizing. That field shift error can be avoided as suggested by IanB:

http://forum.doom9.org/showthread.php?p=1161524#post1161524

And still this method of resizing an interlaced video is not perfect for sharp original pictures (due to aliasing problems), better to use a smart bob using both fields (like LeakKernelBob, TDeint etc.), then resize and re-interlace.

[jagabo]

nevermind.

[VooD]

Mmm, I already compressed the whole video, but I'll try again with the new info. On the other hand correcting the white balance is not very useful since each scene in the video has differetn values.

Thanks to everybody.

Edit: I must be blind or something else, but I encoded the video with the script suggested by Alex_ander and I can't find any significative difference with the method I use. Perhaps looks a little more blocky, but nothing else.

[jagabo]

Using a smart bob will give a sharper image overall. But with your sample video it will give annoying strobing moire patterns and buzzing edges in the small text (like on the pedestal under the statue) and sharp horizontal edges.