@len0x: auto-IVTC methods for AutoGK

[bilu]

Hi len0x,

I haven't tried AutoGK yet but the automatic IVTC detection process you use got me curious.

I had a batch tool to use with Robot4Rip called R4R_ENC. It was a primitive tool based on batch files and Avisynth scripts and was the inspiration for TaZit. It had some pretty steps for auto-resizing based on compressibility as well, faster than TaZit (less steps). You may find some ideas useful, I hope.

http://forum.doom9.org/showthread.php?s=&threadid=51228

I stopped development because I couldn't get a decent AutoIVTC, mainly because you can't trust only in the DVD2AVI output. Example: hardware telecined movies with no MPEG-2 Telecined flags.

http://forum.doom9.org/showthread.php?s=&threadid=53393

Please take a look on my approach of using Telecide's debug information.I do a XVID Null encode with Telecide(FOrder(),guide=1,post=0,debug=true) and capture the output to a file.

http://forum.doom9.org/showthread.php?s=&threadid=64649

FOrder() is a function to get the field order from MPEG-2 sources and use them in Telecide, DGBob or SmartDecimate.

#FOrder works only with MPEG-2 sources
function FOrder(clip c) {
fo= GetParity(c)? 1:0
return fo
}

As for hybrid encodes, process would be easier on Matroska's variable framerate than on AVI's constant framerate. Because with constant framerate you also may need to calculate Decimate hybrid thresholds on mode=1 and mode=3, and collect data for doing so.

This was an experience of mine some time ago, as an example:
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=126

On Matroska process a filter could just decide which parts are Telecined and which are not. And make a process like this even simpler:

http://forum.doom9.org/showthread.php?s=&postid=395247#post395247


Would like your feedback on these. I think this subject deserves a thread for itself.


Best regards,
Bilu

[len0x]

heh, I finally got you interested :)

All the links you've posted I studied before I started working on auto-IVTC. Some ideas are nice, some can be done simpler.

Have a go with AutoGK first and you'll see how it works (and you'll see familiar getOrder function :) ). I don't use d2v statistics at all (apart from detecting pure FILM). I work on direct analysis of motion frames, grab combed statistics and examine the source in portions of 5 frames in a row.

Anyway, to detect the source is easy for me. What I would ideally would like to see is automatic threshold parameter adjustment for Decimate(). Coz say you've detected that source is hybrid and know which mode you gonna run decimate with, but it would be nice if you can automatically adjust default threshold=1.0 used for hybrid sources... I don't know if statistics from telecide can be used for that since I haven't explored that path at all...

*Edit*
I didn't see that link from DG's board about threshold caclulation. Can you sum up what's the algorythm without implementation details?

[bilu]

Originally posted by len0x
heh, I finally got you interested :)I'm glad I can say the same about you :)
Your work can bring much value and attention to the auto-IVTC issues.

Originally posted by len0x
I didn't see that link from DG's board about threshold caclulation. Can you sum up what's the algorythm without implementation details?[/B] Output from Decimate(mode=0,debug=true):

!Decimate: 0: 0.00
!Decimate: 1: 2.87
!Decimate: 2: 0.48
!Decimate: 3: 2.35
!Decimate: 4: 2.49

These values are differences between frames, the same you use on the the hybrid threshold.

On my algo I would account how much frame metrics fit between 0.0 and 0.1, 0.1 and 0.2, and so on. But I would read this values only on frames detected as duplicates. I was accounting only between 0.0 and 2.0, seemed more than enough for me.

Example from a Neo Genesis Evangelion clip (false detected as IVTC,but enough as an example):

Each value is a threshold range count, first is 0.0<range<=0.1 and so on.

14 60 94 53 23 22 20 17 13 6 9 6 4 4 4 4 6 6 6 3

This means that
14 frames accounted as 0.0 - 0.1 range
60 " " " 0.1 - 0.2 range
and so on.

Then it would sum this values from beginning until 90% of the duplicates or the last accounted value represent less than 3% of the duplicates. Choice would be 0.9 in this case. Of course percentages could be redefined.

About false detected IVTC clip:
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=174

Another very nice approach for smoother 30fps->24fps video parts on hybrid encoding, wish someone would do a filter based on this:

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=216


Bilu

[len0x]

Originally posted by bilu

These values are differences between frames, the same you use on the the hybrid threshold.


Do we know exact algorytm for caclulation of those differences or we need to ask DG ?

Originally posted by bilu

On my algo I would account how much frame metrics fit between 0.0 and 0.1, 0.1 and 0.2, and so on. But I would read this values only on frames detected as duplicates. I was accounting only between 0.0 and 2.0, seemed more than enough for me.


I don't get the part about duplicates. First why value them, second how do you detect them? (duplicate is either true duplicate, or static scene, or very dark image - I see no way to distinguish between them)

*Edit* or by duplicates you mean those with values < 2.0, meaning static frames? That makes sense actually. I just wonder - I do motion detection myself, so in general I could do the same without telecide help if I can map my motion values to telecide's one

[bilu]

What I'd like to see one of these days:

A Decimate() based filter that would have two modes: VFR and CFR.

VFR mode would simply chop duplicates and output timestamps to a log file as 24 fps for the 4 former frames prior to the duplicate. This would be for the Matroska format.

CFR mode would chop duplicates and do one of scharfis_brain 30fps->24fps approaches, mode=3 is my favorite but haven't tried the others myself.
Scharfis method is smoother than Decomb's or SmartDecimate's hybrid approaches on the video parts. And with no thresholds :)


Bilu

[len0x]

Originally posted by bilu

VFR mode would simply chop duplicates and output timestamps to a log file as 24 fps for the 4 former frames prior to the duplicate. This would be for the Matroska format.


I doubt it'll become really popular (VFR I mean) as it will require quite a support from hardware...

[bilu]

Originally posted by len0x
Do we know exact algorytm for caclulation of those differences or we need to ask DG ? Better ask :)

Originally posted by len0x
I don't get the part about duplicates. First why value them, second how do you detect them? (duplicate is either true duplicate, or static scene, or very dark image - I see no way to distinguish between them) [/B]

I explained badly. Duplicates are not necessarily true duplicates, as in analog hardware-telecined. Decomb's reference:


threshold (decimal, default 0.0)

When mode=1, frames determined to be the most similar to their preceding frame can be treated in two possible ways: 1) they can be blended as described above, or 2) they can be passed through if the threshold parameter is non-zero and the difference metric exceeds the threshold. By setting an appropriate threshold, you can have duplicates get blended while passing through frames that have new content, i.e., which differ significantly from the previous frame. This allows hybrid film/nonfilm clips to be dealt with intelligently: the film portions will have blends and the nonfilm portions will not. The threshold parameter has no effect when mode=0. Use show=true (or debug=true in conjunction with the DebugView utility) to view the difference metrics and thereby determine an appropriate threshold for your clip.

the threshold parameter also affects mode=3 in a similar way.


Bilu

[bilu]

Originally posted by len0x
I doubt it'll become really popular (VFR I mean) as it will require quite a support from hardware...

You're right, but it would be an option for VGA or TV-out users.


Bilu

[bilu]

If mode=3, instead of discarding the most similar frame, Decimate() will apply different decimation strategies for 3:2 pulldown material (film) and for pure video (nonfilm) cycles. Film cycles are decimated in the normal way. Nonfilm cycles are decimated by applying a frame blending decimation of the cycle from 5 frames to 4 frames. The resulting frame rate is the film rate (decimated by 1/5).

I guess threshold in mode=3 would mean blending 5 frames into 4 if threshold is exceeded by the frame which was supposed to be a duplicate.


Bilu

[len0x]

Originally posted by bilu
I explained badly. Duplicates are not necessarily true duplicates, as in analog hardware-telecined. Decomb's reference:


I'm slowly getting there... we want only most similar frames to be blended, right? But in any case we gonna blend static VIDEO parts of the source as well ?

[len0x]

Originally posted by bilu

I guess threshold in mode=3 would mean blending 5 frames into 4 if threshold is exceeded by the frame which was supposed to be a duplicate.


that makes sense as well.
May be I outta do some experiments on how my motion detection relates to telecide's one... If I can duplicate it(roughly) in AVS, then it would be nice...

[bilu]

Originally posted by len0x
*Edit* or by duplicates you mean those with values < 2.0, meaning static frames? That makes sense actually. I just wonder - I do motion detection myself, so in general I could do the same without telecide help if I can map my motion values to telecide's one

I really have to try AutoGK to see how your motion detection process works, but won't have the time today.

But what would you think about checking which parts are Video or Film and using pure Film IVTC on the Film part and scharfis approach on the Video part instead of using Decimate hybrid modes?

You really have to look at it. Very good and without thresholds.

EDIT - Scharfis_brain script page with videos:

http://home.arcor.de/scharfis_brain/60ito24p.html

[len0x]

it works real simple:

global diff = 0.50*YDifferenceFromPrevious(clip) + 0.25*UDifferenceFromPrevious(clip) + 0.25*VDifferenceFromPrevious(clip)

About scharfis's method - I really have to put myself together and read that thread when my brain is still working OK (i.e. in the morning) :) I can't think now at all :)

[bilu]

Check the videos to see the potential.
I won't have time for more until tomorrow too.

Bye.

[manono]

Hi-

While scharfis_brain's approach is certainly valid, I think it comes down to personal preference as to whether or not you use his way, or Decimate(Mode=3), or SmartDecimate to convert the video portions to 23.976fps. I generally try to avoid the blurring/blending effect as much as possible, and prefer a clearer/cleaner result, even if it leaves the video slightly jerky.

But I'm glad that you're finally involved in this bilu. If you run some of your video clips through AutoGK, you may be able to help refine len0x's methods some more. But I think you'll agree that a lot has been accomplished since you first mentioned the idea of Auto IVTC detection, something I didn't even think possible at the time.

[bilu]

Originally posted by manono
While scharfis_brain's approach is certainly valid, I think it comes down to personal preference as to whether or not you use his way, or Decimate(Mode=3), or SmartDecimate to convert the video portions to 23.976fps. I generally try to avoid the blurring/blending effect as much as possible, and prefer a clearer/cleaner result, even if it leaves the video slightly jerky. Having options was allways a tradition in Gordian Knot. I don't want to break that tradition :)

Have you checked mode=1 and mode=2 on schafis script? No blending used, it stutters just a bit, so you could find it better than Decomb.Mode=3 uses blending and is the smoothest, too smooth for some :) Mode=1 seems the most Film-like IMHO.

Still you would need to separate Film from Video in a script to be able to use something else than Decimate() on the video parts. And decision of which frames should be treated as Film or as Video can also be hard.

Check out this example:
http://forum.doom9.org/showthread.php?s=&threadid=64649

I've been exchanging some mails with lighty about the possibilities for this sort of decision. But it's been hard to establish contact with him in the last days. He was developing a program that would parse Telecide output like in that anime thread I mentioned to do the variable framerate timecode log automatically for Matroska muxing later.

Specs on the last mail:


Parameters
=======
Minimum cycle for IN-PATTERN (default 1)
Minimum cycle for OUT-PATTERN (default 1)

Pattern Detection
===========
Use cycles in parameters instead of frames to garantee that the pattern matching changes when finding a complete pattern or lack of pattern. Internal processing should be still in frames, of course.

Example: 11111 11111 11000 11111 11111 would keep the 3 out-of-pattern frames as in-pattern, since there is not a complete lack of pattern. Should work better with false detections this way.

The framerange for a detected pattern doesn't have to be a multiple of 5, just the minimum threshold.
Hence the use of cycles instead of frames on the parameters, to enforce this point.

Example: 11111 11111 11000 00000 11100 would detect the first 12 frames as in-pattern, because it respects the minimum 5 frame (1 cycle) threshold. Then it would detect 8 frames as non-pattern. The last 5 frames would still be detected as non-pattern because 111 was not enough for the minimum 1 cycle threshold.

Frame Reduction
==========
X = nr of frames before IVTC
Y = nr of frames after IVTC

Y = INT (( X - (X MOD 5)) * 0.8) + X MOD 5

INT( ( 841 - 1) * 0.8 ) + 841 MOD 5 = 672 + 1 = 673
INT( ( 842 - 2) * 0.8 ) + 842 MOD 5 = 672 + 2 = 674
INT( ( 843 - 3) * 0.8 ) + 843 MOD 5 = 672 + 3 = 675
INT( ( 844 - 4) * 0.8 ) + 844 MOD 5 = 672 + 4 = 676
INT( ( 845 - 0) * 0.8 ) + 845 MOD 5 = 676 + 0 = 676
INT( ( 846 - 1) * 0.8 ) + 846 MOD 5 = 676 + 1 = 677

Why do 844 and 845 frames before IVTC end up both with 676 frames? It's simple.

5 5 5 4 becomes 4 4 4 4
5 5 5 5 becomes 4 4 4 4

Where 5 means the number of frames in each pattern, 4 on the upper left example is the rest (not enough to fill a pattern) and 4 4 4 means patterns after decimating.
This means that everytime you get an IVTC range you need to reduce the framenumber in the timecodes by (X-Y).
Most info here is useful IMHO. Also I think that a block of 2 consecutive IVTC cycles instead of 1 would be useful to avoid false detections that would end up stuttering by chopping a real frame instead of a duplicate.


Bilu

[bilu]

Originally posted by manono
But I'm glad that you're finally involved in this bilu. If you run some of your video clips through AutoGK, you may be able to help refine len0x's methods some more. But I think you'll agree that a lot has been accomplished since you first mentioned the idea of Auto IVTC detection, something I didn't even think possible at the time. I'm very glad to see key developers and moderators such as you and len0x having a look on this challenging problem. I'm sure this will bring more attention from the encoding community to this issue, more than ever.

And as more attention this gets, more problematic clips get checked, and more solutions arise. It's a pity for us that neuron2 is taking a sabbatical this year, but we shouldn't be selfish :) Kevin Atkinson (SmartDecimate) is a bit offline now too.

Maybe we could convince trbarry to work on this subject one of these days ... ;)


Bilu

[manono]

Hi-

Still you would need to separate Film from Video in a script to be able to use something else than Decimate() on the video parts.

Yes, and although I can't pretend to speak for len0x, I don't think, because of time considerations, that he's prepared to run a null encode on the whole thing to determine exactly which portions are Film and which are Video. He samples the source to determine whether it's Film, Video, or Hybrid, and if Hybrid, if it's mostly Video, or mostly Film. So I don't know if sharfis_brain's ideas can be used in AutoGK. Gordian Knot, maybe, but not AutoGK, where the whole process has to be automated as quickly and as accurately as possible. But he does get reports every so often where the user says AutoGK said it was one thing, when it was something different. Maybe those things have been fixed now. I don't really know, because I see so little Hybrid material these days.

But it would be pretty cool to be able to run a null encode on the DVD, and then IVTC the Film portions normally, and put on 60i->24p for the video parts using sharfis_brain's methods, particularly if it results in less blurring.

I'm very glad to see key developers and moderators such as you and len0x having a look on this challenging problem.

Nothing key about me. :) I'm just a user always looking for a better way.

It's a pity for us that neuron2 is taking a sabbatical this year, but we shouldn't be selfish Kevin Atkinson (SmartDecimate) is a bit offline now too.

Yep, I agree 100%. I noticed before that neuron2 was going to tackle the blended fields problem, to try and weed them out, and give us back clean frames. Something like that would help me personally the most. RePAL works for some things, but I've never had much luck with Unblend. I saw a sharfis_brain script for that, but it was kind of over my head. Just have to be patient, I guess.

[bilu]

Originally posted by manono
Yes, and although I can't pretend to speak for len0x, I don't think, because of time considerations, that he's prepared to run a null encode on the whole thing to determine exactly which portions are Film and which are Video. He will still have to do it to find Decimate hybrid thresholds IMHO.
And that means a script using Telecide(debug=true) and Decimate(debug=true). But if we could use a 30fps -> 24 fps method that wouldn't require thresholds we would avoid Decimate(debug=true) in the Null encode. But I do have to check how AutoGK is working now, I don't know yet if len0x is using Telecide or Uncomb before his motion detection method. Uncomb would be faster, but has no 3-way match. Also SmartDecimate is faster, but leaves interlaced artifacts sometimes.Originally posted by manono
I don't really know, because I see so little Hybrid material these days. Mostly Sci-fi series like Babylon 5 or Star Trek TNG and some anime.
I wouldn't know about DVD extras, never encoded it.

About blended fields - they sure are a problem. The Neo Genesis sample I have has lots of this:
A AC C
A B C
where B is an orphan field, the other half was replaced by a blend from former and next frames. And the clip is full of this. It's enough to confuse any pattern matching as you can see in the anime thread I mentioned before.


Bilu

[bilu]

Originally posted by len0x
Have a go with AutoGK first and you'll see how it works (and you'll see familiar getOrder function :) ). I don't use d2v statistics at all (apart from detecting pure FILM). I work on direct analysis of motion frames, grab combed statistics and examine the source in portions of 5 frames in a row. Do I have a way to use AutoGK with just VOB samples? :)

Originally posted by len0x
Can you sum up what's the algorythm without implementation details? My turn to ask :D

I understand how your motion detection process works, it's based on the HomieFR script. But how are you doing field match before motion detection, is it Telecide? And are you using Telecide(guide=1) for NTSC?

I'm asking this because PAL to NTSC conversions (guide=3) are rare IMHO, and the gthresh feature from pattern guidance is very good for anime, where there are lots of static parts. I have a sample of "Read Or Die" anime that gives completely different results when you use (guide=0) or (guide=1).

How are you collecting the combing statistics?
What use do you have for it in your process?


Bilu

[len0x]

Originally posted by bilu
Do I have a way to use AutoGK with just VOB samples? :)


yes, they should be in the form VTS_??_?.vob and contain VTS_?? - Stream Information.txt file produced by DVDDecrypter (you can fake that one, but make sure PAL or NTSC is correctly specified there) or ifo file.

Originally posted by bilu
I understand how your motion detection process works, it's based on the HomieFR script. But how are you doing field match before motion detection, is it Telecide? And are you using Telecide(guide=1) for NTSC?


I have two statistics for each frame:
- is it motion frame (based on diff)
- is it combed frame (based on isCombed() from decomb 5.1)

So I don't use telecide at all.
After that I parse output file (very tricky bit) in portions of 5 frames to determine if _those_5_frames_ are:

- progressive pattern
- interlaced pattern
- telecined pattern

I only work on motion frames and discard static ones since as I said I have no way to distinguish between static FILM/interlaced scenes and static progressive scenes.
This seems to be very robust method and it has only two variables to tune: threshold parameter for isCombed and threshold for motion frames.

*Edit* This is very diffrent approach from what ppl tried before - but this is one-to-one mapping from opening the source manually and use your eyes to determine what kind of source you're dealing with.

[len0x]

Originally posted by bilu
Having options was allways a tradition in Gordian Knot. I don't want to break that tradition :)


Not in the AutoGK - we have to use the best solution without an option :)

[len0x]

Originally posted by manono
Yes, and although I can't pretend to speak for len0x, I don't think, because of time considerations, that he's prepared to run a null encode on the whole thing to determine exactly which portions are Film and which are Video.


You're right - I'm not prepared to do that. :)
When I have nothing more to do I'll start integrating such methods like YATTA and VFR :D But before that - it's not worth it...

Originally posted by manono

But he does get reports every so often where the user says AutoGK said it was one thing, when it was something different. Maybe those things have been fixed now. I don't really know, because I see so little Hybrid material these days.


I see it failing only for one reason: what can we call hybrid? which percentage of FILM and NTSC ? Now I have thresholds 6-94% for hybrid. The rest is either pure FILM or pure NTSC. I had one user who said that with 94.5%(was it 93.5%) he still wants to be able to just deinterlace no matter what. I can raise this to 10-90% to be absolutely sure. But then some might complain that 10% of the movie is not in a good shape.

Another problem is threshold parameter for decimate which has to be adjusted, but as Bilu said that we can deal with as well. So I don't see any problems.

[len0x]

Originally posted by bilu
He will still have to do it to find Decimate hybrid thresholds IMHO. And that means a script using Telecide(debug=true) and Decimate(debug=true).

Not really - even if I use telecide for that I will use only 10% of the source. I need an estimation anyway...

[bilu]

Originally posted by len0x
I have two statistics for each frame:
- is it motion frame (based on diff)
- is it combed frame (based on isCombed() from decomb 5.1)

So I don't use telecide at all.
After that I parse output file (very tricky bit) in portions of 5 frames to determine if _those_5_frames_ are:

- progressive pattern
- interlaced pattern
- telecined pattern

I only work on motion frames and discard static ones since as I said I have no way to distinguish between static FILM/interlaced scenes and static progressive scenes.
This seems to be very robust method and it has only two variables to tune: threshold parameter for isCombed and threshold for motion frames.

*Edit* This is very diffrent approach from what ppl tried before - but this is one-to-one mapping from opening the source manually and use your eyes to determine what kind of source you're dealing with. I have to try it out with my Neo Genesis Evangelion clip.
Haven't tried it yet but I already think that this is probably the most robust method available :)

I feel that this approach is the right one for the blended fields.
Telecide's pattern guidance could be fooled more easily IMHO.

But what do you do with your decision? Would you do a Telecide(guide=1).Decimate(debug=true) to collect Decimate hybrid threshold?

I have an idea: your method using IsCombed on moving areas can help predicting which frames would become duplicates after Telecide.

Then you could do a smaller analisys using Telecide(guide=1).Select( frame before dup, dup frame).Decimate(debug=true). Since the debug would output the difference from the last frame, and you already know the dup framenumbers, it would be much faster to collect this data.

What do you think?

EDIT: How do you guess which frame blocks are telecined? 2 combed frames in every 5? :)

Bilu

[len0x]

Originally posted by bilu
But what do you do with your decision? Would you do a Telecide(guide=1).Decimate(debug=true) to collect Decimate hybrid threshold?


I don't do that atm at all. Just select appropriate mode for decimate
(0 for normal ivtc, mode 1 or 3 for hybrid with threshold=1.0) for actual encoding. That's why I was looking for a method to adjust that threshold.

Originally posted by bilu

I have an idea: your method using IsCombed on moving areas can help predicting which frames would become duplicates after Telecide.

Then you could do a smaller analisys using Select( frame before dup, dup frame).Telecide(guide=0).Decimate(debug=true). Since the debug would output the difference from the last frame, and you already know the dup framenumbers, it would be much faster to collect this data.


Interesting. So you're saying we just need stats from dupes, right?
I really wonder if I can produce similar statistics as telecide uses via avisynth scripts. Then we can avoid using telecide at all...

[len0x]

Originally posted by bilu
EDIT: How do you guess which frame blocks are telecined? 2 combed frames in every 5? :)


That's correct. but only if out of 5 frames more than 3 are motion frames. Otherwise I discard the whole block. The beauty of this method is that you can recognize progressive patterns in hybrid sources as well very easy. (you can have FILM/progressive hybrid sources)

[bilu]

Originally posted by len0x
I really wonder if I can produce similar statistics as telecide uses via avisynth scripts. Then we can avoid using telecide at all... You'd have to collect frame difference after Telecide (or Uncomb, much faster) between (frame before dup, dup frame) and "synchronize" your values with Decimate. I guess this can be faster than any Decimate(debug=true) process...

Bilu

[len0x]

Originally posted by bilu
You'd have to collect frame difference after Telecide (or Uncomb, much faster) between (frame before dup, dup frame) and "synchronize" your values with Decimate. I guess this can be faster than any Decimate(debug=true) process...


If I'm able use my motion value somehow, then there is no need for second pass of processing since I already have the motion value when deciding if the frames is moving or not, so instead of just result(true/false) I can output motion values and process them in one go within my program.

[bilu]

Originally posted by len0x
If I'm able use my motion value somehow, then there is no need for second pass of processing since I already have the motion value when deciding if the frames is moving or not, so instead of just result(true/false) I can output motion values and process them in one go within my program. But isn't your motion value applied without any field matching first?
You would need to match fields with Uncomb or Telecide and then collect frame differences!


Bilu

[len0x]

Originally posted by bilu
But isn't your motion value applied without any field matching first?
You would need to match fields with Uncomb or Telecide and then collect frame differences!


What do mean by field matching? (I might be new to this...)

[len0x]

Can I get hold of that one somehow ?

[bilu]

Originally posted by len0x
What do mean by field matching? (I might be new to this...) You aren't, believe me :)

Telecide(post=0) or Uncomb do field matching. FieldDeinterlace or KernelDeint are deinterlacers.

The difference is that deinterlacers apply post-processing over the fields of the current frame to get rid of interlacing interfacts, blending or interpolating.

ABCDE -> A*B*C*D*E*
ABCDE A*B*C*D*E*

Relation between A and A* is that A* fields are the result of blending or interpolating A fields.

Field matchers check fields from the next or previous frames if a frame looks combed, then replace a field with the most similar one, and then post-process if you choose to.

Example 1: Telecide(back=0) - match fields in current or next frame

Order=1 (Top Field First)
AABCD -> ABCCD
ABCCD ABCCD

Example 2: Uncomb - matches fields in current or previous frame

No need to define order (can be problematic with missing fields)
AABCD -> AABCD
ABCCD AABCD

That's where the definition of Telecine duplicate frame comes from :)
And that's why you need it before measuring the duplicate threshold.

Bilu

[bilu]

Originally posted by len0x
Can I get hold of that one somehow ?

I can upload to you that one and other problematic clips.
PM me an FTP server if you can. If you can't I'll try to set up something and tell you when ready.

I also got some problematic AVI clips that we could try to convert into VOBs if needed. I think they could be helpful for research too.

EDIT: about measuring.

1) Motion Detection
2) IsCombed()
3) Telecide(post=2,back=0)
4) Dup threshold measure

Optimizations:

AABCD
ABCCD

frames 2 and 3 are combed. After field matching will become

ABCCD
ABCCD

frame 4 will be the duplicate.So we would select frames 3 and 4 for dup threshold measurement.

Conclusion: Whenever the 5 frame pattern is FILM, if

frame A is combed
frame B is not combed

then B will be the dup and (A,B) will be the framerange for dup threshold.

EDIT2: As you can see in the Uncomb example it works the opposite way: if frame A is not combed and B is combed then B will be the duplicate.

EDIT3:
1) Motion detection
2) IsCombed()
3) If pattern=FILM then dup=(not combed frame after combed frame)
4) Select(frame before dup, dup frame)
It will look like this:
ABCDEF
BBDDFF

5) Telecide(guide=0,post=2,back=0)
It will look like this:
BBDDFF
BBDDFF

6) Calculate dup threshold (even frames may have post-processing and be slightly different from odd frames, enough to generate a dup threshold. Most times between 0.0 (pure telecine) and 1.0 (somewhat dirty) but it can go to 2.0 or more)


Bilu

[bilu]

I don't know much about the missing field problem. But I do understand why it would mess with Uncomb:

AABCD -> AABCD or AABCD
AB*DD AABBD AABDD

It would choose to match current (C top and D bottom) or previous (C top with B top, since there was no C bottom in frame 3).

Telecide supports 3 way matching as an option, but it can cause stuttering (mostly in real life video, non-anime).

back (0-2, default 0) selects the matching mode. When back=0, the backward match is never tested. This means that at bad edit cuts, a progressive frame may not be found and the resulting frame must be deinterlaced by postprocessing. When back=1, if a frame is still combed after field matching (according to a test against 'bthresh' -- see below), then the backward match is tried. This requires post > 0 and may allow a good progressive frame to be found at bad edit cuts. When back=2, the backward match is always considered. Some clips, especially those with a lot of blended fields, may be handled better with back=2, which tests for matching with the previous, current, and next frames. But use it with caution, because it can make some clips jerky.

By better handling with back=2 in blended fields neuron2 means a part of the blended frame may match better with previous than next or current frames. Not all blends are 50-50.

Example on 30fps pure video:

AB0DE
ABCDE

if 0 is a blend more close to B than to D then frame 3 will be

B
C

with post-processing on top, and the result can look closer to the previous frame than to current or next frames. Hence the stuttering.

bthresh (0.0-255.0, default 50) sets the combing detection threshold for conditional backward matching (back=1). The backward match will be considered if the candidate match has combing greater than 'bthresh'. Typically you set a high 'vthresh' to catch stray combed frames, together with a lower 'bthresh' to catch bad edits.

If you raise vthresh and lower bthresh it will make it easier for Telecide to choose 3-way. And the stuttering problem gets bigger too.
This should be used only in anime IMHO. On real live movies post-processing (deinterlacing) would be a better choice.

vthresh (0.0-255.0, default 50.0) sets the combed frame detection threshold for the postprocessing. You may want to increase this value if too many good frames are being deinterlaced, or reduce it if some combed frames are not getting caught. The default is a reasonable general purpose value. Note that this threshold determines whether a frame is considered combed and needs to be deinterlaced; it is not the threshold you might be familiar with in Smart Deinterlacer. That threshold is determined by dthresh (below); it is the threshold for deinterlacing the frames detected as combed.

As you've seen before, if you want 3-way matching you may end up dealing with vthresh values too.

dthresh (0.0-255.0, default 7.0) sets the threshold for deinterlacing frames detected as combed. Note that this threshold is the threshold you might be familiar with in Smart Deinterlacer.



I'd rather use telecide(back=0) than Uncomb or any other option.
It's safer on motion and on missing fields too.

Bilu

[len0x]

Originally posted by bilu
I can upload to you that one and other problematic clips.
PM me an FTP server if you can. If you can't I'll try to set up something and tell you when ready.


I'll try to organize something about it.

Originally posted by bilu

EDIT3:
1) Motion detection
2) IsCombed()
3) If pattern=FILM then dup=(not combed frame after combed frame)
4) Select(frame before dup, dup frame)
It will look like this:
ABCDEF
BBDDFF
5) Telecide(guide=0,post=2,back=0)
It will look like this:
BBDDFF
BBDDFF
6) Calculate dup threshold (even frames may have post-processing and be slightly different from odd frames, enough to generate a dup threshold. Most times between 0.0 (pure telecine) and 1.0 (somewhat dirty) but it can go to 2.0 or more)


OK, looks pretty nice.
By select you mean that I have to construct this:

clip=Select(3,4)+Select(8,9)+...

right?

Over the weekend I'll try to compare telecide's statictics with mine and see if mine can be used for this purpose (I wish there was a way to dump stats from telecide to an external file without special utilities).

P.S. Now I see the big picture and it doesn't sound that scary anymore as it looks :)

[bilu]

Originally posted by len0x
By select you mean that I have to construct this:

clip=Select(3,4)+Select(8,9)+...

right?yep, that's right :)Originally posted by len0x
Over the weekend I'll try to compare telecide's statictics with mine and see if mine can be used for this purpose (I wish there was a way to dump stats from telecide to an external file without special utilities). Are you a mind reader? :D
Before reading your post I was writing this one:

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=2685#2685

EDIT: you need Decimate-like statistics, not Telecide.
And Decimate(debug=true) output looks like this:

!Decimate: 0: 0.00
!Decimate: 1: 5.50
!Decimate: 2: 6.11
!Decimate: 3: 6.55
!Decimate: 4: 0.00
!Decimate: in frm 0, use frm 0
!Decimate: dropping frm 4
!Decimate: in frm 1, use frm 1
!Decimate: dropping frm 4
!Decimate: in frm 2, use frm 2
!Decimate: dropping frm 4
!Decimate: in frm 3, use frm 3
!Decimate: dropping frm 4
!Decimate: in frm 4, use frm 5
!Decimate: dropping frm 9
!Decimate: 5: 6.87
!Decimate: 6: 7.00
!Decimate: 7: 6.69
!Decimate: 8: 6.73
!Decimate: 9: 0.00

You would want metrics from frame 4 and 9 here.
Threshold would be 0.0 (Clean Telecine)

Eventually you could replace Decimate's output with conditional filtering like you're doing now.

But then again, dup frame decision already says what's the dup frame in "dropping frm X" and we could parse that metric.

It's up to you:

A) use Telecide + calculate and collect frame differencing on 40% of the sample (2 frames on every 5) after predicting which would be dup frame;

B) use Telecide + Decimate(debug=true) and parse an output file. Would run Telecide/Decimate on 100% of the sample but would avoid predicting the dup frame (just parse "dropping frm") and calculating the frame difference;

Which would you think that would be faster? :)


Bilu

[bilu]

Originally posted by len0x
I wish there was a way to dump stats from telecide to an external file without special utilities My method:

NULL.BAT
========
reg import null.reg
dbgproxy avs2avi MOVIE.AVS MOVIE.AVI -p 0 -c xvid 2> debug.txt

( 2> is to output STDERR )

NULL.REG
========
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\GNU\XviD]
"mode"=dword:00000006

DBGProxy: http://ivan.vecerina.com/code/dbgproxy/
Capture program logs generated using the DebugString call, and output them to STDERR (standard error output) prefixed with a '!'

Bilu

[len0x]

btw, there is no need for null encode. I'm doing it with vdubmod - direct stream copy mode on avs which crops image to 4x4 and therefor avi output is really small and data is not propagated to the codec (which seems to be 1-2fps faster then null encode)

[len0x]

Originally posted by bilu
Which would you think that would be faster? :)


For sure the first one. And considering that motion statistics is gathered on 10% of the source, then 40% of that would be 4% of total size which is less then comp test - should be real fast...

[bilu]

http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=2688#2688

Let's see if we can convince sh0dan to do it... ;)


Bilu

[bilu]

Originally posted by len0x
For sure the first one. And considering that motion statistics is gathered on 10% of the source, then 40% of that would be 4% of total size which is less then comp test - should be real fast... The other advantage of this method is that you don't need any debug=true output :)

[len0x]

Originally posted by bilu
The other advantage of this method is that you don't need any debug=true output :)

exactly, but more work to be done for mapping values to threshold parameters though...

[bilu]

Yes, but it's your work. Wouldn't depend on others (sh0dan modifying decomb, etc.) or parsing tools. So you won't have to wait for others to continue your work on AutoIVTC :)

[bilu]

Originally posted by len0x
exactly, but more work to be done for mapping values to threshold parameters though...

Would looking at Decomb.dll source code help?

[len0x]

Originally posted by bilu
Would looking at Decomb.dll source code help?

it would, but it may take really a while for a person who didn't write any avisynth plugins to figure out what's going on there :)

[bilu]

Originally posted by bilu
A) use Telecide + calculate and collect frame differencing on 40% of the sample (2 frames on every 5) after predicting which would be dup frame;

B) use Telecide + Decimate(debug=true) and parse an output file. Would run Telecide/Decimate on 100% of the sample but would avoid predicting the dup frame (just parse "dropping frm") and calculating the frame difference; C) use Telecide(guide=1).Select(frame before dup, frame dup).Decimate(debug=true) and parse the frame difference over 40% of the sample. Would avoid mapping values and still use 2 in every 5 frames(just in Decimate, not in Telecide).

D) use Select(frame before dup, frame dup).Telecide(guide=0).Decimate(debug=true) and parse the output file.
Would be even faster since it would throw 2 frames in every 5 both in Telecide and Decimate, not like in C).

The D) process could be less accurate because guide=0 doesn't use gthresh as (guide=1) does, but pattern guidance can also get fooled by blended fields. Since this is a statistical approach it wouldn't be important to use pattern guidance, since you work only on moving areas.

D) would be faster than C), use 40% of the sample and would avoid mapping values, hence becoming faster to implement. And almost as fast as A) I think. My new favorite :)

EDIT: You would still have to predict the dup frame.

Bilu

[bilu]

Dup Prediction
==============
if IsCombed(frm-1)=true and IsCombed(frm)=false then dup=frm

Hybrid threshold measure Part I
===============================
Select(Dup-1,Dup)
Telecide(guide=0,back=0,post=0)

Hybrid threshold measure Part II (not decided)
================================
A)Decimate(cycle=2,debug=true)
Collect and parse output data

or

B)Scripted frame differencing


Comparison
==========

A) Output values will be correct. Will have to collect and parse using third-party apps.

B) Output values need to be scaled. No need for other apps.

Both) Use 40% of the sample.


Your opinion?

[len0x]

Looks good. Dup prediction will be done inside my program anyway (which will parse isCombed() output) and then avs script will be generated for threshold measure.

And it might not be 40% actually since not all patterns are telecined in the source...

[bilu]

Originally posted by len0x
Looks good. Dup prediction will be done inside my program anyway (which will parse isCombed() output) and then avs script will be generated for threshold measure. But between A) and B) from my last post, which do you prefer? Collect Decimate's output or scale frame differencing in Avisynth?

Originally posted by len0x
And it might not be 40% actually since not all patterns are telecined in the source... [/B] By 40% I mean 40% of the pattern cycle (2 in every 5, 2 is 40% of 5).If a pattern is telecine, you'll use 40% of it :)

[len0x]

Originally posted by bilu
But between A) and B) from my last post, which do you prefer? Collect Decimate's output or scale frame differencing in Avisynth?


I have to look at it first. Before I see how difficult mapping can be I can't tell for sure. I'd like to be able to do that without dbgproxy though...

[bilu]

Originally posted by len0x
I have to look at it first. Before I see how difficult mapping can be I can't tell for sure. I'd like to be able to do that without dbgproxy though... The source code is available in dbgproxy.zip, and it's very small.

[len0x]

Originally posted by bilu
The source code is available in dbgproxy.zip, and it's very small.

source code of what ?

[bilu]

Of dbgproxy, to capture the OutputDebugString from Decomb and parse it.

[len0x]

ah, you mean that I can do that by myself without using dbproxy and no mapping is still required ? It's getting interesting :)

[bilu]

yep, that's it :)

But still requires parsing, of course.

Edit: You should try DBGProxy to see what kind of output you get and prepare your parsing.

[bilu]

About the Star Trek Hybrid clip, I finally found this post again:

http://forum.doom9.org/showthread.php?s=&postid=337685#post337685
This works good for me for the challenge clip:

telecide(order=1,guide=1,post=4,vthresh=45,hints=true)
decimate(mode=3,threshold=0.6)

Two points: 1. You need to get the threshold right for mode=3. 2. It's important not to have too low a vthresh with post=4, because it will force backward matches that declare out-of-pattern and thus force video decimation.

I'm planning a new attack on hybrid clips. But first we have to nail this crashing problem with guide=1 for betas 11 and beyond.post (0-5, default 2) controls whether and how Telecide performs postprocessing to clean up frames that come through the field-matching still combed:

post=0: Use this to totally disable postprocessing.
post=1: Use this to enable the metrics calculation and to display the vmetric values but not perform deinterlacing.
post=2: Use this to enable deinterlacing. Note that in this mode, the field matching occurs normally and the best matched frame is deinterlaced and delivered.
post=3: This is the same as post=2 except that the deinterlacing motion map is displayed in white on the deinterlaced frames.
post=4: This is the same as post=2 except that instead of using the best field match for the frame, the original frame is deinterlaced. You would use this to pass video sequences through when you have a hybrid clip.
post=5: This is the same as post=4 except that the deinterlacing motion map is displayed in white on the deinterlaced frames.


vthresh (0.0-255.0, default 50.0) sets the combed frame detection threshold for the postprocessing. You may want to increase this value if too many good frames are being deinterlaced, or reduce it if some combed frames are not getting caught. The default is a reasonable general purpose value. Note that this threshold determines whether a frame is considered combed and needs to be deinterlaced; it is not the threshold you might be familiar with in Smart Deinterlacer. That threshold is determined by dthresh (below); it is the threshold for deinterlacing the frames detected as combed.

Vthresh: frames that exceed it will be considered combed and will be post-processed (deinterlaced).

Post=4: try to do a field match with the FILM pattern. If it can't it will deinterlace (post-process) the current frame instead of trying to match with the best field available. This will be useful for Decimate hybrid modes: they will recognize this as VIDEO and treat accordingly.

So what neuron2 seems to be saying is: if vthresh is low frames will be post-processed, and this will lead to bad matches in post=4 pattern detection, so there is a risk that FILM gets treated as VIDEO both in Telecide and Decimate.

I don't know if this problem is solved, and I think vthresh should somewhat be disabled during hybrid processing: after all, frames will be post-processed by post=4 whenever they don't fit the FILM pattern.

So for now I'd stick with post=0 and deinterlace after the Telecide/Decimate process with KernelDeint. I'd also prefer to use hints=false with Telecide so that it doesn't affect KernelDeint: works better this way with very fast scene changes.

I'll post this in Neuron2 and in Avisynth Usage forums to know if there is any solution (or misunderstanding of mine) to this "vthresh VS post=4" issue.

Reported in:
http://forum.doom9.org/showthread.php?s=&threadid=66236
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=2724#2724


Bilu

[alucard83]

Bilu is the Star Trek mostly film or video?

[bilu]

Mostly film with video parts on remastered or new special effects.
As most Sci-fi hybrid movies. In anime you can't tell for sure :D but some also get 3D CGI effects @30fps on top of Telecined 24fps->30fps.

From http://www.doom9.org/ivtc-tut.htm :

THE DREADED HYBRIDS. Many "making of" documentaries or other special features on DVD’s, and unfortunately, some complete DVDs (a very few thank goodness) are a mix of Film and Video (30fps Interlaced) material. Some (including a lot of the newer anime DVDs, such as Excel Saga) are a mix of Film and 30fps Progressive material. Here you are faced with 2 choices, neither of them pleasant. It, in part, depends on how much of each there is and how it looks with the 2 solutions. For example, a DVD made from a television show might have been created in Film, but have a few minutes of Computer Generated effects done at 29.97fps. The Anime Serial Experiments Lain has some of this. So do the infamous Star Trek: The Next Generation DVDs. So, do you IVTC it and make it 23.976fps and have the CG material play jerky? Or do you make the whole thing 29.97fps so that it will play relatively smoothly, but in the process get lower quality for the same file size, because of the 25% greater number of frames? It's a tough decision. I've seen DVD Documentaries which are made up of mostly Film material. But there will also be interlaced photographs which are frequently panned or zoomed. You IVTC these and those photographs play very jerky. Perhaps the best solution is to use Decomb's Decimate(Mode=1). This will preserve most of the progressive material and will play relatively smoothly but, again, keep it at 29.97fps. If you are using AviSynth 2.51, you can try the Mode=3 option which will blend much of the 29.97fps material and return the whole thing to 23.976fps. I can't tell you what to do in those cases. You’ll have to experiment and see what looks best to you.

Bilu

[bilu]

Good news: I wasn't able to recreate the problem.

Even with an insane vthresh=0 (mark all frames for post-processing) I wasn't able to make it go out-of-pattern - it never got jerky.

telecide(order=1,guide=1,post=4)
decimate(mode=3,threshold=0.6)

works just fine on this clip.

@len0x
Let's keep on moving ;)


Bilu

[len0x]

Originally posted by bilu

@len0x
Let's keep on moving ;)


I'm trying :)
But I'm short on time a bit since not only I have to fix bugz in AutoGK, but also update GK this weekend...

p.s. and also I just spent 4 hours marking courseworks of stupid students :)

[bilu]

Originally posted by len0x
I'm trying :) No need to hurry, mate :)
I just thought you had stopped working on AutoIVTC until my "post=4 VS vthresh" thingy was clear. I'm glad it was a false alarm.Originally posted by len0x
p.s. and also I just spent 4 hours marking courseworks of stupid students :) what are you teaching, oh talented one? :D


Bilu

[len0x]

Originally posted by bilu
what are you teaching, oh talented one? :D


Thank god, nothing :)
But occasionally I've been asked to mark some stuff though...

[bilu]

Hi Len0x,

Any news?


Bilu

[len0x]

yes and no :)

No means I haven't done anything actually, but yes mean that I know when I do that :)

This week i'm releasing 0.8 and then go for three weeks holiday during which I'm planning to come up with two features for AutoGK:
- batch encoding
- IVTC hybrid parameters tuning

[bilu]

My two favorites... :D

[len0x]

after that I don't really see any other tool even come closer to AutoGK :)

P.S. bli'me - my 1500's post :)

[bilu]

Originally posted by len0x
after that I don't really see any other tool even come closer to AutoGK :)

Well, it would be great if encoding tools for RV9 and/or Matroska also got AutoIVTC... ;)

How do you deal with the Field Shift problem? Using Telecide(guide=2) on PAL and KernelDeint on NTSC everytime a source is considered interlaced?

I'd like to know if NTSC sources could also suffer from the field shift problem. I've allways heard of this as a PAL problem :rolleyes:


Bilu

[len0x]

Shifted order is dealt with in d2v (Field operation).
I chose the mode which has less interlacing percentage.
And yes, it's specific to PAL sources.

P.S. RV has no future...

[bilu]

Originally posted by len0x
P.S. RV has no future...

Let's give them a chance, shall we? :D
They're behaving very well with the community, it's the best codec around for anime according to some, they only lack standalone support but hey, not everybody encodes for standalones... ;)

Bilu

[len0x]

Originally posted by bilu
they only lack standalone support but hey, not everybody encodes for standalones... ;)


this is what I call future...
by the end of next year the number of standalones which do not have support of divx/xvid will be the same as now the number which supports them (the money big players are investing in this now are amazing). So why normal end-user should bother with the format he can't really watch anywhere apart from PC whilst there is a format which can be played almost everywhere ?

[bilu]

I guess you're right. Then again, on today's news:
elta also promises to support XviD GMC by mid February as well as OGM. Maybe we can see OGM getting somewhere. And if ChrisHJW pushes enough, maybe even Matroska... :D

Bilu

[len0x]

Originally posted by bilu
I guess you're right. Then again, on today's news:
Maybe we can see OGM getting somewhere. And if ChrisHJW pushes enough, maybe even Matroska... :D


I didn't say anything about containers. Their support is rather on the firmware level, not hardware. Totally different story for codecs.
In fact i believe that both OGM and MKV can be adopted by hardware vendors, but there must be tools producing those files.

[bilu]

Originally posted by len0x
I didn't say anything about containers. Their support is rather on the firmware level, not hardware. Totally different story for codecs. I know, I know. Hope the RV guys start taking a look at licensing to become competitive in such a market. Wouldn't be a bad thing to avoid MPEG licensing monopoly... :rolleyes:

Bilu

[len0x]

First problem I'm running into:

dbgview has issues when running VDubMod, but not avs2avi...

And while writing a simple debugger for it I also see lots of issues with debug process of vdubmod... (for a start I can't even launch vdubmod as debug process - very probably it's _very_ slow to do that)

[bilu]

You don't need to use VDMod in any debug mode, you just need to capture Win32OutputDebugString(). Any process may use this independently, and dbgview will in this case capture messages from Telecide/Decimate, with no need to capture debug from VDMod itself.

I've just downloaded the latest VDMod and DebugView and previewed a script like this:

Telecide(FOrder(),debug=true)
Decimate(debug=true)

with DebugView open, and successfully captured the debug messages.
And since there was no codec or VDMod messages, the output I got was only from Telecide and Decimate. With DBGProxy I had no problems either, although it gets more garbage in the output, drivers loaded ,etc.

So you just need to use VDMod normally and have a process capturing Win32OutputDebugString() messages. You can find related examples on the net or use DBGProxy's source code for that.

PS: Well, maybe you already knew that :rolleyes: .
What kind of issues have you seen between VDMod and DBGView?


Bilu

[len0x]

I know more than that :) (And btw, I'm using dbgproxy from the link you posted ealier)

First when I'm running vdubmod under dbgproxy i get this log (I'm trying to get debug info from KernelDeInt as an example):

dbgproxy is starting up...
Process Launched...
Process Created
DLL Loaded: ntdll.dll
DLL Loaded: C:\WINDOWS\system32\kernel32.dll
DLL Loaded: C:\WINDOWS\system32\ADVAPI32.dll
DLL Loaded: C:\WINDOWS\system32\RPCRT4.dll
DLL Loaded: C:\WINDOWS\System32\AVICAP32.dll
DLL Loaded: C:\WINDOWS\system32\USER32.dll
DLL Loaded: C:\WINDOWS\system32\GDI32.dll
DLL Loaded: C:\WINDOWS\System32\WINMM.dll
DLL Loaded: C:\WINDOWS\system32\VERSION.dll
DLL Loaded: C:\WINDOWS\System32\MSVFW32.dll
DLL Loaded: C:\WINDOWS\system32\SHELL32.dll
DLL Loaded: C:\WINDOWS\system32\msvcrt.dll
DLL Loaded: C:\WINDOWS\system32\SHLWAPI.dll
DLL Loaded: C:\WINDOWS\system32\COMCTL32.dll
DLL Loaded: C:\WINDOWS\System32\AVIFIL32.dll
DLL Loaded: C:\WINDOWS\system32\ole32.dll
DLL Loaded: C:\WINDOWS\System32\MSACM32.dll
DLL Loaded: C:\WINDOWS\system32\comdlg32.dll
DLL Loaded: D:\GK4U\VDubMod\corona.dll
DLL Loaded: <unknown>
DLL Loaded: <unknown>
EXCEPTION cont-first @77f75a58: Breakpoint was encountered
DLL Loaded: C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64
DLL Loaded: C:\WINDOWS\System32\SynTPFcs.dll
DLL Loaded: C:\WINDOWS\System32\MSCTF.dll
DLL Loaded: D:\GK4U\VDubMod\SciLexer.dll
DLL Loaded: C:\WINDOWS\System32\IMM32.DLL
DLL Loaded: <unknown>
DLL Loaded: C:\WINDOWS\system32\oleaut32.dll
DLL Loaded: C:\WINDOWS\System32\Riched20.dll
DLL Loaded: <unknown>
DLL Loaded: <unknown>
DLL Loaded: C:\WINDOWS\System32\MSVCP60.dll
DLL Loaded: C:\WINDOWS\System32\QUARTZ.dll
EXCEPTION noncont-first @77e73887: Unknown Exception
EXCEPTION noncont-first @77e73887: Unknown Exception
DLL Loaded: C:\WINDOWS\System32\DCIMAN32.DLL
DLL Loaded: C:\WINDOWS\System32\CLBCATQ.DLL
DLL Loaded: C:\WINDOWS\System32\COMRes.dll
DLL Loaded: C:\WINDOWS\System32\ddraw.dll
EXCEPTION noncont-first @77e73887: Unknown Exception
EXCEPTION noncont-first @77e73887: Unknown Exception
DLL Loaded: <unknown>
DLL Loaded: <unknown>
DLL Loaded: <unknown>
DLL Loaded: <unknown>
!MPEG2DEC3: D2V v1.77.3 Detected...Compensating
!MPEG2DEC3: bad frames = 0

EXCEPTION noncont-first @77e73887: Unknown Exception
!KernelDeint Version 1.4.0, (C) 2003, Donald A. Graft, All Rights Reserved

EXCEPTION noncont-first @77e73887: Unknown Exception
EXCEPTION noncont-first @77e73887: Unknown Exception
!KernelDeint: frame 0: interlaced

!KernelDeint: frame 0: interlaced

!KernelDeint: frame 0: interlaced

EXCEPTION noncont-first @77e73887: Unknown Exception
DLL Loaded: <unknown>
DLL Loaded: C:\WINDOWS\System32\winspool.drv
EXCEPTION cont-first @37641a4: Access Violation.
FATAL FAILURE -> terminating the process...
Result: FAIL - process had to be exterminated.


I saw the code and know why this is happening (exception causes dbgproxy to kill the process.) Here is how full debugging thing works:

1) you create the process with DEBUG_ONLY_THIS_PROCESS flag
2) you have a loop waiting for WaitForDebugEvent
3) then you process OUTPUT_DEBUG_STRING_EVENT

So I can't atm even start VDubMod with debug flag - main window never shows up :( Without debug flag I obviously can't get WaitForDebugEvent to work properly.

[bilu]

Originally posted by len0x

I saw the code and know why this is happening (exception causes dbgview to kill the process.) Here is how full debugging thing works:

1) you create the process with DEBUG_ONLY_THIS_PROCESS flag
2) you have a loop waiting for WaitForDebugEvent
3) then you process OUTPUT_DEBUG_STRING_EVENT

So I can't atm even start VDubMod with debug flag - main window never shows up :( Without debug flag I obviously can't get WaitForDebugEvent to work properly.

I may not understand you well in programming issues ;)

Why don't you simply output to a file and parse it later instead of using that full debugging process? It's simpler and probably faster too.

Bilu

[len0x]

Originally posted by bilu
I may not understand you well in programming issues ;)

Why don't you simply output to a file and parse it later instead of using that full debugging process? It's simpler and probably faster too.


Let me explain. To capture debug messages you _have_ to run the program (vdubmod) in debug mode. Now I have two options:

1) use dbgproxy (which is a debugger itself and runs everything as debug processes) to output to file and parse it. This doesn't work as I previously told you since dbgproxy kills vdubmod.

2) use my own debugger the same way as in dbgproxy and write file myself. This doesn't work for me yet coz I can't seem to start VdubMod properly...

Dead end so far...

[bilu]

Originally posted by len0x
Let me explain. To capture debug messages you _have_ to run the program (vdubmod) in debug mode. Now I have two options:

1) use dbgproxy (which is a debugger itself and runs everything as debug processes) to output to file and parse it. This doesn't work as I previously told you since dbgproxy kills vdubmod.

2) use my own debugger the same way as in dbgproxy and write file myself. This doesn't work for me yet coz I can't seem to start VdubMod properly...

Dead end so far...

This command-line tool can launch any other program while acting as a debugger to:

* Capture program crashes: when the debugged program crashes, it is terminated without user intervention. A specific return code informs the calling script of what happened.
* Capture program logs generated using the DebugString call, and output them to STDERR (standard error output) prefixed with a '!'.
* Send additional messages to STDERR, about DLL loading, thread creation/termination, etc) -- information typically seen in the output log of a debugger in Windows.


The return codes of dbgproxy are:
-1 Failed to launch the debugged application -- check your command line.
0 The debugged application ended normally, with a return code of zero.
1 The debugged application ended normally, but with a non-zero return code.
2 The debugged application had to be killed because of a fatal error -- a description of the issue has been written to STDERR.

Can't you just trim functionality from DBGProxy's source?
a) Avoid additional messages like thread creating/terminating;
b) Avoid terminating apps on fatal error;

This way you could:
a) use DBGProxy's way of loading VDMod;
b) avoid using debug mode in VDMod;

Bilu

[len0x]

Originally posted by bilu
Can't you just trim functionality from DBGProxy's source?
a) Avoid additional messages like thread creating/terminating;
b) Avoid terminating apps on fatal error;

This way you could:
a) use DBGProxy's way of loading VDMod;
b) avoid using debug mode in VDMod;


I'm trying to find C++ compiler at hand :)
In any case I wanted to use delphi for that. I completely duplicated the calls (it's win32 API anyway), but damn thing is not working...

[len0x]

I made some progress after all ! :)
finally after half a day of struggling I managed to run applications under debug mode with no probs... hopefully now nothing can stop me from reading debug output in memory without writing to intermediate files.

[bilu]

Originally posted by len0x
I made some progress after all ! :)
finally after half a day of struggling I managed to run applications under debug mode with no probs... hopefully now nothing can stop me from reading debug output in memory without writing to intermediate files. That's the spirit ;)

Merry Xmas len0x :)


Bilu

[len0x]

Finally the whole infrastructure is in place and I can implement thershold algorythm itself. I'm looking at the optput of decimate now and trying to think: if all the values I get are already for dupes only then the threshold can be simply set as rounded maximum of metrics from Decimate, right?

So there is no need in algorythm of 90% as you described in the very beginning. What do you think ?

P.S. Also the output I get from decimate is in form of:


Decimate: 0: 0.00
Decimate: 1: 0.21
Decimate: 2: -0.00
Decimate: 3: -0.00
Decimate: 4: -0.00
Decimate: in frm 0, use frm 0
Decimate: dropping frm 1
Decimate: in frm 1, use frm 2
Decimate: dropping frm 3
Decimate: 4: 2.44
Decimate: 5: 0.14
Decimate: 6: -0.00
Decimate: 7: -0.00
Decimate: 8: -0.00
Decimate: in frm 2, use frm 4
Decimate: dropping frm 5
Decimate: in frm 3, use frm 6
Decimate: dropping frm 7
Decimate: 8: 3.41
Decimate: 9: 0.12
Decimate: 10: -0.00


Am I safe to just to look at frames 1,3,5,7,9... ? (coz I feed only sequences of two dupe frames anyway).

[bilu]

This is the kind of output I've seen so far, never seen negative values :confused: Are you sure you used Telecide(guide=0) before Decimate?
!Decimate: 0: 0.00
!Decimate: 1: 5.50
!Decimate: 2: 6.11
!Decimate: 3: 6.55
!Decimate: 4: 0.00
!Decimate: in frm 0, use frm 0
!Decimate: dropping frm 4
!Decimate: in frm 1, use frm 1
!Decimate: dropping frm 4
!Decimate: in frm 2, use frm 2
!Decimate: dropping frm 4
!Decimate: in frm 3, use frm 3
!Decimate: dropping frm 4
!Decimate: in frm 4, use frm 5
!Decimate: dropping frm 9
!Decimate: 5: 6.87
!Decimate: 6: 7.00
!Decimate: 7: 6.69
!Decimate: 8: 6.73
!Decimate: 9: 0.00
We would only need the thresholds from frames 4 and 9 in this case, you are correct. Only the dropped frames threshold value matter.

Bilu

[len0x]

I'm using the following script:

Telecide(order=getOrder(),guide=0,back=0,post=0).Decimate(cycle=2,debug=true,threshold=0.0)

I wonder what is the precision of threshold parameter - 0.1 or 0.01 ?

[bilu]

Originally posted by len0x
I'm looking at the optput of decimate now and trying to think: if all the values I get are already for dupes only then the threshold can be simply set as rounded maximum of metrics from Decimate, right?

So there is no need in algorythm of 90% as you described in the very beginning. What do you think ?

P.S. Also the output I get from decimate is in form of:

Decimate: 0: 0.00
Decimate: 1: 0.21
Decimate: 2: -0.00
Decimate: 3: -0.00
Decimate: 4: -0.00
Decimate: in frm 0, use frm 0
Decimate: dropping frm 1
Decimate: in frm 1, use frm 2
Decimate: dropping frm 3
Decimate: 4: 2.44
Decimate: 5: 0.14
Decimate: 6: -0.00
Decimate: 7: -0.00
Decimate: 8: -0.00
Decimate: in frm 2, use frm 4
Decimate: dropping frm 5
Decimate: in frm 3, use frm 6
Decimate: dropping frm 7
Decimate: 8: 3.41
Decimate: 9: 0.12
Decimate: 10: -0.00

Am I safe to just to look at frames 1,3,5,7,9... ? (coz I feed only sequences of two dupe frames anyway). I'm waking up now it seems... :)

If you're using something like I mentioned here (http://forum.doom9.org/showthread.php?s=&postid=407507#post407507) for dup prediction then you're feeding a frame and its duplicate ( to be able to generate the diff threshold), not two dups. Hence every even frame threshold counts, but not all frames.

EDIT: Precision seems to be 0.1 from the reference manual.

EDIT 2: Still waking up... since frames in Avisynth start on nr. 0, then you were allways right :) : 1,3,5,7,9,....


Bilu

[len0x]

Originally posted by bilu
If you're using something like I mentioned here (http://forum.doom9.org/showthread.php?s=&postid=407507#post407507) for dup prediction then you're feeding a frame and its duplicate ( to be able to generate the diff threshold), not two dups.

Well, that's what I meant by two dupes (one is duplicate of the other) :)

So I will proceed to by selecting maximum metric for duplicates as a threshold parameter for Decimate then.

[bilu]

Originally posted by len0x
Well, that's what I meant by two dupes (one is duplicate of the other) :)

So I will proceed to by selecting maximum metric for duplicates as a threshold parameter for Decimate then. Please test this over some hybrid stuff before assuming the maximum metric. My tests with the Star Trek hybrid have shown some thresholds higher than 0.6 IIRC and 0.6 is what looks best. Hence that majority theory - you could have some dirtier dupes.


Bilu

[len0x]

Originally posted by bilu
Please test this over some hybrid stuff before assuming the maximum metric. My tests with the Star Trek hybrid have shown some thresholds higher than 0.6 IIRC and 0.6 is what looks best. Hence that majority theory - you could have some dirtier dupes.


I won't be able to do that before I release new version, unfortunately. But it's gonna be alpha, so ppl around here can test it (including you I hope).

[bilu]

That means new version soon? :D

Bilu

[len0x]

Originally posted by bilu
That means new version soon? :D


kinda... next week I hope :)

[len0x]

I hardly could test it on NTSC sources though (have just a few of them at hand and no hybrid stuff at all). On normal IVTC-able source I get threshold of 0.2-0.3.

I have only two questions now:

- is this threshold useful only for mode=1,3 of Decimate or mode=0 (normal IVTC) can benefit from it as well ?
- atm I'm putting two decimal digits as threshold value, so I wonder if Decimate interprets that properly.

[bilu]

I can provide some neuron2's Star Trek hybrid clip and some dirty telecined clips as well (some are AVI, not VOB). Send me a PM with an upload address if you want.

Only modes 1 and 3 benefit from the threshold.
I think two decimals are OK, it's not the first time I hear about it.
But I can't try at the moment.


Bilu

[len0x]

Originally posted by bilu
I can provide some neuron2's Star Trek hybrid clip and some dirty telecined clips as well (some are AVI, not VOB). Send me a PM with an upload address if you want.


This has to wait until I'm back from holidays - I can't download/upload anything atm...

[len0x]

Can you test your vob samples with new (0.86) AutoGK. The value chosen for thershold of decimate is: max_decimate_value_for_dupes+0.01

[bilu]

I don't have much time, can you PM me an upload place?

Bilu

[len0x]

I don't have one atm, but can download it from anywhere though...

[bilu]

I've uploaded them to Dark-Cracker.
Please ask him if they're still online and if you can use my account.

It's about 160 MB of VOB samples. All samples are NTSC.

13.391.872 telecine1.vob
19.509.248 telecine2.vob
46.243.840 anime_telecine.vob
35.921.920 hybrid.vob
52.293.632 interlaced.vob

EDIT: Server is down, and before uploading sucessfully some days ago he told me "hum i think my server have shutdown i am currently not at home (i made my study in an another town and i come back to my house only friday). i will restart the server once i will come back and i will send u a PM once the ftp server will be open, sorry for the time waste " , so I guess it'll have to wait. I'll try tonight your last alpha on my samples and give you some feedback tomorrow.

EDIT2: Values I hope to achieve:

telecine1.vob -> 0.01
telecine2.vob -> 0.01
anime_telecine.vob -> 0.01

They're all pure telecined.

hybrid.vob -> looked good at neuron2's proposed value (0.6), but our method is more scientific :D I'm curious about the results.


Bilu

[darkonejr]

len0x,

I've tested this on a couple of Babylon5 episodes, with mixed results. Sometimes, I get calculated threshold values that are higher than 1 (I got 3.34 in one, 4.26 in another)... I'd imagine that the resulting video results can't be good, though I didn't notice anything that jumped out at me when I took a cursory look at it... In any case, I have log files, just need to know which one you need.


Julian

[len0x]

Originally posted by darkonejr
len0x,

I've tested this on a couple of Babylon5 episodes, with mixed results. Sometimes, I get calculated threshold values that are higher than 1 (I got 3.34 in one, 4.26 in another)...

If dupe detection is correct (i.e. all frames detected as dupes are indeed dupes) then yes, resulting video should not suffer even with higher values. Atm the only way to find out how well it works is to examine *_test.avs by commenting out crop in it and looking carefully in vdubmod frame by frame if all even frames are dupes of odd frames...

[len0x]

Originally posted by bilu
EDIT2: Values I hope to achieve:

telecine1.vob -> 0.01
telecine2.vob -> 0.01
anime_telecine.vob -> 0.01



that is impossible as they won't be even detected as hybrid and therefore analysis will not be run...

[darkonejr]

Originally posted by len0x
If dupe detection is correct (i.e. all frames detected as dupes are indeed dupes) then yes, resulting video should not suffer even with higher values. Atm the only way to find out how well it works is to examine *_test.avs by commenting out crop in it and looking carefully in vdubmod frame by frame if all even frames are dupes of odd frames...

Um, I did as you said, and the frames aren't duplicates at all... they aren't even close really, (one frame has a character's eyes open, the next frame, the character's eyes are closed)....

I just commented the line that said crop (0,0,4,4), and moved frame by frame by hitting the right arrow in vdubmod..


Is something seriously messed up?

Julian

[len0x]

Originally posted by darkonejr

Is something seriously messed up?


looks like dupe detection failed at one point and synchronization was lots... it's hard to trace. Do you not see any dupes from the very beginning?. Can you mail me interlace.log, please?

[bilu]

Maybe AVS framenumber versus VDub framenumber?

EDIT: Normal dup values are below 1.0, dirt ones can get to 2.0 or a bit higher. I never seen values higher than 2.0 myself.


Bilu

[len0x]

ok I might have an idea why dupe detection is failing:
say you have a sequence:

progressive
progressive
progressive
interlaced
interlaced

interlaced
interlaced
interlaced
interlaced
interlaced

The pattern as we can see is that first 5 frames is not real telecine, but just the start of interlaced pattern, so detection of dupes as it is will fail here. So In case I have frames 4 and 5 interlaced I need to look at next frame to see if it is real telecined pattern or not... (same goes for first two interlaced frames). Major pain in the ass actually.

[len0x]

Can you try this version and report what results do you get, please:
http://len0x.leffe.dnsalias.com/AutoGK.zip
(I improved dupe detection but have no ways of testing it yet)

[darkonejr]

Originally posted by len0x
Can you try this version and report what results do you get, please:
http://len0x.leffe.dnsalias.com/AutoGK.zip
(I improved dupe detection but have no ways of testing it yet)

Ok, I'll try it out on the same movie I sent you the log files..

Julian

[darkonejr]

Originally posted by darkonejr
Ok, I'll try it out on the same movie I sent you the log files..


I aborted during the actual encode... it calculated the same threshold value.. I've sent you the two files you wanted last time.

Julian

[bilu]

May be helpful:

http://forum.doom9.org/showthread.php?s=&postid=429025#post429025


Bilu

[len0x]

Originally posted by bilu
May be helpful:

http://forum.doom9.org/showthread.php?s=&postid=429025#post429025


how exactly ?

[bilu]

Nevermind, diagonal reading :rolleyes:

Just hoping that this new possibility could bring you some ideas, it didn't to me.

About telecine:

progressive
progressive
interlaced
interlaced -> pre-dup
progressive -> dup

progressive
progressive
interlaced
interlaced -> pre-dup
progressive -> dup

Your example:

progressive
progressive
progressive
interlaced
interlaced -> read as pre-dup.

interlaced -> read as dup? shouldn't be, it's combed.
interlaced
interlaced
interlaced
interlaced


IMHO we must find a way to discard pre-dup and dup values altogether if dup candidate is combed.


Bilu

[len0x]

@Bilu

Actually the problem is much more global. I had to rewrite some stuff now, coz I previously I only analyzed the number of combed frames in 5, but not it's sequence. They just might be distributed like this: 1,3; 2,5 etc. In this case it's not really telecined pattern at all.

@darkonejr

Can you try again a new version please (the same link as it used to)?

[darkonejr]

Originally posted by len0x

@darkonejr

Can you try again a new version please (the same link as it used to)? [/B]

Round 3 results e-mailed


Julian

[len0x]

We're improving slightly, but I came across major problem. Consider this log sequence:

true-true
true-true
true-true
true-true
true-true

true-true
false-true
false-true
false-true
true-true

true-true
true-true
true-true
true-true
true-true

Second 5 frames are considered as telecined pattern while its not :(
Detection can be improved only to a certain extent since I have non-continues sequence of frames...

Any thoughts ?

P.S. Now I see the rationale to discard a certain number of high thresholds to get the most useful ones. maybe I should discard everything more that 1.0 and keep maximum under 1.0 ?

[bilu]

Originally posted by len0x
true-true
false-true
false-true
false-true
true-true

frames are considered as telecined pattern while its not :(
Detection can be improved only to a certain extent since I have non-continues sequence of frames... the combed frames must be together to be considered Telecine.

false-true
false-true
true-true
true-true
false-true

would be considered Telecine. Could you think of a way to consider Telecine only if {2 progressive + 2 interlaced + 1 progressive}? It's the safest way to deal with your interlace.log file IMHO .

Originally posted by len0x
P.S. Now I see the rationale to discard a certain number of high thresholds to get the most useful ones. maybe I should discard everything more that 1.0 and keep maximum under 1.0 ? One way to deal with this would be to output the framenumbers as well to your interlace.log and then check for hybrid thresholds only on neighbour frames: if former framenr != framenr -1 ....

About the threshold values I think that 2.0 is a more broad value, that could handle most dirt hybrids. But only to be used if you can't skip non-neighbour frames.


Bilu

[len0x]

Originally posted by bilu
the combed frames must be together to be considered Telecine.


That's not enough. If we don't have continues frames then everything with just two frames in a row has to be considered as telecined (even if they are in the different 5-frame sequences). But yes, we have to check if next frame or previous frame (of those two) is not combed, which is tricky since often I don't have it due to SelectRagneEvery (and looks like I have to increase significally...)

If I just discard unknown patterns, then for instance for darkonejr case we get mostly NTSC instead of mostly FILM detection (since a lot of telecined patterns were discarded). Tricky thing here that false telecined patterns don't screw general statististics at all (their % is too low anyway), but even one false telecined pattern will destroy threshold detection algorithm...

[bilu]

1) Generate interlace.log as you do now, but add the framenumber.

Example:

1.false.true
2.false.true
3.true.true
4.true.true
5.false.true
21.false.true
22.false.true
23.true.true
24.true.true
25.false.true
41.false.true
42.false.true
43.true.true
44.true.true
45.false.true

2) Look for this pattern:

false.true
false.true
true.true
true.true
false.true

and framenumbers have to be neighbours, or else discard pattern. Will work OK if each piece has enough frames, i.e. use larger chunks than the 14 frames used on compressibility test - 14 frames is not even 3 cycles. 30 frames chunks would be nice IMHO - you can find a maximum of 6 telecine cycles here. And would be pretty accurate for NTSC/Telecine analisys since you know you're dealing with neighbour frames.

3) Keep Telecine framenumbers and IsCombed info on a separate file, will be useful for the next step. No need for IsMoving info, you've already filtered that on this phase.

4) Generate a TXT file with this format for hybrid thresholding:

dups.txt
=======
type int
default 0
4 1
5 1
24 1
25 1
44 1
45 1

Framenumbers followed by 1 are the pre-dup and dup frames. You can generate such a file easily from the file generated on step 3)

About the file format, have a look:
http://www.avisynth.org/index.php?page=ConditionalReader

4)
dec=clip.Telecide(FOrder(),guide=0,post=0).Decimate(cycle=2,debug=true)
clip2=(dup==1)? dec : clip
clip2.ConditionalReader("dups.txt", "dup", false)

Not tested, it may not work. But with this process you could:
1) Avoid non-neighbours;
2) Use info generated on NTSC/IVTC analisys for hybrid thresholding later;
3) Get thresholding only from real dupes;


I don't have the time for more than this, but I hope this gives you some nice ideas :)


Cheers,
Bilu

[len0x]

No worries, the new version I made with some tricks seem to work for darkonejr's cases without any probs (and without those complicated thing you described above) :)

[bilu]

That's what I like to hear :D

So, what are those new tricks? :)


Bilu

[len0x]

just checking two previous frames instead of one (for each 5-frame sequence) and discarding values > 2.0...

[bilu]

Well, that's a hack :D but may be enough :)

Bilu

[len0x]

the only way it fails now is when you have sequence like which is not telecined (not sure how this can happen though since we only look at moving frames):

progressive
interlaced
interlaced
progressive

That's why 2.0 threshold was added. In any other case it works without that hack anyway...

[bilu]

progressive
interlaced
interlaced
progressive

looks like

AABC or ABCC
ABCC AABC

MPEG-2 flags like 301 (TFF+RFF,BFF,BFF+RFF) or 123 (if field order=BFF)

which is part of the Telecine pattern

01230123
---

23012301
---

Possible deviations:

3123 123 1301
--- ---

1301 301 2300
--- ---


Just to represent the situations.

Bilu

[len0x]

I mean there can be two "combed-like" frames in a row which are not really interlaced. I often see one frame which is being detected as combed but is actually progressive that looks like combed...

[bilu]

Sometimes it happens, hence the need of the statistical process like you made :)

I summarized what must be the 4 previous frames before an interlaced or a progressive frame, may be helpful.

p=progressive
c=combed

progressive
=======
ppcc
pccp
ccpp

interlaced
======
cppp
pppc


Bilu

[bilu]

A neat thing about interlaced frames:
cpppc
pppcc
if you keep a "former combed framenumber" value, you'll see that in a telecine pattern:

formercombed=(combedframenr-1) OR (combedframenr-4)

This can become part of a very simple and accurate algorythm :D

NOTE: But to be sure you have to keep another variable: "combed before former combed"

beforeformer < combedframenr - 4

or else you'll detect interlaced ccccc as telecined :)

Bilu

[len0x]

Originally posted by bilu
...if you keep a "former combed framenumber" value...
...NOTE: But to be sure you have to keep another variable: "combed before former combed..."

I'm already doing that :)
The code became almost unreadable :)

[bilu]

Nice :D

But you can't be wrong if:

formercombed=(combedframenr-1) OR (combedframenr-4)
beforeformer < combedframenr - 4

Are you checking these conditions already?

Bilu

[len0x]

not exactly these, but meaning is absolutely the same (I don't actually have frame numbers :) )

[bilu]

Without framenumbers? Weird... :rolleyes:

The conditions I've posted can absolutely assure a Telecine pattern, unless you have one of those 6 frame cycle PAL -> NTSC conversions (also know as 2:2:3:2:3 pulldown)

Read "PAL to NTSC" in http://www.doom9.org/ivtc-tut.htm about these.
Handled by Telecide(Guide=3).Decimate(6)

ABCCDE -> ABCDEE
ABCDEE ABCDEE

As you see, a dup every 6 frames.

ABCCDEFGHHIJ
ABCDEEFGHIJJ

pppccppppccp

So the 5 frames before combed frames are:

cpppp
ppppc

formercombed=(combedframenr-1) OR (combedframenr-5)
AND beforeformer < combedframenr - 5
Conclusion:

TELECINE: fc=((c-1) OR (c-4)) AND bfc = c-5
PAL2NSTC: fc=((c-1) OR (c-5)) AND bfc = c-6

and everything else should be considered unpatterned :)

NOTE: Never heard of hybrids mixing NTSC or Telecine with PAL2NTSC conversions.

EDIT: Pattern detection never looked so easy :D

EDIT2: Advantage of this method on findind the dup frame for hybrid thresholding:

if (fc=c-1 AND bfc=c-5) then c=predup and the next frame will be dup.

EDIT3: And since we're talking about framenumbers maybe we can garantee only neighbour frames ;)


Bilu

[bilu]

Formula works to check the validity of every cycle > 3:

CYCLE: (fc=(c-1) OR fc=(c-(CYCLE-1))) AND bfc= (c-CYCLE)

So if (fc=c-1 OR fc=bfc+1) then cycle=c-bfc

I've got to show this to manono, the silent movie man :D

The formula doesn't work for cycle=3 because it assumes you have more than one combed frame per pattern.

Cycle=3 = 3131 or 1313 MPEG-2 flags

AAB -> ABB
ABB ABB

AABCCD
ABBCDD
pcppcp

before combed: pp

fc=c-1 or fc=bfc+1 doesn't work here. And assuming just cycle=c-bfc for everything would mean every interlaced stuff -> cycle=3 :devil:


Bilu

[len0x]

Originally posted by bilu
Without framenumbers? Weird... :rolleyes:


My routines work just on series of boolean variables (lots of them). As I'm doing everything in one go (i.e. just one loop for interlace/telecine/dupe detection) I find it easier :)

P.S. we cannot really deal with non 5-cycle sources anyway.

[bilu]

We would be able to deal with cycle=3 now: ;)

New version: IF (fc=c-1 OR fc=bfc+1) THEN cycle=c-bfc ELSE cycle=c-fc

Also nice for weird patterns like 22312231.

http://forum.doom9.org/showthread.php?s=&postid=431551#post431551

EDIT: Done better on the same thread, but I guess you're not interested :p

Bilu

[len0x]

finally got to try a couple of vobs if yours:

- hybrid.vob: threshold was 0.01 and in fact there were only 3-4 telecined patterns detected in 10% of the source and the whole sample was treated as hybrid mostly NTSC. I actually liked the resulting avi. But the algorithm definitely needs large source to work on.

- anime_telecine.vob: was detected as FILM (after I fixed divided by zero error, since it was first NTSC material when no telecined or interlaced patterns were detected at all). There were pretty much very few movement frames at all and combed frames are only standalone ones (no pairs at all). very weird.

[CCoug83]

I did have a slight problem encoding 'An American Werewolf in Paris' where .01 was found as the threshold. The entire movie was treated as a hybrid and the result was not so good. The motion in the film looked extremely jerky. I have since re-encoded the file using Gordian Knot, demuxed in Forced Film and whatnot, with better results. I also had some problems with the motion in 'Jason X', but did the same thing with more success.

Other than that, every single movie I have encoded (upwards of 150 now) have turned out better in AutoGK than my previous encodes done in GK. Thanks for the great tool once again.

[len0x]

Originally posted by CCoug83
I did have a slight problem encoding 'An American Werewolf in Paris' where .01 was found as the threshold. The entire movie was treated as a hybrid and the result was not so good. The motion in the film looked extremely jerky. I have since re-encoded the file using Gordian Knot, demuxed in Forced Film and whatnot, with better results. I also had some problems with the motion in 'Jason X', but did the same thing with more success.


I'd like to see the logs file for those movies with interlace.log.
Most probably they were detected as hybrid by mistake...

[therealjoeblow]

I encoded "The Red Violin", 4x3, detected as hybrid, and the encode plays back *very* jerky. Looking at frame by frame it in VDubMod, there are several frames that look like perfect, sharp, stand-alone images, then one or two which are blurry, looking like 2 images were mixed together (sorry, I don't know all the correct terminology, but they do not look 'combed', just like 2 consecutive images in a motion sequence blurred together), then the sequence repeats. I used AGK 1.0 and 1.05, no difference, XviD Alpha, XviD 1.0RC3 and DIvX5.1.1. Here's portions of the log and interlace files:


false-true
false-false
false-false
false-false
false-false
false-false
true-true
true-true
false-false
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-true
true-true
false-true
true-true
true-true
false-false
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-false
true-false
false-false
false-false
false-true
true-false
true-true
false-false
false-true
false-false
false-false
false-false
false-false
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
true-false
false-false
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
true-true
true-false
false-false
false-false
false-false
true-false
true-false
false-false
false-false
false-false
false-false
false-true

[3/14/2004 8:58:57 PM] Input dir: D:\DVDVolume\VIDEO_TS
[3/14/2004 8:58:57 PM] Output file: D:\DVDVolume\Red Violin.avi
[3/14/2004 8:58:57 PM] Audio: Unknown language
[3/14/2004 8:58:57 PM] Subtitles: none
[3/14/2004 8:58:57 PM] Codec: XviD
[3/14/2004 8:58:57 PM] Target size: 1401Mb
[3/14/2004 8:58:57 PM] Custom resolution settings: fixed width of 576 pixels
[3/14/2004 8:58:57 PM] Custom audio settings: AC3
[3/14/2004 8:58:57 PM] Started encoding.
[3/14/2004 8:58:57 PM] Demuxing and indexing.
[3/14/2004 9:00:36 PM] Analyzing source.
[3/14/2004 9:00:36 PM] Writing the following script to D:\DVDVolume\gk_tmp\lastjob.vcf
===========================================================
VirtualDub.Open("D:\\DVDVolume\\gk_tmp\\_.avs",0,0);
VirtualDub.RemoveInputStreams();
VirtualDub.video.SetDepth(24,24);
VirtualDub.video.SetMode(0);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetCompression();
VirtualDub.video.filters.Clear();
VirtualDub.subset.Delete();
VirtualDub.SaveAVI("D:\\DVDVolume\\gk_tmp\\_.avi");
===========================================================
[3/14/2004 9:08:24 PM] Source has percentage of interlacing in motion areas: 39.27
[3/14/2004 9:08:24 PM] Source has percentage of telecined patterns: 92.80
[3/14/2004 9:08:24 PM] Source has percentage of progressive patterns: 6.66
[3/14/2004 9:08:24 PM] Source has percentage of interlaced patterns: 0.54
[3/14/2004 9:08:24 PM] Source is considered to be hybrid (mostly FILM).
[3/14/2004 9:08:25 PM] Writing the following script to D:\DVDVolume\gk_tmp\lastjob.vcf
===========================================================
VirtualDub.Open("D:\\DVDVolume\\gk_tmp\\_test.avs",0,0);
VirtualDub.RemoveInputStreams();
VirtualDub.video.SetDepth(24,24);
VirtualDub.video.SetMode(0);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetCompression();
VirtualDub.video.filters.Clear();
VirtualDub.subset.Delete();
VirtualDub.SaveAVI("D:\\DVDVolume\\gk_tmp\\_test.avi");
===========================================================
[3/14/2004 9:08:25 PM] Looking for optimal hybrid thresholds.
[3/14/2004 9:13:48 PM] Found threshold of: 1.87
[3/14/2004 9:13:50 PM] Found 187179 frames
[3/14/2004 9:13:50 PM] Audio size: 187,367,424 bytes (178.69 Mb)
[3/14/2004 9:13:50 PM] Overhead: 2,222,720 bytes (2.12 Mb)
[3/14/2004 9:13:50 PM] Video size: 1,279,464,832 bytes (1220.19 Mb)
[3/14/2004 9:13:50 PM] Running compressibility test.
[3/14/2004 9:13:50 PM] Writing the following script to D:\DVDVolume\gk_tmp\Red Violin_comptest.avs
===========================================================
LoadPlugin("D:\PROGRA~1\AutoGK\filters\mpeg2dec3dg.dll")
LoadPlugin("D:\PROGRA~1\AutoGK\filters\autocrop.dll")
LoadPlugin("D:\PROGRA~1\AutoGK\filters\decomb.dll")
LoadPlugin("D:\PROGRA~1\AutoGK\filters\undot.dll")

function getOrder(clip c) {
order = GetParity(c) ? 1 : 0
return order }

movie = mpeg2source("D:\DVDVolume\gk_tmp\Red Violin.d2v")
cropclip = autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=0,threshold=35)
c_width = width(cropclip)
c_height = round(height(cropclip) / 0.911392405063291)
input_par = float(c_width)/float(c_height)
fixed_aspect = input_par > 1.4 ? 0.911392405063291 : 0.888888888888889
c_height = round(height(cropclip) / fixed_aspect)
input_par = float(c_width)/float(c_height)
out_width = 576
out_height = round(float(out_width) / input_par)
hmod = out_height - (floor(out_height / 16 ) * 16)
out_height = (hmod > 4) ? (out_height + (16 - hmod)) : (out_height - hmod)
new_aspect = (float(out_width) / float(out_height)) / fixed_aspect
autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=new_aspect,threshold=35)
Telecide(order=getOrder(movie),guide=1,post=2).Decimate(mode=3,threshold=1.87)
Undot()
LanczosResize(out_width,out_height)
SelectRangeEvery(300,15)
===========================================================
[3/14/2004 9:13:51 PM] Writing the following script to D:\DVDVolume\gk_tmp\lastjob.vcf
===========================================================
VirtualDub.Open("D:\\DVDVolume\\gk_tmp\\Red Violin_comptest.avs",0,0);
VirtualDub.video.SetMode(1);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetRange(0,0);
VirtualDub.video.SetCompression(0x64697678,0,10000,0);
VirtualDub.video.SetCompData

[len0x]

Part of the interlace.log file you posted doesn't contain any progressive pattern, but normal FILM pattern. Almost 7% of progressive is quite a lot and I wonder how they managed to be in almost FILM movie...

[therealjoeblow]

I don't know what I'm supposed to see here, the file is 280k (23000 lines long). I'm assuming you don't want me to post the whole thing...

I also notice when frame-stepping with vdubmod that in some of the places where the motion looks choppy on playback that just before the blurry frames there are duplicate ones (ie, 2 of the exact same frame then the blurry one)

Here's another portion of interlace.log that looks different from the one I posted before:

true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-false
true-true
false-true
false-true
false-true
true-false
true-true
false-false
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-false
true-true
false-false
false-true
false-true
false-true
false-true
false-true
true-false
true-true
false-false
false-true
false-false
true-false
true-true
false-false
false-true
false-true
true-false
true-true
false-false
false-false
false-true
false-true
false-true
false-true
false-true
false-true
false-false
false-true
false-true
false-false
false-true
false-true
false-true
false-true
false-true
false-true
false-false
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-false
true-false
false-false
false-true
false-true
true-false
true-true
false-false
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-false
false-false
true-false
true-false
false-false
false-false
false-false
true-true
true-false
false-false
false-true
false-true
true-false
true-true
false-false
false-true
false-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-false
true-false
true-true
false-false
false-true
false-true
true-true
true-true
false-true
false-true
false-true
false-true
false-true
false-true
true-false
true-false
false-false
false-false
false-true
true-false
true-false
false-false
false-true
false-false
true-false
true-true
false-false
false-false
false-false
false-true
false-false
false-false
false-true
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-false
false-true
false-false
false-true
false-false
false-false
false-false
true-true
false-true
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-false
true-true
false-false
false-false
false-false
false-true
false-true
false-true
true-false
true-true
false-false
false-true
false-true
true-true
true-true

[len0x]

Ok, now the log is better. Without seeing the source if we assume that it's FILM - the reason that AutoGK is failing to detect it as such is that probably combing detection is failing (in decomb). it may be fixed with different threshold parameter for it, but atm changing that is not possible in AutoGK...

[therealjoeblow]

Originally posted by len0x
...it may be fixed with different threshold parameter for it, but atm changing that is not possible in AutoGK...

Will it be adjustable in the future? I'm following all of the AGK threads, so I know your agenda for what it is and isn't supposed to be, but what I (and others, I'm sure) would *really* like would be *some* 'GK-like' flexibility in configuration. Recognize that I said *some* - We do not want AGK to become as complex as GK, that's why I (and others) use it, because the learning curve and amount of tweaking in GK is too high. But, if you could add the ability to include user-configurable filters into AGK, that could help with the 10% (?) of the encodes where AGK can't do a perfect job - ie, in this case, I could spec out a different decomb filter, or adjust the parameters of the default one. Likewise, I tried to encode a few of the old (1960's) children's cartoons which have a lot of noise, and the default undot filter doesn't do a very good job of cleaning them up, they're full of artifacts after the encode. It would be nice to be able to use some of the other denoise type filters available to see if any of them do a better job.

Like I said - the object is *not* to make AGK as complex as GK, but to add some advanced flexibility here and there so that 'power users' can take advantage and get that extra 10% out of AGK, while remaining transparent to the bulk of end users who don't need the added functionality.

By the way - I don't think I've ever said 'Thank you' for the great tool - Your work and effort is truly appreciated, and although it may seem that some people complain alot, hopefully you can see through that and pick-out what is intended to be constructive, and continue to develop AGK to be the one tool that shines above all others.

[therealjoeblow]

Just for fun, I ran the Red Violin through FairUse 0.40, using the IVTC and Smart Deinterlace options, and it managed to properly deinterlace the entire hybrid movie perfectly. There are none of the duplicated frames, nor any of the mixed (blurry) frames, and playback of the encoded file is perfectly smooth toruoghout, no jerkyness.

Only problem is that the actual quality of the xvid encode is *significantly* poorer than what AGK produces. So now I'm at an impass with this type of material - AGK can't deinterlace it properly but produces excellent visual quality, and FU IVTC's/deinterlaces perfectly, but produces only mediocre visual quality. Crap.

Hopefully you can figure out what it is that FU does in it's deinterlacing logic (I know there's been some discussion on their thread and it's not all that clear), and adjust AGK's plugins and algoritms too, that would be great.

[len0x]

There is nothing really to adjust in encoding process - of course if movie is detected as hybrid while it's not, then its going to be screwed. FU doesn't handle proper hybrid matterial _at_all_. AutoGK can handle IVTC material no worse than FU, but it's physically impossible to write an automatic 100% correct detection tool, so in some cases you have to go to normal GK and select IVTC there...

P.S. I'm curious though - can you make a significant vob (i.e. several hundred Mb) available for me to play with ?

[therealjoeblow]

Originally posted by len0x

P.S. I'm curious though - can you make a significant vob (i.e. several hundred Mb) available for me to play with ? \

@len0x - I PM'd you about this - did you get the message?

[Carraway]

Originally posted by len0x
There is nothing really to adjust in encoding process - of course if movie is detected as hybrid while it's not, then its going to be screwed. FU doesn't handle proper hybrid matterial _at_all_. AutoGK can handle IVTC material no worse than FU, but it's physically impossible to write an automatic 100% correct detection tool, so in some cases you have to go to normal GK and select IVTC there...

I seem to recall back in the very early versions of GKnot there being an "Always IVTC" option, or at least something to that effect. Pretty much all my problems relating to AutoGK since version 0.8 have been related to the auto-detection, and it's frustrating because it's on material that I know has to be 100% IVTC'ed. I realize that the virtues of auto-detection are that the demographic the program is made for (newbies) have no idea what IVTC means or does. Is there any chance that this option might make a return in a hidden or non-obtrusive form so that it doesn't confuse the newbies but is still useful by those of us who tend to encode a lot of difficult-to-auto-detect FILM material?

(P.S. I may have mentioned this, but I'm deeply in love with your program. I would marry it if man and software were allowed to mate. :) Thanks again.)

[len0x]

Originally posted by therealjoeblow
\

@len0x - I PM'd you about this - did you get the message?

Yes, I did. Thanks. It's just its a weekend :)
I'll PM you on Monday when I set up things for uploading...

[len0x]

Originally posted by Carraway
Is there any chance that this option might make a return in a hidden or non-obtrusive form so that it doesn't confuse the newbies but is still useful by those of us who tend to encode a lot of difficult-to-auto-detect FILM material?


well, if we're talking about just one scenario: force normal ivtc on any NTSC material then I can do this - put ".ivtc" file in the output dir and then AutoGK overrules its detection...

[Carraway]

Originally posted by len0x
well, if we're talking about just one scenario: force normal ivtc on any NTSC material then I can do this - put ".ivtc" file in the output dir and then AutoGK overrules its detection...

Wow, that's a great solution. That would fix all my IVTC problems, and is virtually impossible for a newbie to accidentally turn on. Thanks len0x. :)

(Woohoo!)

[len0x]

so, version with this hack is out (1.08). I hurried with it coz I run into similiar problems myself on one source :)

[therealjoeblow]

Excuse my ignorance - when you say 'put ".ivtc" file in input directory', do you mean that I just need to create a dummy file named the same as the 1st .vob file, but with the extension .ivtc instead? And is the file just empty, or does it need something in it,

Thanks. I'll test it tonight and send you the test files too as discussed.

[len0x]

it should be just ".ivtc" file (i.e. just extension without a name). contents doesn't matter.

[therealjoeblow]

Ok - I figured out how to create the ".ivtc" file - bloody Windows won't let you create a file with extension only (ie, no filename infront of the .)

Have to do this from a DOS command line using something like:

ECHO >.IVTC {F6}{CR}

[therealjoeblow]

Well, the forced IVTC worked perfectly - the entire encode plays back with no jerkyness or blurry frames now. I still get the odd frame with a little of the grey and red shadowing at edges (eg. around faces) here and there, but not a big deal - I'm going to try a divx encode, maybe that's an issue with the xvid codec, I'll let you know.

Thanks for the IVTC fix len0x - I'm still trying to send you the test files along with some of the interlace and encode logs for you to continue research into this if you want them.

[Carraway]

Originally posted by therealjoeblow
Well, the forced IVTC worked perfectly - the entire encode plays back with no jerkyness or blurry frames now. I still get the odd frame with a little of the grey and red shadowing at edges (eg. around faces) here and there, but not a big deal - I'm going to try a divx encode, maybe that's an issue with the xvid codec, I'll let you know.

Very briefly, I'm certain it's not just an xvid bug for two reasons -- first, the grey/red shadows are present in the AVS script before it ever gets encoded, ane second, changing the autocrop multiple to 8 in the AVS script fixes the problem. I don't know whether the bug is in the autocrop filter or in decomb, but I don't think the problem specifically involves the code of AutoGK (or Xvid/Divx).

[therealjoeblow]

Originally posted by Carraway
Very briefly, I'm certain it's not just an xvid bug for two reasons -- first, the grey/red shadows are present in the AVS script before it ever gets encoded, ane second, changing the autocrop multiple to 8 in the AVS script fixes the problem. I don't know whether the bug is in the autocrop filter or in decomb, but I don't think the problem specifically involves the code of AutoGK (or Xvid/Divx).

Sorry - I forgot to report back, but of course, you're absoultely correct - DivX5 doesn't make any difference. Neither does using XviD alpha.


@len0x - any chance of changing the autocrop values as Carraway suggests?