@len0x: auto-IVTC methods for AutoGK

[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 :)