Boulder wrote:
Yes I did.

Problem solved,after searching,downloading and
trying several codecs,I found one that let me use
AVISource() for captures in AviSynth,
the name is "AVIcodec v. 1.1.0.4",and can be found
on this page:
www.codec-download.com

So I think its goodbye to DirectShowSource() now.

Boulder;
When I loaded the info() test with AVISource() after the codec
installation,colorspace reported was YV12.

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

viking

I'm not 100% sure which one would be better as it would be good to know the native colorspace. There's nothing wrong with using DirectShowSource, it's just that it used to cause issues but with the latest AviSynth versions there have been no known problems. I think you might want to ask incredible about it, if I remember correctly he has/had a DC30 so he might be able to advise you better.

The DC 10/30 series and their driver do capture in 768x576 or 640x480 directly. Also you can use 384x576 as its a half PAL resolution out of PAR 1:1 768x576

- two possibilities

a) The driver caps using 14.769mhz and 52.000µ (14.769*52 = 76

b) or uses 13.5mhz and 52.000µ (=702) AND scales up to 768 width.

The purpose of the DC Series wasnt only to capture but also to do a hardware playback DIRECTLY to TV specs which IS 13.5*52=720, so I do assume the option b) "could" be the internal process of the driver.

Anyway....

As you got NO option to capture at 704 width for instance, YOU SHOULD keep the full PAR 1:1 capture width, means 768!!

So capping at 768x576(PAL) or 640x480(NTSC) is OBLIGATORY!
Cropping out trashy edges will be done ALWAYS afterwards in Avisynth or Vdub.

The vfw Driver: Yep, right, the delivered Pinnacle mjpeg decoder "could" be only a directshow one. But no Problem, as you should look out for the "PicVideo mjpeg codec". That one comes as a vfw AND directshow codec, so no Problem if opening that DC resulted mjpeg stream AS IT IS in a ...

directshow decoding environment

- Mediaplayer
- Graphedit
- Avsiynths "Diretshowsource()"
- TmpgEnc's directshow import
- etc....

vfw decoding environment

- Vdub
- CCE
- Avisynths "Avisource()"
- TmpgEncs "Avi file reader"
- etc ...


If you want to be precise ....
The active ITU compilant capture window of FULL pal at square pixels is 702, not 704 ... the mega-correct way would be capping at 13.5mhz at 52.000µ and adding to the 702 result 1pix right and 1px left of simple black to get a 100% right AR .... but thats like "sex between ants" as they say in germany

BUT! ....

You have to look at the card specifications at WHICH µs the incoming signal will be sampled AND WHAT will be used as µs by your outputting Device like a SAP.

Example:
A Cinergy400 from Terratec WITH the orig Cinergy driver used, captures in an ITU compilant signal way as followed ...

13.5mhz are used and sampling is done by 52.148µs! The result is 704 (13.5*52.14

Now that 704x576 Signal will be processed by your DVD SAP as followed ..

Playback at 13.5*52.148 = 704

So that Cinergy Card in combo with its driver does directly output a 1:1 compilant stream width for playback on a DVD Device at cropped D1 (=704 width)


Also do have a look at that VERY excellent doom9 capture guide, where the co-author wilbert has listed some parameters of some card/driver combinations and HOW you do resize/crop in the mhz/µs way ... which would be the total right (remember the ants ) way.
Thats for instance very important in case of a capture to mpeg4 encoding! As its possible to fine-adjust PC monitor proportions, but TV Screen Proportion adjustments arent available for many TVmodels like for PC Monitors

Also its a big compromise when trying to get a 100% AR!
Because if your card just samples 2-4px incorrect, you must ask yourself ... "Do I want to end up in a 100% AR but in a blurrier result cause of the interpolation during a resizing so I do correct these 2-4px OR do I want to end up in a sharper orig image but 1% AR Error"

I recall that a registered PicVideo codec v2 (there's v3 available now) was installed with some shareware capture application and the codec stayed even if you uninstalled the capture app itself! I just don't remember the name, maybe it was ShowShifter? I even tried searching at Doom9 and the VDub forums but couldn't find it.

Also FFdshow does play back "mjpg" FourCCs in directshow environments AND also in vfw envirenments by its internal ffdshow-vfw engnine.
BUT ... Im not shure if its capable to decode interlaced mjpeg footages correctly! The Encoding engine of that libavcodec based mjpeg codec CANT encode fieldbased and stripes-errors will be the result out of a ffdshow mjpg interlaced input encoding.

I also wouldn't trust ffvfw with interlaced sources.. it's best to stay at those that surely know how to deal with the material.

Hello,I was reading a lot of guides/topics about resolutions/
A/R /active picxel area/DAR/PAR/sampling..... yesterday.

Inc. wrote: I haven't found out which µs the incoming signal will be sampled,
This is the only specs. I can find:
-Plug and Play 32 bit PCI board with bus mastering interface
-Video inputs:1 composite and one S-Video
-Video outputs:1 composite and one S-Video
-Video Capture and Output:
-Video Format:PAL/SECAM/NTSC(SECAM:input only)
-Frame Rate:Up to 25 frames per second/50 fields per second(PAL)
-Frame size:Up to 768x576
-Compression:MJPEG,user selectable from 3:1 to 100:1
-MicroMV support requires Win XP

About PICVIDEOv3codec,yes its installed,have a look HERE
for the settings,there is also a picture of the specs.for my SAP.

I found this article at
http://www.uwasa.fi/~f76998/video/conversion/:

Sooo...There won't be any more capturing at 720x540 for me I guess

But a question,maybe teoretical, but I have a lot of captures
in 720x540,and I want to get them on a KVCD/KDVD.SO when
I load the captures into FitCD the program reports(of course) a
real aspect of 1.3333,resizing to,lets say 624x512 also have a real
aspect of 1.3333,so if I use 624x512 with black borders all the way
around the picture I can put it on a 720x756 KDVD,and at the same
time get all active pixels in the 720x540 picture.

Or is it a better way to do it Its a lot of work capturing all the video once again

Take a look
HERE and you see what I mean(I hope)

But as I said,Ill capture in 768x576 from now on.

Thats all for now

Anyone that can point me to some kind of "how to crop noisy edges
with Virtual Dub" article?I havent found any

Thanks

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

viking

Well in case of a 720x540 capture cropped OUT of real 768x576 signal by the driver, that simply means cropped each side of the width by 16 and each side of the height by 8 thats called the "cache" in a PAR 1:1 state.

So the real gain is that you reduce a bit the Artifacts at the SAME MB/sec rate your capturing in.

Your link tells the truth (IMHO) as THAT input IS PAR 1:1 (like XVID/DIVX):


BUT!!!!: Your result gots too much overscan (but AFAIK that was your intention, right?) as Addborders(48,32,48,32) should never go above Addborders(16,16,16,16) in case of playback on a TVdevice (just a reminder)

And also DO UNCHECK ALL RGB CHECKBOXES! As your input is YUY2 and only should be changed IF filters do need another colorspace ... and at the end ONLY use ConverttoRGB24() in case of using TmpgEnc for encodig, .. or in case of CCE ConverttoYUY2() !!

BTW: Your PAR 1:1 Captures are almost prediscinated to be encoded using DIKO! I recommend you to have a look at it as its a great tool to get also PAR 1:1 captures on one DVD

Yeah,DIKO is great,have tried it.
But I learn more of doing it the "old fashioned way",i.e.
VirtualDub -FitCD-AviSynth-TMPGEncPlus-TMPGEnc DA-Nero.

Yes the heavy borders was my intention.IF I want to present
my videos om TV with visible black borders all the way around,I have to go above Addborders(16,16,16,16).

According to the scripts from FitCD,I only use the rezise and addborders
line from it.

But a simple question after all my reading,when source is
1.3333 and rezised movie is 1.3333 everything is ok?Right?

when source is 1.8234 and rezised movie is 1.8234,its ok?

When source is 1.8243 and rezised movie is 1.8379 I got a
A/R error of 1.0075% am I right IF yes I think i have understood
something

Thanks
--------------------
viking

The same output AR as the INPUT AR "would" be optimal.
BUT as mostly we do change from incoming PARs to outgoing PARs, its inevitable to perform a compensated minimal cropping by fitcd to KEEP the output AR as most accurate as possible! And still you often end up with a minimal AR Error wich wont be noticable on the final viewing device.

Like Muaddib statet, you can a) perform a Pan-scanning by zooming the picture when INCREASING the height by entering the resize buttons (like if you would like to Pan-Scan a movie from 2.35:1 Cinemascope to 1.85:1 Widescreen).
Or ....b) performing a Zoom-out of the screen (as you like to) by decreasing the size at the resize buttons.

Ok Inc.,Ill think I get your point.

Let's say we want to to do a backup of a 720x576 DVD to
704x576 DVD.Source real aspect is 1.3675,using target 704x576 with
one block overscan the movie is rezised to 688x560 ,and that
will give us a target real aspect 1.3441,and the A/R error will
be 1.01% or something like that.And that small error we cant see on a TV.
(Back to the ants having sex )

Thats right?

All calculations is done with FitCD.

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

An AR Error 1.01% is within the tolerance .... and maybe a noticable value for the ants (IMHO)

And what comes to determining the crop values with VDub, load the clip in VDub, add the filter "null transform" (in fact just about any filter will do), click OK and choose 'Cropping'. Get the correct values and feed them to FitCD and add them to your script. You should keep some basic points in mind when cropping, see the Avisynth documentations Crop page.

Yeah,I figured that out Boulder.

So I captured at 768x576 yesterday,loaded the clip into VDub Mod,
cropped off some noisy edges,and created a script like this:

Then I loaded the script into FitCD,choosed "No Cropping" as you
said,and with one block overscan I came out with this
resize/border lines:
The A/R error for this operation was 0,44%.

With two blocks overscan I got this values:

The A/R error here was -0,11%.

I've made test encodings with both options,and it looks OK on my TV.

So back to the colorspaces...

When I load :
AviSource("G:\Capture 768x576\Video 1.avi")
Info()
In WMP I get the following values:

FRAME: 524
COLORSPACE: YV12
WIDTH: 768 HEIGHT: 576
FPS: 25
FIELDBASED (SEPARATED) VIDEO: NO
PARITY: ASSUMING BOTTOM FIELD FIRST
VIDEO PITCH: 768 BYTES
HAS AUDIO: YES
AUDIO CHANNELS: 2
SAMPLE TYPE: INTEGER 16 BIT
SAMPLES PER SECOND: 44100
CPU DETECTED: x87 MMX ISSE SSE 3DNOW 3DNOW_EXT

When I load :
DirectShowSource("G:\Capture 768x576\Video 1.avi",fps=25)
Info()
In WMP I get the following values:

FRAME: 524
COLORSPACE: YUY2
WIDTH: 768 HEIGHT: 576
FPS: 25
FIELDBASED (SEPARATED) VIDEO: NO
PARITY: ASSUMING BOTTOM FIELD FIRST
VIDEO PITCH: 1536 BYTES
HAS AUDIO: YES
AUDIO CHANNELS: 2
SAMPLE TYPE: INTEGER 16 BIT
SAMPLES PER SECOND: 44100
CPU DETECTED: x87 MMX ISSE SSE 3DNOW 3DNOW_EXT

And Reading on AviSynth homepages told me this:
So I don't know whats the correct colorspace for this captures.

But I make test encodings,one with AVISOURCE() and one
with DIRECTSHOWSOURCE(),using TMPGEnc,so I added
ConvertToRGB24() at the end of the script,and my eyes could
not see any difference on the encoded movies.
Anyone have any ideas what's the best one to use?

So then I tried to make a complete script for this clip,using
Boulder's script for interlaced sources,it went out like this:
And the results was Ok,
maybe try some other filters will give even
better results.More testing tomorrow.

So if anyone see something in my post here that doesn't
make sense,tell me please.

Thanks

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

viking

I tweaked your script a little:

I switched to DirectShowSource and replaced UnDot() with RemoveGrain(mode=2) and moved the ConverttoRGB24 line before reinterlacing, which will give better quality. I also added AssumeBFF() to the script to make sure the result is TFF.

It goes like this:

AssumeBFF() + SelectEvery(4,1,2) = TFF video
AssumeBFF() + SelectEvery(4,0,3) = BFF video
AssumeTFF() + SelectEvery(4,1,2) = BFF video
AssumeTFF() + SelectEvery(4,0,3) = TFF video

As we are not sure which is the original colorspace, I recommend sticking with the codec that the card's software installed. Thus DirectShowSource should give the best results.

Also you have to watch out WHATS used when playing back that stream via Directshowsource (as said, when PicVideo is installed it also comes with a vfw-compount which is used by Avisource() ).

Directshowsource is tricky! (seeking, preview!-syncing, Dshow chain order/inserts by the system).

Do ope your source in Graphedit and you see how the Dshow chain is build by your system.

@Inc.:Ok,I opened the .avi file in GraphEdit.
The result(chain) is HERE
on top of the page.

@Boulder,your "new" script give great results,I've made
a test encoding now and the quality is very good.

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

I think you should uninstall PicVideo v3 so that Pinnacle's own codec is used (check with GraphEdit).

So I uninstalled PICVideo 3,uninstalled AviSynth,restart PC,
installed AviSynth,restart PC,then tried

AviSource("G:\Capture 768x576\Video 1.avi")
Info()

and get that "Could not decompress frame 0" error.

And so the funny part, ,when I load:

DirectShowSource("G:\Capture 768x576\Video 1.avi",fps=25)
Info()

in WMP it reports colorspace RGB32

screenshot from GraphEdit after uninstalling PICVideo
HERE

On the last screenshot there is a "color space converter" I noticed.

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