Script für neuen Analog Capture Guide v4

Hast du schon mal GripFit() ausprobiert?

http://forum.gleitz.info/showthread.php?t=13850&page=2&pp=10

Hi,

also ich finde das script nicht schlecht, nur eine Frage:
Warum soll die horizontale Auflösung ein vielfaches von 32 sein?

Überhaupt bin ich mir in letzter Zeit nicht sicher durch was die Auflösung teilbar sein soll?
vielleicht etwa so:
DVD/(S)VCD: 16
XviD: 8
XviD mit Qpel: 4

...cya

Schones script, sehr schone.

Zitat

Weder GripFit noch FitCD/Fit2Disc können dies berücksichtigen, da das active Capture Window d. Chip/Treiber-Kombination ja nicht bekannt sind.

Ich habe die source of fitcd 1.05. Wenn ich Delphi haben, versuche ich das zu andern.

Zitat von grua

hab mir GripFit noch nicht im Detail angesehen, auf den ersten Blick ergeben sich aber für mich folgende Fragen:

1) PAR des Ziels: In der Vorgehensweise lt. Analog Capture Guide v4 (s. mein Script oben) wird das PAR des Zielformats berücksichtigt (DivX/XviD PAR = 1, SVCD/DVD PAR = 1.094).
Welches Zielformat-PAR verwendet GripFit?
Und welches Zielformat-PAR verwendet eigentlich FitCD/Fit2Disc - vmtl. stets PAR = 1.094 für SVCD/DVD?

Soviel ich weiss nimmt GripFit (laut c++ code) bei PAL Targets folgende PAR's:

720x576 = 128/117
704x576 = 128/117
544x576 = 512/351
352x576 = 256/117
352x288 = 128/117

FitCD wird dies wohl auch tun, wobei bei non ITU 720 Input (Meine Philips7134 z.b skaliert lediglich auf 720, also keine eff. 9+702+9) die generic PAR verwendet wird.

Eben laut der Bibel:
http://www.uwasa.fi/~f76998/video/conversion/#conversion_table

GripFit hat lediglich einen kleinen AR Fehler, wenn NTSC 528 oder 544 als Traget Width ausgewählt wird, da die Target PAR nicht korrekt ist. Laut R6D2 aus Doom0.org (ich glaube so heisst er).

Ich schlage mich auch schon seit wochen mit den Threads bei Doom9 und vielen Links herum, wo denn nun die Lösung ist.
Aber letztendlich führt alles wieder auf den Link von Jukka Aho.
Ob 52.00000, 52.14815 oder 53.33333 bei 13,5 MHz .... alle besitzen eine aktive PixelArea von 702x576?

Für mich heisst dies bei z.B. einer mit 53.3333 µs arbeitenden Karte:
53.33333x13.5 = 720pix ... mit einer activen Pix Area von 702, somit lautet dies für mich (und hier ist eben auch eine kleine Frage drin), dass diese Karte ITU konform die 720 captured??? Und nicht lediglich die Activen Pixel auf 720 skaliert, denn dies macht meine 7134er, welche ja laut Forum eben mit 52.14815 captured. Folglich 52.14815x13,5 = 704 mit 702 activen Pixels. Also lediglich 2 pixels drüber. Würde ich eben mit dieser 7134er Karte direkt 720 Capturen, müsste ich mit einer generic PAR resizen (ITU in FitCD Off).
Das erklärt auch für mich (laut Capture Guide, wenn ich nicht falsch liege), weshalb ich mit jenen 720 via 7134er gecapture'ten pixel direkt auf 704(702) oder 352(351) width resizen kann. Wie eben auch mit 704 Sources, da eben jener Treiber lediglich auf 720 skaliert.

Und jetzt kommt eben das was mich stutzig macht: Wenn ich z.B. mit einer 53.3333 µs arbeitenden Karte auf 704 beim capturen gehe, würde sie dann auch jene 9+...+9 lediglich auf 704 runter resizen und nicht croppen??? Denn dann wäre dies eben der Knackpunkt. Hmmmm .....


@ Wilbert
In case of a capture chip based correct internal µs related resizing in FitCD, ... that would mean you would have to add a "used Capturecard chip" Gadget, ... right?
AIK there's still a bug in that old FitCD release related to the correct NTSC 528/544 Target PAR, but maybe Im wrong.

Greets
Inc.

I will read the german part of your post tomorrow, it's too late for that now.

Zitat

In case of a capture chip based correct internal µs related resizing in FitCD, ... that would mean you would have to add a "used Capturecard chip" Gadget, ... right?

Sort of. We just need to add an active capture window box. That's all.

Zitat

AIK there's still a bug in that old FitCD release related to the correct NTSC 528/544 Target PAR, but maybe Im wrong.

Oh, I don't know. I will ask shh about this.

Zitat

Und jetzt kommt eben das was mich stutzig macht: Wenn ich z.B. mit einer 53.3333 µs arbeitenden Karte auf 704 beim capturen gehe, würde sie dann auch jene 9+...+9 lediglich auf 704 runter resizen und nicht croppen??? Denn dann wäre dies eben der Knackpunkt. Hmmmm .....

Remember a cap at 720x576 or 704x576 is just a scaling of each other.

I will adjust example 1 in section 5.6:

1) Say you want to make a DivX/XviD (PAL). Full PAL TV on a PC gives 52 µs * 14.7692 MHz = 768 pixels, ending with 768x576. Your "SAA7108, Nvidia with a WDM driver" has a capture window of 53.33 µs. So, how many PC sized pixels fit in the capture window? 53.33 µs * 14.7692 MHz = 788 pixels. So you have two options here (however, if you can't capture at arbitrary sizes you only have one option):

a) Cap pixels that are at or close at the target size. That's not always possible.

b) Capping at another resolution and resize to the correct pixel size afterwards. If you want that, cap high, say 704x576.
However, your card caps only 53.33 µs, so you need less pixels to make up the difference with the 52 µs a PC needs for correct AR. How many?
(52 / 53.333) * 704 = 686 in total.

So, remove 704-686.4=17.6 ~ 18 black pixels of your 704x576 cap
[*]. You now have 52 µs of info in 704 pixels. Resize the resulting 686x576 to 768x576 or a scaling of it.

[*] If you would have capped at 720x576, you get (52 / 53.333) * 720 = 702 and you have to remove 720-702=18 black pixels of your 720x576 cap. Resize the resulting 702x576 to 768x576 or a scaling of it.

I hope it's a bit clear ?

Bei allem was du oben gerechnet hast, kommts aufs selbe bei raus wie ich es oben gemeint habe.

53.3333 Capturing at 720px = ITU conform

bedeutet eine active px area von 702, welche zu 1:1 PAR targets direkt resized werden kann.
Somit stimmen die 702x576 zu 512x384.

Deine "1.2) PAR berücksichtigung", sprich auf erst 526x384 und sodann mit 14px croppen ist das selbe in grün (vorsichtig gesagt IMHO):

720/526= 1,3689
18/1,3689 = 13,15 (MOD2 = 14)....

Letztendlich kommen wir ja immer wieder hier hin:
http://www.uwasa.fi/~f76998/video/conversion/#conversion_table

720x576 @ 53.33333 = 702 active Px Area (PAR 128/117)
704x576 @ 52.14815 = 702 active Px Area ( dto )
702x576 @ 52.00000 = 702 active Px Area ( dto ) ..... ist ja klar

702x(128/117) .. also auf PAR 1:1 entzerrt = 768
768x576 = DAR 1,33333

512x384 = DAR 1,33333

somit stehen die 702x576 (PAR 128/117) im direkten Verhältnis zu 512x384 womit jene activen Px der gecaptured'en Auflösung hin skaliert werden können.

Somit ist bzgl. FITCD etwas "Handarbeit" angesagt und man muss sich über das Active Capture Window in [µs] seiner Karte im klaren sein. Aber da man ja wunderbar in den "Film Pixel" Fields manuell jene activen px area Werte eintragen kann, wäre das kein Problem. Wenn du also ein 720px 53.3333 capture hast, stellst du in Film-Pixel 702 ein und es wird richtig resized. Genauso bei einer Terratec Cinergy 7134 .... dort die 704 in den "Film-Pixel" auf 702 croppen ... und es wird richtig resized.

Aber jetzt kommt der PAR 1:1 Target Knackpunkt, welchen du richtig bemerkt hast, denn den kann man nicht mit individuellen Resolutions in FitCD festlegen.

Trick:
Lade z,B dein 7134 capture mit 52.14815 und 704width und stelle wie gesagt, die FilmPixel auf 702x576! = active px
Sodann stellst du unten bei "Destination" auf "1:1 Monitor" denn FitCD berücksichtigt somit die XVID Target PAR!. Das resizen nimmst du nun mit dem vertikalen "Resize" adjuster vor (MOD16 oder 32) und du wirst sehen, welche "bekannten" mpeg4 Auflösungen da rauskommen.

Im fertigen Avisynth Script unten beamst du einfach die Addborders(...) weg und hast somit dein fertiges avs resizing script für XVID.

....... aber vielleicht habe ich ja auch den grossen "Gong" übersehen, denn manchmal sieht man den Wald vor lauter Bäumen nicht. Daher bin ich an deinem Feedback interessiert .. da ich nicht in XVID PAR 1:1 enkodiere


PS:

Ich sehe deine Bedenken gingen in Richtung GripFit, sorry.

Aber ich "vermute", dort hat Ross Thomas eine "detection" eingebaut:

Auszug aus dem Code von GripFit:

{
  		dest_par = DeterminePAR(dest_standard, dest_dim);
  		if(0.0 == dest_par)
 			env->ThrowError("GripCrop: Unrecognized destination frame size");
  	} else
  		dest_par = 1.0; // Assume square pixels when only height is defined

Versuche mal mit gripfit "nur" die höhe der Target anzugeben (klingt verrückt), aber vieleicht klappts :hm:

incredible:

Wir haben ja vergleichbare Capture-Karten. Kannst Du mal Deine Fit2Disc-Einstellungen als Screenshot posten? Interessiert mich mal.

Tja, ist nix besonderes.

Ich habe meine Crop Rounders alle auf 2 und die Resize Rounders auf 16.
Beim Import des Philips 7134er 704width captures belasse ich ITU checked.
Sodann bleibt die Crop Area bei 704x576, was bei einem 704x576 (DVD) Target richtig ist, da beide (704er input und 704er Target) die selbe active Px Area und auch die selbe PAR haben.
Ich gehe lediglich hin und croppe die unsauberen Kanten der Source weg, indem ich bei "FilmPixel" die Area und die x,y Koordinaten eingebe.

Fit2Disc habe ich nicht, da ich immer manuell die Source croppe und mir somit FitCD ausreicht.

Ich habe mir mal das neue FitCD angesehen und es sind dort erheblich Änderungen erfolgt. shh scheint nun generell die resized Target Height aus der Relation von entzerrten(PAR) Target Width geteilt durch cropped Source DAR zu ziehen, demnach bekommst du bei 720 ITU input und direktem 704 output keine reine 720-cropped-to-704 raus bei beibehaltener 576er Höhe. Hier wird nun das gesamte Bild, also die gesamten 720 auf 704 DAR basiert gestaucht, was sodann eine Höhe von 560 ergibt, welche wiederum am Schluss auf 576 ge-padded wird.

D.h. bei einem 720er DVD input, wo komplett Filminformationen über die gesamten 720px verfügbar sind, macht das Sinn, da dadurch alle Filminformationen bei einbehalten der DAR vohanden bleiben.
Wenn du aber nun ein 53.333 Capture nimmst und dieses vorher NICHT via "FilmPixels" Feld croppst, wirst du eben jene "out of bounds" TVArea (also die 9+9px von720px) mit in der 704er Target drin haben.

Und DA liegt eben der Haken, dass man FitCD bei Capture Inputs mitteilen sollte, WELCHER Chip und Treiber da verwendet wurde, damit sowas nicht passiert

---- alles (wie immer) mit dem Zusatz "wenn ich mich nicht irre"

Hi, muss mich mal einklinken... ;D

FitCD v1.05 hat in der Tat noch ein paar aspect-ratio-bugs, die ich leider nicht mehr genau im Kopf habe.
zB stimmt das 3/4-DVD für die Quelle nicht, weil's ja 524xYYY und 544xYYY gibt. Beide DVB-Auflösungen scheinen ein von 720x576 runterskaliertes Format zu haben, und sie haben auch nicht genau 3/4-DVD PAR.
Leider gibt's mit der alten v1.05 auch einige Schwächen, wenn man mit interlaced-Quellen arbeitet. So gibt's da zT field-swaps, oder Avisynth weigert sich ein Skript anzunehmen, weil Cropping-Werte nicht an den Farbraum angepasst sind.

Leider habe ich keine Capture-Karte und wurde mit dem Problem noch nicht konfrontiert. Somit kann ich euerem Problem auch nicht genau folgen. :cool:
Was würde denn genau helfen?
Soll noch ne Anzeige "sampling matrix width in µs" rein?
Muss die vom User veränderbar sein, oder reicht's ein paar neue Werte in die Pixelform-Box reinzunehmen?

Da isser!

Also am besten wäre es, wenn deine Input-Combo-Box Gadgets noch zusätzliche Einträge bekämen. Also zu den "1:1", "DVD720", "DVD704" .... etc etc etc.
Solche Einträge wären dann entweder z.B "52µs Capture", "53.33333µs Capture", "52.14815µs Capture" etc.

Da gibts nur ein kleines Problem:
Welcher User weiss denn wie seine Karte captured, also mit welchen µs ?!
Demnach müsste man Wilbert fragen, welche Produktnamen (z.B. TerratecCinergy, PCTV Rave, ... etc etc etc.) .... nur dann gibts ja auch ein problem mit welchem Treiber sodann eine z.B. 878 karte betrieben wird.
Summasummarum, alles Faktoren die berücksichtigt werden müssen.

Mein Vorschlag (nach dem ich das jetzt geschrieben habe):
Nehme in die Input PopUpBox sodann wie o.g. neue Einträge mit auf, welche eben "Capture XXXX µs" heissen (s.o.).

In deiner ReadMe kannst du sodann schreiben, welche Karten mit welchen Treibern welche µs haben. Und da dies für dich aber eine irre Recherche darstellen würde. Reichts wenn das z.B. in einem Thread bei Doom9 etc. behandelt wird. Jenen Link kannst du in die readme oder in einen aktve-Hyperlink Text in FitCD unterbringen.
Dort in jenem Thread werden dann wohl die Cracks sagen, welche Karten mit welchen Treibern welche Einstellung brauchen.

-----------

Mir ist noch was kleines aufgefallen, als ich gestern eine 768px Width / 2.35:1 PAR 1:1 Avisource eingeladen habe und auf 352x576 Target mit Overscan=2! gehen wollte, wurde irre viel an der Soure Width abgeschnitten. Klar: cropped DAR muss ja Target DAR soweit wie möglich entsprechen.
Ich habe mir gerade einen Resizer für Mencoder Commandline Outputs geschrieben (Referenz Jukka Aho und das PDF von DerKarl) und zudem einen "Barrier" eingebaut, welcher zudem drauf achtet, das selbst die Cropped DAR nicht zu sehr von der SourceDAR abweichen sollte, was ein zu starkes cropping der Source verhindert. Die relative RoundX höhe der "Resized" Target height, wird dadurch natürlich etwas kleiner, aber die MovieArea ist weitgehend erhalten.

> Solche Einträge wären dann entweder z.B "52µs Capture", "53.33333µs Capture", "52.14815µs Capture" etc.
> In deiner ReadMe kannst du sodann schreiben, welche Karten mit welchen Treibern welche µs haben

Hört sich gut (und einfach zu implementieren) an.
Bei der popup-Hilfe kann ich ja noch ne generelle Anzeige der Pixellänge in µs hinzufügen.
Ich spekuliere nur gerade, ob bei dieser Unterscheidung die ITU-Box überhaupt noch Sinn macht. Ich kenne keinen, der DVDs auf Korrektheit der aspect-ratio analysiert, also diesbzgl. die ITU-Box setzt oder nicht. Also ist sie nur für die Capture-Leute interessant - aber nach Einführung der "Capture µs" wäre die eh überflüssig.
Ich werde bei Gelegenheit auch die überholte pseudo-Erkennung von ITU-oder-nicht bei falsch skalierten DivX-AVIs u.ä. raustun. Die ist für "neuere" Quellen wie 524x576 noch nicht angepasst, und stimmt auch nur zu 80% - der User muss also sowieso aufpassen.

Ich baue gerade sowieso an den aspect-ratios rum. ZB wird jetzt das ganze "Pixelform" zu der üblicheren PAR, also dem Kehrwert. Leider habe ich damit noch einige Probleme, sodass eine Version mit den capture-µs etwas dauern kann.

> Mir ist noch was kleines aufgefallen
> irre viel an der Soure Width abgeschnitten

Ich kann nicht folgen, was genau da verkehrt läuft. :cool:
Das "irre viel" könnte auch ein bug sein. Für die Analyse bräuchte ich dann noch die eingebenen Werte und die möglicherweise falschen Ausgaben von FitCD.
Ich habe mal die aktuelle FitCD v1.2.3 hochgeladen (u.a. mit support für die neuen D2V-Projekte). Vielleicht läuft's mit der Version etwas besser.
http://shh.sysh.de/files/FitCD_v123.zip
Release-Note bringe ich noch raus. Hatte noch keine Zeit dafür.

> welcher zudem drauf achtet, das selbst die Cropped DAR nicht zu sehr von der SourceDAR abweichen sollte, was ein zu starkes cropping der Source verhindert. Die relative RoundX höhe der "Resized" Target height, wird dadurch natürlich etwas kleiner, aber die MovieArea ist weitgehend erhalten.

Öhhh.... wie meinen?
Eigentlich geht das nicht, ohne die aspect-ratio des Ziels zu verbiegen.
Die aktuelle v1.2.2 hat eigentlich schon "optimales" cropping drin. Es wird doch schon je nach der Beschneidungsgrösse entschieden, ob "max width" oder "max height" optimal wäre. Dementsprechend wird bei "accurate" auch optimal gecropped. Klappt das nicht richtig?

Zitat

Da gibts nur ein kleines Problem:
Welcher User weiss denn wie seine Karte captured, also mit welchen µs ?!
Demnach müsste man Wilbert fragen, welche Produktnamen (z.B. TerratecCinergy, PCTV Rave, ... etc etc etc.) ....

1) tabel in sektion 5.4

2) um es sich feststellen: http://www.doom9.org/capture/capture_window.html

Zitat

tabel in sektion 5.4

Perfect!
Da wäre dann der Link shh.

@ Wilbert
You might think I dont read your nice guide, but the truth is that (due to the intensive recent days programming that mencoder resizer) .... I dont see the forest (i.E. this nice Table in the guide) cause of too many trees (maths in Resizing)... as they say in German.

Ja, genau, die 704 auf 702 active pix croppen und das machst du mit den input Feldern von "FilmPixel". Ich sehe gerade, die neue Vers. von FitCD hat dieses Felder FilmPixel nicht mehr. Daher musst du dort in dem neuen Cropping Layout links un rechts jeweils 1 pixel croppen . Sodann steht unten automatisch Crop 702 576, da wird also nix zu 698 gecroppt! Ich habe Fit2Disk nicht, sondern dies mit FitCD gemacht.
Ich sehe geradu, du gibst die target size bei destination ein, das geht nicht! Lasse diese bei 768x576 1:1 ... die targetsize erhälst du sodann wenn du im "Resize" Feld den vertikalen adjuster soweit veränderst, das deine 512x384 auflösung kömmt.

# -= AviSynth v2.5.4.0 script by FitCD v1.2.2 =-
AVISource("G:\goetter.avi")
BicubicResize(512,384,0,0.6,2,0,702,576)
AddBorders(128,96,128,96)
#Trim(0,433088).FadeOut(150)

Wie gesagt, dann müssen eben nur noch die Addborders manuell gelöscht werden.