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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 2nd July 2008, 07:23   #21  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
@florinandrei,

Interlaced resizing is fast, but you pay a price for generating each new field based only on the original field. Any new pixels spacially between 2 original field lines will effectivly be a weighted average of only the pixels above and below in that field, i.e. a blur. Effectively all the pixels in the new fields are vertically blurred slightly.

Using the SmartBob/Resize/ReInterlace method, although slower, will give vastly superior results in static areas because each new field can be based on a full frame. In static areas there is no "spacially between 2 original field lines". Those new pixels are rendered from complete frame data. i.e. no blur in static areas.

Of course in motion areas any difference can be attributed to how good the SmartBob interpolates the missing pixels. If using linear interpolators like in KernelBob or DGBob there will be no difference to Interlaced Resizing. i.e. a blur again. If using Edge Directed and/or Motion Compensated interpolators then the results can be a significant step up from bog interlaced resizing.

And apart from everything else the eye has trouble seeing bluring of things in high motion, it attributes motion to the blur, instead of blur to the blur. So it is a little unfair to look at individual fields on a PC screen, you really should evaluate the results on an interlaced display device at normal speed.
IanB is offline   Reply With Quote
Old 2nd July 2008, 10:28   #22  |  Link
Alex_ander
Registered User
 
Alex_ander's Avatar
 
Join Date: Apr 2008
Location: St. Petersburg, Russia
Posts: 334
Quote:
Originally Posted by Blue_MiSfit View Post
LeakKernelBob is prety out of date
NNEDI is newer, but this doesn't mean it can replace the 'outdated' Kernel bobber for any type of image - it works differently. Theoretically, in case of an image being as sharp as HD pixel resolution provides, it simply can't work correctly. It throws away one of the fields at interpolation and this means it halves vertical sampling frequency for an image which demands twice higher value by discretization theorem (by Kotelnikov/Nyquist). To have an illustration to what could happen sometimes, imagine a radical case of image type: all even lines in a still HD frame are black and all odd ones are white. NNEDI would simply alternate black and white frames, while Kernel bobber would still work somehow since it uses data from both fields. Of course the problem doesn't appear with softer or upsampled images and NNEDI is good there.
Alex_ander is offline   Reply With Quote
Old 2nd July 2008, 10:36   #23  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by IanB View Post
Effectively all the pixels in the new fields are vertically blurred slightly.
Yes, demonstrably true, but...

1. You will then resize vertically to less than half the original resolution (or a little more than half the original resolution for "PAL") - that's a fair amount of blur!

2. You will then throw away half the remaining lines in each field to interlace the signal - that's a fair amount of lost information.

3. You will then rely on the deinterlacing in the display, if any, to restore those missing lines - or view on a native interlaced display, which will display inter-line twitter on sharp vertical details unless they are blurred before interlacing! Either way, you will be very lucky to see any extra detail you recovered with a "smart" bob.


As for "why not use X smart bobber - it's still fast?" – fast, yes, but everyone one I've seen (that counts as "fast") is prone to artefacts on something - sometimes quite nasty artefacts. The artefacts can be far more visible on the downconversion than any slight softness due to bobbing.

Of course mcbob to tgmc will do a better job and are almost always artefact free - but with these the slow down is considerable.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 2nd July 2008, 11:05   #24  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by Alex_ander View Post
To have an illustration to what could happen sometimes, imagine a radical case of image type: all even lines in a still HD frame are black and all odd ones are white. NNEDI would simply alternate black and white frames, while Kernel bobber would still work somehow since it uses data from both fields.
Your point is well made - NNEDI "needs" to be used with something that can weave both fields as-is when necesary.

However your extreme example is too extreme. In an interlaced system, that image is ambiguous - the original image (before interlacing) could equally well be one frame black, then one frame white - or it could be two identical frames with alternate black/white lines. There is no way of knowing which, other than assuming.

All "smart" deinterlacing is based on assumptions - basically that the content changes little field by field - the camera is still pointing at roughly the same scene. If every field was completely independent, then a dumb bob would be the best you could do.

There are interesting graphs on pages 23 and 24 of this...
http://www.snellwilcox.com/community...des/edecod.pdf
...and I don't claim to fully understand them(!) but the stars represent typical content - mostly low detail and low movement (the centre of the stars) but a little fine detail and significant movement (the "arms" of the stars). If you had lots of fine detail and significant movement - almost random content, the frequency response wouldn't look like a star, but more like a square (up to the Nyquist limits for each dimension).

If you turn the stars into squares in the progressive plot, they don't overlap. If you turn the stars into in the interlaced plot, they do overlap. That's the ambiguous region. Your example is right in the middle of the overlap.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 2nd July 2008, 12:03   #25  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
I've attached two pictures.

The first one compares the output of bob (dumbest bobber available!) and mcbob (smartest bobber available).

I've stacked the output vertically, resized to 704x480, and added limitedsharpenfaster since the OP seems to want a sharp output (I don't think it's necessary). The script is:
Code:
avcsource("00000.dga")
assumetff()

lanczosresize(704,last.height)

a=bob()
b=mcbob()
stackvertical(a,b)

lanczosresize(last.width,480*2)

limitedsharpenfaster()
The output of frame 5 is in progressive.jpg, and the advantages of mcbob on the telegraph cables is just visible if you look carefully. Also, they are slightly more stable in the mcbobbed version than the dumb bobbed version.

However, that's not what the OP wants to do - the OP wants interlaced output.

If you interlace the image, and then do your best to watch it (either on an interlaced display, or via a great deinterlacer like mcbob) then it becomes almost impossible to see any difference. Really. The lines look the same, and their stability is the same.

This is shown in interlaced.jpg, where I took the video shown in progressive.jpg, interlaced it, and then ran it through mcbob. This is the code:
Code:
avisource("dga test.avi")

assumetff()
separatefields().SelectEvery(4,0,3).Weave()

converttoyv12(interlaced=true)

mcbob()
Now the advantage of the first mcbob is hidden - you might as well use bob when deinterlacing HD content for an SD interlaced output. If anything, the softer output from the original bob deinterlaces better than the sharper original output from mcbob.

The advantage of better bobbers in HD is not visible in the interlaced SD output for this content.

btw, either way, it's too sharp vertically for interlaced displays IMO - if anything, it needs slight softening in the vertical direction before interlacing, if you expect to watch it on a CRT.

Cheers,
David.
Attached Images
  

Last edited by 2Bdecided; 2nd July 2008 at 12:11.
2Bdecided is offline   Reply With Quote
Old 2nd July 2008, 16:56   #26  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
florinandrei, while you are bothering with the interlacing stuffs, you may want to consider another issue: aspect ratio.

Do you find your encoded NTSC 16:9 DVD looking a bit "wider/fatter" than your original 1920x1080 source?

As far as I know, if we take the pixel aspect ratio of NTSC 16:9 DVD as 40:33, your 1920x1080 1:1 material will scale to 704x480 [704 = 1920*(33/40)*(480/1080)]; after left and right pads of 8 pixels each, you have 720x480. On the contrary, if you resize to 720x480 directly, the resultant DVD will look a bit "wider/fatter" than your source.

If you don't want to have two thin black bars on the two sides, you may crop 12 pixels from (both) the top and bottom, making it 1920x1056, before resizing to 720x480.

Last edited by henryho_hk; 2nd July 2008 at 17:05. Reason: Just notice that 2Bdecided is resizing to 704x480 too. ^_^
henryho_hk is offline   Reply With Quote
Old 2nd July 2008, 17:40   #27  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
I just go to 704 - it's a legal DVD resolution and saves confusion. It gets you the correct aspect ratio in software players and stand-alones (to within one pixel). No need to pad to 720.

http://forum.doom9.org/showthread.php?t=132378
http://forum.doom9.org/showthread.ph...87#post1100187

However, most pros go to 720, and don't care about the slight error which they sometimes introduce, and sometimes don't.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 2nd July 2008, 19:02   #28  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 120
OK, I'm starting to understand a few things.

Quote:
Originally Posted by IanB View Post
Interlaced resizing is fast, but you pay a price for generating each new field based only on the original field. Any new pixels spacially between 2 original field lines will effectivly be a weighted average of only the pixels above and below in that field, i.e. a blur. Effectively all the pixels in the new fields are vertically blurred slightly.

Using the SmartBob/Resize/ReInterlace method, although slower, will give vastly superior results in static areas because each new field can be based on a full frame. In static areas there is no "spacially between 2 original field lines". Those new pixels are rendered from complete frame data. i.e. no blur in static areas.
In this message, the interlaced resizing is the second script, right? If that's correct, what I don't understand is the usage of SeparateFields() - if the source is interlaced, what fields are there to separate? Aren't they already separated?
And bob is the first script? If that's the case your prediction appears correct, the second script seems to create output slightly blurred vertically, compared to the first one (at least on a computer and on the PS3 + flat panel).

Encoding speed has no importance to me. I prefer something that's very slow but very accurate. Encode once, watch forever - so better encode it right.

So, in that context, I guess you're saying: "use the first script but with the best bob you can find."

Quote:
Of course in motion areas any difference can be attributed to how good the SmartBob interpolates the missing pixels. If using linear interpolators like in KernelBob or DGBob there will be no difference to Interlaced Resizing. i.e. a blur again. If using Edge Directed and/or Motion Compensated interpolators then the results can be a significant step up from bog interlaced resizing.
So, again, to obtain that result I just need to use the best bob available with something similar to my first script? E.g., mcbob() or something like that. I guess it's possible to simply remove LeakKernelBob() and just drop in something else? Something like this?

Code:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
MCBob()
LanczosResize(720,480)
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()
ConvertToYV12()
Can that be called a very accurate interlaced resizer HD-to-DVD, for real-life video (not computer generated) with no scene changes?

Quote:
So it is a little unfair to look at individual fields on a PC screen, you really should evaluate the results on an interlaced display device at normal speed.
I know. I guess I need to revive the old CRT and DVD player. That's a much bigger "project" than it seems.
OTOH, the DVD will be watched on progressive displays too, not just on old CRT. So I can't neglect either.

Quote:
Originally Posted by 2Bdecided
Of course mcbob to tgmc will do a better job and are almost always artefact free - but with these the slow down is considerable.
Not a problem. Accuracy comes first.

Quote:
All "smart" deinterlacing is based on assumptions - basically that the content changes little field by field - the camera is still pointing at roughly the same scene.
That seems to be the case with the material I'm scaling. The source is an HD camera and there are no scene changes (a scene change is always the beginning of a new file).

Quote:
added limitedsharpenfaster since the OP seems to want a sharp output
My fault, I should have phrased it better. I guess what I'm after is "accuracy". If the original is sharp, I want that sharpness preserved, as much as the scale-down allows. But the result should not be subjectively "sharper" than the original.
What I want is a reduced-size copy that looks, statically and dynamically, as close to the original as possible, aside from the smaller resolution. The master is interlaced HD video captured with a camera (not computer-generated) and has no scene changes. The result will be watched on a variety of screens, from plain old CRT to new smart upscalers + progressive HD panels.

I am aware that there might be conflicting requirements hidden here (such as accurate statically and dynamically). If that's true, that's one of the things I'm hoping to learn from this discussion.
florinandrei is offline   Reply With Quote
Old 2nd July 2008, 19:11   #29  |  Link
florinandrei
Registered User
 
Join Date: Jul 2006
Posts: 120
To put "accuracy" in perspective: I'm shooting with a consumer-level camera, but it's tweaked to be as neutral as possible. It has a Cinema mode which gives a somewhat flatter, non-aggressive gamma curve (unlike the "torch mode" on most cheap cameras) and I also changed settings such as saturation, brightness, etc. to make the result as neutral as possible. If I need brighter colors or bigger contrast, that can be taken care of in post - and now I see AviSynth could be used for that (but that's not the subject of this discussion).

I guess I should really use a "prosumer" camera, but those are 5 times more expensive. Can't do that now.

So I don't need something that looks flashy or "sharp" to the average user. I need something that is close to the original.
florinandrei is offline   Reply With Quote
Old 2nd July 2008, 19:20   #30  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,986
I think you're taking a very good approach to this project. Kudos for sticking it out and trying to understand what's really happening, instead of throwing in the towel, copying and pasting a script, and being done with it. For reference, here's a little explanation of your script:

Code:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS")

#At this point, your video is untouched true 1080i

MCBob()

#Now, we've bobbed 1080i to 1920x1080 @ 59.94fps. 
#99.9% of your processing time will be spent here.

LanczosResize(720,480)

#Now we're down to 720x480 @ 59.94fps

AssumeTFF()
SeparateFields()

#Now we've pulled the progressive frames apart into 720x240 fields. 
#It's technically at 119.89fps, but that doesnt matter ATM

SelectEvery(4,0,3)

#Now we've decimated away half the information like this: 
#Input:   A B C D
#Output: A   C

#So, we're back to 59.94fps, still 720x240

Weave()

#Now we actually interlace the fields to produce interlaced frames. 
#So, we're at 720x480 @ 29.97i fps

ConvertToYV12()

#And finally we convert the colorspace from something else to YV12 
#(odd, because AVCHD should be YV12 - must be a decoder error).

#Actually, ConvertToYV12(interlaced=true) would be better
I hope that helps your understanding. As you guessed, any bobber - TDeint(mode=1), bob(), yadif(mode=1) etc etc could be dropped in here with equivalent results, but varying quality.

~MiSfit
__________________
These are all my personal statements, not those of my employer :)

Last edited by Blue_MiSfit; 2nd July 2008 at 19:31.
Blue_MiSfit is offline   Reply With Quote
Old 2nd July 2008, 20:06   #31  |  Link
mikeytown2
Resize Abuser
 
mikeytown2's Avatar
 
Join Date: Apr 2005
Location: Seattle, WA
Posts: 623
Building off of Blue_MiSfit's script

Code:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS")
#At this point, your video is untouched true 1080i

MCBob()
#Now, we've bobbed 1080i to 1920x1080 @ 59.94fps (1080P). 
#99.9% of your processing time will be spent here.

ZoomBox(704,480,"LanczosResize", SourceDAR=16.0/9.0, TargetDAR=16.0/9.0, align=-5)
#Now we're down to 704x480 @ 59.94fps
#Resizer set for a source and target DAR of 16/9.
#Set Align=5 to get rid of black bars and crop instead of adding borders

AssumeTFF()
SeparateFields()
#Now we've pulled the progressive frames apart into 704x240 fields. 
#It's technically at 119.89fps, but that doesnt matter ATM

#ConvertToYV12()
#Uncomment this to change colorspace. It's a good idea to change color space while it's still progressive video.

SelectEvery(4,0,3)
#Now we've decimated away half the information like this: 
#Input:   A B C D
#Output: A   C

#So, we're back to 59.94fps, still 704x240

Weave()
#Now we actually interlace the fields to produce interlaced frames. 
#So, we're at 704x480 @ 29.97i fps
ZoomBox Thread
MCBob takes YV12() so your video is already YV12

Edit: Changed 720 to 704 after reading about DVD players from the links that 2Bdecided gave above (post 27).

Last edited by mikeytown2; 2nd July 2008 at 20:44.
mikeytown2 is offline   Reply With Quote
Old 3rd July 2008, 00:19   #32  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
It seems a lot of the evaluation is being done here looking at static images. As this material is originally interlaced and motion fluidity is important it is vital to view the results in motion at normal speed, preferably on all the target displays. Having really great individual static bobbed frames that vertically twitter like crazy when viewed is about the worst result I could imagine. Examine carefully all thin vertical, horizontal and diagonal lines and sharp high contrast edges.


And one last point, if a ConvertToYV12() is required, where should it go.

I would recommend straight after the Bob and before the Resize. There is a whole raft of discussion about chroma positioning with interlaced 4:2:0 material. Summary is the chroma is positioned the same with both interlaced and progressive, but with interlaced, alternate lines are temporally distinct. This means for a static scene there is no difference between progressive and interlaced chroma. See these threads for the gorey details, AutoYUY2() updated and Adaptive chroma upsampling
IanB is offline   Reply With Quote
Old 3rd July 2008, 19:32   #33  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by florinandrei View Post
Not a problem. Accuracy comes first.
Going from 20fps to 1fps processing speed for no visible improvement isn't really searching after accuracy - it's OCD.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 3rd July 2008, 21:24   #34  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,986
True

But the golden rule here is - whatever makes the user happy!

If that means encoding Blu-ray using Apple's MPEG-4 SP encoder at 512kbit, so be it!

~MiSfit
__________________
These are all my personal statements, not those of my employer :)
Blue_MiSfit is offline   Reply With Quote
Old 4th July 2008, 04:39   #35  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Assuming that Bob() is good enough for 1080i to 480i downsizing, what about this?

Code:
AVCSource(dga="mts00000.dga")
#1920x1080i @29.97fps YV12

AutoYUY2()
#1920x1080i @29.97fps YUY2

Bob(0, 1, 480) # .... or Bob(0, 0.5, 480) ?
#1920x480p @59.94fps YUY2; shift correction automatically performed for the vertical resize

AssumeTFF()
#Dunno if the field order is preserved, so play safe

Separatefields().SelectEvery(4,0,3).Weave()
#1920x480i @29.97fps YUY2

ConvertToYV12(interlaced=true)
#1920x480i @29.97fps YV12; will it destroy the AutoYUY2() effects?

BicubicResize(704, 480, 0, 0.5)
#704x480i @29.97fps YV12

Last edited by henryho_hk; 4th July 2008 at 17:09. Reason: AutoYUY2() can be downloaded from in http://neuron2.net/autoyuy2/autoyuy2.html
henryho_hk is offline   Reply With Quote
Old 4th July 2008, 11:44   #36  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: UK
Posts: 1,673
Quote:
Originally Posted by Blue_MiSfit View Post
But the golden rule here is - whatever makes the user happy!
No, not when the user doesn't know what they want! Seriously though, I think florinandrei wants to learn - that sometimes includes learning that what you originally thought you wanted to do isn't really what you want to do at all!


I'm still thinking about this statement...
Quote:
Originally Posted by florinandrei View Post
I guess what I'm after is "accuracy". If the original is sharp, I want that sharpness preserved, as much as the scale-down allows. But the result should not be subjectively "sharper" than the original.
What I want is a reduced-size copy that looks, statically and dynamically, as close to the original as possible, aside from the smaller resolution.
IME I don't find HD>SD works like that at all. The sharpness of the HD original has little bearing on the sharpness of the SD output (unless it's badly out of focus). For a given processing chain, either both pin sharp and barely sharp HD will give sharp SD, or both pin sharp and barely sharp HD will give barely sharp SD.

If you do a bicubic resize and leave it at that, it'll all look a bit soft.
If you do a lanczos resize and run limitedsharpenfaster, it'll all look very sharp (too sharp?).
Neither will always "keep the perceived sharpness of the original, but on a smaller scale" - resizing doesn't work like that. You have to use the appropriate tools to get the sharpness you want, which is partly independent of the source. If you want it to look like the source, you'll have to throw in the processes that "recreate" that look at the new resolution, because it won't happen by magic.

I think I'm explaining this really badly, but I hope it make sense to someone.


Anyway, at least having a 60i input and 60i output will keep the motion looking the same - that part at least is "easy".

The problem is it contradicts the sharpness goal somewhat: whenever I see really sharp SD, it's progressive (25p in the UK). Interlaced SD never seems to look quite as sharp.

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 5th July 2008, 18:03   #37  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Quote:
Originally Posted by neuron2 View Post
I don't agree that your second is fuzzy. You are imagining it.
Perhaps he is not. The wires in frame 5 got "broken" by the 2nd script. They are okay with shift=0 or with Bob's resize. Perhaps the shift calculation formula is wrong.
henryho_hk is offline   Reply With Quote
Old 5th July 2008, 18:37   #38  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
broken != fuzzy
Guest is offline   Reply With Quote
Old 6th July 2008, 01:43   #39  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Sorry that my english is not good. Perhaps, when the shift adjustment is wrong, the two fields are misplaced. Hence, it makes the wire looking "broken" on computer monitor and the video looking "fuzzy" on CRT TV.

MVBob -> Separatefields -> Weave:



Bob(0, 0.5, 480) -> Separatefields -> Weave:



Separatefields -> Spline36Resize (with shift adjustment) -> Weave:


Last edited by henryho_hk; 6th July 2008 at 09:57. Reason: The 3rd image is corrected.
henryho_hk is offline   Reply With Quote
Old 6th July 2008, 06:35   #40  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
@henryho_hk,

Your last image looks like you had the 2 red statements reversed.
Code:
Global NewHeight=480
Global NewWidth=720

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()
Please post the actual script you used
IanB is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:17.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.