Avoid 4.2.0 degradation for interlaced content by de-interlacing ?

[Music Fan]

Hi,
I was told there were some chroma losses in 4.2.0 (yv12) encoding for interlaced contents compared to progressive contents.
My capture card works in 4.2.2 (I use Lagarith in yuy2), but if I wanna encode my videos in mpeg-2 or x264 to make dvd's or avchd's, I have to convert yuy2 to yv12, which makes lose quality.
So I got a simple idea : I could de-interlace my 25i sources to 50p (to keep the fluidity of 50 fields) in yuy2, then convert yuy2 in yv12, then compress in x264.
Both my standalone players accept 1080p in 50 and 60 fps on avchd's, so I guess they will accept 50p in 720.576 (even if it's not supposed to be supported).

Is it a good idea ?

There is at least one disadvantage, 50p will need much more bitrate than 25i (maybe not twice but not far I guess).
But 2 advantages :
-no (or less) chroma losses
-much better de-interlacing done by avisynth (qtgmc for example) than by my standalone player in real time.

[Asmodian]

It is a very good idea.

I made a thread about this a while ago. Interlaced YV12 is a bad idea in my opinion. I think Post #9 (http://forum.doom9.org/showthread.php?p=1542902#post1542902) is the best example I came up with. Please also read Gavino's responses and my post #11, Gavino helped me understand it a lot.

[Music Fan]

Thanks, very interesting.
I'd like to understand some points of this topic (I didn't read the entire thread mentioned by Gavino in post 10 because it's very technical for me) ;
On your examples, the color blending seems due to the resize, but what if there is ConvertToYV12(interlaced=true) without resize ? And what if the source is de-interlaced before the conversion in YV12, as I wanted to do ?

this is a well known and understood issue that still exists (and it has to exist
Why does it have to exist ?
What is the best script now, 3 years after your tests, to convert interlaced yuy2 to interlaced yv12 ? Because I will continue to make dvd's anyway, I won't convert all my files to 50p.

While avisynth can handle 4:2:0 with interlaced chroma and progressive luma the YV12 standard does not allow for this
Do you mean there is a difference between 4:2:0 and YV12 ? I believed both designated the same notion.


It is currently not possible to get progressive luma + interlaced YV12 into x264 and have it treated as interlaced YV12 through playback, right?
Actually I got an idea to store interlaced YV12 in x264 as if it was progressive (but it won't be watchable as is) with this simple script ;
JDL_UnfoldFieldsVertical(flip=true)
This separate fields but gather them in the same picture one above the other, unlike separatefields() which alternates even and odd fields.
The advantage of JDL_UnfoldFieldsVertical is that there is no flickering because fields stay always at the same place, like 2 progressive videos one above the other.
To watch it, the reverse operation has to be done with this script ;
JDL_FoldFieldsVertical(flip=true)
No problem to do it in real time, this is very light.
It's findable there ;
http://www.avisynth.nl/users/stickboy/
Put jdl-interlace.avsi and jdl-util.avsi in avisynth's plugin folder.
It's not recent but I was told about it only a few months ago.
This simple and ingenious function has been invented to allow to use spatial filters on interlaced sources without having to de-interlace them, which makes a huge gain of time and quality.
The usual script with this function looks like this ;
interlaced source
JDL_UnfoldFieldsVertical(flip=true)
filters
JDL_FoldFieldsVertical(flip=true)
flip=true is optional but better because it reverses the bottom field so both fields touch themselves by their bottom side, like a mirror effect. It is supposed to simplify the work of spatial filters.

But I wonder if my idea is really good because encoding flattened fields is not usual and maybe not ideal.

There is also a trick to store yuy2 or rgb in x264 : dividing the picture in 3 primary colors and stacking them, but this would make a very large video and the bitrate would be very high, thus not very useful but feasible.
This is not my idea, but this could be combined with JDL_UnfoldFieldsVertical to store interlaced yuy2 in (lossless) x264.
And of course, to play it correctly, the reverse operation should be done to gather R, G and B and weave the fields.

[Asmodian]

On your examples, the color blending seems due to the resize, but what if there is ConvertToYV12(interlaced=true) without resize ? And what if the source is de-interlaced before the conversion in YV12, as I wanted to do ?

It isn't due to the resize, a point resize will never blend colors and is only used in the examples to increase the size so one can see what is going on. The blended color stripes are one pixel wide but magnified so we can see it on a high dpi computer monitor. Yes, deinterlacing before the conversion to YV12 solves this problem - that is exactly what I am saying to do. Never create interlaced YV12.

Unless you mean the chroma resize as mentioned in my post 11 from that thread? That resize is exactly what YUY2 -> YV12 means, YUY2 is full vertical resolution while YV12 is half vertical resolution, a resize is required and is done by the ConvertToYV12().

Why does it have to exist ?
What is the best script now, 3 years after your tests, to convert interlaced yuy2 to interlaced yv12 ? Because I will continue to make dvd's anyway, I won't convert all my files to 50p.

Interlaced YV12 stores color information as one pixel for line 1 and line 3, and another pixel for line 2 and line 4. Progressive YV12 stores one color pixel for line 1 and line 2. This means to generate progressive YV12 line 1 and line 2 you need the blend the two color pixels meant for lines 1, 2, 3, and 4. If you want to create interlaced YV12 final video the simple ConvertToYV12(interlaced="true") is the right way. Interlaced YV12 is only a bad idea if you plan to end with progressive YV12. Interlaced YV12 is what it is.

Do you mean there is a difference between 4:2:0 and YV12 ? I believed both designated the same notion.
While avisynth can handle 4:2:0 with interlaced chroma and progressive luma the YV12 standard does not allow for this
It would be nice to keep the chroma as is and simply use one chroma pixel for line 1 and 3 and another for line 2 and 4 but you cannot tell anything (except Avisynth) to do the YV12 -> RGB/YUY2 like that. The luma has to be interlaced as well. This still isn't as good as using YUY2 until you go progressive but would be better than the normal conversion of interlaced YV12 to progressive YV12.

Actually I got an idea to store interlaced YV12 in x264 as if it was progressive (but it won't be watchable as is) with this simple script ;

Funny tricks are easy to come up with, simply leaving the chroma as interlaced YV12 and using a ConvertToYUY2(interlaced=true) on playback would be fine (as fine as interlaced YV12 could ever be). Normal playback without the ConvertToYUY2(interlaced=true) would use the color value meant for line 1 and 3 for line 1 and 2, and the color value meant for line 2 and 4 for line 3 and 4.

There is also a trick to store yuy2 or rgb in x264 : dividing the picture in 3 primary colors and stacking them, but this would make a very large video and the bitrate would be very high, thus not very useful but feasible.
This is not my idea, but this could be combined with JDL_UnfoldFieldsVertical to store interlaced yuy2 in (lossless) x264.
And of course, to play it correctly, the reverse operation should be done to gather R, G and B and weave the fields.

x264 can store YUY2 or RGB as is, no need for any tricks.


I will say that when capturing most VHS the chroma is so terrible already it is not at all obvious when it has been blurred across 4 lines instead of only 2.

[foxyshadis]

You wouldn't want to keep interlaced chroma after deinterlacing anyway, because the alternating lines of chroma will no longer match up with the new luma lines.

On the other hand, you can just encode interlaced (using ConvertToYV12(interlaced=true)) and let your player deinterlace - the good ones have become quite good in realtime, both the chips in hardware players and TVs and PC based software. That way you'll maximize the temporal smoothness without paying the penalty of keeping extra progressive lines. (Interlaced 60i encoding in x264 only requires approx 70-80% of full 60p filesize for similar quality, while dropping to 30p is about 60%.) Of course, then you can't vertically resize.

[Asmodian]

You wouldn't want to keep interlaced chroma after deinterlacing anyway, because the alternating lines of chroma will no longer match up with the new luma lines.

True, that is only really relevant for IVTC rather than true interlaced, which should be a very rare analog capture today.

I still say, capture interlaced video in YUY2 if you can and convert it to YV12 near the end of the process. However, if the final format is only going to be interlaced YV12 it probably wouldn't make much if any difference to capture in interlaced YV12.

[Music Fan]

Thanks, very dense explanations, I have questions to clarify it.

Interlaced YV12 stores color information as one pixel for line 1 and line 3, and another pixel for line 2 and line 4. Progressive YV12 stores one color pixel for line 1 and line 2. This means to generate progressive YV12 line 1 and line 2 you need the blend the two color pixels meant for lines 1, 2, 3, and 4.
Do you mean this blending has to be done and is done automatically by de-interlacers (like qtgmc) ?
And when you say "to generate progressive YV12", I guess you mean from interlaced YV12, not from progressive yuy2.
My captures are done in yuy2, so if I de-interlace 25i to 50p in yuy2 and convert this progressive yuy2 in progressive yv12, I won't be concerned by this blending, right ?

If you want to create interlaced YV12 final video the simple ConvertToYV12(interlaced="true") is the right way.
From interlaced yuy2 I guess.
If the source is progressive yuy2 and if I have to encode it in interlaced yv12, do I still have to chose ConvertToYV12(interlaced="true") or ConvertToYV12() is enough (with an interlaced encoding like Pal movies on dvd) ?

Interlaced YV12 is only a bad idea if you plan to end with progressive YV12.
I don't understand what you mean : it's a bad idea to encode Interlaced YV12 if I plan to display it in progressive YV12 (de-interlacing being done by the player) ?

It would be nice to keep the chroma as is and simply use one chroma pixel for line 1 and 3 and another for line 2 and 4 but you cannot tell anything (except Avisynth) to do the YV12 -> RGB/YUY2 like that. The luma has to be interlaced as well. This still isn't as good as using YUY2 until you go progressive but would be better than the normal conversion of interlaced YV12 to progressive YV12.
What would be the benefit of a YV12 -> RGB/YUY2 and also of an interlaced YV12 to progressive YV12 conversion ?
I won't de-interlace the files that I plan to encode in interlaced YV12, and those I plan to encode in 50p will be converted in yv12 from yuy2 sources (progressive after de-interlacing), so I guess I won't meet the situation you describe.

Funny tricks are easy to come up with, simply leaving the chroma as interlaced YV12 and using a ConvertToYUY2(interlaced=true) on playback would be fine (as fine as interlaced YV12 could ever be). Normal playback without the ConvertToYUY2(interlaced=true) would use the color value meant for line 1 and 3 for line 1 and 2, and the color value meant for line 2 and 4 for line 3 and 4.
Do you mean with JDL_UnfoldFieldsVertical that flattens the fields ?
And why should it be converted to yuy2 ? My captures are already in yuy2.

x264 can store YUY2 or RGB as is, no need for any tricks.
Astonishing, I read that it was only yv12 compatible (written in 2010) ;
http://forum.videohelp.com/threads/318382-Lagarith-or-x264-lossless?p=1971276&viewfull=1#post1971276
x264 is YV12 only
Was he wrong or it changed after 2010 ?

I will say that when capturing most VHS the chroma is so terrible already it is not at all obvious when it has been blurred across 4 lines instead of only 2.
Do you mean that de-interlacing and encoding in progressive yv12 is not really useful for VHS sources ?

[Music Fan]

You wouldn't want to keep interlaced chroma after deinterlacing anyway, because the alternating lines of chroma will no longer match up with the new luma lines.
What do you mean exactly ? I guess anyway these problems are managed by de-interlacers, aren't they ?

On the other hand, you can just encode interlaced (using ConvertToYV12(interlaced=true)) and let your player deinterlace
That's a (not easy) choice I have to make, with the advantages and disadvantage I gave in 1st post.

That way you'll maximize the temporal smoothness without paying the penalty of keeping extra progressive lines.
Why maximize ? Do you mean it's better to let 25i in 25i than convert it in 50p (with qtgmc or other) ?

Of course, then you can't vertically resize.
Yes, but I don't plan to resize. Anyway the player makes resize after de-interlacing when output is set on 1080p.
Actually, the extreme method to avoid the (little) problems of real time de-interlacing and upscaling would be to convert 25i in 50p and upscale 720.576 in 1920.1080, but what a huge bitrate increase !

[Music Fan]

I still say, capture interlaced video in YUY2 if you can and convert it to YV12 near the end of the process. However, if the final format is only going to be interlaced YV12 it probably wouldn't make much if any difference to capture in interlaced YV12.
Ok, but as my capture card works in yuy2, the de-interlacing in yuy2 is tempting.

[Asmodian]

Do you mean this blending has to be done and is done automatically by de-interlacers (like qtgmc) ?
And when you say "to generate progressive YV12", I guess you mean from interlaced YV12, not from progressive yuy2.
My captures are done in yuy2, so if I de-interlace 25i to 50p in yuy2 and convert this progressive yuy2 in progressive yv12, I won't be concerned by this blending, right ?

Right, from interlaced YV12. Using YUY2 avoids the extra blending, this is why I want to capture in YUY2 and deinterlace before going to YV12.

From interlaced yuy2 I guess.
If the source is progressive yuy2 and if I have to encode it in interlaced yv12, do I still have to chose ConvertToYV12(interlaced="true") or ConvertToYV12() is enough (with an interlaced encoding like Pal movies on dvd) ?

I am not positive but I think you need to use ConvertToYV12(interlaced="true") for encoding progressive YV12 as interlaced. If the YUV -> RGB is done assuming interlaced it will use the color information as interlaced.

I don't understand what you mean : it's a bad idea to encode Interlaced YV12 if I plan to display it in progressive YV12 (de-interlacing being done by the player) ?

If you want store the video as interlaced YV12 this blending will have to happen on display to some degree. The blending is worse if you deinterlace first (interlaced YV12 -> progressive YV12) but some blending could be avoided if the player converted to YUY2/RGB first. It is a bad idea to use interlaced YV12 if you plan to store the video as anything other than interlaced YV12. Interlaced YV12 has more chroma blending after being displayed on a progressive display than progressive YV12 but you have to accept that if you want to keep the video stored as interlaced YV12.

What would be the benefit of a YV12 -> RGB/YUY2 and also of an interlaced YV12 to progressive YV12 conversion ?
I won't de-interlace the files that I plan to encode in interlaced YV12, and those I plan to encode in 50p will be converted in yv12 from yuy2 sources (progressive after de-interlacing), so I guess I won't meet the situation you describe.

Yes probably best to ignore me for this bit, just me wandering off on a tangent. :o

Do you mean with JDL_UnfoldFieldsVertical that flattens the fields ?
And why should it be converted to yuy2 ? My captures are already in yuy2.

Well if you want to capture interlaced YV12 and do a trick to store it as progressive YV12 you don't need JDL_UnfoldFieldsVertical, just encode as progressive YV12, open in Avisynth, and tell it to convert to YUY2 or RGB as interlaced. You don't want to do this anyway so this is more down that tangent.

Astonishing, I read that it was only yv12 compatible (written in 2010) ;
http://forum.videohelp.com/threads/318382-Lagarith-or-x264-lossless?p=1971276&viewfull=1#post1971276

Was he wrong or it changed after 2010 ?

Maybe talking about the vfw version of x264? I don't know but at this moment x264 supports this list of color spaces for input:
Raw: i420, yv12, nv12, i422, yv16, nv16, i444, yv24, bgr, bgra, rgb
lavf: yuv420p, yuyv422, rgb24, bgr24, yuv422p, yuv444p, yuv410p, yuv411p, gray, monow, monob, pal8, yuvj420p, yuvj422p, yuvj444p, xvmcmc, xvmcidct, uyvy422, uyyvyy411, bgr8, bgr4, bgr4_byte, rgb8, rgb4, rgb4_byte, nv12, nv21, argb, rgba, abgr, bgra, gray16be, gray16le, yuv440p, yuvj440p, yuva420p, vdpau_h264, vdpau_mpeg1, vdpau_mpeg2, vdpau_wmv3, vdpau_vc1, rgb48be, rgb48le, rgb565be, rgb565le, rgb555be, rgb555le, bgr565be, bgr565le, bgr555be, bgr555le, vaapi_moco, vaapi_idct, vaapi_vld, yuv420p16le, yuv420p16be, yuv422p16le, yuv422p16be, yuv444p16le, yuv444p16be, vdpau_mpeg4, dxva2_vld, rgb444le, rgb444be, bgr444le, bgr444be, y400a, bgr48be, bgr48le, yuv420p9be, yuv420p9le, yuv420p10be, yuv420p10le, yuv422p10be, yuv422p10le, yuv444p9be, yuv444p9le, yuv444p10be, yuv444p10le, yuv422p9be, yuv422p9le, vda_vld, gbrp, gbrp9be, gbrp9le, gbrp10be, gbrp10le, gbrp16be, gbrp16le

Maybe output color spaces are more relevant:
i420, i422, i444, rgb

Do you mean that de-interlacing and encoding in progressive yv12 is not really useful for VHS sources ?

No, just that if you capture in interlaced YV12 and then deinterlace to progressive YV12 it isn't obviously worse than if you capture in YUY2 and deinterlace to progressive YV12. This is because the chroma is already so bad on VHS a 4 line blending isn't obvious. I still say no reason to do more damage to the poor chroma but I did get some pushback before based on this point.

Why maximize ? Do you mean it's better to let 25i in 25i than convert it in 50p (with qtgmc or other) ?

I am pretty sure foxyshadis simply meant you get to keep the full motion resolution (maximize temporal smoothness) without needing to convert to 50p, not that temporal smoothness was better at 25i vs 50p.

I have noticed 50p doesn't take too much more bitrate than 25i if the 25i is a bit noisey and the 50p was created with QTGMC, QTGMC's denoising and other post-processing helps with bit rate a lot.

[Music Fan]

Thanks for all your responses :thanks:

If you want store the video as interlaced YV12 this blending will have to happen on display to some degree. The blending is worse if you deinterlace first (interlaced YV12 -> progressive YV12) but some blending could be avoided if the player converted to YUY2/RGB first.
I see, so if de-interlacing has to be done (if I plan to encode in progressive), it is always better to go through a yuy2 step, whatever the source is in yv12 or yuy2.
If it is ;
-interlaced yuy2 (as my captures) : just de-interlace (and then possibly convert to yv12 if needed)
-interlaced yv12 (as tv, dvd or Blu-ray sources) : convert to interlaced yuy2 and de-interlace (and then possibly convert to yv12 if needed)
Right ?

Well if you want to capture interlaced YV12 and do a trick to store it as progressive YV12 you don't need JDL_UnfoldFieldsVertical, just encode as progressive YV12, open in Avisynth, and tell it to convert to YUY2 or RGB as interlaced.
Ok but I was talking about x264 encoding : if one has to encode in 4.2.0 x264 for some reasons and if the source is 4.2.2, I believe JDL_UnfoldFieldsVertical could be useful because the interlaced yv12 step could be avoided if the script has this order ;
interlaced yuy2 source
JDL_UnfoldFieldsVertical(flip=true)#becomes sort of progressive
ConvertToYV12()#not ConvertToYV12(interlaced="true") because it's supposed to be progressive
and encode in progressive yv12 x264.
But of course, to be watchable, the JDL_FoldFieldsVertical(flip=true) step should be used when opening this x264 file (to weave the fields), maybe preceded by a ConvertToYUY2() step to weave the fields in yuy2.

Maybe output color spaces are more relevant:
i420, i422, i444, rgb
Interesting, I guess these options are not that old. But I believe standalone players only accept yv12.

I have noticed 50p doesn't take too much more bitrate than 25i if the 25i is a bit noisey and the 50p was created with QTGMC, QTGMC's denoising and other post-processing helps with bit rate a lot.
Good news, how many more percent in 50p ; 30, 40 ?
I guess QTGMC's denoising is done in progressive, after de-interlacing, which means de-interlacing is done on noisy pictures, which is not ideal.
If the interlaced source is noisy, I believe using JDL_UnfoldFieldsVertical(flip=true) can be helpful, even when one needs progressive at the end of the process, because denoising filters are used on (sort of) progressive source, which can facilitate the de-interlacing work and give better results.
The script would look like this ;
interlaced source
JDL_UnfoldFieldsVertical(flip=true)#becomes sort of progressive
denoising filters
JDL_FoldFieldsVertical(flip=true)#becomes interlaced again
qtgmc()

[foxyshadis]

QTGMC (and the other fancy mo-comp deinterlacers) actually denoise during deinterlacing. I wouldn't worry too much about min-maxing the deinterlacing; qtgmc already does that step internally, creating a cleaner source to match from. The EDI step alone contributes significantly to denoising, and the mocomp further reduces the presence of noise. Beyond that, QTGMC gives you lots of toggles on how and how much to reduce the noise beforehand, and how much to restore after. The full docs have lots of detail, at some point they'll have to be adapted onto avisynth.nl.

[Asmodian]

I see, so if de-interlacing has to be done (if I plan to encode in progressive), it is always better to go through a yuy2 step, whatever the source is in yv12 or yuy2.
If it is ;
-interlaced yuy2 (as my captures) : just de-interlace (and then possibly convert to yv12 if needed)
-interlaced yv12 (as tv, dvd or Blu-ray sources) : convert to interlaced yuy2 and de-interlace (and then possibly convert to yv12 if needed)
Right ?

If you plan to end at progressive YV12 and are starting with interlaced YV12 I don't think going through YUY2 will help, all the blending will happen by the time the video is displayed either way. I suppose the deinterlacer might do a better job with YUY2 but it also might do a better job with YV12, one can never trust deinterlacers. :p

Interesting, I guess these options are not that old. But I believe standalone players only accept yv12.

True, it has only been a few years. Standalone players don't like odd tricks either; standard YV12 or nothing. ;)

Good news, how many more percent in 50p ; 30, 40 ?

Yes? More and less too... sorry very source dependent and I have never tried coming up with a rule of thumb, it would be so variant as to not be very helpful on an individual case. I like "not too much" because it implies an acceptable tradeoff while not tying me down to anything.

I guess QTGMC's denoising is done in progressive, after de-interlacing, which means de-interlacing is done on noisy pictures, which is not ideal.
If the interlaced source is noisy, I believe using JDL_UnfoldFieldsVertical(flip=true) can be helpful, even when one needs progressive at the end of the process, because denoising filters are used on (sort of) progressive source, which can facilitate the de-interlacing work and give better results.
The script would look like this ;
interlaced source
JDL_UnfoldFieldsVertical(flip=true)#becomes sort of progressive
denoising filters
JDL_FoldFieldsVertical(flip=true)#becomes interlaced again
qtgmc()

I am not sure I would agree with this. In my experience deinterlacing with QTGMC works best if performed on as original a source as possible, you don't want to change the fields at all as that tends to confuse it. I also wouldn't assume the behavior of QTGMC, it is a quite complex script.

JDL_FoldFieldsVertical(flip=ture) could be useful for spatial filters but usually I wouldn't denoise before QTGMC. I also understand most denoising is done on fairly small blocks. Wouldn't the output be almost identical between JDL_FoldFieldsVertical(flip=true) and SeparateFields()? Only the very bottom edges would have an influence on the other field. Edit: Actually I guess JDL_FoldFieldsVertical() is more useful for temporal filters as you would need SeparateFields().SelectEvery() to keep top and bottom fields from interacting without it.

Anyway that is moving a bit off topic, feel free to experiment with JDL_FoldFieldsVertical() at worst it shouldn't do any harm.

[Music Fan]

QTGMC (and the other fancy mo-comp deinterlacers) actually denoise during deinterlacing.
Avisynth can't make two things at the same time and I guess qtgmc, like all Avisynth scripts, work in a certain order and denoising is probably done after de-interlacing.
Anyway, make denoise (the way I explained in my previous post) before de-interlacing with qtgmc could be interesting to compare results with denoise done by qtgmc.
The results may not differ a lot but in case temporal filters are needed on interlaced sources that one don't plan to de-interlace, I believe JDL_UnfoldFieldsVertical stay a good trick.

[Music Fan]

If you plan to end at progressive YV12 and are starting with interlaced YV12 I don't think going through YUY2 will help, all the blending will happen by the time the video is displayed either way. I suppose the deinterlacer might do a better job with YUY2 but it also might do a better job with YV12, one can never trust deinterlacers.
In this case, when is the yv12 to yuy2 conversion useful ?

[Asmodian]

Anytime you end at something other than progressive YV12? For display you would end at RGB.

[Asmodian]

Avisynth can't make two things at the same time and I guess qtgmc, like all Avisynth scripts, work in a certain order and denoising is probably done after de-interlacing.
Anyway, make denoise (the way I explained in my previous post) before de-interlacing with qtgmc could be interesting to compare results with denoise done by qtgmc.
The results may not differ a lot but in case temporal filters are needed on interlaced sources that one don't plan to de-interlace, I believe JDL_UnfoldFieldsVertical stay a good trick.

Actually QTGMC denoises before deinterlacing, as I said do not assume when it comes to QTGMC. During is actually probably more accurate as it doesn't necessarily use the video information it uses to make decisions as the final output.

[Music Fan]

Actually QTGMC denoises before deinterlacing
Astonishing, I often read that it had to be done on progressive frames.
What are the filters used by qtgmc ?

During is actually probably more accurate as it doesn't necessarily use the video information it uses to make decisions as the final output.
I don't understand very well what you mean, could you detail ?

[TheSkiller]

(Q)TGMC does not denoise on purpose, it is a side effect of the way the deinterlacing works. In QTGMC there are options to apply additional denoising on top of that using FFT3D filter by default. There are also options to add back a customizable amount of the source's original grain and/or noise to reduce or eliminate the sometimes undesireable denoising side effect.

[foxyshadis]

Astonishing, I often read that it had to be done on progressive frames.
What are the filters used by qtgmc ?

Like I said, it's all in the fine manual. I finally had a chance to put it on the wiki (http://avisynth.nl/index.php/QTGMC#Noise_Bypass_.2F_Denoising), too.

[Reel.Deel]

Like I said, it's all in the fine manual. I finally had a chance to put it on the wiki (http://avisynth.nl/index.php/QTGMC#Noise_Bypass_.2F_Denoising), too.

Aha, so it was you! :) Thanks foxyshadis, believe or not you're the first person (other than Wilbert) to add a full page to the wiki since it move to avisynth.nl (sad but true).

[Music Fan]

Like I said, it's all in the fine manual. I finally had a chance to put it on the wiki (http://avisynth.nl/index.php/QTGMC#Noise_Bypass_.2F_Denoising), too.
Thanks.
If I read carefully ;
-2 filters are used to denoise : dfttest and fft3dfilter (one or the other)
-NoiseProcess(0) removes completely all denoising operations
-NoiseProcess(1) denoise source, which means before de-interlacing ?

But you wrote ;
The use of multiple temporal smooths means that this script denoises by default.
As default value for NoiseProcess is 0, isn't it contradictory ?

[foxyshadis]

Thanks.
If I read carefully ;
-2 filters are used to denoise : dfttest and fft3dfilter (one or the other)
-NoiseProcess(0) removes completely all denoising operations
-NoiseProcess(1) denoise source, which means before de-interlacing ?

But you wrote ;

As default value for NoiseProcess is 0, isn't it contradictory ?

QTGMC is a thousand lines long, even if half of them are documentation and setup, it's not a binary "before" or "after". Denoising occurs during deinterlacing at several points and keeps more detail or removes noise better than anything you can do purely beforehand. Instead of denoise+deinterlace, it's a many-step process, and you can often significantly raise final output quality by adjusting its knobs rather than pre-denoising.

That's actually the manual vit wrote, some of it is a little harder to follow, especially the source match section, but that means stronger noise processing is only enabled if you enable it.

If you want to exploit QTGMC beyond the basics, I implore you to learn what it does and can do instead of assuming it does something and trying to work around that. The basic steps of QTGMC are: Dumb bob, strong smooth, restore details, strong spacial blur for better matching, mo-comp and/or filter denoise, restore detail, EDI bob, strong mo-comp smoothing, mo-comp denoise, again restore detail, optionally restore even more details (source match), sharpen and fix EDI failures, a light mo-comp smoothing, motion-blur removal, and finally detail restoration. (At this point it can also add in extra motion blur.)

[Music Fan]

Thanks, I will have to read its manual, and I guess the use of qtgmc is nearly obligatory to de-interlace with avisynth as it is probably the best script for this (and other operations).

edit : by the way, do you know if a yv12 to yuy2 conversion can help qtgmc to raise quality of de-interlacing ?