Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
16th July 2008, 12:56 | #81 | Link | ||
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Quote:
(BTW, yes the wrapper is missing the b,c parameters) Quote:
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
||
16th July 2008, 14:52 | #82 | Link | |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
Quote:
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)
__________________
now playing: [artist] - [track] ([album]) |
|
16th July 2008, 16:38 | #83 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
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. |
20th July 2008, 07:17 | #84 | Link | |
Registered User
Join Date: Jul 2006
Posts: 120
|
Quote:
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. |
|
21st July 2008, 01:51 | #85 | Link |
Registered User
Join Date: Jul 2006
Posts: 120
|
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: Code:
DirectShowSource("hd.m2ts", audio=false) AssumeTFF() # Choose one of these #Bob() #Yadif(mode=1) LanczosResize(720,480) AssumeTFF() SeparateFields() SelectEvery(4,0,3) Weave() Code:
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() Code:
*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 Code:
HCenc.exe -ini HC-hd.ini -i hd-video-yadif.avs -o hd-yadif.m2v -log hd-yadif.log -frames all Last edited by florinandrei; 22nd July 2008 at 17:33. Reason: no shimmering |
21st July 2008, 08:58 | #86 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
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. Last edited by henryho_hk; 21st July 2008 at 16:38. Reason: Grammar ~~~~ |
21st July 2008, 13:22 | #87 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
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... Code:
Bob() assumetff() LanczosResize(704,480) blur(0.0,1.0) separatefields().SelectEvery(4,0,3).Weave() 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... Code:
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() Cheers, David. |
21st July 2008, 16:16 | #88 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Code:
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) - 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. |
|
21st July 2008, 16:37 | #89 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
No. IanB's initial code for interlaced resizing is correct. Period.
Look once more at it: Code:
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.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
21st July 2008, 16:58 | #90 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
@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. Last edited by Gavino; 21st July 2008 at 17:41. |
21st July 2008, 18:05 | #92 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
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. Last edited by 2Bdecided; 21st July 2008 at 18:09. |
21st July 2008, 23:40 | #93 | Link | |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
Code:
// 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)); 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) Last edited by IanB; 23rd July 2008 at 23:15. Reason: Yell a little louder ;) |
|
22nd July 2008, 18:06 | #94 | Link | ||||||
Registered User
Join Date: Jul 2006
Posts: 120
|
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. 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. Quote:
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". Quote:
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? Quote:
Quote:
Quote:
Quote:
|
||||||
22nd July 2008, 18:19 | #95 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
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. Last edited by 2Bdecided; 22nd July 2008 at 18:22. |
|
23rd July 2008, 02:43 | #96 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
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()? |
23rd July 2008, 05:49 | #97 | Link | |
Registered User
Join Date: Jul 2006
Posts: 120
|
Quote:
I'll have to try this. |
|
23rd July 2008, 08:24 | #98 | Link |
Registered User
Join Date: Jul 2006
Posts: 120
|
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. |
23rd July 2008, 10:26 | #99 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
Most people watching your video aren't going to be looking at the technical quality anyway (unless the content is really boring!). Cheers, David. |
|
23rd July 2008, 17:37 | #100 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
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. |
|
|