capture vergleichen

Moin grua,
wenn ich nochmal zum Resizen zurückkommen darf, genauer zu Deiner DVD-Rechnung:

Zitat von grua

Setzt man nun in die Formel ht = ha * PARs / PARt ein, ergibt sich:
ht = 686 * 1.094 / 1.094 = 686

Wir müssen nun von hs x vs auf ht x vt resizen, was in diesem Fall hinfällig ist, da sich zufälligerweise ht = hs = 686 ergibt ...

Naja, Zufall würde ich das nicht nennen:
Wenn das Verhältnis gleich bleiben soll (beides TV-PAR) und einer der Faktoren, dann ist klar, daß sich der zweite auch nicht ändern DARF. In diesem einfachsten Fall muß das immer so sein, da die TV-Karte offensichtlich "sinnvoll" arbeitet.

In diesem Beispiel stimmen wir noch überein, aber wenn es ums Bitrate sparen für XViD geht, verstehe ich nicht, wiesoDu die 686x400 + Ränder ganz außer Betracht läßt. Ersparnis der Fläche ist mit 750x438 / 686x400 auch immerhin ca. 20%, und man behält wenigstens in einer Richtung das ursprüngliche Bild.
OK, man erhält die y-Dimension, die ja analog eh Nix wert ist, aber da inzwischen doch fast alles digital verarbeitet wird, sehe ich diesen Punkt noch nicht so ganz ein.

Hi,
auch wenn ich mich zum Rest grade nicht so recht traue, mit dem CaptureGuide ist der hier verlinkte gemeint:
http://forum.gleitz.info/showthread.php?t=14246

Moin,

Zitat

aber wie kann es dann sein, dass ich nach dem encoden mit cce trotzdem bei bitrateviewer und restream angezeigt bekomme, dass der film in bff vorliegt.

Das liegt gänzlich außerhalb meiner Vorstellungskraft..
Poste doch mal das Ergebnis den Bitrate-Viewers.
Sowas:
------------------------------------
Num. of picture read: 1146
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*576
Aspect ratio: 4:3 Generic
Framerate: 25.00
Nom. bitrate: 8000000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 9
Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced
----------------------------------

Gruß Karl

Zitat von Trekkie2

Naja, Zufall würde ich das nicht nennen:
Wenn das Verhältnis gleich bleiben soll (beides TV-PAR) und einer der Faktoren, dann ist klar, daß sich der zweite auch nicht ändern DARF. In diesem einfachsten Fall muß das immer so sein, da die TV-Karte offensichtlich "sinnvoll" arbeitet.

Mit Zufall meinte ich, dass er Glück hat eine Karte erwischt zu haben welche in Verbindung mit 720 "sinnvoll" arbeitet - denn "zufällig" hat er eine Karte erwischt, welche mit einem active capture window von 53.333µs arbeitet und dadurch bei 720 ein Source-PAR von 1,094 ergibt was genau dem Target-PAR einer DVD entspricht.

Hätte er z.B. eine Karte welche z.B. mit 51.56µs active capture window arbeitet und capturt (immer dies Anglizismen ;)) ebenfalls in 720x576 so erhält er eine Scource-PAR von:
IAR = 4/3 * 51.56µs / 52µs = 1.3221
PARs = 1.3221 * 576 / 720 = 1.058
Also Source-PAR ungleich Target-PAR und da muss er schon resizen:

Bei eimen active capture window 51.56µs und 720er Capture hätte er 720 x 52 / 51.56 = 726 aktive Pixel. D.h. er verliert beim Capturen 726 - 720 der eigentlich im PAL-Signal vorhandenen aktiven Bildpixel. Im Gegensatz zu der Karte mit 53.333µs hat jene mit 51.56µs also seitlich keine schwarzen Ränder, sondern zeigt sogar etwas weniger als das orignal ausgestrahlte Bild an.

Angenommen er muss nun nichts croppen (da er ja auch keine seitlichen schwarzen Ränder hat) und möchte das Capture direkt auf MPEG2 / DVD encoden:
PARt * ht / vt = PARs * hs / vs
Wenn man vt = vs setzt (wir wollen ja vertikales Resizen wieder vermeiden), dann lässt sich ht berechnen zu:
ht = hs * PARs / PARt = 720 * 1.058 / 1.094 = 696

D.h. er müsste von 720x576 resizen auf 696x576 und dan seitlich 8 Pixel dranpappen um auf 704x576 zu kommen. Oder 24 Pixel dranpappen um auf 720x576 zu kommen. Für DVD wäre ja beides zulässig und sollte auf einem SAP beides gleich wiedergegeben werden (PC-DVD-Player machen das oft anders (falsch) - siehe Nachbarthread im DVB-Unterforum).

Anderes Beispiel (weils gerade so Spaß macht :)):
53.333µs (wie Hanzos Karte)
Capture aber nun in 704x576 statt 720x576
Ziel DVD --> PARt = 1.094
Aktive Bildpixel: 704 x 52 / 53.333 = 686, also seitlich 704 - 686 = 18 schwarze Pixel. Croppt er diese weg, bleiben 686 x 576.
IAR = 4/3 * 53.333µs / 52µs = 1.3675
PARs = 1.3675 * 576 / 704 = 1.1189, somit ungleich dem Targe-PAR!!!
ht = hs * PARs / PARt = 686 * 1.1189 / 1.094 = 702

Er muss nun also von 686x576 auf 702x576 resizen und anschl. seitlich 2 Pixel dranpappen um auf 704x576 zu kommen oder 18 dranpappen um auf 720x576 zu kommen (beides wird vom SAP identisch dargestellt).

Insofern also wirklich Glück, wenn er bei dieser speziellen Karte (53.333µs) und gewünschtem Ziel DVD mit 720 capturt und nicht mit 704, da er dann nicht resizen muss.

Zitat von Trekkie2

wenn es ums Bitrate sparen für XViD geht, verstehe ich nicht, wieso Du die 686x400 + Ränder ganz außer Betracht läßt. Ersparnis der Fläche ist mit 750x438 / 686x400 auch immerhin ca. 20%, und man behält wenigstens in einer Richtung das ursprüngliche Bild.
OK, man erhält die y-Dimension, die ja analog eh Nix wert ist, aber da inzwischen doch fast alles digital verarbeitet wird, sehe ich diesen Punkt noch nicht so ganz ein.

Ich hatte da hinsichtlich Auflösung ein komplett beliebiges Beispiel gebracht und einfach aus blauem Himmel 512x384 mit und ohne Overscan-Ränder gewählt, lediglich um den Rechenweg zu zeigen wie man dann richtig resizt und croppt. Das war nicht als Empfehlung für 512x384 zu verstehen - es ging nur um den Rechenweg.
Für XviD würde ich GKnot vorschlagen und mich am Bits/(Pixel*Frame) Wert orientieren um ein Gefühl für die richtige Größe zu erhalten. Dann kann man ja wieder manuell weiterrechnen, da ja auch GKnot das active capture window nicht berücksichtigt. Viele GKnot-Guides schlagen z.B. einen bppf-Wert von ca. 0.2 bis 0.3 vor. Mit dem bin ich bisher auch recht gut gefahren.

Zitat von Hanzo Steel

aber dass ich als ziel 704*576 und nicht 720*576 für eine DVD erhalten sollte, habe ich mir schon gedacht, aber weil ich schon zwei filme fertig habe und der dvd author filme mit unterschiedlicher auflösung nicht akzeptiert, bleibe ich für dieses projekt noch mal bei der "falschen" auflösung. beim nächsten mal wird alles besser.

Für eine DVD sind sowohl 704x576 als auch 720x576 gültig. Ein DVD-Player der richtig arbeitet gibt ein Bild von 704x576 vollständig ident wieder wie das selbe Bild welches mit AddBorders(8,0,8,0) auf 720x576 vergrößert wurde. Du kannst also ruhig deine Captures auf 704x576 bringen, pappst dann links und rechts je 8 Pixel mit AddBorders dran.

Zitat von Hanzo Steel

also z.B. AddBorders(8,72,10,66)

aber wenn sowieso keine rücksicht auf macroblock-optimierung genommen wird, warum addest du dann nicht so symmetrisch wie möglich, also z.B. AddBorders(8,70,10,68) (oder sind diese 4 px Korinthenkackerei )?

Bei AddBorders(8,72,10,66) ist zumindest der linke und der obere Rand durch 8 teilbar, wodurch bereits einige CPU-Optimierungen greifen.

Zitat von Hanzo Steel

Wenn mein Ziel jedoch 704*576 ist, und ich bei einer Capture-Auflösung schwarze Ränder habe, sollte ich dann nicht lieber gleich 704*576 capturen? Denn wenn ich dann noch die ausgefransten Ränder abschneide müsste ich doch troztdem wieder auf auf meine 686*438 kommen.

Habe ich in meinem vorigen Post durchgerechnet. Du hättest Resizing gewonnen, da das Source-PAR dann von Target-PAR abweicht. Wäre zwar nicht sooo schlimm, aber muss ja nicht sein.

Zitat von Hanzo Steel

welchen guide meinst du denn genau, hab gesucht aber eine V4 habe ich nirgends entdecken können. Ist das der neue englische, oder der alte deutsche von BaronVlad?

Ja, den neuen englischen (s. Link von Trekkie2 - ich hatte darauf auch in meiner Rechnung verlinkt). Darin ist ein Kapitel enthalten wo beschrieben steht wie man das active capture window ermitteln kann. Auch die ganzen Rechenwege sind da sehr anschaulich enthalten. Aber falls du bei 720 od. 704 Capture tats. 18 schwarze Pixel hast, dann stimmt das mit den 53.333µs schon.

Zitat

Das liegt gänzlich außerhalb meiner Vorstellungskraft..

karl

nimm den CCE 2.70.xx.xx und entferne den Default Hacken bei TopFielfirst, und schon schreibt der CCE jetzt brav bff in den Header.

Auch soll der CCE seit diesen 2.7xxxxx Versionen bff und tff verarbeiten können, ein drehen der Fieldorder per AviSynth also bei bff Material nicht mehr nötig sein.



max

Man kann sich wirklich auf nix mehr verlassen!

Danke für die Info Max.
Kommt davon, wenn man das Neueste nicht immer gleich ausprobiert..
..aber ehrlich gesagt, hab ich auch gar keine Verwendung dafür, da ich den CCE ausschließlich für progressives Material verwende.

Werds mir demnäxt mal anschaun.

Gruß Karl

EDIT: Hab den thread nochmal überflogen, aber hier ist nirgends vom CCE 2.7 die Rede - auch diese komische Anleitung: Die screenshots sind vom 2.67er oder so...

Zitat von Der Karl

auch diese komische Anleitung

Meinst du damit den englischen Analog Capture Guide? Weshalb bezeichnest du ihn als komisch? didaktisch ist er vielleicht nicht optimal aufgebaut, aber m.E. steckt da geballtes Wissen drin...

Hi

karl

ich habe nicht mal den Thread gelesen, wollte es nur kurz ansprechen, laut Cinemacraft kann der CCE jetzt bff und tff .

Getestet habe ich es auch nicht, werde ich auch nicht, da ich ebenfalls nur progressives Material im CCE encodiere, da er in meinen Augen bei Progressiv die Referenz ist, und da ist es eh egal ob nun im Header bff oder tff steht, sofern es sich durchweg um progressives Material handelt ( erst neulich 3 DVDs gehabt die im Abspann eindeutig Interlaced waren -- TDeint Test)

Interlaced macht man am besten mit dem Procoder im FieldModus, ich denke mal dass wirst Du genauso handhaben.


max

Zitat

( erst neulich 3 DVDs gehabt die im Abspann eindeutig Interlaced waren -- TDeint Test)

Die waren aber tff!

Zitat

Interlaced macht man am besten mit dem Procoder im FieldModus, ich denke mal dass wirst Du genauso handhaben.

Yupp - wobei ich "field" bisher nur für DV-Material verwendet habe. Auch mit "frame" schlägt der PC2 den CCE um Längen.

>Komische Anleitung:

Die: http://dvds-kopieren.de/svcdfreak/v.../video.html#4.2 war gemeint.

Gruß Karl

Zitat von Der Karl

http://dvds-kopieren.de/svcdfreak/v.../video.html#4.2

Ok, die ist wirklich komisch

Zitat

Die waren aber tff!

Muss ja, da in den DVD Spezifikationen eindeutig tff als Fieldorder bezeichnet ist, obwohl ich bisher noch keinen Player gesehen habe der meine DV AVI bsierenden bff DVDs nicht abgespielt hat.

Kommerzielle DVDs sind aber immer tff , zumindest ist mir bisher keine einzige mit anderem flag untergekommen.

Zitat

noch eine andere Frage. BV und Restream können nur Mpeg-Files prüfen. gibts ne möglichkeit schon vor dem encoden mit cce das avi-file auf tff oder bff zu testen?

Ich teste das immer so:
http://dvdskopieren.buitink.de/divxboard/thre…did=35&page=1#1



max

[qote=Hanzo Steel]gibts ne möglichkeit schon vor dem encoden mit cce das avi-file auf tff oder bff zu testen?[/quote]guck mal in meine Signatur, da steht wie du erkennst ob tff od. bff vorliegt.

Aber um zu prüfen ob überhaupt wirkliches Interlacing vorliegt hat ja Max in seinem Link schon einen guten Weg beschrieben.

I.d.R. greift auch diese Methode recht gut:

Zuerst versucht man
Telecide(order=0,guide=2,post=0)

Beseitigt dies die Kämme nicht, dann versucht man statt dessen
Telecide(order=1,guide=2,post=0)

Sind die Kämme immer noch vorhanden, dann liegt i.d.R. echtes Interlacing vor, welches du dann untersuchen solltest ob tff od. bff.

karl:
Du schreibst in deimen Aspect Ratio, dass DVD-Player mit 54/59m also PAR 1.0926 ausgeben.
Lt. Berechnung im Capture Guide v4 liegt die PAR einer DVD jedoch bei 1.094. Sind zwar nur ca. 0,12 %, aber als Techniker will ich das natürlich möglichst genau wissen - wie kommt es zu dieser Diskrepanz?

Moin,

der Unterschied ist rein akademischer Natur, denn wie "breit" die Pixel wirklich sind, weiß kein Mensch

Die 1.094 bzw. 1.0940171 stammen aus dem Verhältnis 768/702.
Woher ich die 1.0926 damals hatte, weiß ich jetzt nimmer - das war irgendwie ein gängiger Wert, den alle benutzten. Stammt vermutlich aus den Disskussionen mit shh, mb1 und Kika. Wenn ich mich recht erinnere, war da die "Definition" der "richtigen" square-Auflösung nicht 768*576, sondern 767*576 - also 767/702=1.09259...
..welcher Tatsache/Vermutung/Irrtum/.. das geschuldet war, bekomme ich aber nicht mehr zusammen.

Gruß Karl

Danke für die Info - ist ja wirklich rein akademischer Natur