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 20th March 2019, 13:21   #21  |  Link
domator
Registered User
 
Join Date: Mar 2019
Posts: 14
I only have 1st and 2nd season in NTSC.

If you want the NTSC DVD here's for 56€ on Ebay:
https://www.ebay.com/itm/Sliders-The...Condition=1000
That's how I buy NTSC stuff and they ship just fine to EU.
domator is offline   Reply With Quote
Old 20th March 2019, 19:06   #22  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Here's some silliness I came up with for cleaning up the problem scene in the PAL version. I don't know how long it stays that way as I only have the short sample domator uploaded. It doesn't fix it completely, but you'd probably have to hunt for what's left to notice it.

VTS_02_1.demuxed.mkv

Code:
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
mpeg2source("D:\VTS_02_1.demuxed.d2v")

A = Last
B = A.TFM().AssumeFPS(24000,1001)
C = A.TFM(pp=2).AssumeFPS(24000,1001)
D = A.TDeint(mode=1).SelectOdd().AssumeFPS(24000,1001)

B.Trim(0,292) ++ \
D.Trim(293,293) ++ \
B.Trim(294,723) ++ \
B.Trim(723,723) ++ \
C.Trim(725,807) ++ \
D.Trim(808,965) ++ \
C.Trim(966,966) ++ \
D.Trim(967,0)

QTGMC(InputType=1, EzDenoise=1)
crop(16, 6, -14, -6)
Spline36Resize(704,528)
Gradfun3()
Edit: Changed the script to remove the part that effectively wasn't doing anything


Last edited by hello_hello; 20th March 2019 at 21:24.
hello_hello is offline   Reply With Quote
Old 20th March 2019, 19:54   #23  |  Link
domator
Registered User
 
Join Date: Mar 2019
Posts: 14
Well, hello_hello, it does look great. I don't understand it but it does look great.

Are you deleting here frames with Trim() using any pattern?
domator is offline   Reply With Quote
Old 20th March 2019, 20:14   #24  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
There's no pattern, except the blending seems to change on a scene change. Some of it caused by de-interlacing the existing blending (I think), which is why I changed de-interlacing methods.

(Edit: To fix a mistake dividing the video into sections.)

Divided into three sections, 0-724 is clip "B", 725-807 is clip "C" and 808-0 is clip "D".

So for that alone you would do this:

B.Trim(0,724) ++ \
C.Trim(725,807) ++ \
D.Trim(808,0)

"B" uses the original TFM field matching/de-interlacing.
"C" uses TFM again, but with blending as it's de-interlacing method. TDeint was being used too but I just realised it's pointless so I'll edit the script to remove it (I tried several things).
"D" uses TDeint to bob de-interlace to 50fps. The end result was mostly a pattern of blended and non blended frames, and the blended ones are removed with SelectOdd(). For that scene it worked better than TFM's de-interlacing.

That did leave three blended frames on scene changes, so I fixed them manually with extra Trims.

Replaced frame 293 from clip B with frame 293 from clip D.
Frame 724 was a lost cause so I replaced it by repeating frame 723. A repeated frame on a scene change is usually unnoticeable, at least compared to a blended frame.

That means instead of this for the first section

B.Trim(0,724) ++ \

the Trims became this:

B.Trim(0,292) ++ \
D.Trim(293,293) ++ \
B.Trim(294,723) ++ \
B.Trim(723,723) ++ \

Replaced frame 966 from clip D with frame 966 from clip C.

So instead of this for the third section

D.Trim(808,0)

the Trims became this:

D.Trim(808,965) ++ \
C.Trim(966,966) ++ \
D.Trim(967,0)

I followed all that with QTGMC in progressive mode to clean it up a bit. I didn't upscale as to be honest I think it's pointless (except for animation), so I just cropped and resized to 4:3.

Last edited by hello_hello; 20th March 2019 at 21:27.
hello_hello is offline   Reply With Quote
Old 20th March 2019, 21:56   #25  |  Link
mbcd
Registered User
 
Join Date: Dec 2008
Location: Germany
Posts: 173


WOWWWW

That looks very good with my German PAL-Source. Stutter, no glitches, and it seems that also scenechanges are good.

I am doing this complete episode now with a test-run, takes about 1,5 hours, will control it and report tomorrow (its late-evening right now).

But it seems that its VERY VERY good work. This might work for all episodes!



NOOO

So, I though it must be: Still problems some scenes later. Overall some doubled frames, not only at scenechanges, but also some blendings coming up.

Those scene is ok, very good work on it, but there are still some shifts in whatever.
This is what I got months ago, if I got one scene right, some other failed.

I think you cant belive of that there is nothing you can get shure that its fixes, the fixed ranges might be the problem.

Last edited by mbcd; 20th March 2019 at 22:19.
mbcd is offline   Reply With Quote
Old 20th March 2019, 22:43   #26  |  Link
Frank62
Registered User
 
Join Date: Mar 2017
Location: Germany
Posts: 234
These sources use to change "field dominance" irregularly and steplessly. With "field dominance" I meant which of the two fields is displaced. While changing the "dominance" fields are blended.
I did some corrections of such sources by hand, in a simliar way, hello-hello did, but gave it up - doable, but not with a whole series, because it changes every few seconds. (My record was a six-part-series )

Again:
SRestore with frate=25 gives reasonable results. - Try it, or buy NTSC.
Frank62 is offline   Reply With Quote
Old 20th March 2019, 22:57   #27  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
For these sorts of problem, when I really care, I tend to encode a whole episode using the field matching or de-interlacing that mostly works, then I watch the encode and make a note of the problem sections. I'd re-encode them again, trying to fix the problems, and later split out the bad sections and replace them with the fixed versions. It can involve a bit of work... obviously... and it pays to always add --stitchable to the x264 command line if you want to append encoded video.
hello_hello is offline   Reply With Quote
Old 20th March 2019, 23:30   #28  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,048
Sliders, like MANY shows from the '80s and '90s, was shot on film but edited on tape for NTSC audiences. It will have 60 hz effects and orphaned fields everywhere even when you're dealing with a clean NTSC copy. Converting it to PAL absolutely destroys it.

Solution: get the NTSC discs.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.
Katie Boundary is offline   Reply With Quote
Old 21st March 2019, 00:07   #29  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Originally Posted by Katie Boundary View Post
It will have 60 hz effects and orphaned fields everywhere
While you may well be right, don't make such statements unless you know them to be correct for this particular source. It's not helpful.

And if anything, it would be more likely to have 30Hz effects than 60.
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 22nd March 2019 at 11:22.
wonkey_monkey is offline   Reply With Quote
Old 21st March 2019, 01:14   #30  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Here's my latest theory. I didn't like SRestore when I tried it originally, but I think that's because Yadif was de-interlacing. When I switched to QTGMC it was better.
Here's an encode with

QTGMC()
SRestore(25)
AssumeFPS(24000,1001)

VTS_02_1.demuxed SRestore.mkv

The only problem is in a few places there's duplicate frames where (I assume) SRestore took out a frame with blending, when it probably would have been better to leave a slightly blended frame instead (you can see a break in movement as the car goes past the pole, as the guy in the blue jacket walks past the group, and three or four times as they walk down the stairs). So I checked the sample and there only seems to be two patterns of frames to keep using FixBlendX instead of SRestore. You have to decide where to use each pattern yourself, but it solves the problem of repeated frames.

The two sections in the sample are these:

B.Trim(0,723) ++ \
C.Trim(724,0)

but it leaves two blended frames on scene changes, so if you're very fussy.... for the blended frame in clip B, I swapped it out for the same frame in clip C, and for clip C I swapped the frame out from clip B.
Wouldn't it be nice if the whole episode could be done with just two patterns, even if you have to find them yourself?

Edit: Doh! Changed the script below so it only has to de-interlace once.

mpeg2source("D:\VTS_02_1.demuxed.d2v")

A = last.QTGMC()
B = A.FixBlendX(1,25.0,10)
C = A.FixBlendX(8,25.0,10)

B.Trim(0,292) ++ \
C.Trim(293,293) ++ \
B.Trim(294,723) ++ \
C.Trim(724,965) ++ \
B.Trim(966,966) ++ \
C.Trim(967,0)

AssumeFPS(24000,1001)
crop(16, 6, -14, -6)
Spline36Resize(704,528)
Gradfun3()


VTS_02_1.demuxed FixBlendX.mkv


The downside is de-interlacing does blur fine detail a bit more than using TFM(), even with QTGMC. Maybe one of QTGMC's lossless modes would work better here.
Normally when I'm looking for the frames to keep with FixBlend, I'd de-interlace with Yadif(mode=1) and replace it with QTGMC() for encoding. This is the first time that hasn't worked.

Last edited by hello_hello; 21st March 2019 at 10:17.
hello_hello is offline   Reply With Quote
Old 21st March 2019, 19:20   #31  |  Link
domator
Registered User
 
Join Date: Mar 2019
Posts: 14
You did a great job here , hello_hello!

Trimming frames from the whole series might be a bit too much work to no go crazy.
I think they did the conversion from whatever source automatically. Such guys are lazy. If they weren't lazy they would do this properly and this is not done properly.
So in theory whatever they applied to get so much blurring and interlacing should be possible to undo. I mean- there should be a pattern here.
domator is offline   Reply With Quote
Old 21st March 2019, 20:19   #32  |  Link
zorr
Registered User
 
Join Date: Mar 2018
Posts: 447
Quote:
Originally Posted by hello_hello View Post
Here's some silliness I came up with for cleaning up the problem scene in the PAL version.

B = A.TFM().AssumeFPS(24000,1001)
C = A.TFM(pp=2).AssumeFPS(24000,1001)
D = A.TDeint(mode=1).SelectOdd().AssumeFPS(24000,1001)
...
It might be possible to detect automatically which version is the best choice for each frame. There are algorithms that calculate the "blurriness" of the frame and I guess the most correct one should have the least blurriness. I did implement such a measure as part of B-SSIM metric.
zorr is offline   Reply With Quote
Old 21st March 2019, 21:25   #33  |  Link
mbcd
Registered User
 
Join Date: Dec 2008
Location: Germany
Posts: 173
Short response:

Tried hello_hello`s last script:
Does not work, sorry ...

As I said, fixed value are a no-go here, for me it looks like they did some motion blurrer, as more movement, as more blending ... but I am not a professional.
But I agree: Manually adjusting stuff is not the way, too much work!


But we come closer:
Based on the link of hello_hello, I got his script and it did mostly magic:
I tried a lot with this episode. I get about 90% rid off all problems with this:

bob()
FixBlendNTSC(3)

As far as I can see the only part that is mostly NOT working with this settings is the scene with the scanner and the directly following entering the foodplace. All other seems to work fine, so this scene has something special, thats why I advised to it.

Last edited by mbcd; 21st March 2019 at 21:52.
mbcd is offline   Reply With Quote
Old 21st March 2019, 22:31   #34  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by mbcd View Post
As far as I can see the only part that is NOT working with this settings is the scene with the scanner and the directly following entering the foodplace. All other seems to work fine, so this scene has something special, thats why I advised to it.
Splitting out that one scene with Trims to use a different FixBlendX setting doesn't sound like too much work.

Some/most of it must have out of alignment fields and that's why TFM() on it's own does the job. For the section we've been playing with there's oddities I don't understand.

I had another look, and if you look at the fields this way:

A = last.SeparateFields()
B = A.SelectOdd()
C = A.SelectEven()
StackVertical(B,C)

You can see there's nothing unusual about the first few frames where the car goes past.

When it switches back to the shot of the group there's blending in the odd fields only. And it's constant. The even fields are nice and clean (except for one field on the scene change). For a normal field-blended conversion, the odd fields will be blended for several fields, then the even fields for several fields, but (ideally) never at the same time. When you bob de-interlace, the fields become full frames, so there's always a fairly clean version of each frame, and SRestore or FixBlend etc can be used to pick them out as it normally happens in a fairly constant pattern.

It stays that way until the shot where they walk through the scanner, where it switches to the even fields being the one's with constant blending, and the odd fields are clean. Once again the only exception is the scene change, where the odd field is also blended. That's no doubt why the blending on scene changes is somewhat harder to remove in the usual way. It's also why TDeint(mode=1).SelectOdd() mostly worked for that section. After bobbing, every second frame is blurred and SelectOdd keeps the good ones.

TFM() doesn't work for the blended field sections because ultimately it's trying to pair non-blended and blended fields, and then it has to de-interlace the blended parts. You can really only fix it with bob-deinterlacing (to make each field a frame) and then remove the blended ones, but because it's such an odd thing, I can't find an automatic way to do it. Maybe zorr will return and offer some suggestions.

Theoretically, the following should be fine for the whole episode, and hopefully the "B" clip will cover most of it, but where it doesn't you'll have to switch to either the "C" clip or the "D" clip using Trims, according to whichever one has no blended frames. If there's only a few short problem sections it shouldn't be too much work. For the scene changes you'll have to pick the least offensive frame. If there's other problems.... well... that'll be another bridge to cross. I've no idea how it ended up the way it is.

A = Last
B = A.TFM()
C = A.TDeint(mode=1).SelectOdd()
D = A.TDeint(mode=1).SelectEven()

B.Trim(0,?) ++\

Here's some screenshots.
The clean section (TFM can match up the fields):



Odd fields blended:



Even fields blended:



And a scene change where a single odd field is also blended.


Last edited by hello_hello; 21st March 2019 at 23:41.
hello_hello is offline   Reply With Quote
Old 21st March 2019, 22:39   #35  |  Link
mbcd
Registered User
 
Join Date: Dec 2008
Location: Germany
Posts: 173
THank you VERY VERY much for your affort here, I remember the blendending switches from odd to even fields, you are right with that.

My suggestion with:
bob()
FixBlendNTSC(3)

are a little bit wrong, I watched the whole episode and it seemd it needs also
bob()
FixBlendNTSC(2)

I check that right now, takes some time.

I also check yout last suggestion out !

Could it be possible to deblend odd and even field separate ? So you would get clean odds and evens ... dont know if that would work ...

Last edited by mbcd; 21st March 2019 at 22:43.
mbcd is offline   Reply With Quote
Old 22nd March 2019, 05:16   #36  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by mbcd View Post
Could it be possible to deblend odd and even field separate ? So you would get clean odds and evens ... dont know if that would work ...
I'm not sure.
SRestore normally works by just picking out the non-blended frames after bobbing (as far as I know), so it doesn't actually deblend (although it must look for it). Except for it's mode for deblending progressive 29.97fps video that was creating by blend de-interlaced telecined material. It can deblend that pretty well, as long as the pattern is fairly consistent, but if it's not truly blend de-interlaced telecined 29.97fps, it puts out all sorts of horrible artefacts, so it must rely on a consistent blending pattern.

Here's something else I discovered a bit by accident. It might be possible to use TFM for the whole clip. You don't get out of splitting the clip with Trims, but as TFM (I'm pretty sure) only de-interlaces where it detects combing, it should retain more detail than bobbing and deleting frames. The trick seems to be to force TFM to field match from a particular field. Try this (there's a link to a sample below):

A = last
B = A.TFM()
C = A.TFM(field=0)

B.Trim(0,292) ++ \
C.Trim(293,293) ++ \
B.Trim(294,723) ++ \
C.Trim(724,965) ++ \
B.Trim(966,966) ++ \
C.Trim(967,0)

AssumeFPS(24000,1001)
QTGMC(InputType=1, EzDenoise=1)
crop(16, 6, -14, -6)
Spline36Resize(704,528)
Gradfun3()

I think I had SelectEven and SelectOdd the wrong way around in my previous post. For the top field, which is the first field, to be at the top, I think it should have been

A = last.SeparateFields()
B = A.TDeint(mode=1).SelectEven()
C = A.TDeint(mode=1).SelectOdd()
StackVertical(B,C)

Anyway.... it seems if you change the field TFM matches from to the bottom field where the top fields are blended, when it de-interlaces, it must interpolate the pixels from the unblended field with new ones, and therefore seems to deblend the frame. I'm guessing... but I can't think of another logical reason as to why it works. When the bottom fields are blended, you field match from the top field, which is the default for a top field first video. Same for the sections without blending.

At least the above way you can get benefit from QTGMC's cleaning up the video, but it'll be much faster than bobbing with QTGMC.

I aso tried an encode with TFM taking the combed pixels from QTGMC while still running QTGMC in progressive mode to clean up the rest. I think it's an improvement bit it's also slow. Check out the railings in front of the windows as they walk past. The version with TFM using QTGMC's de-interlacing is more stable, but maybe it's not worth the hit on encoding speed.

A = last
DeintClip = A.QTGMC(Preset="medium")
DeintClipB = DeintClip.SelectEven()
DeintClipC = DeintClip.SelectOdd()
B = A.TFM(Clip2=DeintClipB)
C = A.TFM(Clip2=DeintClipC, field=0)

B.Trim(0,292) ++ \
C.Trim(293,293) ++ \
B.Trim(294,723) ++ \
C.Trim(724,965) ++ \
B.Trim(966,966) ++ \
C.Trim(967,0)

AssumeFPS(24000,1001)
QTGMC(InputType=1, EzDenoise=1)
crop(16, 6, -14, -6)
Spline36Resize(704,528)
Gradfun3()

That all works, but I'm really not all that sure I understand why at the moment.

VTS_02_1.demuxed tfm.mkv

VTS_02_1.demuxed tfm qtgmc.mkv

Last edited by hello_hello; 22nd March 2019 at 05:45.
hello_hello is offline   Reply With Quote
Old 22nd March 2019, 09:59   #37  |  Link
mbcd
Registered User
 
Join Date: Dec 2008
Location: Germany
Posts: 173
I am giving up again guys, chances are not bad to get a better result out of this source, but it looks like it is not possible to do it automatically.
Deinterlace, take even and odd streams seperate and decide which one has no blending in the actual scene, sounds pretty easy ...
By hand with about 88 episodes is a no-go.

EDIT:
If someone wants to try on another scene, this is one, If the upper scene works correct, I still get problems with this one, because the blended fields change:
https://ufile.io/d6met

Last edited by mbcd; 22nd March 2019 at 14:00.
mbcd is offline   Reply With Quote
Reply

Tags
deinterlace, dvd

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 17:07.


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