HD 1080i to DVD (all interlaced) - how?

[Didée]

Originally Posted by IanB

@2Bdecided,As an exercise try to code up a script that behaves as your example does with the current Bob() rules.

I'm not quite sure if I get you ATM ... are you heading for the following almost-trivial wrapping code for Bob() ?
(BTW, yes the wrapper is missing the b,c parameters)

Originally Posted by MVBob by Scharfis_brain

# wrapping bob(), this means bicubic interpolation of fields
# this function also passed the Fieldorder information to the output,
# unlike bob() which always resetts the fieldorder to BFF.
# The current field stays untouched.

	Function DumbBob(clip Input, int "Height")
	{
		Input.Bob(0, 0.5, height = Height)
		GetParity(Input) ? AssumeTFF() : AssumeBFF()
	}

[Leak]

Originally Posted by IanB

There is no right answer. It came down to what was a more expected, practical and manageable behaviour. For me the pivotal argument was, that it is not trivial to copy the parity across the Bob() filter script wise, but it is easy for the filter to internally copy the input parity to the output clip. And it is easy script wise to ignore this action and keep the default behaviour.

But it's also perfectly possible to create a wrapper around LeakKernelBob that will feed it the order based on GetParity and use the correct AssumeXFF afterwards if you want that behaviour...

EDIT: Ugh, didn't notice there was another page where Didée already did (almost) exactly that... ^_^;;;

np: Boy Robot - Magic Toys For Girls And Boys (Rotten Cocktails)

[2Bdecided]

But that's a horrible bodge to fix an obvious bug. Much better to fix the bug itself.

...then if anyone still wants or needs to sprinkle their scripts with assumeXff, they can still do so.

...and those who don't need to think about field order, don't need to.

Cheers,
David.

[florinandrei]

Originally Posted by florinandrei

Yadif(mode=1, order=1).

On the big progressive screen, the power lines hanging in the air are a bit jagged. This could be just the limit of the deinterlacer on the Playstation3, which is usually very good but I assume is not perfect.

I'll try it on the native interlaced CRT - that should be the "make it or break it" test.

I just did that. The power lines are still a bit jagged. Maybe I forgot how the interlaced display is supposed to look like. But I remember that interlaced video on interlaced display is not supposed to look quite that jagged.

Here's what: tomorrow I'll go back to the same place. I'll take the HD camera, and also the old DV camera, and shoot the same scene with both. Then I'll convert the HD footage to SD and compare the two on an interlaced display. IMO, there should be no difference between the two, other than that the sequence originally made on HD should look better (better camera, then it's scaled down).

I'll let y'all know what happens.

[florinandrei]

EDIT: There was no "shimmering". Bad choice of words. It was aliasing. I'll reply below and explain.

I went back to the place with the power lines, two cameras in hand: HD and SD (DV Super8). Both cameras shoot 16:9. The SD camera is pretty cheap and amateurish.
The SD video was encoded to DVD/MPEG2 with no processing (other than ConvertToYV12(interlaced=true)). The HD video was converted to DVD by 3 methods: Bob()/Lanczos(), separatefields/shift/interleave, and Yadif()/Lanczos().
I made a DVD with all 4 clips and compared them on a regular 4:3 SD (480i) TV and a plain old DVD player connected via Component.

Both the TV and the DVD player have a "16:9" mode; I guess the TV in 16:9 will just scan a smaller area on the screen so as to match the 16:9 aspect ratio, while the DVD player in the 16:9 mode will simply fill the whole screen with video when playing a 16:9 DVD (will not letterbox).
So I have to either set both the TV and the DVD player to 4:3, or both to 16:9. The result is roughly the same, but in 16:9 mode a 16:9 DVD will look sharper (letterboxing is wasting scan lines, while in 16:9 there's no letterboxing).

Anyway, the results with the TV and DVD player in 16:9 mode:
Bob() and Yadif() look very similar. I can't really tell, visually, if there's a big difference (and Bob doesn't encode much faster than Yadif either). Thin horizontal lines (power lines hanging in the air) are shimmering a little bit when the camera moves vertically. If they are not perfectly horizontal, they also look a bit jagged.
Shift/interleave has zero shimmering/jaggies. However, I have a hard time telling whether it's more "soft" vertically than Bob(). I know on the computer screen shift/interleave looks soft. On the interlaced 480i "16:9" TV I don't think I can actually see a difference. What I do see might be due to my imagination. This was very surprising.
The native SD video looks more similar to shift/interleave than to Bob(). It has essentially zero shimmering/jaggies - well, it does have a very tiny amount, which might be due to the 4:1:1 color "softness" of the master format (DV), which produces nasty color shimmering on hard edges.

In 4:3 mode all videos shimmer a bit at the power lines. This is expected, since it maps a 480i video on a "300i" screen, or something like that.

Compared to what I see on the computer screen, the verdict after watching on the 480i TV is very surprising. Shift/interleave is the most similar to a full native 480i processing chain. It doesn't shimmer, just like native 480i, and unlike Bob or Yadif. And it's not softer vertically than Bob or Yadif - if there is any softness, I'll have to do a lot more tests to reveal it, and the vast majority of viewers will not likely notice it.

I would love to hear your comments.
What I don't quite understand is how shift/interleave looks so soft (vertically) on the computer as to seem almost deinterlaced :-) but on the native 480i screen it looks similar to the native 480i video. I know there's less resolution on the TV, but I'm pretty sure that's not the whole story.

Here are the MPEG2 files:

Bob:
http://dl.getdropbox.com/u/29966/hd2dvd/hd-bob.m2v
Shift:
http://dl.getdropbox.com/u/29966/hd2dvd/hd-shift.m2v
Yadif:
http://dl.getdropbox.com/u/29966/hd2dvd/hd-yadif.m2v
Standard def:
http://dl.getdropbox.com/u/29966/hd2dvd/sd.m2v

This is a typical bob .avs for converting HD to DVD:

DirectShowSource("hd.m2ts", audio=false)
AssumeTFF()
# Choose one of these
#Bob()
#Yadif(mode=1)
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

This is the shift/interleave .avs:

Global NewHeight=480
Global NewWidth=720

DirectShowSource("hd.m2ts", audio=false)
AssumeTFF()
SeparateFields()
Shift=(Height()/Float(NewHeight/2)-1.0)*0.25
Tf=SelectEven().LanczosResize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().LanczosResize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()

This is the .ini for HCenc for HD (the one for native SD is very similar). It's very high bitrate encoding, to maximize quality, but not quite CBR.

*MAXBITRATE       9500
*ASPECT           16:9
*PROFILE          best
*AUTOGOP          18
*CQ_MAXBITRATE    5.000
*AQ               4
*DC_PREC          10
*INTERLACED
*NOSCD
*MATRIX           fox1
*LUMGAIN          2
*PRIORITY         normal
*WAIT             1

This is how I encode:

HCenc.exe -ini HC-hd.ini -i hd-video-yadif.avs -o hd-yadif.m2v -log hd-yadif.log -frames all

[henryho_hk]

florinandrei,

Could you post a sample of the original DV avi somewhere?

NTSC DV 4:1:1 should be "sharp" vertically (coz 4:1:1 dun have vertical chroma sampling). I tend to believe the softness of sep-resize-int method is due to the resizing of alternate field lines as if they were adjacent to each other.

But then I dun understand why bob/resize/selectevery are shimmering on TV.

[2Bdecided]

A few comments...

Firstly, it's interesting - the "separate fields shift corrected" resize does surprisingly well, but it's not performing magic. What it's doing is blurring the image in the vertical dimension, while the bob resize is keeping it sharp.

It you _want_ to blur the image in the vertical dimension to get the same results from bob, this is pretty close...

Bob()
assumetff()
LanczosResize(704,480)
blur(0.0,1.0)
separatefields().SelectEvery(4,0,3).Weave()

It reduces the lanczos halos a little compared to no bluring, which you may or may not want. (I think they look quite ugly on the "separate fields shift corrected" version, being generated at a 240-line resolution rather than 480-line resolution).



Secondly, in my testing (not related to this thread), sources which cause a problem (e.g. shallow sharp lines, repeating fine patterns) benefit from softening in the vertical dimension before interlacing; other source do not (and look beter sharp). Broadcast cameras and format converters typically use a compromise, softening a little, but not enough to remove all aliasing. The place to tune and set this is in the progressive domain (in this case, the output of bob) - by doing the "separate fields shift corrected" trick, you can't alter what you're doing so easily.



Thirdly, I'm still not convinced by that "Shift" value calculation - it fails for the trivial case - i.e. if the new height is the same as the source height, it still tries to shift the image, which can't be right.

I think it should be...

avcsource("00000.dga")
assumetff()

NewWidth=704
NewHeight=480
amount_to_crop=((float(last.height)/float(NewHeight))*0.5)-0.5

separatefields()

Tf=SelectEven().lanczosresize(NewWidth,NewHeight/2,0,0,0,-amount_to_crop)
Bf=SelectOdd().lanczosresize(NewWidth,NewHeight/2,0,amount_to_crop,0,0)

Interleave(Tf, Bf)
Weave()

This gives a shift of 0.625, rather than 0.875, for the current case. The difference is nearly invisible, but I think it's the correct calculation in the general case. I'm sure someone will correct me if I'm wrong. I recall seeing some kind of correction in a thread, but can't find it - I figured out the above myself from first principles.

Cheers,
David.

[Gavino]

Originally Posted by 2Bdecided

I'm still not convinced by that "Shift" value calculation - it fails for the trivial case - i.e. if the new height is the same as the source height, it still tries to shift the image, which can't be right.

I think it should be...

...
amount_to_crop=((float(last.height)/float(NewHeight))*0.5)-0.5
separatefields()
Tf=SelectEven().lanczosresize(NewWidth,NewHeight/2,0,0,0,-amount_to_crop)
Bf=SelectOdd().lanczosresize(NewWidth,NewHeight/2,0,amount_to_crop,0,0)

I think you're on the right track (the trivial case proves the previous calculation was wrong), but I think it should be

amount_to_shift=((float(last.height)/float(NewHeight))*0.5)-0.5
# this is (total) required relative shift of odd v even in field-based co-ordinates
separatefields()
Tf=SelectEven().lanczosresize(NewWidth,NewHeight/2)
Bf=SelectOdd().lanczosresize(NewWidth,NewHeight/2, 0, amount_to_shift, 0, height)

Two points to note here:
- since the top field is not displaced by SeperateFields or Weave, it seems to me all the shift should be given to the bottom field;
- your solution was scaling an image of the wrong height, so changing the scale factor as well as shifting.

[Didée]

No. IanB's initial code for interlaced resizing is correct. Period.

Look once more at it:

Global NewHeight=480
Global NewWidth=720

DirectShowSource("hd.m2ts", audio=false)
AssumeTFF()
SeparateFields()
Shift=(Height()/Float(NewHeight/2)-1.0)*0.25
Tf=SelectEven().LanczosResize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height())
Bf=SelectOdd().LanczosResize(NewWidth, NewHeight/2, 0, Shift, Width(), Height())
Interleave(Tf, Bf)
Weave()

This code does NOT fail in the trivial case. When old_height == new_height, it calculates a shift of zero.

Note that in the "shift=..." line, "Height()" refers to the height of the field separated clip, which then is divided by the half of new_height. This division results to "1.0" in the trivial case. Proceed with 1.0 - 1.0 which equals zero. Zero times 0.25 is zero. Hence, the shift is zero for the trivial case.

BTW, it was me who "corrected" IanB in the shimmering bars thread, and I was wrong with that. I confused the shift correction needed for bobbing with the shift correction needed for interlaced resizing, which isn't the same. (For bobbing, you've to omit the "-1.0" from the shift correction term, subsequently resize to new_height/1, and omit the final weave().)

On this matter, IanB was correct from the very beginning.

[Gavino]

@Didée.

I took what 2bdecided said about the trivial case at face value, and didn't check back against the original, again working from first principles.

What I ended up with is basically the same as IanB's version, with the difference that I gave all the shift to the bottom fields instead of splitting it between top and bottom. Can you explain why this is wrong? (Note the distinction, as you pointed out, between this case and the usual bobbing one.)

EDIT: Is it something to do with the resizer being center-based rather than zero-based? I still don't quite see it though.

[2Bdecided]

Originally Posted by Didée

Note that in the "shift=..." line, "Height()" refers to the height of the field separated clip

Missed that, thank you.

Cheers,
David.

[2Bdecided]

My shift amount is equivalent to half a line in the final field, minus half a line in the original field (one line in the final frame, minus one line in the original frame).

Ian's shift amount is exactly half this.

Proof:
Ian's formula:
Shift=(Height()/Float(NewHeight/2)-1.0)*0.25
Before separate fields, height was double, hence this is equivalent to:
Shift = ((last.height/2)/(newheight/2) – 1.0) * 0.25
Shift = ((last.height)/(newheight) – 1.0) * 0.25
Shift = last.height/newheight*0.25 – 0.25

Which is exactly half of what I had:
amount_to_crop=((float(last.height)/float(NewHeight))*0.5)-0.5


I crop my value from the top of the bottom fields, and the bottom of the top fields. Of course this scales it - the distance from the first to last line in one field of the lower res picture is a shorter distance than from the first to last line in one field of the original higher res picture (think about it).

Ian crops his value from top of the bottom fields, and adds his value to the top of the top fields. This gives exactly the same inter-field offset as me at the top of the field, but an overall offset of 1/4 line per final field (1/2 line per final frame) relative to me at the top of the field. Ian is keeping 1/2 line per final field more picture data than me.


I don't state all this as fact. I state it as what I think at 6:03PM Monday evening - feel free to prove me wrong.

Cheers,
David.

[IanB]

Originally Posted by Gavino

EDIT: Is it something to do with the resizer being center-based rather than zero-based? I still don't quite see it though.

resample_functions.cpp:234

  // the following translates such that the image center remains fixed
  double pos;
...
  if (fir_filter_size == 1) // PointResize
    pos = subrange_start;
  else
    pos = subrange_start + ((subrange_width - target_width) / (target_width*2));

Yes the -ve shift of the top field is to undo the centre correction calculation inside the filter generator. And the +ve shift of the bottom field is the opposite. I discussed this with Wilbert in Cropping interlaced video = shimmering bars where I coined the term output uncrop.

One thing to remember here is we are going from a 1080i source to a 480i display, a 2.25 times reduction in height, there is so much excess information here it really won't matter how you convert it, as long as you do it correctly. In the smart Bob case it is more like a 4.5 times reduction.

Using dumb Bob followed by SeparateFields() is a way of cheating the Nyquist limit. Effectively you are doing a 540-(Bicubic)->480-(Point)->240 the Interlaced Resize method does 540-(Lanczos)->240 so the low pass filtering frequency is approximately double (point resizing does no anti-aliasing (low pass) filtering)

[florinandrei]

OK, first off, I made a bad choice of words. There was no "shimmering" on the horizontal lines with those algorithms. What I was seeing was aliasing, stair-stepping. Sorry about the confusion, English is not my native language.

I did more tests. This time I put the DVD in the PS3 and watched on the 1080p screen. Everything looked pretty similar to the native 480i screen actually.
Bob and Yadif suffer from aliasing on the almost-horizontal lines.
Shift/interleave is rock solid, zero aliasing, and I had a discussion with a friend who was watching with me - I said I think it's slightly more blurry on the vertical than the other clips, while he said it was my imagination. After watching repeatedly, I didn't know what to think anymore.
The native 480i video from the DV source actually had a little bit of aliasing on the big screen (unlike on the native 480i screen in 16:9 mode, where it was flawless), I guess due to the PS3's deinterlacing software.

I watched again everything on the interlaced CRT screen in 16:9 mode.
Bob and Yadif exhibit visible and annoying aliasing.
Shift/interleave has zero aliasing. Again, the same discussion: is it more blurry or not? I don't know if it's really blurry or it's just what I remember from the computer screen (on the computer it's clearly a bit blurry on the vertical). Even in 4:3 mode it still looked pretty good, maybe a hint of aliasing, barely noticeable if you know where to look.
The DV-source native 480i clip looks great in 16:9 mode (all 480 scan lines from the DVD are mapped onto 480 scan lines on the TV, since the scan area on the CRT is compressed vertically). There's some moderate aliasing in 4:3 mode (because there are 480 scan lines from the DVD mapped onto fewer than 400 lines on the TV).

I'm starting to realize just how bad the DV camera is. I wish I did the test with a better camera. Yes, it's just 480i, but even by that standard it's pretty lame.

Because this DVD will be watched on interlaced standard-def CRTs, most of them in 4:3 mode I guess, I am strongly inclined at this moment to just use shift/interleave and forget about Bob, Yadif and all that stuff. Unless somebody comes up with something new to try.

Originally Posted by henryho_hk

Could you post a sample of the original DV avi somewhere?

I'll go one step above that.

Here's the DV file:
https://dl.getdropbox.com/u/29966/hd2dvd/sd.avi

And here's the AVCHD file:
https://dl.getdropbox.com/u/29966/hd2dvd/hd.m2ts

Now y'all have all the master files, all the results, and the scripts I used to do the processing.

Funny how the HD file is about half the size of the standard-def file, yet it has a lot more information. The technology really moves forward I guess.

Originally Posted by 2Bdecided

Firstly, it's interesting - the "separate fields shift corrected" resize does surprisingly well, but it's not performing magic. What it's doing is blurring the image in the vertical dimension, while the bob resize is keeping it sharp.

Almost too sharp. There's aliasing in the image after bob that was not there before. I mean, compared to the native full end-to-end 480i chain, which looks perfect, bob clearly does something to the image, either adds some info, or removes something, or changes it, or a combination of the above.

Is it possible that the bob procedure is technically equivalent to an artificial sharpening?

Finally, my eyes tell me that bob needs "anti-aliasing". Isn't that essentially blur/softening? Are there ways to remove alias without making the image too soft?
Of course, this is all interlaced, which makes it pretty difficult to do anything. This forum needs a new icon - "I hate interlacing".

It you _want_ to blur the image in the vertical dimension to get the same results from bob, this is pretty close...

Bob()
assumetff()
LanczosResize(704,480)
blur(0.0,1.0)
separatefields().SelectEvery(4,0,3).Weave()

I'll try that, but honestly bob looks great on the computer screen. It's very sharp. If I could keep that and remove the jaggies...

And I'd rather use the other algorithm, if the result is the same, since it's faster. Or do you mean to tweak the blur to get an intermediate result?

It reduces the lanczos halos a little compared to no bluring, which you may or may not want. (I think they look quite ugly on the "separate fields shift corrected" version, being generated at a 240-line resolution rather than 480-line resolution).

What halos?

Secondly, in my testing (not related to this thread), sources which cause a problem (e.g. shallow sharp lines, repeating fine patterns) benefit from softening in the vertical dimension before interlacing; other source do not (and look beter sharp). Broadcast cameras and format converters typically use a compromise, softening a little, but not enough to remove all aliasing. The place to tune and set this is in the progressive domain (in this case, the output of bob) - by doing the "separate fields shift corrected" trick, you can't alter what you're doing so easily.

So, you're saying "do bob with softening while in progressive".

Originally Posted by IanB

One thing to remember here is we are going from a 1080i source to a 480i display, a 2.25 times reduction in height, there is so much excess information here it really won't matter how you convert it, as long as you do it correctly.

That's what I expected. Yet the differences are fairly visible between the various scripts.

Using dumb Bob followed by SeparateFields() is a way of cheating the Nyquist limit. Effectively you are doing a 540-(Bicubic)->480-(Point)->240 the IntResize method does 540-(Lanczos)->240 so the high pass filtering is approximately double.

OK, that was a bit more than I could parse in one gulp. Can somebody rephrase this please?

[2Bdecided]

Originally Posted by florinandrei

OK, that was a bit more than I could parse in one gulp. Can somebody rephrase this please?

That bit is what you're saying by "bob is too sharp", and I'm saying by "some people filter vertically before interlacing".

1080i-bob-then-resize is giving you 480 sharp lines which are perfect for weaving back together, but almost "too" sharp for interlaced display, and far too sharp for just looking at 240 of them (aliasing - higher frequencies than can be accurately represented).

The separated fields resizing is only giving you about 240-320 lines of resolution in the 480 output lines, but that's probably enough for interlaced display.

The problem/trade off is that interlaced display isn't just 240 out of 480, nor is it just all 480 perfectly weaved back together - it's a mish mash of the two depending on what your eyes (or the deinterlacer, on a progressive display) make of it.


Halos are, for example, white parts around the edge of black objects - you can see them above and below the power lines.

Cheers,
David.

[henryho_hk]

VCD used to be fairly good on CRT TV and they look terrible on computer CRT monitor. Now DVD looks bad on a 22" LCD monitor. Monitors are really engineered to reveal the bad side of images.

BTW, what if we use BiCublinResize (http://ziquash.chez-alice.fr/) or even BilinearResize for the vertical dimension after Bob()?

[florinandrei]

Originally Posted by henryho_hk

BTW, what if we use BiCublinResize (http://ziquash.chez-alice.fr/) or even BilinearResize for the vertical dimension after Bob()?

I was kind of thinking along the same lines. Use a dumb resize instead of a smart one. But perhaps that would be equivalent (to some extent) to Lanczos and then blur?

I'll have to try this.

[florinandrei]

I took the Yadif script and made some variations.

First off, I tried 3 different resizes: Bilinear, Lanczos, and Spline36.
Lanczos and Spline36 are very hard to distinguish. The Yadif/Lanczos script is exactly the one I posted above, and I commented it already (crisp but aliased).
Bilinear seems to be less crisp, aliasing is not quite so bad but still visible.

Then I did a Yadif/Lanczos, either plain, or followed by blur(0.0, x) where x = (0.25, 0.50, 0.75, 1.00)
Obviously, increasing the x makes the video more blurry and reduces aliasing. With 0.75 aliasing is almost completely gone and it's a bit blurry but not too bad. Even with x=1.0, there is still a very tiny amount of aliasing visible. It's not exactly the same like shift/interleave.

I guess I will have to compare shift/interleave with blur with x either 0.75 or 1.0.
But I can't do that right now, I think I just bricked my main computer with a BIOS update.

[2Bdecided]

Originally Posted by florinandrei

Even with x=1.0, there is still a very tiny amount of aliasing visible. It's not exactly the same like shift/interleave.

I thought that too. If you're happy with shift/interleave, and don't mind the halos, then I'd just use it.

Most people watching your video aren't going to be looking at the technical quality anyway (unless the content is really boring!).

Cheers,
David.

[henryho_hk]

Originally Posted by 2Bdecided

(unless the content is really boring!)

You remind me of those Blue-ray titles.

Suddenly I have one question on the shift correction. What does a negative "src_top" value mean for the resize? Does it mean a duplication of top pixels?

And.......... I still think that it's not a good idea to re-size the separated fields progressively as if the horizontal lines are laying on each other.