Stickboy's JDL functions - can this script mangle interlacing??

[jeffy]

I have the question, can this script mangle the interlacing of the source (it is purely interlaced)? Thank you.

import("LRemoveDust_YV12.avsi")
import("jdl-util.avsi")
import("jdl-interlace.avsi")
mpeg2source("clp.d2v",idct=4)
JDL_UnfoldFieldsVertical(true)
DeGrainMedian(mode=4)
LRemoveDust_YV12(17,1)
JDL_FoldFieldsVertical(true)

The rest of the code:
yadif(mode=2)
DCTFilter(1,1,1,1,1,0.75,0.25,0)


LRemoveDust_YV12.avsi
function LRemoveDust_YV12(clip input, int clmode, int "limit")
{
limit=default(limit,2)
clmode=default(clmode,17)
repmode = 2
clensed = Clense(input)
rep = Repair(clensed, input, mode=repmode)
rg = RemoveGrain(rep, mode=clmode)
return LimitChange(rg, input, limit)
}

two other AVSi files:
http://avisynth.org/stickboy/

[stickboy]

If you're using YV12, then yeah, my JDL_UnfoldFieldsVertical function would lose chroma resolution. OTOH, if you're using YV12, you've already lost important chroma resolution, so in some sense it's already kind of mangled IMO.

You probably should convert to YUY2 first if possible (although I'm guessing that LRemoveDust_YV12 requires YV12...)

[Didée]

Why should JDL_UnfoldFieldsVertical lose chroma resolution? If you do SeparateFields().Weave(), you don't lose anything.
Isn't JDL_UnfoldFieldsVertical just a shorthand for

SeparateFields()
Stackvertical(SelectEven,SelectOdd)

?

[stickboy]

Well, I admittedly don't do much work in YV12, so maybe I don't understand how luma and chroma data is stored for field-based YV12 video.

If there's only one line of chroma for every two lines of luma, what does SeparateFields do when it tries to select every other line? And what does Weave do when it tries to reconstruct a frame with the lines repositioned?

[Didée]

If nothing else brings me six feet under, interlaced YV12 will. :)

The storage of chroma samples is the same for framebased and fieldbased YV12. Different is the interpretation, and how the samples are constructed when the interlaced YV12 is created.

In YV12i, the 1st line of chroma samples corresponds to the luma lines 1 & 3, the 2nd chroma line corresponds to luma lines 2 & 4, and so on. That's YV12-interlaced chroma sampling.
After field separating, the 1st chroma line corresponds to lines 1 & 2 of the 1st field, the 2nd chroma line corresponds to the lines 1 & 2 of the 2nd field, and so on. That's normal progressive-YV12 chroma sampling within the (progressive) fields.

Interlaced YV12 is evil and all, but at least Separating + Weaving can be done without loss.

[IanB]

In YV12i, the 1st line of chroma samples corresponds to the luma lines 1 & 3, the 2nd chroma line corresponds to luma lines 2 & 4, and so onAlso important to note for TFF chroma lines 1, 3, 5, ... are for time t1 and chroma lines 2, 4, 6, ... are for time t2 (16.6 or 20 millseconds later). For a purely static image you can treat YV12i as YV12p - See Dons AutoYUY2 filter.

...normal progressive-YV12 chroma sampling within the (progressive) fields.For the most part this is an acceptable simplification. However for correlative functions you may need to take the alternating vertical postioning into account. i.e. top field the chroma is closer to line 1, for bottom fields the chroma is closer to line 2.

[jeffy]

Thank you very much to you all, I honestly still don't fully understand this:
- the D2V index file is created for MPEG-2 videos recorded by Hauppauge PVR-350 or from the DVD VOB files

- then the fields are unfolded
JDL_UnfoldFieldsVertical(true)

- the result is denoised
DeGrainMedian(mode=4)

- and cleaned
LRemoveDust_YV12(17,1)

- the fields are folded
JDL_FoldFieldsVertical(true)

Can there be some problem with all the script lines above before the actual deinterlacing with the Yadif filter? Could the interlacing lines be damaged and then misplaced/misaligned in result by Yadif? Or are you really sure the result will be correct? Thank you again.

- then deinterlaced
yadif(mode=2)

- then DCT filtered
DCTFilter(1,1,1,1,1,0.75,0.25,0)

[Didée]

Thanks for clarifying. I wanted to keep it simple, for giving the idea in respect to the posed question.

Also, I'm not that saddle-fast of the details of this darned thing called interlaced YV12. For example:
For a purely static image you can treat YV12i as YV12p - See Dons AutoYUY2 filter.
That's one point that still confuses me. If there is a "perfectly static" scene in an interlaced YV12 source, isn't it so that the chroma lines are still "weaved"? The sampling scheme is still 1+3/2+4/..., no matter if there is motion or not. Doesn't this mean that in a color gradient, even if there's no motion at all, there should be some kind of chroma combing to be seen?

[scharfis_brain]

Didée, you will see some slight aliasing/stairstepping, if you weave interlaced YV12 (ie. treat as progressive YV12).
this is due to the 1+3/2+4 sampling scheme as you pointed out correctly.
but weaving interlaced yv12 in non motion areas and then upsample it progressively is still better than do the plain dumb interlaced upsampling/treatment.

that's why the best (O_o rule-broken :p ) method to sample between YUY2 and YV12 is bob-deinterlacing the chroma with a good deinterlacer (ELA/EDI helps a lot here); scaling the chroma planes to fit the dimensions of the destination colour space and then refitting them.

The functions are old, but I think you get what's going on there:
http://forum.doom9.org/showpost.php?p=618364&postcount=1

[IanB]

@Jeffy,

Sorry to hijack your thread with our uber-techy discourse.

With the filters you propose, there should be no problem. The issue is to avoid damaging any edges (warping type filters) in the image while it is field separated (JDL_UnfoldFieldsVertical).

If the edges are distorted then the deinterlacer can become confused about what is moving (combed) and what is static (no need to fiddle).


@Didée, scharfis_brain,

I find it helps to consider the original source of the image, probably these days a CCD device, 720x576 pixels. 50 times a second the image is sampled. At this point you might consider it 576P/RGB24.

Lines 1, 3, 5, ... can be sampled to produce the luma values for the Top field, 20ms latter lines 2, 4, 6, ... can be sampled to produce the luma values for the bottom field.

Now for the chroma, lines 1+2, 5+6, 9+10, ... can be sampled to produce the values for the top field, 20ms latter lines 3+4, 7+8, 11+12 can be sampled to produce the values for the bottom field.

Now a real camera may or may not actually work this way, but I find it a useful mental model . For a telecine machines this model is exactly correct, it samples a full progressive image 24 times a second, latter a 3-2 pulldown is applied and starts the fun YV12i machinations.

[jeffy]

@Jeffy,

Sorry to hijack your thread with our uber-techy discourse.



No need to apologize, I think all these details might help someone else in the future and they are really interesting.

[2Bdecided]

@Didée, scharfis_brain,

I find it helps to consider the original source of the image, probably these days a CCD device, 720x576 pixels. 50 times a second the image is sampled. At this point you might consider it 576P/RGB24.

Lines 1, 3, 5, ... can be sampled to produce the luma values for the Top field, 20ms latter lines 2, 4, 6, ... can be sampled to produce the luma values for the bottom field.

Now for the chroma, lines 1+2, 5+6, 9+10, ... can be sampled to produce the values for the top field, 20ms latter lines 3+4, 7+8, 11+12 can be sampled to produce the values for the bottom field.

Now a real camera may or may not actually work this way, but I find it a useful mental model.No, I think it could be misleading.

I have no idea how a camera works, but in most professional SD content, it's 4:2:2 interlaced until the final encode(s!). So it's interlaced, and then converted to YV12. Your "mental model" assumes that it's progressive at the point the YV12 is originated - which means you use data (chroma from the "other field" lines) as a source for the interlaced chroma which is not actually present in an interlaced signal.

In other words, it can't possibly work that way in an all interlaced system (i.e. SD broadcasting).

So for most content, the line 1 chroma really is for lines 1 and 3. It can have no knowledge of line 2 from the original progressive image (even if such a thing was ever read from the original CCD) because that line is thrown away long before the colour is converted to YV12.

Cheers,
David.

[2Bdecided]

To the original poster:

Probably dumb question from me: why are you doing it like that? Is it speed? It seems you could do Yadif first and then just work with frames throughout.

I tried using mc_spuds in a field separated way, and it produced combing when subsequently deinterlaced. There was nothing "wrong" with the script, but the source (analogue video) had slightly different noise characteristics in the two fields. With the noisy original, this was barely noticeable, and didn't interfere with deinterlacing. However, the "cleaned" fields were sufficiently (and consistently / stabily) different to cause problems.

So I had to bob, then process, even though I wanted an interlaced output. Of course, with a motion compensated process, this is always best, but I was hoping to cheat - it didn't work. I don't think you have any motion compensation in your script, but if you have some weird field differences to start with which are increased by the filters, or the filters simply do "too much" without proper reference to the other field, then it could give a kind of combing. Or there could just be a bug!

Cheers,
David.

[IanB]

No, I think it could be misleading.I would hope not, it is only a model to contrast the ideal and the actual.

... in most professional SD content, it's 4:2:2 interlaced until the final encode(s!). So it's interlaced, and then converted to YV12.Yes this is true, and it is a compromise on what would be ideal. Interlacing is a compromise. Chroma subsampling is a compromise. And to unwind both we need to understand it. I hoped my model might help here.

Your "mental model" assumes that it is progressive at the point the YV12 is originated - which means you use data (chroma from the "other field" lines) as a source for the interlaced chroma which is not actually present in an interlaced signal.In an absolutly ideal world my model would be the case, the data was present in the real world, ideal YV12i sampling could use this discarded data.

But with interlaced sampling we know that the data is not present. We can use a mental model of the ideal so we can understand where the compromises are, how they effect the results and by how much.

So for most content, the line 1 chroma really is for lines 1 and 3.But mostly line 1. Line 3 really has little chroma information belonging to it. Likewise for the other field line 4 "owns" the chroma, line 2 comes along for the ride.

In the end the compromises are valid, the eye cannot usually discern that the chroma has been badly mangled. In the cases where the compromise is noticed, a model such as the one I proposed serves to expose and understand the shortcomings.

As I noted at the end of my previous post, the model can be valid for a telecine machine. I am not saying telecine machines actually work this way. I am saying telecine machine could take good advantage of this model to improve there output. i.e. Progressive YUY2 to YV12 conversion has advantages with film sources when the target is interlaced. And I believe this is actually the case with domestic DVD players when playing progressive encoded MPEG2 with RFF flags to do the 3-2 pulldown.

[jeffy]

To the original poster:

Probably dumb question from me: why are you doing it like that? Is it speed? It seems you could do Yadif first and then just work with frames throughout.
Cheers,
David.

David, the reason is not speed. Although I can't explain it very well, the noisy TV captures (analog PAL broadcast encoded in MPEG-2 via PVR-350 hardware encoder chip) if done this way (2 examples below) look visually worse (to me) than the JDL variant. If anyone is willing to compare, can you see the differences with your sources in these 3 methods?

import("LRemoveDust_YV12.avsi")
mpeg2source("clp.d2v",idct=4)
DeGrainMedian(mode=4,interlaced=true)
yadif(mode=2)
LRemoveDust_YV12(17,1) #after Yadif
DCTFilter(1,1,1,1,1,0.75,0.25,0)

or another:

import("LRemoveDust_YV12.avsi")
mpeg2source("clp.d2v",idct=4)
yadif(mode=2)
DeGrainMedian(mode=4) #after Yadif
LRemoveDust_YV12(17,1) #after Yadif
DCTFilter(1,1,1,1,1,0.75,0.25,0)

Compare with the JDL code in the first post.

[2Bdecided]

Ian,

I guess it doesn't help my brain (at least) if you invent yet another set of pixels for the interlaced chroma to be sourced from, given that MPEG-2 and DV are already (supposed to) use different pixels to source the YV12 interlaced chroma from each other!

Cheers,
David.

P.S. for the confused...
http://en.wikipedia.org/wiki/Chroma_subsampling
...includes nice pictures of what can go wrong.

[IanB]

David,

That is the issue, I am not inventing another set of pixels, I am offering a model of how the existing pixels should be in an ideal world. (Note the model is for interlaced MPEG-2). Once you have the model in your head, you should be able to better appreciate things like 75%/25% - 25%/75% sampling from 4:2:2 formats like YUY2, why using progressive mode conversion on static parts of an image has merit and why CUE (Chroma Upsampling Error) is such a problem.

Now DV is a different beast the Cr and Cb are sampled alternately by line within a field.

Regards
IanB