Decomb YV12 status report

[Dreassica]

with the new decomb and mpeg2dec combo entering the telecide() command causes vdub(mod) to immediately close without any error whatsoever, when i leave the telecide command out, it opens without a hitch.

[jang0]

Originally posted by Wilbert
Welcome to the forum.

You need to read the YV12 faq ... You also need to install a recent Xvid built of Koepi (link can be found in the faq) or DivX5 (link can be found in the DivX5 forum).

Uh, I still had an old stable build installed. could fix the problem, thx.

So I ran some tests with the new telecide, with the futurama pal dvd as source material, which has some weird stuff, including changes of patterns of progressive/interlaced frames, changes of field order once in a while etc., so i thought this could be well-suited for testing telecide() + fielddeinterlace(full=false, chroma=true, blend=true)

After doing some spot tests, i also encoded a few scenes, and i have to say that everything just worked out very well, that means i couldn't see any difference between the old decomb and the new one (well, i think thats supposed to be a good sign in this case :D )

There were no errors/crashes etc. and speed was ok, too. good work!

sorry for bad english :devil:

[Guest]

Originally posted by Dreassica
with the new decomb and mpeg2dec combo entering the telecide() command causes vdub(mod) to immediately close without any error whatsoever, when i leave the telecide command out, it opens without a hitch. Post the failing script in its entirety, please.

[Guest]

Originally posted by jang0
After doing some spot tests, i also encoded a few scenes, and i have to say that everything just worked out very well, that means i couldn't see any difference between the old decomb and the new one (well, i think thats supposed to be a good sign in this case :D )

There were no errors/crashes etc. and speed was ok, too Thank you for the results, jang0. I think the speed gain from using YV12 is being offset by the (current) lack of low-level optimization. When the latter is done, things should get really fast.

[Dreassica]

i deinstalled everything and reinstalled and got it working, Phew!!
weird, it worked fine before. ah well

[MaTTeR]

Just a quick thanks Donald. Tested the typical Telecide()
Decimate(cycle=5) and all seems to work very well with no noticable artifacts, frames were nice and clean:)

[ookzDVD]

@neuron2,

I did small test with 4:50 minutes video clip,
with telecide() and decimate(cycle=5) and the result is ok.
No problem so far.

Thank you for your great work.

[Guest]

Good news, Gentlemen. Thank you for your test results.

Next steps:

* Put FD code into Telecide (postprocessing).
* Low-level optimizations.
* Proper help file.

Here's a question for users. Would you be OK with separate DLL versions as follows:

1. DecombYV12 for Avisynth 2.5
2. DecombYUY2 for Avisynth 2.5
3. DecombYUY2 for Avisynth 2.0x

...or would you consider it important to combine 1 and 2 into one DLL? Of course 3 cannot currently be combined.

[trbarry]

I think it is very important to be able to combine all 3. But it doesn't look like that is going to happen.

- Tom

[ErMaC]

Well, I think it would be a pain once plugin autoloading returns, cause then we'd need different names for the various functions (i.e. TelecideYV12() and TelecideYUY2()) or else they would collide and we wouldn't know which one we're getting unless it doesn't work ^_^
I'd much prefer them both in one DLL so that this can be avoided. Then I can just say Telecide() and not have to worry about moving DLLs around or manually loading plugins.

But then again, from where I'm sitting it's not a lot of work for me either way - you're the one programming it so it's up to you. ^_^ Not my place to demand they both be in the same DLL, but it would be more convenient.

As for 2.0 DLL vs. 2.5 DLL, that's fine. I don't care about that since I'm keeping the plugins separate anyway (and I don't have autoloading for 2.5 yet).

[ookzDVD]

@neuron2,

I prefer to have the seperate DLL version,
since the Marc's MPEGDEC3 also have seperate DLL version for YV12 ;)

[vinetu]

I'm for seperate DLLs too - I'll never use
plugins autoloading and I like 98lite and I
want to know what the plugins doing while
I'm not at home ! :)

[Wilbert]

I prefer to have the seperate DLL version,
since the Marc's MPEG2DEC3 also have seperate DLL version for YV12
Marc FD has no version for v2.5 which directly outputs to YUY2. Talking about Decomb for v2.5, why don't you add an argument which lets the user choose between "YV12" or "YUY2".

I think less confusing is to keep a dll for v2.07 and one for v2.5

[Marc FD]

both avisynth 2.5 YUY2 and YV12 versions in one dll.
avisynth gives you the colorspace, decomb can switch automatically between YUY2/YV12. totally transparent to the user, like blur does :
blur works in RGB24,RGB32,YUY2 and YV12, with all C/MMX code writen for each case (with some shared parts) ^^

BTW, to make thinks clear, an avisynth 2.07 & 2.50 filter in one .dll is simply impossible.

[DarkNite]

I've been a fan of decomb for a long time, and i must say that i'm surprised that the conversion is coming along so quickly and smoothly. You've done nothing but excellent work so far, and i wish you the best of luck in the future.

As for the dll's: I vote for a joined dll for yuy2 & yv12

[Razor04]

I have been using Decomb for quite a while now, and I definately have to vote for having the YUY2 and YV12 versions combined into one dll. As long as it can automatically determine what colorspace is being used, I think this is the best option. Especially for people that switch back and forth between different sources/colorspaces. Anyways...just my 2 cents :)

[Guest]

OK, then, the 'ayes' have it. I'll combine the YV12 and YUY2 support and it will be transparent to the user. But we'll still need a separate DLL for Avisynth 2.0x.

[ErMaC]

OffTopic: Don, your new avatar is uber-cute. Is that a very lucky kitty, or what? :D

[Guest]

Of all my previous lives, the one I spent as a cat was the most rewarding and joyful. This photo of me was taken in early 1934.

[Guest]

Attached is DecombYV12 4.03b6. Post-processing is now enabled in Telecide(), so it is not necessary to use FieldDeinterlace() as in the previous beta.

firstlast=true now forces deinterlacing of the first and last frames.

Another option has been added. The nt option sets the noise threshold for field matching. Refer to this thread for details:

http://forum.doom9.org/showthread.php?s=&postid=224684#post224684

Next steps:

1. Low-level optimize.
2. Combine YUY2 and YV12 support into same DLL.
3. Proper help file and formal release.
4. Improved field matching and expanded override capability.
5. Retrofit feature changes to DecombYUY2 and release.

[OUTPinged_]

mmm... Is that me or firstlast=false _disables_ deinterlacing for first and last frames now? :-)

[Guest]

Originally posted by OUTPinged_
mmm... Is that me or firstlast=false _disables_ deinterlacing for first and last frames now? :-) Setting firstlast=false does nothing; while setting firstlast=true forces deinterlacing. If this is not what you observe, please post your script. Thank you.

[ErMaC]

Don, status report:
Did an encode of "Rejected" today - it's encoded pure interlaced but it's obviously telecined from film. Used Telecide(guide=1) and (Decimate) and it worked perfectly, no combing or other issues, but this is hardly a torture test for it since I turned Guide on.
Will look forward to speed improvements as I saw around 7-8fps encoding times as compared to 12-13fps encoding times when using forcefilm on progressive streams, and I recall decomb being faster than this. :)

[Guest]

Here is DecombYV12 4.05 beta 1.

It has some optimizations for speed but they are not yet complete by any means.

It has a new parameter called 'mm'. Set mm=0 (default) for the current matching behavior, i.e., tries to match to current/previous/next. Set mm=1 to match only to current/previous. Set mm=2 to match only to current/next. These new modes are useful when you know the clip's parity (top or bottom first), because you can both run faster and prevent some spurious matches. This should be used only by experts who know when it can be safely used.

Here's the really nice new feature. You can now specify full patterns for your matching in the Telecide overrides file. For example, suppose you wanted to force a pattern of ncccn for frames 100 through 185. Your overrides file line would be:

100,185 ncccn

You can put as many specifiers in the pattern as you like. For example, this would be legal too:

100,185 nc

The specified pattern will be repeated beginning at the starting frame and ending at the ending frame of the range.

This capability allows for flexible and convenient manual control of field matching. You can do your whole film manually if you like!

Feedback will be appreciated. This is the feature freeze. These new features will be ported to the Avisynth 2.0x-compatible and Avisynth 2.5 YUY2 versions soon.

[trbarry]

Donald -

Ah, new version, good news. ;)

I've been using your previous YV12 release for the last few days in my testing. Only boring feedback, no obvious problems.

I rarely use the fancier options but it is nice to know they are there to fall back on.

Thank you for your efforts.

- Tom

[Trahald]

i threw a some animation at it and telecide-decomb spit out a perfect copy. good work (4.03 b6) i'll try 4.05 in tonite

[Bulletproof]

If I remember correctly there used to be a function in avisynth that was able to detect the proper field order, could it be possible to implement that so decomb can choose the right field order?

[CruNcher]

@ neuron2
DecombYV12 4.05 beta 1 gives me allways this error when trying to load an avs in VirtualdubMod or trying to play it directly
encoding makes no problems

"DecombYv12.dll" is not an Avisynth 1.0 plugin

any idear what this is causeing ?

PS: Encoding with Avs2avi hehe for those who wonder how i can encode
if the AVS is not loading into VirtualdubMod

[MaTTeR]

Originally posted by CruNcher
"DecombYv12.dll" is not an Avisynth 1.0 plugin I was getting this same error until I updated AVS2.5 to the 12-17 build. Fixed the problem on both of my machines IIRC.

[Guest]

Yes, you need to get the latest Avisynth 2.5, because I changed to use AvisynthPluginInit2() as instructed by sh0dan.

[CruNcher]

@ neuron2 and matter
sorry my fault i had an yuy2 version in system32 folder so by opening the avs he took that avisynth.dll
thx for the help

but i see another problem it has nothing to do with Decomb i think but it looks like crooping in YV12 is not the same as in YUY2 the first topline gets hacked only the half line is rendered strange hmm i'll report if i found out more maybe its a mpeg2dec problem

EDIT
----
ok it is not an error thats caused by any filter or avisynth it was in my source a so caled VBI vertical blanking line sorry again
thx to all the #xvid channel members for pointing me in the right direction :)

[Demone]

I'm trying to deinterlace a 'PAL interlaced' video (this is what dvd2avi reports).
I crop the video in the .avs then using vdub 1.4.13, I set
the smart-deinterlace 2.7 b2 this way:

frame-only differencing
compare color channels
use bicubic for interpolation
motion map denoising
motion threshold at 6

after the de-interlace I apply a Lanczos3 resize still in vdub.
and its PERFECT !!! (so its obviously a pure interlaced PAL).

Now the problem...
I wanted to avoid all the colorspace conversions, so thought to use
YV12 stuff i.e. vdubmod, avisynth 2.5b and decombyv12,
BUT I cant recreate the same deinterlacing accuracy this time...
I tried:
FieldDeinterlace() -> bad borders
FieldDeinterlace(chroma=true,dthreshold=1,threshold=1,blend=false/true) -> better but still some strange borders.
Is it possible that the Vdub smartdeinterlace is very different from
the fieldeinterlace of decomb ?

P.S. I attach two test frames...Test.zip (http://space.virgilio.it/gnomomagico@tin.it/Tests.zip)
Notice white text gives broken pixels too
Neuron2 if you want I can give mini vob.

[scmccarthy]

If I am not mistaken, cropping must always be at least twice the mod for YV12 than for YUV2. Cropping must be an even number of lines and columns, because the chroma planes are half the luma plane in both directions.

In any event, the crop function makes everything mod2. This is the relevant code from crop:

if (vi.IsYUV()) {
// YUY2 can only crop to even pixel boundaries horizontally
_left = _left & -2;
_width = (_width+1) & -2;
if (vi.IsYV12()) { //YV12 can only crop height to multiple of 2
_height = _height & -2;
_top = _top & -2;
}
} else {
// RGB is upside-down
_top = vi.height - _height - _top;
}
Note that IsYUV includes both YUV2 and YV12.

Stephen
[edit] Ooops! It's a double post.:rolleyes:
[edit2]This post is meant to confirm Crunchers statement that cropping in YV12 is not the same as in YUV2.

[Demone]

Could it be a bad crop values ?
I'm using crop(14,4,693,568) mmm I think its.
Lets try !

[Demone]

Tried crop(13,3,693,567) but same thing. :(

[Demone]

@scmccarthy
So I can actually feed any crop values an avisynth manages it internally ?

[scmccarthy]

Not exactly. AviSynth2.5a mods everything to 2, so for accuracy you need to feed it only mod2 values.

My hint is that you try this:
Crop(0,0,702,576)
Then resize, followed by another crop if nessesary.
Just resize to 4:3 or if anamorphic 16:9.

Stephen

[Demone]

Thats the script I feed VirtualDubMod with:

LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2Dec3_094.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\DecombYV12.dll")
mpeg2source("D:\Mocambo\mocambo.d2v")
FieldDeinterlace(chroma=true,dthreshold=1,threshold=1,blend=false)
crop(14,4,693,568)
LanczosResize(704,528)

[Guest]

Originally posted by Demone
Is it possible that the Vdub smartdeinterlace is very different from the fieldeinterlace of decomb?
Yes. You have used frame differencing for the VirtualDub filter and FieldDeinterlace does not offer that mode. Try the field differencing in VirtualDub and tell me if the results are closer.

[Demone]

Yes, you'r right, if I use field based option I obtain very similar results.
I must say that at field level decomb is better than smart-de.
What to do ?
I have a heart, cant ask you to implement this :p
btw thank you Donald.

[Guest]

Originally posted by Demone
I must say that at field level decomb is better than smart-de.What do you mean? I don't understand this.
What to do ?
I have a heart, cant ask you to implement this :p
btw thank you Donald. [/B] I don't have any plans for a frame-mode deinterlacer in Decomb at this time.

[Demone]

It seems that juggies are less pronounced in decomb than in smartdeinterlace, using field mode in both.
I will deinterlace in the old way.
Thank you

[Guest]

This thread is closing because the next version will be dual YV12 and YUY2 capable. Please continue in the new thread "Decomb 4.05 for Avisynth 2.5":

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