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. |
|
|
Thread Tools | Search this Thread | Display Modes |
|
13th October 2006, 01:08 | #1 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Plain deinterlacing or Bob+SelectEvery: what do you prefer and why?
Is there an inherent advantage for each method on particular cases?
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
13th October 2006, 01:24 | #2 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
bob.selecteven/odd can be useful for detecting if something's already been deinterlaced (the bad way ala final cut pro or premiere). if there's not-very-much difference between the source and the bob.selecteven then it's been deinterlaced and needs to be eedi2'ed up to a higher res.
but generally you can tell that just by looking at it
__________________
sucking the life out of your videos since 2004 |
13th October 2006, 01:33 | #3 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
So Bob+SelectEvery is not a good deinterlacing method then? What about straight-up deinterlacing, is TDeint+EEDI2 still the preferred method?
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
13th October 2006, 01:41 | #4 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
i think the preferred method is the one that gives the better visual quality vs speed tradeoff. depending on the situation that's usually somewhere between leakkerneldeint and tdeint.
[edit] of course, if you want a guarantee of no artefacts (except aliasing), then bob.selecteven is probably the way to go
__________________
sucking the life out of your videos since 2004 Last edited by Mug Funky; 13th October 2006 at 01:46. |
13th October 2006, 01:56 | #5 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
I'm only interested in the best quality short of interlaced encoding. I guess that still means TDeint+EEDI2 then, thanks for the feedback .
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
21st October 2006, 01:46 | #7 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
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!) |
|
17th November 2006, 11:10 | #8 | Link | |
Registered User
Join Date: Mar 2003
Posts: 128
|
Quote:
/MLS |
|
14th October 2006, 02:42 | #9 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Basically, quality-wise both methods are the same. The result depends on the used deinterlacing routine only. A same-framerate deinterlacer will ask you for a "field=top/or/bottom" parameter, defining which of both fields will be thrown away & interpolated: Same framerate = one field doomed.
A bobber does the same, but after each frame inserts another frame that is based on the previously thrown-away field: Framerate doubled by not dooming one field. Or, perhaps like this: Same-framerate-deinterlacing: > source.Deinterlace(field=[top or bottom]) Double-framerate-deinterlacing (Bobbing): > source.DoubleWeave().Deinterlace(field=[alternating]) So, obviously, decisive for the result is only the deinterlacing algo. And that's where MVbob is bringing an additional choice over TDeint, LeakKernel-XX, and Co. : all these are "only" motion-adaptive, i.e. in moving areas, they have to give up & can only do interpolation guesswork. MVBob currently is the only one taking the chance to search around for really-present image information that can be transported into those missing scanlines. I'd say that, in theory, MVBob.SelectEither() should deliver superior image quality compared to the other methods, simply because the technique used for deinterlacing is more advanced. Note that this doesnt say that the technique is already maxed-out ... MVBob does have its own problems just as well, so it's not necessarily "the best" of the available choices. The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area.
__________________
- 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!) |
14th October 2006, 03:38 | #10 | Link |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Thanks for the explananation, Didée .
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
27th October 2006, 02:06 | #12 | Link | |
Huh?
Join Date: Sep 2003
Location: Uruguay
Posts: 3,103
|
Quote:
__________________
Read Decomb's readmes and tutorials, the IVTC tutorial and the capture guide in order to learn about combing and how to deal with it. |
|
21st October 2006, 14:52 | #14 | Link |
Registered User
Join Date: Jan 2005
Posts: 48
|
The topic title keeps changing. i'm sorry to say that the current tilte "Plain deinterlacing or Bob+SelectEvery: what do you prefer and why" is not quite appropriate. TDeint (with or without EEDI2) is a very sophisticated deinterlacer and will do a much better job of deinterlacing than a dumb/not-so-smart bobber +SelectEvery
|
21st October 2006, 16:29 | #15 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
For me personaly i allways use Securebob it's a good Speed/Quality tradeof for me.
but the best Speed/Quality @ the moment wich sadly yet can't be used (at least no one wrote a custom allocator for it yet) is Nvidias Per Pixel Adaptive Motion Deinterlacer inside their Mpeg-2 Decoder (PureVideo) it has no problems to convert 1080i into double framerate progressive Video in Realtime (on the GPU) pretty exciting to see that in front of your eyes, quality isn't as good as tdeint tough Tdeint with GPU support that would be the revolution
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 21st October 2006 at 16:41. |
21st October 2006, 17:13 | #16 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
IMO, SecureDeint is too anxious with its motion masking. Avoiding motion artefacts is good and all, but if it comes at the cost of many "in fact static" areas still keeping bobobobobbing, then it's not a good tradeoff.
Motion masking of the upcoming upproach is fully adaptive to local complexity, like my unheared proposal in the TDeint thread. Works like a charm, nonetheless. Wrapping it out ala SecureDeint won't be a problem.
__________________
- 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!) |
22nd October 2006, 13:37 | #17 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Hi Didee,
In testing your ‘SoonToComeBob’, I thought you might be interested (as I would) in seeing how it fares with this clip, which I think is as good a ‘deinterlace stress test’ as any. http://rapidshare.com/files/229055/T..._YV12_3sec.avi It’s sample from one of the reference D1 576i25 sequences (src6_ref__625) at ftp://ftp.crc.ca/crc/vqeg/TestSequences/Reference/ I converted the original 8 bit YUV4:2:2 (UYVY or YUY2) sequence (Top Field First) toYV12 (FFDShow-HuffYuv) via RawSource and ConvertToYV12(interlaced=true) and used a 3 second sample as the source for testing: MVBob (latest public version 14.9.06) SecureBob TDeint-EEDI2 SmoothDeinterlace I intentionally sampled the clip to include a scene change. After deinterlacing I resized to 720x544 (Lancozos3). As expected, MVBob and SecureBob are rather more effective in avoiding residual interlacing artifacts, most noticeable with the white road line and around the captions in the areas of fast background motion. Here are grabs of frame 102: http://rapidshare.com/files/230193/F...ob_14.9.06.jpg http://rapidshare.com/files/230258/F...Secure_Bob.jpg http://rapidshare.com/files/230342/F...eint_EEDI2.jpg http://rapidshare.com/files/230416/F...ooth_Deint.jpg However, on stepping through the frames, it will be seen that MVBob and SecureBob are rather more susceptible to modulation (swelling) in the height of the captions with some bobbing of the strip margin. Of course, this is barely noticeable on normal playback, but is it what you are referring to by ‘bobbing of static areas’? Last edited by WorBry; 22nd October 2006 at 13:49. |
14th November 2006, 20:29 | #18 | Link |
Registered User
Join Date: Sep 2004
Posts: 160
|
noob noob noob
If I use this in Aviysynth for a pal 25 dvd source:
SeparateFields SelectOdd BilinearResize(384,288) First 2 lines makes the vertical resolution look squashed. Then the resizing of the horizontal res. will make it a good picture again. But if I do this. selecting odd-lines from the vertical with no aliasing ( i guess), could this make round-edges in vertical resolution look strange? I mean, you do lose information that was stored in the even lines I just threw away? Am I correct? |
22nd October 2006, 17:37 | #19 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Good (awfully) test clip indeed. Reveals there is work left to do.
Why did you vertically resize for the comparison? That's less than ideal, in order to check for the raw deinterlace performance. Your result with MVBob I cannot reproduce at all. With the latest version, just "MVBob()" gives me this: And that's pretty much the performace I'm getting always of it. Only rescue is to reduce "correctth" so much that the whole thing becomes almost a no-op. You surely didn't mix up something? Could you please state the exact settings used?
__________________
- 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!) |
22nd October 2006, 19:20 | #20 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Didee,
Yeah, you are right, in my haste I duplicated the frame grab from the SecureDeint encode, instead of MVBob. Here’s the ‘correct’ MVBob frame 102 (at 720x544). http://rapidshare.com/files/268836/F...ob_14.9.06.jpg These are the scripts I used – nothing fancy, with both MVBob and SecureBob at default. AVISource("C:\... Test 576i25 TFF YV12 3sec.avi") AssumeTFF() MVBob() or SecureBob() LanczosResize(720,544) AVISource("C:\... Test 576i25 TFF YV12 3sec.avi") AssumeTFF() interp = separatefields().eedi2(field=2) tdeint(mode=1,order=1,edeint=interp) LanczosResize(720,544) AVISource("C:\... Test 576i25 TFF YV12 3sec.avi") AssumeTFF() SmoothDeinterlace(tff=true, doublerate=true) LanczosResize(720,544) The MVBob (and SecureBob) version used is this one (14th Sept 2006): http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar I resized to 720x544 because that’s the resolution I normally use for MPEG-4 encodes for PC playback, but I receive your point about it being more difficult to accurately assess deinterlacing performance. Here are the grabs again without resizing: http://rapidshare.com/files/269028/F...06_720x576.jpg http://rapidshare.com/files/269095/F...ob_720x576.jpg http://rapidshare.com/files/269170/F...I2_720x576.jpg http://rapidshare.com/files/269138/F...ce_720x576.jpg |
Thread Tools | Search this Thread |
Display Modes | |
|
|