Thanks a lot Inc.,you solved the problem

From here I use
Avisource("X:\xxxxxx.avi", Pixel_Type="YUY2")
for my captures.

So the "final" script will be like this:
---------------------------
viking

Looks nice!

But do a final test and apply at the very end of your script again a ...

info()
bob()

I would like to know which's the fieldorder now reported by avisynth! and do some framesteps forward in vdub using a movement scene of your capture.... if the result is ok, then NO! back 'n forth behaviour will do occur (if happen,vertical flickering is normal).

AviSynth reports this:

Fieldbased(Separated)Video: NO
Parity: ASSUMING TOP FIELD FIRST

And I looked at the movement scenes,everthing looks OK.
as far as I can see.

--------------------------

viking

I did some corrections to your script:

You should also download the latest kerneldeint.dll, http://gast3.ssw.uni-linz.ac.at/~kp/...eint_1.5.2.zip . There were some bugs fixed, one affected the motion masking portion.

Boulder, one question ...

why do you force after the stupid bobber (bob(x,x)) a reallocation of the fields by 4,1,2??

I think it -was- right as his stream ended up ok?

Also the DC10/DC30 do provide at default TFF streams (only as you also did assume a BFF after the bobbing).

I dont know but does make an assumption of a Fieldordering makes sense in a bobbed state? As the stream in that temprarely state is truely progressive? I only do know those assumeXXX commands placing before the bobber or after the reinterlacer - means when the stream is in interlaced state?

NO straight doubts, but nice questions.


I only remember that discussion between Kika and Scharfis_Brain at Gleitz.de where something like this ended:

bob()
separatefields()
Selectevery(4,0,3)
weave()

... does not change the fieldorder as its compensated by 4,0,3 as bob gots a bug related to an unwanted internal fieldorder change

bob()
separatefields()
Selectevery(4,1,2)
weave()

... does end up with a changed fieldorder

now ...

kernelbob()
separatefields()
Selectevery(4,1,2)
weave()

.. here when using kernelbob() its the other way around as kernelbob() keeps the fieldorder internally ..

kernelbob()
separatefields()
Selectevery(4,0,3)
weave()

... does change the fieldorder.

hmmmm ....



thats why I did first a script using an imported capture of my card/driver by just using .... assumeXXX().bob() ... when I captured the first time, ... to recognise the true order of the fields delivered by my capturedevice/driver.

So in every Avisynth script where I do process an interlaced footage I do apply AssumeTFF() right after the import of a capter based on my capturecard ... so everything is at it has to be.
Avisynth at default DOESNT interprete the fieldorder out of the source! Its just avisynths default! which is used when doing an info() on a simple imported avi in avisynth.
I heared that IF mpeg2 captures are treatenn via DVD2avi .... mpeg2source does provide the right fieldorder flag into avisynth - but Im not shure ... and also here it has to be proofed IF the capturing application does set the flag in the mpeg stream right ....

Interlaced ..... oh oh oh oh oh

I just did that to keep both SelectEvery lines the same (easier to remember in future cases), and to make sure that the stream is TFF when it hits KernelBob as AssumeBFF() followed by SelectEvery(4,1,2).Weave() produces TFF output. It would be easiest if KernelBob used the field order flag set by Avisynth instead of having to enter the order parameter every time

(note:I increased my post above)

Another point to try would be ...

Kernelbob() with a threshold set to ZERO and no other enhancements set should behave the same like Bob(), means no adaptive interpolation.

You could do a test...
v=Avisource(....).assumeTFF() # or the ACTUAL Fieldorder provided by your card/driver
a=v.bob(0,x)
b=v.KernelBob(order=x,sharp=false,threshold=0)
subtract(a,b)

looking at the difference of both bobbers

Next step:

v=Avisource(....).assumeTFF() # or the ACTUAL Fieldorder provided by your card/driver
a=v.bob(0,x).separatefields().selectevery(4,1,2).w eave().info().subtitle("This is the result of Bob()",10,400)
b=v.KernelBob(order=x,sharp=false,threshold=0).sep aratefields().selectevery(4,1,2).weave().info()..s ubtitle("This is the result of kernelBob()",10,400)
interleave(a,b)

... doing a comparison "one after one" of these normaly in a NOP operation ending streams incl. the report WHICH fieldorder results.

Im at office so Im just able to write out of my mind ... without script checking :)

I thought about that zero threshold as well, I'll have to test it. However, my capture script for interlaced footage is already slow enough so I can't bob and reinterlace twice, it would take several hours to finish a 45-min episode

EDIT: btw, ColorMatrix is something which might be useful if the colors are off after encoding

OK, I did some testing.

The difference between Bob(0,0.5) and KernelBob(order=x,sharp=false,threshold=0) is small, unnoticable without using Subtract() but it looks like the edges are the areas of difference.

AssumeTFF().Bob(0,0.5).SeparateFields().SelectEver y(4,1,2).Weave().Info() = TFF
AssumeTFF().KernelBob(order=1,sharp=false,threshol d=0).SeparateFields().SelectEvery(4,1,2).Weave().I nfo() = BFF (WTF?!)

Using AssumeBFF() and order=0 makes both TFF.

If TFF is assumed and I add AssumeFrameBased() after KernelBob, it's TFF (as Avisynth defaults to BFF).

Looks like KernelBob() swaps the field order..

... holy ... In our tests it was the other way around ... but wait! I think we didnt add assumetff() right at the beginning!!!
As many people do forget that avisynth assumes BFF as default when beeing feeded with avis. So it seems thats the other way around, that Kernelbob does change the fieldorder as you said .... hmmmm

These little funny command additions could mess up everything .... yeah! Lets beleive in avisynths internal process *lol
I think thats worth a big testing .... beside that AC3 thing

Actually AssumeFrameBased() belongs to KernelBob(), that was in scharfis_brain's original function. Leak just forgot to add it in the dll version, and I had some strange issues before we noticed that. Maybe they happened because the assumed field order is swapped?

So the conclution is to use the script as it is,to keep right
field order?

But I did tests today with and without bob(),
and I can't see any difference on the final video.Only longer
encoding time.

But another question,whats normal colorspace for DV captures?
When I tried AviSource()Info(),avisynth reported RGB24,
and when I used DirectShowSource()Info() it reported YUY2.
Maybe it is an idea to use pixel_type="YUY2 at this videos to??

I know this is bottom field first video,so the script would be like this(without bob() ):
------------------------
viking

I think the native colorspace is YV12 (I have no DV experience). However, with DV material you get a headache with the different decoders as some of them screw up the chroma upsampling and you need to fix that.

This forum might interest you : http://forum.doom9.org/forumdisplay.php?s=&forumid=59 , especially the reinterpolate420 -thread could be useful.

Interesting reading,my panasonic DV codec outputs only RGB24.
So after reading it seems I have to try ffdshow DV decoder,
that gives 4:2:0 YV12 output when using
DirectShowSource() with AviSynth

----------------------
viking

Does anybody know the difference between the Win TV-PVR 250 and the Win TV-PVR 150 model?

You meant the 350
The PVR 350 is identical to the 250, except it has a hardware MPEG decoder, and TV out.
That's all the difference.

-kwag

Nope, there is also a Win TV-PVR 150 model. I seen it in the stores and it looks just like the Win TV-PVR 250, but I just don't know the difference. I've even asked the people that work there and they don't know either.

Ok, I found the differences in this link:

http://www.hauppauge.com/pages/compare_pvr.asp


1) Which of the first four would you guys go for? Why?

2) Do the MCE models only work with Windows XP Media Center Edition?


I also have in mind of going for this one:

http://www.pinnaclesys.com/ProductPa...26&Langue_ID=7


3) What do you guys think about this one in comparison of the other four?

I can see clearly that the 150 doesn't have MPEG-1 encoder on the chip
So I guess the 150 is a trimmed down version of the 250.

I would go for the PVR-350

-kwag

Thanks kwag.

What gives a better video SVideo, Composite, or Coaxial?

So, what did you think about the Dazzle?