PDA

View Full Version : IVTC development thread - Moved from divx 3


DDogg
12th August 2001, 23:41
YES! Example of a working and verified AVS script using the InverseTelecine plug-in. Also, *Super* Dividee recompiled the source and got a 10-15% speed increase according to the dvd2svcd author. Get if from link below.
---------------------------------------------------
LoadPlugin("C:\Program Files\gknot\MPEG2DEC.dll")
LoadPlugin("C:\PROGRAM files\dvd2svcd\InverseTelecine.DLL")
mpeg2source("D:\sandra\DVD2AVI Project file.d2v")
crop(13,4,699,466)
DoubleWeave
InverseTelecine(40,10,15)
BicubicResize(640,352,0,0.60)
----------------------------------------------------

dvd2svcd.doom9.net/ (http://dvd2svcd.doom9.net/)

doom9
13th August 2001, 02:13
I was under the impression that auto-ivtc wasn't that great and when you have to do it manually you're better off with tmpg in the first place

DDogg
13th August 2001, 02:59
Well, I kinda thought that too, but this worked like a champ on a 28days. Let's try to find some reasonably nasty stuff to throw in its path. Got anything good for a test?

doom9
13th August 2001, 04:09
how about a lain episode?

DDogg
13th August 2001, 05:03
Don't know much about anything but dvds..is that broadcast interlace or telecined?

Prosper
13th August 2001, 11:37
Just to clarify: telecined==interlaced, but can be reconstructed to progressive (ie: original copy is film, not video), correct?

doom9
13th August 2001, 13:20
that's telecined... and badly cut up as almost any anime flick. In fact I have a inverse 3:2'd (TMPG) copy of an episode plus some trailer, I think Captain Bebop which is also very badly interlaced... I'd rather not manually IVTC these but it's really hell to handle. But I got it from good sources that Fair Use managed to get these things done without problem which is quite amazing.

DDogg
13th August 2001, 14:37
Sounds worth a try. I think the plug-in is more to handle common "hybrids" but what the hell, it may surprise us. We need to know, one way or the other. It would help DVD2SVCD too. I wouldn't mind having a trailer as a test piece. Mail me if you have a ftp or a link available. I've got great DL speed, about 4mbits. Up sucks though.

"But I got it from good sources that Fair Use managed to get these things done without problem..."

/He one mucho smart hombre. It would be great if he would consider doing a DLL with some of his IVTS tricks. I'll bet lots of goodies are in FU, to say the least.

DDogg
13th August 2001, 14:39
Prosper, yes, that is what I understand.

manono
13th August 2001, 20:45
Hi-Congratulations DDogg upon reaching 1000 posts. You're an inspiration to us all :=)

I can confirm Doom9's statement about Fair Use. I've worked with both Cowboy Bebop and Lain in TMPGEnc-VFAPI-Nandub and Fair Use, and Fair Use's IVTC and deinterlacing is unsurpassed. fu2k is a genius.

DDogg
13th August 2001, 21:40
Heh, don't quite know how to take that :)

It's actually rather embarrassing, the number is erroneus. Some of the methods I use to keep up the Q&As seem to confuse the count. It is probably no more than half that, if that much.

If you get the chance to work with another of these difficult sources, please consider a variation of the above script and give it a try. I hope it works; it would make things *so* much easier for people, but I actually expect it to hiccup on a complex telecined anim. Love to be wrong on that one.

DDogg

ArsCraven
14th August 2001, 02:30
I was under the impression that the CG sequences in Lain and Cowboy Bebop were rendered at 30fps. I know that the the spinning episode title blocks in Cowboy Bebop certainly are. Since these scenes were never telecined to begin with, wouldn't running them through IVTC just throw out perfectly good frames and make the end result jerky?

As substitute, I'd suggest Trigun. It's as bad as any anime, and it's pure cel art.

DDogg
14th August 2001, 02:58
ArsCraven, I think you know this plug in don't you? What do you think about it?

Seems like this would be a good place to put a link to the faq you were playing around with?

doom9
14th August 2001, 04:09
cg is mostly 24fps as it's cheaper to make.. and the episodes contain film, ntsc, hybrid, everything you can imagine.. a real nightmare.

DDogg
14th August 2001, 09:17
Love to have a trailer to play around with. :)

doom9
14th August 2001, 11:12
at 64kbit/s up bw that's going to be a problem

manono
14th August 2001, 12:02
"Heh, don't quite know how to take that"

Hi DDogg-that's why I put a smiley after the comment- so it wouldn't be taken as being sarcastic. And I was sincere. Your contributions are plentiful, and you're always (usually?) cheerful and well informed. I, for one, am glad you're here. Didn't your mother teach you to accept compliments gracefully :=)?

Just finished my first test of the IVTC .dll. It was an easy test (an Escaflowne anime episode), but the results were very good. It did the job-converted the 29.97 fps. to 23.796 fps, all signs of interlacing are gone, and none of that shimmering or flashing I get when doing it in TMPGEnc. None of what sometimes is called "dot crawl" or "line crawl", where with static figures, the outlines kind of move or shimmer. I'm very pleased. I'll try a Cowboy Bebop episode tonight (unfortunately, I don't have that real torture test-a Lain episode-lying around).

There's one minor problem, though. The original .avs file is at 29.97 fps and the stats file is at 23.976 fps, and GKnot doesn't allow them both to be open at the same time. In addition, the number of frames as reported by the stats file is slightly different than what I get when switching from 29.97 to 23.976 down at the lower left in the Stats File Editor. These are relatively minor problems, though, and easy to work around. In addition, I may not be doing it exactly right.

Thanks for reporting your find.

Prosper
14th August 2001, 12:35
The worst interlaced DVD I've got is sci-fi channel's Dune. I think it is originally Film, but given the budget for that sort of production it may be video. I've not had much luck with TMPG or VDub's IVTC/de-interlace filters, but I'll try out the new plugin, and report my results.

ArsCraven
14th August 2001, 12:36
I'm going to try this on Record of Lodoss War. Jesus what a mess that is.

ArsCraven
14th August 2001, 12:53
Well, it is possible for it to not-work. However, since the source I used is an absolute bear that I haven't been able to get with any amount of teasing from TsunamiMPEG I think these might be extreme conditions.

See here. (http://www.engr.orst.edu/~sheareni/lodoss-ugly.jpg)

This is a frame from Record of Lodoss War episode one using the IVTC filter with (40,10,15) as the arguments. If you rip the episode with starting with chapter 2 and use the filter, then this is frame 6589. I'm going to try again in a moment with different settings.

Does any have tool to scan through a source for frames above a certain flicker threshold?

ArsCraven
14th August 2001, 13:43
Still no joy on Lodoss. If someone else has encoded this, and knows if/why it's a lost cause please tell me. I'd to stop banging my head against that particular wall.

On the positive side, it did wonderful on Gasaraki. Maybe it will help me with my other problem (http://pub28.ezboard.com/fdoom9smpegforumfrm1.showMessage?topicID=832.topic) encoding that show.

What would also be nice now is a tool that reports the number & %age of frames that have flicker over a certain threshold.

manono
14th August 2001, 19:24
Hi- No luck here either. I encoded the opening song segment of Cowboy Bebop using 40,10,15, then 30,10,10, and finally 15,5,10, and still had a considerable amount of interlaced frames. If anyone understands how to adjust the parameters so that it picks up the pattern changes which occur at just about every scene change in the opening sections of many anime episodes, please enlighten us. Too bad, too. It gives the animes a nice appearance.

ArsCraven
14th August 2001, 22:06
I've been getting a little better results in Lodoss with (50,10,10), but still no where near acceptable. I think a really low threshold would be best, to get it to recalculate constantly.

manono
15th August 2001, 00:27
Hi ArsCraven. I saw your post before you edited it, and I think I know why you edited it, but is it possible to have a 10 frame pattern, as I think I've seen them before (1,3)(2,4)(1,3)(2,4)etc. I thought perhaps that's what you were referring to.

Anyway, I came to the same conclusion as you (more sensitive pattern detection needed), and am experimenting with 40,10,5 now. I went back to working on the Escaflowne episodes I was encoding before I got sidetracked by this (I went over the one I had done before, but more carefully, and noticed some stray interlaced frames), but they aren't really a good test.
Good Luck.

ArsCraven
15th August 2001, 02:57
Actually I was thinking of more variety in 5-frame patterns. Then I realized (belatedly) that all the patterns that aren't used give you a situation where two consecutive frames share half the same fields, which is ridiculous and useless.

DDogg
15th August 2001, 03:05
manono, really thanks for the kind words! :)
-------------------------------

Well, the results are still very, very encouraging so far.

The stuff you crazy anim heads :---) are throwing at this poor little dll are mighty tough and nasty. On the bright side, it sounds like it will handle most "standard" jobs well.

This kind of testing and feedback could well draw a programming type into the battle. The source is available on this thing so hopefully we can get a "champion" going on maybe making some mods to it.

Man, I wish FU2k would look at it. Anybody know him well enough to ask? It nearly has to be a good programmer who *also* has a good understanding of this weird and arcane IVTC stuff. Hell, how many is that? A dozen worldwide? Still, we have the best and brightest in this group so maybe we will get lucky.

Thanks *so* much for these detailed test reports, and if you can, keep 'em coming. We have always been short on good test data on avs based IVTS. I think because it seemed such a huge chore, and again, only somebody that understands the whole *manual* (shudder) IVTS process can really do this stuff.

I am certainly not part of that elite group. I think all you guys are nuts to sit there in TMPG going frame by frame. I just could never "get it". Hell understanding freaking sub-netting is easier that this stuff!

Macdaddy
15th August 2001, 05:21
I ran the plugin (default settings) through the gauntlet by encoding the first angle of "Alive" on the Beastie Boys Criterion Disc...

The results are better than the ati player 4.1 player gives me. However, there are still a number of stray lines, and one set of shots that I think must be in the wrong aspect ratio, but I will see what happens with lower threshold settngs...

I would be happy to post the source-for others to try, but I don't have anywhere to put it...

@DDogg: ["I am certainly not part of that elite group. I think all you guys are nuts to sit there in TMPG going frame by frame. I just could never "get it". ] lol, I thought I was the only one (and it certainly wasn't for lack of trying).

ThePanda64
15th August 2001, 05:42
What about the "reconstruct from fields - adaptive" IVTC in VirtualDub? I always thought that was good. Is this dll any better for anime?
Sometimes I use smart deinterlace in addition to the IVTC, but does this cause any problems? In my latest anime encode, it looks like the black lines on the edges of people and things are moving back and forth..

manono
15th August 2001, 09:50
The guy said in his readme that the deinterlacing hasn't been perfected yet. I'm tired of messing with it. I'm going blind scanning these videos frame by frame. I think I'll go play with the "VerticalReduceBy2" included in the new GKnot. I'm encoding some stuff now, and it seems even faster than before. I'll know in a while how it turns out, but if the WEF recommends it, that's good enough for me.

DDogg
15th August 2001, 13:35
VerticalReduceBy2 followed by resizing is an excellent,fast, down and dirty way to deinterlace true interlace like a capture of a broadcast or dv cam or something like that but it is not Inverse-Telecine which is what most of this thread is about trying to do, as with anything else but IVTC you are still at 29.9 after it is finished. You could also use Dividee's blendfields function in his adapted mpeg2dec, but there would be a speed hit there and again, you are at 29.9 although with better quality (I am told) than VerticalReduceBy2.

What we are trying to accomplish is to remove the telecine process to arrive back at the original film speed (more or less). We are really talking about two completely different processes. Frankly, If I was into anims and it was one of these crazy complicated mixed rate hybrids, I would probably use [edit]Dividee's new port of smartdeinterlace and not worry a bit about the higher fps rate.

But, again, that's not what we were trying to do.

manono
15th August 2001, 18:31
"VerticalReduceBy2 followed by resizing is an excellent,fast, down and dirty way to deinterlace true interlace like a capture of a broadcast or dv cam or something like that but it is not Inverse-Telecine which is what most of this thread is about."

Yes-the Inverse Telecine .dll does the job well enough, but does result in the minor annoyance of the .d2v being at 29.97 fps and the Stats file being at 23.976 fps. But by using "Forced FILM" in DVD2AVI to perform IVTC, and then the "Deinterlace" (VerticalReduceBy2) option in the new GKnot, I've solved the problem, for myself anyway. It's fast and easy, looks good, plays smoothly, and seems to wipe out all of the interlacing. It's not as if I thought of it myself. I've seen the discussions for some time in the forums about the best way to go about this. It's just the first time I've tried it out. I'll try this method on some more difficult material in a few days. Perhaps ArsCraven would like to try it out with Lodoss. I'll have the second disc of Record of Lodoss Wars to test out myself soon. You Europeans don't know how easy you have it unless you've spent a few hours looking at frames in TMPGEnc. Never again.

TheWEF
15th August 2001, 19:22
i do NOT recommend deinterlacing instead if ivtc!!!!

deinterlacing means that you are loosing details and quality. ivtc means reconstructing the original film-frames.
deinterlacing should be uses for truly interlaced (tv) material only.

afaik dvd2avi's force-film (=ivtc) works with 90% of all the ntsc-dvd-material anyway. if it doesn't you should use tmpeg or try this new method.

if you find interlaced matrial on a pal-dvd you have to deinterlace :(
i that case VerticalReduceBy2 is ok.

wef.

ArsCraven
16th August 2001, 11:22
I am still getting better results with TMPGEnc's auto IVTC than with this Avisynth filter. The avisynth filter seems to have problems avoiding interlacing on scene changes. Since I have only been testing it on anime this may stem from the fact that it checks for interlace only using luminance and ignoring chrominance. The large flat areas of color in animation scenes would allow plenty of places where only color would vary. Secondly, there are some sources that I still cannot IVTC (Lodoss War). I'm going to modify the filter to use more pulldown patterns, and if that works out I'll try and get it to consider chrominance as well.

[edit]

Scratch that. This thing is working better than Tsunami, I just happenend to look at a bit of video where Tsunami hadn't fucked up. Yes it's way better, except for the tendency for interlaced frames to occur on scene changes when using it on animation.

Leuf
16th August 2001, 12:58
For sheer adaptability you may be better off trying don graft's telecide filter than setting the threshold on the avs plugin really low. The main problem with telecide is not of letting interlaced frames through but of generating false duplicate frames, which makes the final output noticably jerky if you use his decimate filter to convert it to 23.976. However, if you have something really messy that you are going to leave at 29.97, you may find that running telecide and then following it up with an area deinterlacer gives you better results than an area deinterlacer alone. But for true 3:2 pulldown sources with pattern changes, from the limited testing I've done I think this plugin is the best I've seen from an automatic process.

I've been working on a 2 pass semi-automatic IVTC process that is showing promise, but it's no where near ready for the public eye.

DDogg
16th August 2001, 19:42
"I'm going to modify the filter to use more pulldown patterns, and if that works out I'll try and get it to consider chrominance as well."

Evil laugh, so...you can do this stuff, can you? :)

Actually I wonder if you and Dividee could maybe team up a bit and make this a killer app? Maybe you can do it on your own? Whichever, I would guess with some additional checking and patterns, this thing could really rock. Hope you have the time to pursue it for us.

DD

DDogg
17th August 2001, 20:51
I'm hoping this thread will not die so consider this a bump plus I am wondering it any of you have tried Dividee's version of the smart de-interlace filter on those sources you do not wish to do IVTC.

western shinma
19th August 2001, 10:04
Just a quick note: in spite of what a couple people said in the FairUse forum, it can't do a proper IVTC on Lodoss either (at least for the second disc). Even with FairUse, it is noticeably jerky, and lots of interlaced frames left over which FU doesn't bother to deinterlace for some reason. This looks promising however.

Even when TMPGEnc works properly on anime, there's usually a few interlaced frames left over, so I usually combine that with smart deinterlace anyway. Unfortunately, the avisynth version only works with luma, which is not optimal for anime. And then there's the lack of an Avisynth native VobSub...

DDogg
19th August 2001, 10:40
WS, try to work with Dividee a little. He may be able to assist on the software side with somebody like you who knows the other. Also, thanks, very much, for clarifying that FU is not perfect on IVTC. That means this is one of the most promising solutions, and with the addition of additional patterns and tweaks may well become the most robust solution for IVTC. ANy help you can give would be greatly appreciated by all.

Leuf
19th August 2001, 12:07
I think you'd be surprised at just how bad automatic detection is, it isn't as much a problem of adding patterns (though obviously you need them) as being able to recognize what's there. In my approach I break the source down into scenes, and then search the scenes for patterns. Each scene gets rated based on what percentage of the scene had a detectable pattern. There are more 0s than 90s, where 0 means there was natta in the scene that told the routines anything about the pattern. That means a good percentage of the time the routines haven't the foggiest idea what they are doing. And that is using 2 independent detection routines, searching for patterns of interlacing and for duplicate fields.

The bottom line is that even the best ivtc must provide means for manual override if you want perfection. The human eye is unfortunately the only truly reliable interlacing detector, and the ivtc ought to recognize that and make it easy for the human to help out. Tmpgenc's seems to be designed to help the human make nose prints on the monitor, but the interface is slick and it's really the only thing going for doing it manually. Interlacing that is almost impossible to spot with the eye at 1:1 unless you are very experienced is blatantly obvious to anyone if you do a nearest neighbor resize to double the height (ie double each line).

If you create a log of the decisions made (just like 2 pass encoding) then you have the opportunity to tweak to your heart's content to get it perfect, and then you never have to do it again for that source.

western shinma
19th August 2001, 12:09
This is already pretty great imo. I was getting really tired of having to run almost everything through TMPGEnc, and even with subtitling in Nandub the Avisynth filters are still faster.

I'm not sure how much I can contribute to testing since I don't have a bunch of dvds lying around, but I always seem to notice dropped/interlaced frames (more of a curse than a blessing I'm afraid).

I tested this out with the suggested settings on an episode of Lodoss, and like Craven said, it's not perfect, but it's at least as good as anything else around.

Leuf: are you dealing with movies or anime?

Edit 2: Once again, craven was right on. Setting the threshold to 50 is worlds better than the mess FU came up with on this disc. Almost no jerkiness at all, probably even smoother than keeping it at 30fps.

DDogg
19th August 2001, 12:41
No doubt ArsCraven knows his stuff, but he disappeared as soon as I tried to hog tie him down to code writing, me being the shameless shaighei artist that I am :lol:

Craven, oh Craven, where for are't thou? ;)

Leuf
19th August 2001, 14:01
I'm dealing with analog NTSC broadcast caps. They are mostly 3:2 pulldown with pattern changes at every scene change, with some scenes shot on video and other post production stuff that make it interesting.

The logs gets processed into a scene report, which looks something like:

Scene: 9: Start 905 End 933 | Found: 0 2 0 0 0 | Pattern: 1 Confidence: 35
Scene: 10: Start 933 End 970 | Found: 5 0 0 0 0 | Pattern: 0 Confidence: 67
Scene: 11: Start 970 End 1077 | Found: 0 0 11 0 0 | Pattern: 2 Confidence: 51
Scene: 12: Start 1077 End 1187 | Found: 0 0 22 0 0 | Pattern: 2 Confidence: 100

So everything I need to recreate the complete pattern of this 15000 frame test clip has been distilled from a 1.2 mb log into a 20 kb text file. The nice thing is that because this is 2 pass even though scene 9 only had 2 instances of the pattern recognized you know that a) the right pattern has been chosen for all the frames and b) the pattern changes occured where they were supposed to. And manually editing it is pretty easy, you just have to change the pattern number. There's the potential for user defined pattern numbers, so you anime guys could plug in whatever weirdness you find. I haven't written the scene report-to-log code to regenerate the log, I just use the report as a diagnostic currently - I have a few issues to sort out with extra/missing scene changes and such that need to be addressed first.

The main problem though is that in order to actually convert the log into an avs to perform it, I use separatefields and then 50 billion deleteframe()/duplicateframe() then weave.... can you say overhead? It would choke if you tried that on a full movie. I don't have the knowledge of writing avs plugins to do it directly, so when i get done someone would have to help me out with that if it's going to be of any use to you guys.

western shinma
19th August 2001, 14:39
Hmm, looks interesting. I was going to mention earlier what a mess it would be to do this in Avisynth, but you already covered that. Nonetheless, I don't think I would particularly like finding a new pattern on every scene change. On the other hand, maybe I've just had fewer problems with auto IVTC than you, since we're obviously dealing with different sources.

milkman dan
19th August 2001, 21:55
I've been using the InverseTelecine dll with perfect success in several different animes. I've used it on the Tenchi Muyo OVA DVDs, two discs of Trigun, and a few others that I don't remember offhand.

I've had no success with Lodoss Wars, and that's because someone in the studio there needs to be shot.

Because as far as I can tell, the material is almost completly interlaced...suspiciously like they capped the video masters in interlaced mode, instead of deriving new progressive masters. But in any event, no amount of dickering with the dll produced any sort of progressive output. I just labeled it as a case of bad mastering at the studio, and VerticalReduced it. That didn't look so hot either, but it was alright at full speed.

Trigun...Trigun was different. Some doofus in THAT studio got the fields reversed. Even the tapes are that way...makes them look quite ugly. Anyway, switching the parity of the fields solved that problem, and it IVTC'd seemingly fine with the default settings.

I think it quickest way to improve the binary would be to implement automatic field switching, or at least detect it and print an error on the encoding while the error is present, or log it to a file. In the Tenchi OVA, near the begining of episode 6, the field order reverses, right after the episode title (in Japanese.)

Something else to look out for is that, in my experience, the dll doesn't get along well with the TemporalSmoother plugin in the mpeg2dec dll. Don't use it. The frame buffering I think is what is screwing things up. And resize after the dll does its work.

If anyone else has any questions, I'll try my best to answer them at ayekalover(at)operamail.com

ArsCraven
20th August 2001, 08:33
Hi DDog! Don't hold your breath, I'm a neophyte to writing code for video processing and for win32 (I do most of my work on Linux). Currently work is on hold as I do not yet have a compiler that will even build the .dll :o Sooner or later I shall find an affordable way to get MSVC.

I have 2 directions that I'm attacking the problem from (or will attack the problem from), for anyone else who does have the proper tools.
1) New interlace detection code. For some reason the current code does not properly detect interlacing (a quality it shares with most other IVTC methods). When I was encoding Gasaraki, I noticed that would leave interlaced frames in on scene changes (!!) of all places. My guess is that this occurs because the current algorithm does not take into account chrominance. I will put up a screenshot what convinced me of this anon.
2) Support for new pulldown patterns. (0,1) (0,4) (1,2) (2,3) (3,4). These actually nearly worthless, except on really fucked up material like Lodoss War. In Lodoss War there seem to be places where only _one_field_ from a frame made was encoded, and other places where a field was _tripled_ instead of doubled (eep). Who the fsck mastered that DVD?

I didn't consider changing the field order since I hadn't tried Trigun and I didn't think any DVD mastering studio would be that incompetent. Live and learn.

DDogg
20th August 2001, 08:46
Thanks, man, even if you can't do the coding now just keep discussing your thoughts and ideas, and keep the thread going if appropriate. Somebody will come along and see all the thoughts, ideas and data and feel comfortable jumping in. I've seen it happen many times. I'm not sure the coding is as hard as just understanding this strange stuff. You guys that can bang this stuff manually are the key to helping somebody program a solution. Imagine the best programmer around trying to figure out IVTC from scratch. Hell, he or she would definately beat their dog...repeatedly...several times :)

My best regards and respects to all you crazy animheads and IVTC whackos :)
DD

ArsCraven
20th August 2001, 09:44
Hey Dan, which episode did you reverse the fields on? I was able to IVTC episode 1 fine with the normal field order.

[fiddles with avisynth for second...]

Did you remember to use DoubleWeave before InverseTelecine Dan? I just discovered that if you use ComplementParity before InverseTelecine on that particular show, you can get acceptable progressive frames... at 11.988 fps. If that's what you did, don't feel bad. I just made the same mistake on three episodes of Gasaraki, which I am now going to have to re-encode :(

milkman dan
20th August 2001, 13:41
Erm...It was from the second or third disc, I think. (I was helping out a friend).

Here's what I did. Looking for a quicker way than smart Deinterlacing, I tried out Gabst's Telecide/Decimate combination. The Telecide worked great. But only after I swapped field order ( I looked at the clips in TMPG to help figure out field order, and had to swap there to make the progression work correctly.) Adding the decimate made everything jerky though, so I just gave up on it.

I don't remember if I ComplimentParity'ed after or before I DoubleWeaved, and I can't check the output, as I don't have it anymore. But I'm sure I would have heard some complaint about it if it was 11fps.

Edit:Anyhow, those are good ideas you have already. I think the field swap detection would be a good idea though. Like if the dll sees that no matter what it does, it still passes frequent interlaced frames (I'm sure it already has a post-processing quality check implemented) that it assumes the field order is wrong, and prints an error message.

WizardFL
21st August 2001, 00:22
Forgive my clumsy attempt at some C++ programming (after years of inactivity no less), but I just had to try writing a plug-in after I heard it was possible... Never thought it would go this far!

Anyway, this plug-in was never designed for use with DVDs or really fucked-up material... The idea was to build progressive frames from a VHS source that was all that perfect (but still good). It did what it was supposed to do, but like I said it was clumsy...

I suggest a more brilliant man find a better way of doing this. As for me, I'm still programming on my free time and plan to redo this plug-in right (sometime).

P.S. If you are looking for help with the darn thing, maybe you would be better off emailing the guy who wrote it... ^_^

DDogg
21st August 2001, 01:00
Very nice to see you here, WizardFL!

Actually, your timing is very good as anytime before I don't know if the group would have been focused enough to take your time. Now, as you can see, you would have plenty of testers and community members with an excellent understanding of the, somewhat arcane "need", as well as some potential programming help, again with a good understanding of "the need".

So the question is, how can we assist you? (assuming you have the time to think about it) :) I think I can speak for several by saying, "we are at your service".

Best,

DDogg

WizardFL
21st August 2001, 02:52
Actually, I thought I'd give it a go this week end. My idea was to shift from the current algorith, which checks each frame after doubleweaving to select the best 2 out of 5, to an algorithm which would select the best 4 fields out of 5 thus eliminating the need for doubleweave and parameters.

Anyway, this is still just an idea at the time... But I should have a working prototype this week-end and a better idea about what needs to be done. What I will need from you guys at that point will be ideas about how to improve performance / quality.

I'll keep you posted!

DDogg
21st August 2001, 03:08
Excellent! One thing that might assist you is some sample material of one of the difficult sources. Do you have good bandwidth available to you? If the answer is yes, who in the group could UP some well thought out samples to wizzardFL?

WizardFL
22nd August 2001, 01:08
Of course I have a good bandwidth! I have DSL (who could live without it?? <img src=http://www.ezboard.com/intl/aenglish/images/emoticons/ohwell.gif ALT=":\">

But before you start sending me test material, I'd like to make something that can at least stand up under "normal" circumstances...

DDogg
22nd August 2001, 02:51
k, just let us know when.

Edit: Some info I had was incorrect so I deleted what had followed.

DDogg
24th August 2001, 09:10
pub28.ezboard.com/fdoom9smpegforumfrm8.showMessage?topicID=164.topic (http://pub28.ezboard.com/fdoom9smpegforumfrm8.showMessage?topicID=164.topic)

doom9
24th August 2001, 13:54
I really gotta get into this anime stuff myself even though I don't dig it. I have a Captain Bebop Trailer and a Lain episode in SVCD format (done with inverse 3:2 pulldown in TMPG which conserves all the screwups and looks amazingly good) but that's all atm.

I think the first programmer to come up with a solution that really works on all these buggers deserves a Doom9 software excellency award ;)

DDogg
24th August 2001, 20:46
Funny you mention awards. We should talk about that in another thread sometime. I do think there should be a way for our community to aknowledge the incredible programming efforts of some of the members. What would we do/be without them?

Leuf
25th August 2001, 00:53
The trickiest part for me is trying to autodetect whether it is 3:2 pulldown or true interlaced (in the absence of flags, which broadcast of course lacks). You would think this would be easy, but I've yet to figure out a reliable way to do it. Detecting interlacing is tricky, rather than being able to look at a frame and say yes, this frame is interlaced.. it is more like.. these frames appear to have more characterstics of interlacing relative to some other frames. When you have true interlaced frames, they are all about the same relative to each other. But also when you have little motion any source will all be about the same relative to each other. So, how do you know that the interlaced frames weren't something else? The totals will tend to be higher, but that could equally be the result of a "busier" scene bumping up the totals.

So, any ideas?

Edit:

Okay that isn't going to be as much of an issue as I thought, but I'm still open to ideas on it.

New question: For the interlaced scenes where frames have to be deleted, do you think it's better to delete 1 out 5 frames, or delete 2 fields from separate frames. Tradeoff being smoother play vs ghosting.

WizardFL
26th August 2001, 10:31
Ok, first draft is done... I've sent a copy of my latest work to www.videotools.net (http://www.videotools.net) (hope he posts it!). You can download it, try it, tear it up to shreds and anything else you'd like to do.

Keep in mind, this is a first draft which means it has no optimization and no intelligence... It just applys certain rules with brutal simplicity. It does manage to work most of the time, but it should get much better when I put some intelligence in how it detects the pulldown pattern.

DDogg
26th August 2001, 13:08
Great news. I hope you will also submit it to Doom9 or put it somewhere with a link here so we can get testing it right away.

doom9
26th August 2001, 21:08
don't see it @ edwin's yet. Could you send it over? In a bit I should have my page locally again and Dreamweaver installed so I can start working on the page again.

WizardFL
27th August 2001, 09:19
It's obvious to me now that there are some crutial parts I forgot to code in order for the plug-in to work properly. Without any pattern recognition, it is likely to produce duplicate frames and slightly interlaced frames. Also, the interlacing detection algorithm is quite as acurate as I'd like it to be... Yet.

However, the object of this message is to ask for some specific test material so I can check the efficiency of my theories compared to the old code. What I need is streams of at least 50 frames (but less than 30 sec).

1- A stream with what I call the WEIRD telecine pattern: it contains progressive frames, interlaced frames and frames that apear partly interlaced as well as having even and odd fields mixed

2- A stream that has progressive frames and cut frames instead of interlaced. What I mean is frames which have half the image of one and half the image of the next with some tearing.

3- A stream with an difficult telecine pattern.

I have DSL and will be online every night between 9 and 10 PM (Canada Eastern Time) on ICQ 4105331. Or I'll try to be anyway!

WizardFL
27th August 2001, 09:22
It should read "Also, the interlacing detection algorithm isn't quite as acurate as I'd like it to be... Yet." instead of "Also, the interlacing detection algorithm is quite as acurate as I'd like it to be... Yet."

DDogg
27th August 2001, 09:57
Ok folks, call to action. Please look through your archives and somehow, even if is a complete pain, get what the man asked for, to him. This is a damn good opportunity to help get us an intelligent IVTC plugin that has *real* power. So let's do everything we can to help make it happen.

Thx, DD

jarthel
27th August 2001, 17:00
LoadPlugin("D<img src=http://www.ezboard.com/intl/aenglish/images/emoticons/ohwell.gif ALT=":\"> downloads\windows\utilities\divx\GordianKnot\MPEG2DEC.dll")
LoadPlugin("D<img src=http://www.ezboard.com/intl/aenglish/images/emoticons/ohwell.gif ALT=":\"> downloads\windows\utilities\divx\GordianKnot\InverseTelecine.dll")
mpeg2source("D<img src=http://www.ezboard.com/intl/aenglish/images/emoticons/ohwell.gif ALT=":\"> vision of escaflowne2\escaflowne - episode5.d2v")
crop(8,3,700,477)
DoubleWeave
InverseTelecine
BicubicResize(640,480,0,0.75)

----------from the readme.txt------

USING THE PLUG-IN

Just load the plug-in, open a video stream and use the "InverseTelecine" function (no parameters needed).
------------------

It gives me error when i try to open the .avs in nandub. It's saying that's there a problem in bicubicresize filter. The error message is "Invalid exception" in line where bicubicresize is located.

Any suggestions? Thanks :)

manono
27th August 2001, 17:12
Confirmed, same problem, but my error message referred to the "InverseTelecine" line. There's more detail in the AviSynth forum.

manono
27th August 2001, 17:21
I was wrong-I believe it was referring to the "BicubicResize" line(I counted wrong-duh!).

jarthel
27th August 2001, 19:26
I remove doubleweave and nandub loads it. checking now what doubleweave does.

jarthel
27th August 2001, 19:30
:)

nephilim
27th August 2001, 19:31
As to anime rips, wyself having messed with Lodoss, Escaflowne, DBZ, Fushigi Yugi and some very esoteric stuff I've only come up with one good way to beat interlacing. (Note that the final word with me is smooth motion, not sharp quality or filesize - Those 80GB Firewire drives are great.)
Set up a .avs or VFAPI file as per normal, but do not IVTC. In VDub set 3:2 removal to Adaptive, and also apply the Deinterlace filter set to blend fields. I've seen too many anime titles without any pattern whatsoever to muck around with manual settings, and this seems to catch 99.9% of interlaced frames. Those it does not are fairly still images and are well handled by the deinterlacing. Of course, this wouldn't work well for SVCD.
Before you flame, I know damned well that this is far from an elegant solution. But as far as the amount of work to overall effectiveness, it does well by me.

jarthel
27th August 2001, 20:22
When I used doubleweave with this anime, there are some interlacing problems. Without it, no interlacing problems but fps drop to about 11+.

Also, any suggestion on interlacing problems? thanks

DDogg
27th August 2001, 21:50
This quote from an earlier post from WizzardFL. I think the new one does not need the doubleweave?

Actually, I thought I'd give it a go this week end. My idea was to shift from the current algorith, which checks each frame after doubleweaving to select the best 2 out of 5, to an algorithm which would select the best 4 fields out of 5 thus eliminating the need for doubleweave and parameters.

Later: verified DW is no longer used. Also this is just a test build, (from WizzardFL, "The object is to test how acurate the detection scheme is compared to the old one". We need to get the man some source video as he requested. Who can do this?

WizardFL
27th August 2001, 23:24
Time for some clean up... Do any of you actually read the readme file I put so much effort into?? This version does not use DoubleWeave! The object was to make it simple and to try a new approach, which I did. If you are looking for results, I suggest you stick with the old version since this one is still in its infancy.

For those of you who have been getting wrong FPS stats, thats a problem with avisynth itself... I tried to get some code to work around that, to no avail. However, if you adjust the FPs to match both the lengths of video stream and sound, you'll see that they match around 24 FPS.

IMPORTANT: Do not use crop or any other filter that adds or deletes lines to the frames before the call to InverseTelecine or DeInterlace. Both of them use the line numbers as their reference to seperate even fields from odd fields. If you add or delete an odd number of lines to the frames before they are processed by the plug-in, you just made it think that odd fields are even fields and vice versa!

The same goes for resizing filters... If you use them before the call to the plug-in, you are erasing all the info it needs to get the correct results.

Hope this helps! ^_^

DDogg
27th August 2001, 23:45
This would be correct according to WizzardFL:

Loadplugin("InverseTelecine")
Avisource("D:\capture.avi")
Inversetelecine
#Then crop and resize

So, for us, it becomes:

LoadPlugin("MPEG2DEC.dll")
LoadPlugin("InverseTelecine.DLL")
mpeg2source("yourmovie.d2v")
InverseTelecine
crop(13,4,699,466) #<= whatever your crop numbers are
BicubicResize(640,352,0,0.60) #<= whatever your resize numbers are

Later, I think we should consider moving the new telecine plugin discussion to the development forum so people will understand this is only a "concept test" and is not really ready to be used for doing any encoding work. Continue to use the older plugin until the devel on the newer has progressed some more.

Also, perhaps, discussions on the use of the regular plugin should shift to the AviSynth forum where one has already been started. This thread took on far more life than I had intended with a quick blurb.

dividee
28th August 2001, 02:02
@WizardFL:
The new plugin crash for me with an access violation. I looked at the sources and traced it back to: child->GetFrame(Frame-1,env), which request frame -1 when Frame=0 (for the first frame). If I use Trim before InverseTelecine or change the code to request "Frame+1" then it works.
Maybe I should state I'm using a custom avisynth build. When I use vanilla 1.0b4 it doesn't crash but doesn't perfom his task.

Also you shouldn't change vi in the GetVideoInfo method. Change numframes & FPS in the constructor and there is no need to overload GetVideoInfo. This is probably the cause of your FPS problem.

ErMaC318
28th August 2001, 07:51
I'm kinda new to the forum but if there's one thing I know it's Anime. =)

Lain is not entirely 23.976 FPS. All the scenes where there's a picture of her computer screen and the Copland OS stuff going on is in 29.97. Also most of the scenes in the Wired (like the Phantoma game, and the little Bio on the Knights on the second disc) is in 29.97 I believe, not so sure about the Phantoma but I'm pretty sure on the second.

Cowboy Bebop is also a hybrid - all scenes involving gates/planets/etc are CG and thus in 29.97. You can usually tell these scenes easily by the change in color balance. Also, episode 20 (Pierrot le Fou) was done entirely in computers (never touched film) - thus the change in colorbalance through that entire episode.

Lodoss is of course all film (it was done in '91 after all) and is indeed the most difficult of any Anime source I've ever seen to IVTC.

Other very difficult sources include the first disc of Neon Genesis Evangelion (the rest of the disc are somewhat better, the first was a disaster) which has huge problems with freezes at a scene change and such (it appears their MPEG2 encoder decided that the end of each scene was a still frame or something and encodes it as a 3 frame picture group or some really bizarre shit, I really have no idea).

Other source which is a real bitch to work with - LOST UNIVERSE! That one is a severe hybrid - all CG scenes with the Swordbreaker are in 29.97 and the rest of it is _very_ poorly telecined film. It's a reeeeeeeeal bitch to deal with - I have to do it manually with TMPGenc or there's just no hope.

Also another hybrid (which really isn't very bad, it's merely picking up the switch from film to CG) is Initial D. I have the Region 2 imports of the first season, which is a hybrid of film/CG.

I have a not-so-fast upstream but I can provide some clips from all of the shows I mention if anyone desired it.

DDogg
28th August 2001, 08:17
Just to save anybody having to look back ten posts, this is what he needs. (Note at least 50 frames but less than 30 secs)) :

WizzardFL - However, the object of this message is to ask for some specific test material so I can check the efficiency of my theories compared to the old code. What I need is streams of at least 50 frames (but less than 30 sec).

1- A stream with what I call the WEIRD telecine pattern: it contains progressive frames, interlaced frames and frames that apear partly interlaced as well as having even and odd fields mixed

2- A stream that has progressive frames and cut frames instead of interlaced. What I mean is frames which have half the image of one and half the image of the next with some tearing.

3- A stream with an difficult telecine pattern.

I have DSL and will be online every night between 9 and 10 PM (Canada Eastern Time) on ICQ 4105331. Or I'll try to be anyway!

WizardFL
28th August 2001, 08:30
There is a very simple reason why its Frame-1 and not Frame+1... When a frame is interlaced, the odd field that matches the even field of the current frame is always in the previous frame. I tried it with Frame+1 and got ALL INTERLACED FRAMES. Besides, it never bothered my avisynth as referencing an out of range field always produced either the first frame or the last one. If you are getting errors, try scripting out the first frame ("trim(1,0)").

As for changing vi, thats entirely necessary and correct since I am changing the number of frames that the stream contains. Its simple really... If you remove 2 fields in every group of 5 frames, you lose sync rather quickly unless you adjust the FPS. Correct me if I'm wrong, but reducing the number of frames by 20 percent is accurate after pulldown... After all, thats what my other plug-in did (40 percent actually, but after DoubleWeave)

WizardFL
28th August 2001, 08:51
The problem came from this line:
vi.SetFPS(vi.fps_numerator / 4 / 5, vi.fps_denominator);

Its a typo... Forgot to rebuild the DLL and put the correct source file in the ZIP. That line should read:
vi.SetFPS(vi.fps_numerator * 4 / 5, vi.fps_denominator);

That where the decrease of 20% come (4 / 5 = 80%). Just ignore the bug and correct the fps manually until you download the corrected DLL

RnK Tessai
28th August 2001, 12:35
I have not had the opportunity to play with the new version of the IVTC plugin. I did try to test it with Ranma 1/2 OAV series (box set) eps 5-8. When I did the encode, there was a lot of what some might call "line flicker" I suppose. During scenes when the characters were speaking, the IVTC would not properly keep the frames for the mouth, so you'd see little lines in the mouth while its moving. It's very annoying to say the least. I believe I still have a copy of my avs file when I did it. I used Avisynth->TMPG and Avisynth->CCE, both with the same results. I still have the files I produced with TMPG, so if there is a need for screenshots, I should be able to provide them. I was doing a simple VCD/MPEG1 stream, but failed miserably. I'm hoping this new version will run faster and detect the interlaced frames a little better. I'll have some time to test it in the coming weeks with Ranma 1/2 and Lain (eps 10-13).

Tessai (can be found as Tessai on #pcdvd, just in case Doom9 was wondering ^_~)

dividee
28th August 2001, 16:26
I know that changing vi is necessary, but don't do it in GetVideoInfo, it may be called multiple time by the filter above it in the chain. In fact I ended up with a 19.1808 fps video which is 29,97*4/5*4/5 (and number of frames reduced by the same factor), probably because GetVideoInfo was called 2 times for a reason I don't know.
Put these 2 lines
&nbsp &nbsp &nbsp &nbsp vi.num_frames = vi.num_frames * 4 / 5;
&nbsp &nbsp &nbsp &nbsp vi.SetFPS(vi.fps_numerator * 4 / 5, vi.fps_denominator);
in InverseTelecine::InverseTelecine instead and you can delete GetVideoInfo since the default behavior is to return vi.

About requesting out of range frames, I did the same thing when porting TemporalSmoother to avisynth but had strange problems sometimes (don't remember which) and they were solved when I checked bounds.

ErMaC318
28th August 2001, 18:46
Dividee:

Unfortunately I posted what I have because I'm unsure as to which of any of those things qualify as what he needs - I guess I'm not really understanding the criteria perfectly...

#3 is simple - lodoss OVA.

As for #1 and #2 I'm lost as to what qualifies.

WizardFL
28th August 2001, 22:44
I got some test material of lain (thanks to Inwards for that one), which is supposed to be rather bad pattern wise. I was aiming at making a versatile plug-in to handle many types of sources, but I may have to concentrate on DVD for you guys.

As for the other types of streams, they usually appear on VHS (not on DVD), so just drop that for now. Don't expect too much from the DLL... It was just a test.

Once I know I have a reliable DeInterlacing algorithm, I'll concentrate on the pattern detection part since 50% of the pulldown is deinterlacing the frame.

NOTE: When I say deinterlacing, I don't mean blending lines to get a good looking frame... I mean getting the correct pair of fields from the adjacent frames.

DDogg
28th August 2001, 22:54
Doom9, WizzardFL requests the devel part of this thread be moved to a new thread in the development forum so the test stuff does not get all confusing for people trying to do production. Can you do that?

WizardFL
29th August 2001, 11:01
Ok, here's how it stands: I have enough source material for testing and figuring out how to code the plug-in (special thanks to Inwards and dividee :) ) so I don't need anything new in that department for the time being.

This is how I'm going to divide my work load:
1- I'll start by making a deinterlacing algorithm with a minimum of 99.99% accuracy for reconstructing interlaced frames. Please note that this isn't going to work by blending, but by combining compatible field pairs.

2- This is the hard thinking part... I'll try to come up with an adaptive pulldown algorithm that can make sense out of "crap" (or at least work well even with bad Telecine patterns).

3- The actual coding of step 2 (yes, thinking and coding are 2 different things!).

4- Start testing the DLL with the source material that I have.

5- Once I get something reliable with normal Telecine patterns and not too bad with special cases, I'll upload an Alpha version for testing by you guys.

Of course, the progress of this project (on my part anyway) depends and the free time I have after work... Hopefully, I'll get to work on it at least every week.

doom9
29th August 2001, 13:39
wow.. somebody is really serious about that doom9 award ;)

ArsCraven
29th August 2001, 23:36
Have you taken a look at the automatic 3:2 pulldown code from DScaler (http://sourceforge.net/projects/deinterlace/)? I gave it whirl by running the output from my Sigma Designs card through my tv-cap card. It was able to do reconstruct frames even on Lodoss War. Though it sometimes falls back on a video deinterlace method.

DDogg
6th September 2001, 23:42
Just an update to let you all know WizzardFL is still working on this in his off time.

WizardFL
7th September 2001, 23:18
In all my programming/thinking/tweaking IVTC I've come up against a really anoying lack of AVI... Variable framerate! In some of the test material I've received, both 29.97 interlaced and 24 telecined streams are present which causes a problem with AVI: do you deinterlace and cause extra frames to be encoded resulting in a larger file or do you attempt to IVTC and cut off some frames from the 29.97 fps material causing jerky motion?

Wouldn't it be simpler to assign a duration in milliseconds for each frame instead of setting fps for the entire stream (ex. each frame in a 29.97 fps stream lasts for 33.3667 ms)? Think about it... no more sync problems or errors trying to IVTC hybrid material. Are we so insane that we must try to save the space occupied by such an information, which is the equivalent of a pixel?

western shinma
8th September 2001, 12:01
I hate this limitation as well, mainly because I find telecined material run through a deinterlacer a bit jerky. Not as jerky as dropping a frame in 30 fps sequences of course, but then again only a small number of scenes are 30 fps in most hybrids.

But what can we do? TMPGEnc has an option to repeat a frame after IVTC so you still get 30 fps, but that repeated frame is pretty obvious too.

fu2k
8th September 2001, 16:54
Have you considered trying to make an AVI with 120 (or 119.88) frames/second? For 24 (23.976) fps sections you leave 4 out of 5 frames empty (skipped frames), and for 30 (29.97) fps sections you leave 3 out of 4 frames empty.

I haven't tried this myself so it might not work, but it could be a solution to your mixed fps problem.

WizardFL
8th September 2001, 20:47
That kind of manipulation might make some players go nuts... Besides, what we really need is to switch to a format which does permit variable fps but still has the advantages of AVI. Nice dream, unfortunatly I only have the tools to work with AVI.

On to the work update. I did some programming yersterday trying to deinterlace the test material I have (lain and sakura diaries). Here are the results: lain is really, really fucked up! I didn't understand why none of my efforts could reconstruct the original frames until I took a closer look (way closer) at the interlacing pattern. Lain does not interlace fields, it interlaces some lines and mixes other which makes it appear interlaced while making it impossible to reconstruct to original frames. If you want to see exactly what I'm talking about, try resizing a frame to 5 times its size and look at the pixels where a tearing pattern appear.

As for the sakura diaries material, it appeared to be correctly interlaced so reconstructing progressive frames whould be possible.

I now have decided to drop the new detection code and go back to the old one and adapt it. Reason: the test was never as accurate as the previous version and no adaptation made any real difference. However, I beleive that I can make my old detection code better by adding a little more intelligence into it.

I'll keep you posted!

western shinma
9th September 2001, 02:40
Cool, the old code seemed pretty nice already.

I didn't think Lain was a good choice either. From what I've heard elsewhere, they did some parts in 60 frames per second, even though they could obviously only display half of each frame. So as you noticed, it's impossible to reconstruct progressive frames. I guess the best choice in that case would be to encode at 60 fps and interpolate the missing fields, but that isn't particularly practical.

That sounds pretty cool fu2k.

WizardFL
10th September 2001, 03:17
Using my own algorithms for analyzing frame tearing, I've successfully deinterlaced the Sakura diaries material as well as my own less than perfect VHS material. However, still no luck with Lain.

Now I'm gonna try to add a simple "no field repeat" to create the InverseTelecine function. What this means basically is that the plug-in wouldn't be able to use the same field twice to reconstruct the stream, thus eliminating extra frames.

More news on this next week end.

DDogg
13th September 2001, 06:20
Looking forward to an update. Hope things go well and you do not snatch all your hair out. Anyway, I remember you said you like puzzles, didn't you? :)

guillep2k
14th September 2001, 20:58
Guys, I'm a total newbie about mpeg encoding, but I was doing some thinking... Could it be possible to IVTC only some parts of the movie, those parts where IVTC algorithm is sure to work? I mean, we could use the TFF and RFF flags in those parts of the clip that could safely be IVTCed, saving us some fps, and we could omit them and leave the movie true 29.97 fps in those segments where IVTC was poor or unreliable. Of course this should be performed at MPEG2 encoding time, because I believe TFF/RFF flagging is an MPEG2 feature. I'm I talking nonsense?

Guille

WizardFL
14th September 2001, 23:22
I've heard this idea before and here is why I didn't use it... IVTCing only the parts where it works while leaving it at 29.97 fps would be the same as deinterlacing the stream. While not producing extra frames, this would still produce jerky motion. Remeber, fps in AVI is static and trying to work around it results in loss of audio sync and video quality.

Right now I'm working on the beta IVTC (with a working version this week-end I hope) so it's still rather basic (no optimization, no advanced functions). However, I plan to later add a deinterlacer that will mix odd and even lines on frames that can't be IVTCed or DeInterlaced using the other methods. This should make the video stream appear less interlaced and cut down on the file size.

P.S. Don't expect this until 2-3 weeks minimum

guillep2k
15th September 2001, 04:38
Yeah, but... if the output file would be MPEG2 instead of an AVI... would this be a good method? I'm thinking about passing a DVD to SVCD or to miniDVD, where reencoding is important (to reduce file size), but MPEG2 still is the output format.

May be bbMPEG could be altered to do something like this?

Regards,

Guille

WizardFL
18th September 2001, 21:55
I'm not very familiar with MPEG-2 so I'm not sure what to tell you... The way I understand it is that MPEG-2 has a flag that indicates if the video stream is progressive or interlaced. This lets DVD players know if they have to interlace the video themselves or display as it is. Trying to work with this will not help producing hybrid 24/29.97 progressive frames of course.

You have to understand that, unless a format is designed to handle variable fps, trying to produce hybrid material will always result in a loss of quality (either the image or motion).

If you plan to keep the video in MPEG-2 and view it with a DVD player, I suggest you leave it interlaced. MPEG-2 is designed to encode fields instead of frame which won't affect the bitrate even if the frames are interlaced.

WizardFL
24th September 2001, 04:21
This week-end I suceeded in putting some time on the IVTC project. Progress? Yes and no... I've programmed another IVTC algorithm based on my previous code for frame analysis and the results are mixed at best. I need to take a closer look at my source material ;)

Looks like I'll have to put some more time on this!

Schultz
24th September 2001, 12:07
thanks for the update WizardFL. Really looking forward to when you get the new IVTC Plugin done. Again keep up the great work..

WizardFL
29th September 2001, 12:25
Finally figured out why I couldn't IVTC the Sakura Diaries material... After getting bored playing Diablo II, I decided to play around with the clip just using avisynth without any programming. Turns out the field order was reversed and to IVTC it you had to use SeperateField, SelectEvery(2,1,0) and Weave before calling the IVTC filter. Guess my brain has been asleep for a few weeks! ;)

Now if I could only get some progress on that damn Lain (sigh)!

milkman dan
1st October 2001, 19:25
Couldn't you have just done ComplementParity? That reverses field order. Or am I just missing something?

WizardFL
2nd October 2001, 00:42
Sorry but I'm no expert with avisynth and I'm too lazy for reading the documentation... I usually stick with what I know, but if you say complementparity works then use it! :)

milkman dan
2nd October 2001, 16:39
Would it be possible for IVTC to detect that "no matter what I do, this isn't working, so I'm going to try reversing the field order?"

That would be pretty damn cool, especially since some of the material I've done suddenly decides that it's going to reverse right in the middle, thus making it a pain to encode.

guillep2k
2nd October 2001, 18:49
Yeah, milkman dan, I think THAT would be the real thing!

Guille

WizardFL
2nd October 2001, 23:05
I've received quite a few requests about that... Ok, I'll give it a shot! After all it shouldn't be too difficult (or should it?). I've had a few ideas about how to do that anyway.

However, I'm going to need more test material to see that this works. So dig in your archive guys and give me something f*cked up! :)

Schultz
2nd October 2001, 23:46
Well i am not sure how to Tell if stuff is in reverse order or not.. But if you could point me to somewhere that will teach me how to Figure this out i got Alot of anime that i can look at and see if i can find some really fucked up material.

milkman dan
3rd October 2001, 02:29
Short Answer: If you have the Tenchi Muyo OAVs on DVD, then rip episode 6 (vob vts_01_06.vob), and load it in avisynth, and then in virtualdub. Scrub to the point where the episode title appears, and then cuts to a scene of Sasami running. At that cut, the field order reverses, and remains like that for the entire episode. (However, episode 7 is normal, as is every other one on that disc.)

If you have the IVTC plugin loaded, the start of the episode will IVTC fine, but will look like it stops working at the point above. But using Trim, and ComplementParity, you can see that reversing the field order fixes the problem.

WizardFL
4th October 2001, 21:13
Here is how you can see if a stream has been Telecined: in most cases where fps is converted from 24 to 29.97 using standard algorithms, you should be able to see 2 progressive and 3 interlaced frames in each group of 5 (or is it the other way around? I can't remember...). If the field order is reverse, the stream will probably look like that but the old IVTC plug-in won't be able to convert it.

western shinma
5th October 2001, 13:04
Yeah, it's the other way around. No wonder it isn't working properly. ;)

Blight
9th October 2001, 20:36
Wizard, how about TV captured content?

A lot of the newer TV shows are shot on film (buffy/angel/enterprise, etc...), the thing is, due to noise (digital or analog) or field order switches, it seems that IVTC isn't working up to par.

Any ideas?

gldblade
14th October 2001, 04:24
Wow, this thread is long. I don't think I can finish reading it anytime soon. So I'll get to the point: will something come out of this? I sure hope so. It looks promising.

I think I read somewhere that WizardFL is doing a plugin. Any time on release?

trbarry
14th October 2001, 15:18
Have you taken a look at the automatic 3:2 pulldown code from DScaler? I gave it whirl by running the output from my Sigma Designs card through my tv-cap card. It was able to do reconstruct frames even on Lodoss War. Though it sometimes falls back on a video deinterlace method.

Hi -

I sometimes work on DScaler and I recently created an experimental port of my DScaler Greedy (High Motion) deinterlace plug-in to life as an Avisynth filter.

(Warning, much asm, For SSE supporting machines only, will bomb on others!)

This doesn't have the full DScaler IVTC code in it but it does have optional pulldown matching. That is, it will remove the weave artifacts but not drop any frames. (How do you drop frames in an Avisynth filter?)

See www.trbarry.com/Readme_GreedyHMA.txt and www.trbarry.com/GreedyHMA.zip for more details of this still-experimental filter.

It can give some decent results with anime and some material with messed up pulldown sequences caused by commercials, edits, etc. I'm fairly happy with the deinterlace part of it but the pulldown/IVTC processing could still use improvement.

I need feedback here as I am most definitely not an Avisynth guru.

- Tom

Blight
16th October 2001, 15:20
This thing doesn't seem to be actually doing IVTC, it seems more of a smart deinterlace type filter.

You can use telecide to do a pretty good field matching, but it can't drop the duplicate frame either, which is the actual problem here.

And if you use a source that was 24fps film, and convert it to 30fps duplicated frames, the image will be very jerky due to the duplicate frames.

trbarry
16th October 2001, 16:37
This thing doesn't seem to be actually doing IVTC, it seems more of a smart deinterlace type filter.

Hi Blight -

Yes, but if it looks like good pulldown it will match up entire fields instead of doing adaptive by-pixel deinterlace. Either way, it will first match the current field with either the prev or next field to make a frame with the lowest comb factor.

If it looks sufficiently like a good film based pulldown sequence at that point it will just leave it alone, else it will process pixels. But the recognition here still needs improvement.

In the DScaler version you have access to additional parms, 'Good Pulldown Level' & 'Bad pulldown level' sliders to further tinker with how much you really want to consider it pulldown. But I didn't give access to them here yet, because I still might have to change them. And I'm not sure how yet.

At best it is still only pulldown matching, not pulldown removal. But I really do want to figure out how to drop the appropriate frames under Avisynth. I just sort of haven't gotten to it but I'm sure code like SelectEvery() has to be doing it.

I keep hoping someone will pipe in "Just set the dropped flag" or something like that.

- Tom

Larva
16th October 2001, 21:09
Originally posted by Blight

This thing doesn't seem to be actually doing IVTC, it seems more of a smart deinterlace type filter.

You can use telecide to do a pretty good field matching, but it can't drop the duplicate frame either, which is the actual problem here.

And if you use a source that was 24fps film, and convert it to 30fps duplicated frames, the image will be very jerky due to the duplicate frames.

This is better than Smart Deinterlace for telecined material, since it at least has some pulldown matching. Duplicated frames are close to exact duplicates, which is not the case with Smart Deinterlace.

Sure, deleting duplicate frames is better when the source is actually 24 fps. However, many of the sources I deal with are mostly 24 fps, but with a few scenes thrown in at 30. It's annoying, because while IVTC would make most of the video look a bit smoother, those few 30 fps scenes would be really jerky. The only real solution to this problem is TMPGEnc's inverse 3:2 pulldown, which does selective IVTC. Of course that only works with MPEG2...

Blight
17th October 2001, 18:18
The problem is, if you match the fields without cutting the duplicated frames, the image stutters badly. Just run a video through telecide to see what happens.

trbarry
17th October 2001, 19:32
Yep, sad but true. But I think I've got a handle on that now and should have code soon that drops more or less the right ones. But it will drop 1 in 5 for deinterlaced video also, at least at first.

Larva
17th October 2001, 22:52
Blight, I think we are in agreement on that, and for sources that are telecined completely without flags, I haven't been able to improve on TMPG's IVTC results. Obviously this plugin needs frame dropping to be effective for IVTC, but it would be nice if there was still the option not to drop frames. The reason for this, like I said in my last post, is hybrid 24/30fps sources. I find the repeated frames pretty annoying, but it's better than dropping non-repeated frames in the 30fps scenes. Fortunately, this situation only seems to come up on certain anime videos.

Blight
19th October 2001, 12:18
If you have content that is mixed, it's usually best to just do an area-based blend, at least with that, your movement will be smoothed.

I don't really see a point in writing an avisynth filters for standard deinterlacing as a VirtualDub filter would be more suited.

AVISynth's benefit over VDub is that it allows you to drop frames.

TMPEG's system is indeed pretty good, though not perfect and not exactly easy. I even wrote a tutorial on how to use it, you can read it here (http://www.inmatrix.com/articles/ivtc.shtml).

By some of the specs, it may be possible that trbarry's deinterlace code is better than the smart deinterlacers available in VirtualDub, so it may be good to have that as a VDub filter, but without the field matching, as that will make the image stutter.

western shinma
19th October 2001, 12:40
I used to always use Smart Deinterlace's blending option for hybrids, although I recently decided I preferred stuttering to having several blurred frames every second. I suppose this change of heart could be due to my recent interest in SVCDs, which automatically repeat frames for 24 fps video during playback. Another advantage is that encoding repeated frames takes less space than blended ones, which leaves more room for the non-repeated ones.

On the telecined parts, note that the quality is better than using smart deinterlace with interpolation as well, since it isn't simply discarding a field where needed. And why exactly would a VirtualDub version be better? I find the ability to set up the avs and use it with many different encoding programs rather compelling. And processing in avisynth for dvd rips was still faster last time I checked. According to trbarry, a version with frame dropping should be out soon btw.

trbarry
19th October 2001, 16:58
GreedyHMA field matching is already optional by the AutoPulldown parm. When 0 it just does pure deinterlace. Hopefully, field dropping should also be optional by this weekend.

But Greedy is currently limited to YUV (YUY2) data so there might be a problem as a VirtualDub filter.

Wizard_FL
20th October 2001, 04:36
I emailed the new version of IVTC to DDogg tonight, so it should be available soon. Version 2 now detects reversed field order, although I would have liked to test it more... Also, I eliminated the need for doubleweaving in the script and added a DeInterlace function that matches fields in adjacent frames instead of blending them.

All this needs to be tested of course, any volunteers? :rolleyes:

Schultz
20th October 2001, 06:48
hehe yea i would like to volenteer. I am currently in the process of doing a bunch of anime episodes and would be willing to give it a shot/test it.

wmansir
20th October 2001, 07:21
I would like to give it a try. I've been using the original plugin to IVTC buffy eps with good success. I've done 3 so far and 2 have had field swapping, which is very annoying.

Here is an example of the method I have been using to deal with it. In this segment the field order starts out reversed, switches at frame 6000, switches back at frame 7000, and final switches again at frame 8000.
-----------------
Loadplugin("C:\progs\inversetelecine.dll")

OpenDMLSource("c:\caps\part1.avi").trim(0,6000).complementparity + OpenDMLSource("c:\caps\part1.avi").trim(6000,7000) + OpenDMLSource("c:\caps\part1.avi").trim(7000,8000).complementparity +OpenDMLSource("c:\caps\part1.avi").trim(8000,12000)

Doubleweave.inversetelecine(60,15,10)
-----------------

It works well, but automatic detection would be nice.

Unfortunatly, I don't have anything to try it on right now. But I cap my next episode sunday night.

wmansir@hotmail.com

trbarry
21st October 2001, 16:22
Yes, definately auto detection would be nice.

This changing of the field order is both very interesting and annoying. Can anyone explain or post a link why it occurs?

For instance, is it maybe because some capture card drivers manage to drop fields instead of frames when they get stressed? Does it occur mostly on caps or also on DVD's?

And is there any filter or utility that can just scan a file and report on changes in field order or top first conditions?

I hope I'm not drifting OT here but WizardFL's efforts in this sound very interesting, though I haven't tried it yet.

- Tom

DDogg
21st October 2001, 17:48
Doom9 has the code and I would expect it to be up soon

Edit: try this link:

http://rilanparty.com/vbb/attachment.php?s=&attachmentid=21

Wizard_FL
21st October 2001, 21:38
Here is my problem: Having nothing to do today, I constructed another plug-in that essentially does the same thing as BOB deinterlacing but matches fields together instead of constructing complete frames from only one field. In short, it takes the even field of frame one, scans the adjacent frame's odd field and combine the best match of fields to make a progressive frame and then repeats this process but with the odd field. The result is one really smooth progressive video stream with twice the framerate of the original.

Here is my question: is there a way to tell avisynth that a frame has been dropped and, if so, would virtualdub assign a null value to it or use another frame and encode it?

I ask this because if I used the plug-in I made and flagged the frames which don't seem to change as dropped, the resulting stream would appeared to be IVTCd but have a fps of 60 or so and the size of an IVTCd stream. Also, it would work on interleaved streams just as well as on telecined streams.

Any ideas?

trbarry
21st October 2001, 23:27
Here is my question: is there a way to tell avisynth that a frame has been dropped and, if so, would virtualdub assign a null value to it or use another frame and encode it?

I ask this because if I used the plug-in I made and flagged the frames which don't seem to change as dropped, the resulting stream would appeared to be IVTCd but have a fps of 60 or so and the size of an IVTCd stream. Also, it would work on interleaved streams just as well as on telecined streams.

Yikes! You don't know that? I thought it was your ideas I was stealing to do this in my new filter. ;)

While it doesn't look like you can flag a frame as dropped, you can always choose to process 2 input frames for a single output frame, giving the same impression, as long as you can decide at the beginning what the frame rate is, how many there will be, and keep track of the darn things.

At least I sure hope so because that was the idea I took from IVTC and used in GreedyHMA. Yes?

- Tom

Wizard_FL
22nd October 2001, 02:02
As far as I can tell, the static framerate is THE major problem with AVI. My idea was to work around that by identifying similar frames as dropped, thereby preventing the editing program from encoding them and having an impact on the file size. The advantage of this approach was that it makes it possible to do as if the framerate was variable even if it isn't.

trbarry
22nd October 2001, 04:16
I don't know how to do that. Does AVI even have a clock besides the frame counter? And I was also looking for some 'dropped' flag before I coded it the IVTC way. I couldn't find one and was told there wasn't any.

But if you just want to make dups disappear for file size purposes, maybe it would help to make them exactly the same as what they supposedly duplicate. Then clever Divx4 might (or not) use repeat flags. But I don't really know about this one, just guessing. At the least it seems it would compress better.

- Tom

Wizard_FL
22nd October 2001, 23:13
Yes!! After a short test of 2 AVI files containing ALL the same frame, I can truly say that it can work.

Stream 1: 10 frames Size: 106 kb
Stream 2: 100 frames Size: 108 kb

As you can see, Mpeg-4 (or DIVX) really does the work by processing duplicate frames without affecting bitrate. Thanks to this little work around, those of you that use DIVX can forget entirely about IVTC and just produce streams with 60 fps that are just as smooth and barely bigger. At last, no more hybrid nightmares!

western shinma
23rd October 2001, 00:39
How well does that work, since 24 doesn't divide evenly into 60? Wouldn't 120 be better?

Edit: Still looking forward to downloading this...

fu2k
23rd October 2001, 00:59
Whoa! Deja vu.

western shinma
23rd October 2001, 01:06
Hmm, I didn't bother mentioning that you were the one who brought it up, since we're still in the same thread.

trbarry
23rd October 2001, 01:16
As you can see, Mpeg-4 (or DIVX) really does the work by processing duplicate frames without affecting bitrate. Thanks to this little work around, those of you that use DIVX can forget entirely about IVTC and just produce streams with 60 fps that are just as smooth and barely bigger. At last, no more hybrid nightmares!

Wizard -

I think we have to be careful here. You could extend this logic and happily generate a no-judder 120 fps that was divisible by 24 and 60. But if the players were not clever enough they could die trying to make and pass copies of frames to the video card or to try flipping the overlay buffer 120 times / second.

I have no idea what they really do. Maybe you'd get lucky.

But now if you also made your own Playa ... ;)

- Tom

western shinma
23rd October 2001, 08:27
trbarry, you were right on. I used your plugin on a hybrid clip set to auto pulldown (no decimation), then changed the frame rate to 119.88. On my 1GHz Athlon (in WMP6.4), it works fine with no post processing; the motion is very smooth in both 24 and 30fps scenes. If I use post processing however the video lags way behind. Oh, and the filesize was about 15% larger than just leaving it at 29.97 (DivX4 93% in both cases).

fu2k
23rd October 2001, 09:14
If the "extra" frames are duplicates of the previous frame, then as trbarry suggested, this might still take a bit of CPU power for frame copying/flipping/etc.

You may have better luck if you can make these "extra" frames "dropped frames" instead. However, I don't know if you will be able to do that without a special encoding tool.

Wizard_FL
23rd October 2001, 14:01
Why did I suggest 60 instead of 120? Because I wouldn't know how to convert to 120 fps a video stream containing 24 fps or a hybrid without some kind of IVTC type algorithm. 60 is much easier to produce because that is the number of fields in a NTSC formated stream. Of course, converting into 60 fps still means that some frames* are displayed 1/60 of a second longer than the others, but the human eye can't see it.

Remember, scientist say that the human eye can see 10-15 images per second which is why NTSC is 29.97 (about the double to make sure it's perceived as one stream instead of a series of images). However, from experience I can say that the trained eye can perceive 30 images per second (yes, I know all you nuts out there can see missing frames because I can too :) ). Despite my sharp eyes, I can't see any jerky motion in a 60 fps stream any more than in a 24 fps stream.

Any way, wait till I complete this and try it out for yourselves. I think you'll be pleasently surprised. ;)

* In a telecined stream there is 4 different frames in each group of 5. Doubleweave this stream and you obtain 4 in 10. 2 out of those 4 are displayed longer than the other 2 which means that in a 60 fps stream there are 2 extra frames in each group of 10.

Antti
23rd October 2001, 14:19
10-15 fps is _very_ jerky. Actually, TV broadcast is 50/60 fps considering motion, and very-high-motion scenes still may look unsatisfying. That's why many super movie formats use 70 fps.

DDogg
23rd October 2001, 15:01
I'll try to put a download link here until Doom9 gets back on his feet. Wizard, this is the last one you sent me. I am assuming it is the latest?

http://rilanparty.com/vbb/attachment.php?s=&attachmentid=21

Blight
23rd October 2001, 16:31
60fps video isn't really that good, you're seriously overloading the BUS with all the data, playing an IVTC 640x480 content can be done on a 600mhz cpu with post processing and maybe even 450mhz without post processing. You can pretty much forget it with 60fps, not to mention 120fps.

I think what is needed is a proper IVTC filter first, a lot of the new TV content is IVTC these days. And to archive this content at a good quality you need IVTC working properly.

This 60fps thing may work well for hybrid material, but this isn't as common as TV video.

Milkman Dan
24th October 2001, 09:19
Does anyone else get an access violation from Avisynth when trying to use this plugin?

I get, in the Red avisynth text in Media player and virtualdub:
"Avisynth: caught an access violation at 0x00dc4544, attempting to write to 0x04076000"

Win2k sp2, avisynth 1.04b.
?

Edit: Forgot to mention this is the version 2 of the plugin.

Milkman Dan
24th October 2001, 09:25
I found the problem. I moved my crop statement from before the inversetelecine statement to afterwards. Bam. Fixed the problem, at least in VirtualDub. Media player still crashes if I try to stop or seek in the stream.

But at least now it encodes stuff.

Wizard_FL
24th October 2001, 13:50
Looks like some ppl have been having some problems with the IVTC plug-in, so here are a few things you should do or not do:

1- DO NOT Crop, AddBorders or include any type of function before IVTC except TRIM or converting to YUV, because any type of change to the stream will confuse the plug-in.

2- DO convert the stream to YUV before using InverseTelecine. RGB might work, but you could also get some nasty results (havent tried it).

3- DO NOT use TemporalSoften at ANY point because the IVTC plug-in EXPECTS to receive frame 2 after frame 1 (temporal soften scans several frames for each one it returns).

4- If you use SpatialSoften (like I always do), put it after IVTC otherwise it might get really slow!

Thats all I can think of right now.

Demi9OD
24th October 2001, 19:44
This is my .avs,

LoadPlugin("D:\DVD\gnot 18.1\mpeg2dec.dll")
LoadPlugin("D:\DVD\gnot 18.1\InverseTelecine.dll")
mpeg2source("F:\DVD\yuv.d2v")
InverseTelecine(40,10,15)

This is on a YUV .d2v but I tried adding ConvertToYUY2 and it had no effect. I am getting the same access violation mentioned above. Any ideas?

Milkman Dan
25th October 2001, 00:45
Yeah. I get occasional access violations also. I see that alot of work went into the plugin, but I don't think it's quite ready for prime-time yet.

It also seems that even after complementParity is used on material, the plugin still passes occasional interlaced frames. I've tried messing with the parameters, but honestly, I don't understand their purpose very much, because I can never tell a difference when I use them. But I guess that's my fault.

Anyway, good work. I know you can iron out the bugs in this thing.

Wizard_FL
25th October 2001, 04:15
Ok, here is the current status:
The pitch/rowsize bug has been corrected which means that if you want to use crop BEFORE InverseTelecine you can. However, if you do use crop, I suggest that you crop an even number of line from the top of the frame otherwise you are altering the even/odd field order (I'm not sure what impact that may have on the plug-in).

Also, knowing that the error was a writing access violation does make me think that it may come from the pitch/rowsize bug (they are both in the same spot in the code). Unfortunatly, I'm no pro in reading memory addresses so I can't make a better analysis of your bug report. Come on ppl you gotta be a little more precice when reporting bugs (ex: What plug-ins you were using? Did it crash at the first frame, last frame, somewhere in the middle, after a trim, etc?).

Are most of you using RGB sources? If so, I may include support for it so you don't have to convert everytime...

Wizard_FL
25th October 2001, 04:25
I know some of you have been tinkering with the parameters with little results. Here is the reason why: DVDs are just about the best quality sources you may find in video streams and the parameters are designed to give you some freedom for bad sources (like VHS). Any values from 30 to 60 / 5 to 20 / 10 to 100 will return just about the same thing for DVD but may make a difference for lesser sources.

parameter 1:
The higher the value the more pixels have to appear different before they are considered so.

parameter 2:
The lower the value the more pixels have to appear similar before they are considered so.

parameter 3:
The higher the value the more a frame has to appear messed-up before the IVTC pattern is recalculated. (15 is pretty low as a threshold but it permits the plug-in to let most accurate frames pass and very few interlaced, even barely so, frames to get through)

Milkman Dan
25th October 2001, 06:21
Thanks for the clairifacation on the parameters, esp the last one. Here I was thinking that a lower number told the dll to re-eval the pulldown order. Heh.

manono
25th October 2001, 13:17
Hi Wiz-I have 3 questions for you (and a thanks for the program).
1. It's doing a good lob with default parameters of performing the IVTC and deinterlacing, but I find little bits of interlacing slipping through (DVD-anime-like around people's mouths when they're speaking). How would you adjust the parameters to take care of that?
2. Failing that,is it true that it doesn't allow any separate deinterlacing to take place (use of the Smart Deinterlacer, or GreedyHMA)?
3. Where can we get the revised version (allowing IVTC after cropping)?
Thanks

Wizard_FL
25th October 2001, 13:52
Question: Why is small amounts of interlacing getting by the plug-in?
Answer: Either the interlacing artifacts are not spread across enough lines (has to be spread across 4 vertical lines and 2 horizontal pixels) or the parameters are not set rights. Try a lower value for the first parameter (25 to 40), a higher value for the second parameter (10 to 20) and/or a lower value for the third parameter (1 to 15). Keep in mind that these values are suggested and do not represent limits (the limits are 1-255 / 1-255 / 0+). The first 2 changes will enable the plug-in to detect more interlacing (with a higher error rate tho) and the third change will let less interlaced frames get through. If none of these changes have any effect, then the stream has a non-standard telecined group of frames in it.

Question: Can other DeInterlacers be used with it?
Answer: The plug-in will still work regardless of what deinterlacer you use, but it will work best when it is asked to return frames in sequence. Meaning that filters that scan multiple frames to produce one may cause a problem. The problem is that the IVTC plug-in may find itself recalculating the IVTC pattern for each frame which may result in movement artifacts (2 frames being the same when they shouldn't), but probably not. In fact, in a standard DVD telecined stream it shouldn't cause any problem, just extra processing time.

However, I will include deinterlacing on frames which exceed the Threshold parameter after IVTC recalculation. In english: if the parameters of the plug-in are set right, even non-standard telecined streams should not display any interlaced frames.

Question: Where is the revised version?
Answer: I submitted it to Doom9 by email last night, so look for it soon (I just don't know when...).

manono
25th October 2001, 22:35
Thanks for the reply. I appreciate it.

Demi9OD
26th October 2001, 03:40
Mine crashes when loading first frame in the movie. See the above .avs code.

Edit: Well kiss ma grits. I loaded a frame randomly in the movie and it started working, must be some bug with the first few frames that are actually progressive (the black screen at the start).

Catmando
26th October 2001, 04:33
Thanks for the info. I have the same problem. If I start viewing at frame 2 all works great. If I even look at frame 1 I have to reload the file and start at frame 2 again.

_TAG_
26th October 2001, 21:28
new IVTC algorithm (http://rilanparty.com/vbb/showthread.php?s=&threadid=8025)

.. and i swear i won't cross post it anymore...
i reached this thread too late to unpost it...
give it a try, it's a new algorithm for IVTC which uses patterns from TMPGEnc and is way fast.

[NOTE: someone please compile it and make it work... it's more or less right, but may need some polish :) ]

Wizard_FL
26th October 2001, 22:45
The point of programming IVTC was NOT to have to do it manually... Believe me, after 200 pattern change in a 30 minute stream you get real tired of writing it down (it happened to me). I use to do it that way but I found a better method: start the plug-in I programmed on my 2nd computer and get the results after a good nights sleep!

Wizard_FL
26th October 2001, 23:55
The mpeg2dec.dll + InverseTelecine.dll has been tracked down, dragged in an alley and shot in the head along with the programmer!

Look for the fix in the next version...

Wizard_FL
29th October 2001, 01:20
I have compiled a new version of IVTC (sent to Doom9 tonight) with a few fixes (mainly DeInterlace and some analysis algorithms) and 2 new functions. One of the new functions is Decimate which deletes duplicate frames in a specified group of frames (ex: Decimate(5,8,500) means that 1 duplicate frame in each group of 5 would be removed. This is the same as IVTC if used after DeInterlace).

Another addition is CopyDuplicate which sets frames that looks very similar to another as the same. The effect is to cut down on the file size and boost quality of MPEG-4 encoded AVI. It takes 2 parameters (Filter and Threshold) which are the same as in Decimate. However, I did not have time to document this function so don't look for it in the readme. Also, considering the size this project is taking, I am going to convert the readme to an HTML help file.

On another subject, my 60 fps stream idea has been suspended for some time. It seams that 60 fps streams are 10% (or more) bigger than 30 fps streams (even after duplicate frames have been set as the same) and take twice as much prosessing power to play as their smaller cousins. Not a pretty picture :(

And I will have to suspend my programming for some 2 weeks since my week-ends (the time I use to make updates) are filled-up for now. Don't worry, I will still try to correct bugs and stay active in the forum :)

Blight
29th October 2001, 04:02
Wizard, It would be nice if you can post a URL to new versions here directly ...

Wizard_FL
29th October 2001, 04:43
I know, I know... But I don't have a web page or ftp, nor do I have the time to make one. This is the only way for me to publish my work and still have time to do any programming! :(

SleepEXE
29th October 2001, 15:50
Wizard_FL, why not attach it to your post here in the forums?

Oh, it's just cruel to dangle a new version in front of our faces with nowhere to download it! :D

Best regards,
SleepEXE

Blight
29th October 2001, 22:37
Yeah, notice the "attach file" line at the bottom of the "newpost/reply" forum

_TAG_
31st October 2001, 00:26
in WIZARD_FL's IVTC, since
"[The row size] is usually equal to the pitch or slightly less, but it may be significantly less if the frame in question has been through Crop." (from avisynth's guide)
wouldn't it be better to use GetRowSize instead of GetPitch to calculate the horizontal frame lenght?
ex.

const unsigned char* ptrRead=ptrFrame->GetReadPtr();
[...]
const int RowSz=ptrFrame->GetRowSize();
[...]
height-=3;
for (y=3;y<height;y+=2)
{
for (x=0;x<RowSz;x+=2)
[...]

Wizard_FL
31st October 2001, 01:03
If you'd have checked the last version you'd see it's already been done...;)

_TAG_
31st October 2001, 01:16
in the code for v2.10 (the one in the zip), in AnalyzeFrame(), you do a

Line1=ptrFrame->GetPitch();
[...]
for (x=0;x<Line1;x+=2)

Wizard_FL
31st October 2001, 05:35
I copied that code straight from my first version programmed so many months ago. As far as I know, it shouldn't create any real problem but I have changed it anyway.

On another note, I took some time off my work to create a site where I can put new versions of IVTC instead of sending every built to Doom9's submission address.

http://wizard_fl.tripod.com/

_TAG_
31st October 2001, 11:26
yup, the GetRowSize shoudn't help much... yet it's in the docs, so why not use it? ;)

_TAG_
31st October 2001, 15:02
just 2 ideas:
1. have a data structure in memory to hold found patterns (all of them, 1 for each quintet), so that if a Temporal plugin wants to see 'past' frames we can just look which one to feed it by looking at past patterns, and if it wants 'future' frames we won't calculate them more than once.
(if we store a char for each quintet, we don't waste much memory)
2. dump the data structure in a file to be used in the second pass, so we don't have to AnalyzeFrame(), but just look at the patterns (HUGE speed-up in the 2nd pass).

i'm looking into implementing them right now...

Blight
31st October 2001, 16:02
trbarry, any progress on GreedyHMA?

I tried it on an MJPEG 640x480 cap of the opening sequence of Angel.
The source seems to be a complete mess of composited 23.976 source (so while the original source may have been 23.976 fps, it seems as if they made the intro by compositing scenes on the telecined video).

The result was rather wierd, it seems as if every line it couldn't match it would just duplicate the one of the fields without even blending (so it would pixelate the image).

Oh, and Telecide, Wizard's ITVC and TMPEG's also botched it. Although TMPEG botched it the least.

I'm gonna try again on an actual show-portion of Smallville later this week.

Wizard_FL
31st October 2001, 17:40
What do you use for second pass. Is it virtualdub with DIVX or another program?

And if I do make a version of IVTC that uses 2 pass encoding by writing the first pass results to a file, how do I load the patterns into memory? Do I use tables or is there a better way like in VB with collections? And how do I write a file in C++ (I use to know, but I've forgotten)? You gotta help me here guys 'cause C++ really isn't my best programming language...

:confused:

Catmando
31st October 2001, 19:39
Here's some example C++ code. It might not be the best, but it should work. For this program the input file name is read off the command line and should only contain 0's and 1's.

example: input.txt
01010100100101001010010101001010

example command line:
blah.exe input.txt


#include <iostream.h>
#include <fstream.h>
#include <vector>

int main(int argc, char * argv[]) {
if (argc != 2) {
cout << "Need a file name " << endl;
return 0;
}

fstream infile;
// open file for input, first argument is a c string
infile.open(argv[1], ios::in);

if (!infile) {
cout << "file not found" << endl;
return 0;
}

char ch; // stores 1 character read from file
vector<int> frames; // stores 0's and 1's read from file

// while there's more stuff in the file to read
while (!infile.eof()) {
infile.get(ch); // read character from file

/* if the character is a 0 or 1 convert it to an
integer(atoi) and put it in the vector
*/
if (ch == '0' || ch == '1') {
frames.push_back(atoi(&ch));
}
}
infile.close();


// print out vector of frames to screen
for (int i=0; i < frames.size(); i++) {
cout << "frame: " << i << "\t" << frames[i] << endl;
}


// make file outfile.txt and print the vector to the file
fstream outfile;
outfile.open("outfile.txt", ios::out);

// output to file as 0's and 1's
for (int i=0; i < frames.size(); i++) {
// works just like cout
outfile << frames[i];
}
outfile.close();
}

trbarry
31st October 2001, 20:18
trbarry, any progress on GreedyHMA?

I tried it on an MJPEG 640x480 cap of the opening sequence of Angel.
The source seems to be a complete mess of composited 23.976 source (so while the original source may have been 23.976 fps, it seems as if they made the intro by compositing scenes on the telecined video).

The result was rather wierd, it seems as if every line it couldn't match it would just duplicate the one of the fields without even blending (so it would pixelate the image).


Blight -

I mostly moved GreedyHMA discussion to the Avisynth forum, to stop hijacking Wizard's thread here. ;)

But what you are discussing may or may not be new depending upon your parms and the release of GreedyHMA (currently 0.3.1.0 a few minutes ago).

Could you post a few dozen frames somewhere?

And it's hard to capture Buffy & Angel cause they are so dark, even in digital on my WinTV-HD (but I do anyway). I never tried Smallville but I love the show.

But anyway, see the other thread. GreedyHMA's now now got full IVTC, some bug fixes, open questions about frame rate changes, etc.

- Tom

_TAG_
31st October 2001, 22:49
actually, for each quintet we need to store the patterns and the Reversed flag (guessing from the code, since GetIVTCFrame() has a Reversed parameter).

i thought of storing them in unsigned chars to save memory, like this:
R00ABCDE
(R,A,B,C,D,E=0 or 1...) ;-)
R = reversed flag
A,...,E = pattern bits

we'd need an unsigned char RFF[] to hold the patterns and char * RFFile to store the filename.
then, in IVTC::IVTC() (which would need a new argument char * _RFFile)

int n = vi.num_frames;
strcpy(RFFile,_RFFile); #hope it's the right instruction to copy a string... don't remember it ;-)
fstream infile;
RFF = malloc(sizeof(char)*(n-(n%2))*10/4);
infile.open(RFFile,ios::in);
if (!infile) {
#if there's no file (first run), all patterns are zeroes...
<some code to set all RFF[i]s to 0, like memset()>
} else {
#if there's a file (second or more run), use it and get the data
for (int i=0;i<(n-(n%2))*10/4;i++) infile.get(RFF[i]);
}
infile.close();

and the IVTC::GetFrame() would look like

unsigned char temprff=0;
if (RFF[Group]==0) {
<IVTC code>
if (Reversed) temprff += 128;
#obviously the following "if"s would be incorporated in the multiple "if (PairVal[])"s
if (IVTCPair[0]==0 && IVTCPair[1]==2) temprff += 5; # 00101
if (IVTCPair[0]==0 && IVTCPair[1]==3) temprff += 9; # 01001
if (IVTCPair[0]==1 && IVTCPair[1]==3) temprff += 10; # 01010
if (IVTCPair[0]==1 && IVTCPair[1]==4) temprff += 18; # 10010
if (IVTCPair[0]==2 && IVTCPair[1]==4) temprff += 20; # 10100
RFF[Group]=temprff;
return Frames[IVTCPair[n%2]];
} else {
if (RFF[Group]>128) {
Reversed=true;
temprff -= 128;
}
if (RFF[Group]==5) { <assign IVTCPair[]s> }
if (RFF[Group]==9) { " " }
[...]
<!!!return correct frame!!! (look at the note below)>
}

NOTE: since i don't have time to understand what Reversed is for (going out for Halloween...) ;-) , i don't know how to return the correct frame... sorry. if someone would help me.
then we'd need an IVTC::AtExit() function to save the patterns:

fstream outfile;
outfile.open(RFFile,ios:ut);
for (int i=0;i<frames.size();i++) outfile.put(RFF[i]); #hope it writes the raw char... not sure ;-)
outfile.close();

_TAG_
31st October 2001, 22:51
The problem is that Avisynth keeps the frame rate as an exact ratio of two integers. I was previously changing it by the statement

vi.SetFPS(vi.fps_numerator * 4 / 5, vi.fps_denominator);

but both parms are integer so there can be a truncation error. Now I'm using

vi.SetFPS(vi.fps_numerator * 4, vi.fps_denominator * 5);

from trbarry in Avisynth forum

Wizard_FL
1st November 2001, 14:45
Reversed indicates that the field order in the video stream has been reversed. In this case it enables the plug-in to get the correct doubleweaved frames by mixing the odd field of the next frame with the current even field instead of the even field of the next frame with the current odd field.

jarthel
2nd November 2001, 01:55
Originally posted by Wizard_FL
I copied that code straight from my first version programmed so many months ago. As far as I know, it shouldn't create any real problem but I have changed it anyway.

On another note, I took some time off my work to create a site where I can put new versions of IVTC instead of sending every built to Doom9's submission address.

http://wizard_fl.tripod.com/

I can't download the latest ITVC. Has anyone been able to do it? Maybe you could email it to me. jarthel@operamail.com. Thanks

_TAG_
4th November 2001, 05:03
is the reversed setting there to compensate for what is called field order in TMPGEnc?
(which has 2 settings, Top and Bottom)
If so, shouldn't they be constant in a movie? (or, at least, in many well done movies)

Wizard_FL
5th November 2001, 02:05
I don't know how Reversed field order works with TMPGEnc since I have never used it but here is what it does with IVTC plug-in:

Reversed param is used to help the function determine which field changes first. Granted it would be useless if all video streams went through the same telecine process. However, not all of them aren't standard and some even change field order in mid point making it necessary to adapt the doubleweave method. Reversed param enables the function to adapt itself to field order changes at a minor price of CPU power (40% during pulldown pattern analysis, which only happens once in a perfect scenario, and 0% during normal process).

SleepEXE
5th November 2001, 07:18
Here's a copy of the v2.101 plugin for those who've been unable to download from Wizard_FL's site:

http://rilanparty.com/vbb/attachment.php?s=&attachmentid=50

Wizard_FL
9th December 2001, 21:21
I'm trying to code a Multi-pass IVTC, but I can't get the plug-in to close the output file when the class is terminated. I don't understand how to make a function that will execute when the filter is finished! Can anyone help a newbie?

Milkman Dan
10th December 2001, 08:33
I don't get it. Is the InverseTelecine posted on the frontpage a new version? I looks the same as the one in the GordianKnot pack...

Wizard_FL
10th December 2001, 14:17
Haven't posted anything new for a while since I wanted Multi-pass IVTC to be functional... Latest version is the same as SleepEXE's post (above).

maven
12th December 2001, 11:11
i recently used your (WizardFL) IVTC plug-in (needed to encode 10 episodes of cowboy bebop on a single weekend), and it said in the readme that it detects field order on its own...
according to my experience, this does not work (i.e. did an episode, had tons of interlaced frames, used swap field order in dvd2avi -> interlaced frames (mostly... there still were about 20 frames per episode left))...
good job, though... beats VirtualDub's IVTC, but not TMPGEnc (which takes ages...)

Wizard_FL
12th December 2001, 14:43
Like you said, it was supposed to detect field order, but it doesn't seem to... I used a short video stream of Sakura Diaries to test that part since it had a reversed field order (no change during it's duration) and the plug-in worked well. However, I tried it last night with Legend of Zu which switches field order during the film and got unwanted results.

I need to do some checking here (but not right now 'cause I'm at work :D ) to see where it goes wrong.

Milkman Dan
21st December 2001, 16:18
Any update on your progress wizard? I'm hoping either inverseTelecine or greedy will emerge as a sure solution for iVTC.

Wizard_FL
21st December 2001, 16:27
Yes, I have worked on the IVTC Dll and no, there is no update available on the internet yet.

I have checked my code, made a few corrections and tested it with a 105 minutes long film (Legend of Zu) that has both pattern changes and field order changes. The results are near perfect, but I would still like to look at the finished product before I publish anything tho.

Anyway, with vacations comming up, I plan to post the latest version before January 1.

Milkman Dan
22nd December 2001, 02:39
Wonderful. Sounds great.

robshot
27th December 2001, 20:31
Hiho, this is my first post. Cheers Doom9.
I just read the whole thread! And it IS fantastic.

While I'm no programmer, and what I'm gonna write might be old news, let's rewind back to the mpeg2 treatment.

As I've read this thread, I noticed a lot of DVD2AVI popping out. Here's what i know about NTSC video encoded to mpeg2.

In 1 single mpeg2 NTSC video stream, there can be:

1. 24 frames stored with rff/tff flags and 29.97fps flag
a. 1 or up to 5 pulldown formula always present.
b. 1 or up to 5 pulldown formula, but some part of the mpeg2 does not have rff/tff flag. Screwed up mpeg2 video this is! But I encountered it once. I still wonder how/what encoder does this (hardware or software)

2. 29.97 fps interlaced.
a. pure interlaced 29.97fps (made from video)
b. 29.97fps HYBRID (made from telecined video hardcoded into mpeg2 video stream + pure interlaced 29.97fps). Or there's also possibility that a telecined video got edited in the video environment, thus creating a cadence where the edit point does NOT conform with the original telecine formula.

Now, if we rewind back a bit, the question is, how reliable DVD2AVI translates the mpeg2 video so that you can use it in .d2v?

Since avysinth mpeg2 plugin reads the .d2v from DVD2AVI, the raw data that avysinth get, and then got "tampered" to be IVTC-ed. WHAT IF the .d2v is wrong? Then whatever next process will carry the error, right?

Wizard, I've been reading your post and updates. Since I think your approach is to really-REALLY get a pure IVTC-ed stream, perhaps going back to how the mpeg2 got translated to the raw data feed to avisynth might help trace back the problem.

I have this small proggie written by a friend a long time ago, which reads the flags in mpeg2 video file and dumps a log. The file is .exe but i just renamed it to .jpg so the forum can accept it. Rename back to .exe if you download it.

It runs under with dos command:

m2vinfo filename.m2v > log.txt

Here's a sample dump:

Type 1 tff 1 rff 1 temp_reference 2
Type 3 tff 0 rff 1 temp_reference 0
Type 3 tff 1 rff 0 temp_reference 1
Type 2 tff 1 rff 0 temp_reference 5
Type 3 tff 0 rff 0 temp_reference 3
Type 3 tff 0 rff 1 temp_reference 4
Type 2 tff 0 rff 1 temp_reference 8
Type 3 tff 1 rff 1 temp_reference 6
Type 3 tff 0 rff 0 temp_reference 7
Type 2 tff 0 rff 0 temp_reference 11
Type 3 tff 1 rff 0 temp_reference 9
Type 3 tff 1 rff 1 temp_reference 10

Notes:

Type-1 = I Frame
Type-2 = P Frame
Type-3 = B Frame
temp_ref = DISPLAY ORDER
rff = Repeat_First_Field flag
tff = Top_Field_First flag

What I do is reconstruct the DISPLAY ORDER. I do this from the dump.txt above by rearranging the Frames according to the temp_ref. order

B B I B B P B B P B B P

Then, I put the T_F_F and R_F_F in order too

0 1 1 0 0 1 1 0 0 1 1 0
1 0 1 0 1 0 1 0 1 0 1 0


Now I have the following sequence in DISPLAY_ORDER:

B B I B B P B B P B B P
0 1 1 0 0 1 1 0 0 1 1 0
1 0 1 0 1 0 1 0 1 0 1 0

With this, I can find the correct TELECINE formula... just take the first 5 frames from the sequence above, and assume its an A B C D E sequence:

A B C D E

Apply the T_F_F and R_F_F values to the sequence above, and correctly follow the first T_F_F value, so we know which STARTING FIELD. I got this:

AlAu AlBu BlCu ClCu DlDu ElEu El

The STARTING_FIELD from above sequence is Al = Frame A lower field. Separate the sequence above into 1 frame (containing 2 fields), and we can calculate the TELECINE sequence within this .M2V as follow:

W S S W W W

So, the WSSWW sequence is the EXACT TELECINE formula taking place in the first part of this particular .M2V. Perhaps this information could be useful to analyze further.


Phewww...
so I guess what I'm trying to prove is, first find a 100% reliable mpeg2 decoder to make sure the data is read correctly, then move on to the next level.

Whaddya think?

Cheers.

Milkman Dan
28th December 2001, 18:31
This looks like a pretty smart method, but one question:
What do the W and S stand for?

robshot
29th December 2001, 17:35
W is WHOLE, the original progressive frame (3 frame) followed by
S (SEPARATED), the interlaced 2 frames (created by 2:3 pulldown)

Cheers

Milkman Dan
30th December 2001, 00:02
Ah, I see.

So, anyone willing to code it? Test for its reproducibility? It looks too smart to pass up, in these instances where the original information is intact.

It won't help all sources, of course, and those would be best served with the plugin as it is now; trying to reconstruct without all the information.

robshot
30th December 2001, 09:53
when an mpeg2 file has no rff/tff flags, then the player/decoder will not add frames. If this is what you mean by "without all information" then that particular sequence should not get additional frames in the decoding/converting/IVTC process. At this ocassion, I think the way is to find correct upper+lower fields and then create 1 full frame to make it progressive (i wish it would be _this_ easy) :)

Cheers

trbarry
30th December 2001, 15:07
It would be very useful to have all the flags info when doing IVTC/deinterlace.

But maybe the problems come when that info can not be trusted for the reasons stated above. Then you have to look at the data itself and I think the hardest part is automatically deciding whether to trust the flags at any given time.

- Tom

Wizard_FL
30th December 2001, 19:14
I considered trying this approach when I discovered that most people used IVTC to rip DVDs, but I ran in a few walls.
1- I have no real knowledge of flags within MPEG-2 or how to get that information.
2- I do not really trust flag info, especially with animé which tends to be really f*cked-up standard wise.
3- It would require much time on my part to get an understanding of how do it and programming it, time which I don't have anymore.

If anyone has the know how and the drive for this project, I encourage them to try it! On my part, I'm taking a step back from development for a while. However, I will work on my current project until it works the way I planned it to and is (reletively) bug free.

robshot
31st December 2001, 04:41
let me rephrase the mpeg2 ntsc:

1. 29.97 with the interlaced frames "encoded physically". This case, we will find no pulldown flags (top_field_first + repeat_first_field).

2. 29.97 with pulldown flags. the interlaced frames are "created" by player reading the tff + rff flags.

So, if a utility can read these two files, to find whether there's tff+rff or not, then it's a step forward for next treatment. M2VINFO.EXE can do this _correctly_

After reading which type of NTSC mpeg2 one is going to IVTC (from the 2 above), then one can do further check whether:

1. the 29.97 "encoded physically" has a constant 2:3 pulldown pattern, or not.
2. the 29.97 "encoded physically" is hybrid or not. That is, to find whether it has 2:3 pulldown pattern and pure 29.97 interlaced mixed together, or not.
3. the 29.97 "encoded physically" has various 2:3 pulldown patterns and also hybrid, or not.

4. the 29.97 with pulldown flags has constant 2:3 pulldown pattern or not.
5. the 29.97 with pulldown flags has some 2:3 pulldown flags in one area, and no pulldown in other areas (pure 29.97 interlaced and/or encoded physically), or not.


So, basically, one has to first determine which out of those variables, before IVTC-ing it.

There's nothing to do with trusting the flag _in_the_mpeg2_file. When there's a flag, there's a flag. When there's not, then there's not. One has to determine which of the above, not _not_trusting_ the flags existence in the mpeg2 file.

No matter how f***ed up an NTSC mpeg2 is, the fact that a player is capable of reading and thus playing it, says that that mpeg2 is within the specification boundaries.

I would be glad to assist a programmer to achieve a 100% IVTC program. I am fully confident that it can be done. While I'm not a programmer, perhaps the understanding of these bugger can help a programmer.

Cheers.


Cheers

Wizard_FL
31st December 2001, 08:42
I uploaded my latest build of IVTC, you can get it at http://wizard_fl.tripod.com/wizardslab/id4.html

I know the help is incomplete and I really need to update my site... But it was a late night playing AD&D and I think I'm going to get some sleep before the work life creeps-up on my again :D

SleepEXE
31st December 2001, 17:09
Thanks, Wizard_FL, I've been keeping an eye on the thread in anticipation of the new release.

Best regards,
SleepEXE

Guest
2nd January 2002, 22:24
Previously, the combination of Telecide/Decimate was only *promising* for IVTC, but not useful in practice, because Decimate had unreliable duplicate detection. I have now released a new version of Decimate that is a vast improvement. I'd be curious to have feedback on the combination. If it is positive, I could contemplate porting it to Avisynth, where the cumbersome multiple passes could be combined, resulting in an integrated modeless (patternless) IVTC.

Milkman Dan
3rd January 2002, 00:31
I feel kinda bad posting this right after the post above me, but:

YESSSSSSSSSSSSS!!!!!!!!!!!!!!!!
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
THANK YOU
IVTC WORKS!!!! on my REALLY NASTY ANIME!!!!!!

\/\/0077777!!!!!!!!!!!!!!1111111
Oh how I've WAITED for this day! Finally, all my Tenchi will be flawlessly ivtc'd!!!!
YES!!
[dodges flying objects] Hey, no need to get rowdy! Just expressing some joy!
:p
Wonderful job Wizard. Thanks a bunch.

maven
3rd January 2002, 11:16
but didn't you get good results with TMPGEnc (with the right field order of course)? It's only problem is it takes ages...

On another note, i was wondering whether a slightly different approach would work better:
some times you have a small moving object on a static background, whose weaving factor does not exceed the threshold. what i'm trying to say is how about a option that treats this as an optimisation-problem (i.e. find the smallest weave-coefficient) instead of threshold. and yes, i know it'd be slower.. ;)

Wizard_FL
3rd January 2002, 20:56
Here's the problem: how do you determine the difference between small object interlaced and fine detail?

I found it impossible to do this without having to analyse every frame with very comlicated algorithms that would have an almost human way of thinking. I programmed IVTC to base it's conclusions on blocks of 4 vertical pixels or 3 vertical by 2 horizontal so that it won't confuse tearing with fine details which results in very accurate analysis but also makes it very hard to spot small object moving. I wanted to avoid having to analyse the content of video to reduce processing time, but simple algorithms have their limits!

lgcbmb
19th February 2002, 12:56
from what I understand it should be fairly easy to do 100% accurate ivtc using dvd (mpeg2) source.

a quote from the mpeg2 faq at berkley (http://bmrc.berkeley.edu/research/mpeg/faq/mpeg2-v38/faq_v38.html#tag15):
---
frame_rate_code in MPEG-2 refers to the intended display rate, whereas in MPEG-1 it referred to the coded frame rate. In film source video, there are often 24 coded frames per second. Prior to bitstream coding, a good encoder will eliminate the redundant 6 frames or 12 fields from a 30 frame/sec video signal which encapsulates an inherently 24 frame/sec video source. The MPEG decoder or display device will then repeat frames or fields to recreate or synthesize the 30 frame/sec display rate. In MPEG-1, the decoder could only infer the intended frame rate, or derive it based on the Systems layer time stamps. MPEG-2 provides specific picture header variables called repeat_first_field and top_field_first which explicitly signal which frames or fields are to be repeated, and how many times.
---

i take this to mean that all/most/some dvds are encoded at 24fps, and use repeat_first_field and top_field_first to display 30fps. if this is true then you could read the flags and drop any frames that arent the original 24. as this seems to indicate easy/perfect ivtc ive probably screwed up somewhere..

Wizard_FL
20th February 2002, 14:23
That is an approach I never used because my project started up by trying to encoder from VHS. Granted, this isn't a very elegant solution for making CDs but when that's all you've got, that's what you use.

I could make another IVTC function just for DVDs, but that would require an entirely new project and I suspect that some of the programmers here could do a much better job of it than I could considering my total lack of knowledge concerning the structure of MPEG-2. Knowing there are flags somewhere in there isn't enough, you have to know how to read them or have a tool to do it for you (why I don't).

lgcbmb
20th February 2002, 19:54
good to know that im not just missing something obvious. :)

perhaps a more straight forward mpeg2 ivtc would be to simply ignore the flags and dump the original 24fps. this could be easier/faster then decoding the full 30fps, reading the flags, and droping the unwanted 6 frames. i guess this really wouldnt be ivtc cause a telecine proccess is never performed.

i hope someone has the coding skills/knowledge/time to take this on. there seems to be no shortage of users willing to offer their time for testing at least, myself included.

maven
21st February 2002, 14:19
usually the repeat flags are hardly ever used correctly (unless you got a completely progressive encoding). so it does not work (well) at all... sniff.

Wizard_FL
28th February 2002, 14:24
Does that mean that most DVD's aren't encoded as progressive frames? That would be kinda stupid since 20% of a telecined stream is just repeated fields, but then again I never said the people who encode them know what they are doing... ;)

I guess it would make sense to encode a video stream as fields instead of progressive frames where it contains both 30 fps and 24 fps material (hybrid), but otherwise it's a waste of processing time, bandwidth and disc space.

Can anyone shine a light on this?

Wizard_FL
21st March 2002, 15:41
I've got the programming bug again!:D
I was thinking of doing some work on IVTC to add yet another function. The goal would be to IVTC a DVD I recently got (Soultaker). It has a very nasty 29.97 fps stream that can't be deinterlaced or IVTC because the fields were blended together during the telecine process. The problem becomes even more apparent when you try to resize the video frames (yuck).

The question becomes "Do I do it?". It is pointless to add the function to my DLL if I am the only one that uses it (especially for a DVD I own). Because I've had no feedback for IVTC.DLL since the last version I published (no bug reports or suggestions) I'm beginning to wonder if this thing is worth the effort...

trbarry
21st March 2002, 18:08
Wizard_FL -

I feel your pain. ;)

Except for video deinterlacing I've pretty much taken a vacation from GreedyHMA/Avisynth development as long as Donald Graft is willing to put such excellent energy into Decomb.

But I'd love to know how to get rid of blended fields.

- Tom

Nic
21st March 2002, 18:44
Could you two work together with DG to help make DeComb a "perfect" solution (not that I suppose there is such a thing)?

You three really are the experts in the IVTC/Deinterlace field.... :)

-Nic

trbarry
21st March 2002, 20:15
Nic -

Actually Donald contacted me and we collaborated a bit before he wrote Decomb. My own focus was always more on the deinterlace side with IVTC thrown on as an afterthought. It may be awhile before I have time to do much with IVTC again but Donald seems to be handling it just fine anyway.

To me, much of the problem now is the networks are optimizing for interlaced displays by blending in a way that doens't yield good results if you try to do a progressive encode and looks even worse if you pause and look at certain still frames. Some of that is even finding it's way onto DVD's but maybe is not as much of a problem there.

- Tom

Guest
21st March 2002, 21:13
There is also daxab, who has his IVTC4. Ideally, I'd like to see everybody communicating and discussing their approaches and the advantages and disadvantages. Trbarry, Wiz and I all make our source code available and have been willing to discuss internals. But daxab is remaining secretive, and just makes jokes when asked about it.

As far as further developments are concerned, I have a number of things I need to do for Decomb. The pattern guidance fails after a bad 30fps section and I'm trying to find out why and fix that. I'd like to integrate Decimate into Telecide and let it takes its choice of frame to decimate from the pattern when possible. Then some enhancements to the deinterlacing. I'm in early days for research into pattern guidance, so things could get much better in that regard for Decomb.

Regarding blended fields: These usually arise from PAL<-->NTSC conversions (either way). 3:2 pulldown of an NTSC-->PAL conversion results in a very difficult stream. I don't think there is any good solution.

trbarry
21st March 2002, 23:12
Regarding blended fields: These usually arise from PAL<-->NTSC conversions (either way). 3:2 pulldown of an NTSC-->PAL conversion results in a very difficult stream.

Those are the more common conversions but I think blended frames may now appear in ANY format conversion.

Ths reason I'm griping about this is the increasingly common type of conversion done by UPN to send my Buffy's upconverted to 1080i HDTV. It looks ok interlaced but if pull it into vdub and snap to the next keyframe it is almost guaranteed to be badly blended. Since the other frames key off the keyframes after compression this has a strong negative effect. I'm almost considering dropping all potential keyframes before compression. (and replace with what?) I would rather see a one frame judder on a scene change if needed.

I don't think there is any good solution.

If enough people talk about it something will come up.

- Tom

Wizard_FL
22nd March 2002, 01:07
Looks like I was mistaken, Soultaker isn't blended, it was because I was looking at it with a 27" TV (My bad :p). I can still simulate the effect of blended video and try to undo it, but it just isn't the same as working with the original.

Hey trbarry, can you put some sample of your buffy material somewhere I can download so I can look at it? I'd like to see if I can undo the interlacing.

trbarry
22nd March 2002, 02:46
Wizard -

YGM

- Tom

daxab
26th March 2002, 09:20
@neuron2There is also daxab, who has his IVTC4. Ideally, I'd like to see everybody communicating and discussing their approaches and the advantages and disadvantages. Trbarry, Wiz and I all make our source code available and have been willing to discuss internals. But daxab is remaining secretive, and just makes jokes when asked about it.I'll try to be more serious.

It's my impression that when you write code on your own time, you do with it what you will. You share it or don't share it as you see fit. I've chosen to share my binaries at this time. If there were some reason for me to share my source, I would. Likewise, I haven't read the source code for other ivtc plugins.

As far as discussing internals and sharing information, you asked about my interlacing metric and I posted it, and you asked about my pattern analysis and I described it. You've taken the information I've given you and incorporated it directly into Decomb, so I'm surprised that you're complaining.

Guest
12th August 2002, 02:51
@daxab

As far as discussing internals and sharing information, you asked about my interlacing metric and I posted it, and you asked about my pattern analysis and I described it. You've taken the information I've given you and incorporated it directly into Decomb, so I'm surprised that you're complaining.
No, daxab, you are making a false and unfair accusation here. First, I do not use your combing metric. I use the one I posted that is derived from Gunnar Thalin, and Gunnar is acknowledged in the code. Second, I do not use your pattern analysis method. I developed my own method after being inspired by your *idea* of guiding field matching with the prevailing pattern. Again, you are credited for the inspiration in the source file. My source is available to all who might wish to verify that what I say is true.

I have always been very open with my source code and have always strived to credit others when I use their ideas or code. I have also always encouraged others to use my own work. Only in this way can we make the best progress toward our shared goals.

trbarry
14th August 2002, 09:21
It's my impression that when you write code on your own time, you do with it what you will. You share it or don't share it as you see fit.

I personally support this idea.

I almost always share my source code because I think it gives my software greater value, certainly helps it evolve faster, gives me free backup, and because it is fun.

But I do it because I like to. I don't feel obligated to share it unless it is based upon others work. Each person should be able to make this choice on a case by case basis without getting hassled or having to feel too guilty about it.

- Tom