What's the best deinterlacing method for VHS video for burning to DVD?

[Sharc]

Ok. I'll concede on this one (apart from the DV comment)

DV is an interlaced format, yes, usually BFF. 4:2:0 color subsampling for "PAL" and 4:1:1 color subsampling for "NTSC". The 2 fields may however be pictures from the same instant in time, hence there is no motion between the 2 fields of a frame. Your example in post #79, DVD_23.zip, is such a case. Encoded and stored as interlaced fields, but with progressive content, also called PsF (Progressive segmented Frames). When you step through the fields you will get motion with every 2nd field only. The weaved frames show no visible combing. With true interlaced one would get motion with every field, and the weaved frames show the typical interlace combing. So you can have true interlaced or PsF. For subsequent processing PsF can be treated as progressive.
So again: Inspect the sequence of the fields. Anything else is guesswork and speculation.

The entire realm of "DV" is a real mess btw., so many variants and sub-variants.
FWIW here the DVCAM spec from SONY.
(Sidenote: even this spec has soon been undermined when 4:3 / 16:9 cameras entered the market with the notorious aspect ratio ambiguity which is another can of worms for discussions).

[Alwyn]

DB83, perhaps it is time to throw out the other Field Order methods you have heard about and try the one I (and Davexnet) have described, or if you are into AVISynth, the code that Sharc gave.

As for DVD 23, we are commenting on the VOB, not the DV original. Clearly, AVS2DVD is taking the BFF DV file and turning it into a PsF (aka Progressive) VOB/MPEG2. Why is anybody's guess. I do note, as Ferrari has, that DVDStyler's default is also Progressive; Interlaced and BFF or TFF must be set by the user. I also note that, if Progressive is left as the setting, the resultant VOB still has interlace combing. I haven't worked out why yet.

Once you have tried our methods on a couple of files you'll see exactly what we mean. It will be obvious what the field order is.

[davexnet]

As for DVD 23, we are commenting on the VOB, not the DV original. Clearly, AVS2DVD is taking the BFF DV file and turning it into a PsF (aka Progressive) VOB/MPEG2

Sometimes A2D will not recognize the file is interlaced, resulting in a progressive encode.
However, if you know the file to be interlaced, you can tell it otherwise.
On the main screen you can right click the title/ edit source title info / video scan type > interlaced

[DB83]

Given that I am ripe for slaughter here is one more version of the OP's video. This time TFF has been selected (and a filter removed) and the net result appears to be an interlaced dvd. The chroma 'issue' is still there but who plays a dvd one frame at a time in normal use ?

[Alwyn]

Yes, that is indeed Interlaced, TFF. That chroma edge is less obvious than Sharcs (probably because your is noisier than Sharcs), and yes, probably wouldn't be noticeable. But, once you see it, you can't unsee it!

[Skiller]

Here's my take at encoding Original Sample.avi in a way that would allow 2 hours and 29 minutes of DVD compliant MPEG2 on a single layer DVD.

The raw capture looks good, no major problems there, but it looks to me like the noise reduction of the Panasonic DMR-EH55 was left turned on. Field order is TFF by the way (as to be expected).


What I did:
• preparation in AviSynth
• lossless intermediate for encoding
• MPEG2 encoding using ProCoder 1.5
• Muxman for creating a menu-less DVD

In AviSynth I did some mild chroma denoising in 16 Bits using SMDegrain (temporally) and dfttest (spatially). No luma denoising (it is already rather flat). I masked the dirty frame borders with clean black borders which have a soft transition (one could further optimize this for encoding by sticking to mod16, but that results in quite large borders, so I did not). No cropping or resizing except to go from 720x576 to 704x576 to 352x576.


Let's find out what the bitrate will be using my good old spreadsheet:


[Attachment 75850 - Click to enlarge]

So it's 3897 KBit/s with 192 KBit/s audio to max out a single layer DVD.


To put it bluntly, it is not going to look much if any better than this when going for 2 hours and 29 minutes on a DVD5.
I think it looks alright, very watchable (but personally I would split this across two discs).

[davexnet]

Perhaps it's worth trying in HCenc and pick one of their low bitrtate matrixes.
Keeps the quantization lower; might make a visible difference

[Skiller]

HCenc, no matter the matrix and other settings, does not beat ProCoder 1.5 for this kind of interlaced video – I've done plenty of testing exactly this many years ago. But HCenc is indeed the next best thing for this. You can tweak HCenc to produce lower quants than ProCoder but it still does not look better than ProCoder visually, and I believe that's mainly down to the motion estimation being superior in ProCoder (for interlaced).

[davexnet]

Yes I've heard the same about the early versions of Procoder. I've got some of the installers
on a CD somewhere, one of these days I'm going to try it myself.

Was 1.5 the recommended version ?

[Sharc]

Given that I am ripe for slaughter here is one more version of the OP's video. This time TFF has been selected (and a filter removed) and the net result appears to be an interlaced dvd. The chroma 'issue' is still there but who plays a dvd one frame at a time in normal use ?

Commenting the VTS_01_1.VOB in your DVD_24.zip:
The video is interlaced, TFF, and flagged accordingly. So that's ok now.
What is still flawed is the chroma which moves only at framerate. I don't know where the culprit is. Perhaps a bug in the GUI you are using. Perhaps something like ConvertToYV12(interlaced=true) is missing in the script which your tool creates. I really don't now.
For comparison: the chroma is moving correctly in my dvd5.zip of post#84, and it is also correctly moving in skiller's variant in post#96. So something must be odd with your tools or settings as I see it. Take it as a hint, not as some kind of bashing or plain nitpicking.
@Alwin: In order to analyze it reliably you need to inspect the U,V planes. I don't know if this is possible in Vdub2. I am using Avisynth for that.

[DB83]

Thanks for that.

The avisynth script includes the line "ConvertToYV12" but not the "(interlaced=true)" bit. Maybe that is the issue*. In the DV sample, the full line was present


On another edit screen I did have to select "Interlaced-encoding" and TFF but they could have refered to the source.


*So with that in mind, here (thank f*ck they all say) is my final take with the full line edited in.

[Sharc]

@DB83: Unfortunately the chroma problem still exists in your DVD_25.zip. I am running out of ideas what could have gone wrong in your workflow ....
Heading for 2024 now ...

[Sharc]

@DB83: Out of curiosity I gave AVStoDVD a quick shot. My findings may be incomplete, but apparently it doesn't supply HCEnc with the correct parameters for interlaced encoding.
* PROGRESSIVE instead of INTERLACED (which you noticed as well and corrected manually)
* CHROMADOWNSAMPLE 1 is missing (this is for interlaced chroma downsampling and is probably the root cause of the chroma flaw. Should be inserted manually as well)

ConvertToYV12() should be ConverttoYV12(interlaced=true) (you corrected this manually as well)

So the intermediate .m2v produced by HCEnc had the chroma flaw already.

Oh these nice GUIs ... not maintained (abandoned?) since quite a while
(There is still hope that I used the tool incorrectly, and an AVS2DVD expert may chime in)

Edit: Never mind. My corrections still did not solve the issue, unfortunately. Must be something else. I give up

[lollo]

Oh these nice GUIs ... not maintained (abandoned?) since quite a while

... (badly) using AviSynth internally. As we always say, better to use AviSynth and encoders directly, to have full control over everything

[Skiller]

Was 1.5 the recommended version ?

Yes, version 1.5 is the recommended one. Later versions do too strong of a pre-processing (cannot be turned off) which often results in flat areas becoming blocky.

As we always say, better to use AviSynth and encoders directly, to have full control over everything

I agree 100%. These GUIs look nice and appealing, but I don't trust anything that generates automated scripts.


I noticed another problem in DB83's encodes which I think nobody has mentioned yet – the picture is squeezed horizontally. It's as if the 720x576 input is interpreted to be square pixels and resized accordingly.
See:


[Attachment 75855 - Click to enlarge]


Also, is there a way to do Half D1 in DVDstyler? Full D1 is a block fest at this bitrate...

[DB83]

^^ True.

When I looked at the avisynth script it would add 24 pixels left and 24 pixels right to give it the 768 (720+48) width without any consideration to the true (if any) actual width. Or to put it another way is the 720 *576 capture as is or a squeezing. Hard to tell from the sample yet all lossless codecs capture as '720*576'. So are these square-pixel or not ?. One requires specific input sources to be sure or would such variances be critical ?


I, even now, do not appreciate the percieved chroma issue. I did look at this prior to uploading the last version. TBH I could not see it but there again what does this 'amateur' really know ?

[davexnet]

For trouble shooting problems in A2D results, always look at, or post, the log.
Most likely the problem will be spotted

[Sharc]

Also, is there a way to do Half D1 in DVDstyler? Full D1 is a block fest at this bitrate...

Yes. 352x576 for PAL and 352*480 for NTSC are perfectly supported in DVDStyler. Also nice cropping and border features are included. On needs just to think a little how to crop/border interlaced footage correctly.
By default it uses ffmpeg for encoding which is not the very best mpeg2 encoder for low bitrates.

[lollo]

Hard to tell from the sample yet all lossless codecs capture as '720*576'.

As it should be, according to specification ITU-R BT.601-4 (formerly "CCIR-601" or "Rec.601")

So are these square-pixel or not ?

As it should be, they are not. The 720x576 frame will be streched to 768x576 (square) pixels when displaying, according to 4:3 DAR parameter (or the PAR parameter).
Unfortunately analog captured avi do not contain DAR nor PAR parameter.

To be more accurate the 720x576 frame should be cropped to 704x576 for exact proportions, but that's another story

There are many threads on the forum about these aspects.

[Alwyn]

I noticed another problem in DB83's encodes which I think nobody has mentioned yet – the picture is squeezed horizontally. It's as if the 720x576 input is interpreted to be square pixels and resized accordingly.

I noted that in post #45. That is why I gave DVDStyler a 768x576 file. DVDStyler (like my NLE) doesn't interpret the 720x576 as 4:3. And from what I can see, the cropping function cannot be used to fix it.

[Skiller]

I see. Vegas does the same. It's because of this:

Unfortunately analog captured avi do not contain DAR nor PAR parameter.

Hence square pixels are assumed, although a 720x576 video is never square pixels (well, unless for the extremely weird and basically nonexistent occurance of it being created like that on purpose).

In Vegas I can simply change the properties of the avi from square pixels to whatever is correct. Maybe such thing exists in DVDstyler as well? I've never used it.

While resizing to 768x576 fixes this, it is not ideal to resize twice just to end up with what we started with: 720x576. Every resize puts some (minor) damage on the video.

[Sharc]

I noticed another problem in DB83's encodes which I think nobody has mentioned yet – the picture is squeezed horizontally. It's as if the 720x576 input is interpreted to be square pixels and resized accordingly.

I noted that in post #45. That is why I gave DVDStyler a 768x576 file. DVDStyler (like my NLE) doesn't interpret the 720x576 as 4:3. And from what I can see, the cropping function cannot be used to fix it.

Happy New Year to all.
@ Alwyn: See post #109.
In DVDStyler you can set the DAR 4:3, crop to 704(x576) and encode as 704(x576), and it uses the correct PAR for the DVD. Am I missing something?
In DVDStyler you can also encode as half D1 352x576 as suggested by skiller as a means to accommodate longer clips (lower bitrates) on a DVD5.

What annoys me more is that DVDStyler also exhibits the chroma bug - unless I use it with my own script it seems. But as some seem not to see the bug, why bother ...
Anyway I am a bit tired of analyzing the GUIs and will leave this floor to others

[lollo]

Hence square pixels are assumed, although a 720x576 video is never square pixels (well, unless for the extremely weird and basically nonexistent occurance of it being created like that on purpose).

Yes.

While resizing to 768x576 fixes this, it is not ideal to resize twice just to end up with what we started with: 720x576. Every resize puts some (minor) damage on the video.

100% agree, not only in this specific case (DVD spec is 720x576 4:3 DAR), but also in general.

[davexnet]

Here's my attempt using HCenc directly

[Sharc]

Here's my attempt using HCenc directly

Interesting. The chroma issue which I commented earlier is not (or much less) visible in some remaining frames only than in those versions which I have commented before. Maybe if you would denoise the chroma before encoding all frames would be fully ok? I don't know, but perhaps the noise irritates/fools some of the encoders regarding correct YV12 4:2:0 interlaced chroma processing? In my dvd5.zip (encoded with ffmpeg) and Skiller's half-D1 example (encoded with Procoder) the chroma advances correctly. Both cases have been encoded with denoised chroma. All a bit speculative.

[Skiller]

davexnet, could you please post your settings log of HCenc?
I have an idea regarding the chroma issue...

Edit: Was there any filtering involved? I looks kinda cleaned up a bit.

[davexnet]

davexnet, could you please post your settings log of HCenc?
I have an idea regarding the chroma issue...

Edit: Was there any filtering involved? I looks kinda cleaned up a bit.

yes, I used sharc's script but I added checkmate() before the qtgmc() for a little further cleanup.
I'll post the log and a further test shortly ....

Regarding extra cleanup of the chroma, any suggestions? It would be nice to do it while it was
still 4:2:2, something motion compensated?
Here is the same as before with the checkmate commented out and the log.
Also, a second set where the script leaves it as 422 and HCenc does the chroma down sample
Thirdly, the sample I posted previously had chroma sampling set as progressive, but the source is already 420,
so I'm not sure if it's a factor or not

[Sharc]

Result is the same as I see it: A mixture of fields with correct chroma advancement and out-of-step (or at framerate only) chroma advancements ...

Edit:
Here the script which I am using for testing. The U and V should advance in step with the field (double hight) on the left

LWLibavVideoSource("..source....")
AssumeTFF()
bob(0.0,1.0) #fields
StackHorizontal(last.subtitle("source field"), Stackvertical(UtoY().subtitle("U"),VToY().subtitle("V")))

[Skiller]

The settings look good, maybe one thing we could still try though (more on that later).

I was suspecting the issue is because of "auto detect" in "interlacing options" on Settings 1. This setting would decide for each GOP whether to use Zig-Zag or Alternate scan. It's a risky setting for very little improvement in encoding efficiency. But as it was set to interlaced and TFF, this cannot be the culprit, unfortunately.

There is only one setting left in HCenc I can think of potentially being able to cause this: deadzones. Try this manual combination: Intra=1, Non-Intra=0

I don't quite remember why, but I stopped using auto deadzones in HCenc from very early on and then sticked to those values.

Regarding extra cleanup of the chroma, any suggestions? It would be nice to do it while it was
still 4:2:2, something motion compensated?

I used this (works in YV16). I use it in 16 Bits, but that may be beyond the scope of this thread, so I removed lsb-related parameters.

#Denoises only chroma spatially
dfttest(Y=false, tbsize=1, sigma=16)

#Denoises only chroma temporally
SMDegrain(chroma=true, plane=3, contrasharp=false, tr=3, thSADC=550)

Thirdly, the sample I posted previously had chroma sampling set as progressive, but the source is already 420,
so I'm not sure if it's a factor or not

It's not a factor. If you feed HCenc 4:2:0 and ask for 4:2:0 MPEG2 it does not touch the chroma at all. The chroma downsampling option on Settings 1 is only for 4:2:2 input and when asking for 4:2:0 MPEG2 output.

[davexnet]

thanks Sharc, I'll take a look with your script