Capture Tutorial (beta) von Der Karl

[bergH]

Tach auch !
Bei einer sehr anregenden Off-Line Diskussion mit der Karl (u.a ging es um alte U-Board Threads), bekam ich von ihm ein Tutorial, an dem er arbeitet.

Unter den Moderatoren wurde schon angeregt darüber diskutiert, weshalb wir Euch das Ganze nicht vorenthalten wollen.

Ich bitte um sachliche Diskussion.
(Wir behalten uns vor unsachliche Beiträge zu editieren/löschen! )

Beta Version gelöscht, da endgültige verfügbar.
(BergH 04.10.2002)

Endfassung Capture Tutorial für Dummies ; von Der Karl
_________________
Gruß BergH

[bergH]

Was bisher geschah :
(Gekürzt und editiert bei BergH)

Andreas 21.07.  14:24
Zitat  
Problem ! Er berechnet die 720x576 er DVD mit 1,0666. Das hatten wir schon und haben ja festgestellt, das es falsch ist, oder? Daher auch die 1,0925, denn der Fernseher und der DVD Player machen es so. Wenn nicht, dann ist mein Aspekt ratio Artikel definitiv falsch.

Gruß
ANDREAS  


BergH
21.07. 14:33
Zitat  
tach auch !

Hallo Andreas!
Er nennt doch die 1,09***, oder.(Allerdings auch die 1,06**)

Also ich werde mich aus der Diskussion raushalten, denn ich weiß viel zuwenig darüber.

Verständlich geschrieben ist es aber und die Bilder zum Overscan erklären den OS wirklich gut !

Andreas 21.07   14_00
Zitat  
Also, soweit ich weis, rechnet FitCD auch so (1,0925).

Gruß
ANDREAS

P.S.: Mal sehen  



Andreas 17:23  21.07.
Zitat  
Ich habe mir das jetzt noch mal durchgelesen. Die Aspec ratio mit dem sog. "generic" PAR ist bei Ihm 45/48. O.K. Er geht jedoch davon aus, das ALLE DVDs dann falsch sind und zwangsweise eine andere Streckung brauchen. Wir haben das doch schon mal im Ultimate Board unter der Lupe gehabt (damals noch ixi etc.) Das würde bedeuten, das die gekauften DVDs nach einer anderen Norm verarbeitet sind.

Wenn mein DVD Player das Bild in der Breite nicht weiter streckt, dann macht der Fernseher immer das selbe, nämlich 1,0925. Wenn mein DVD Player die SVCD nimmt und um den Faktor 1,5 Streckt, dann macht aber der Fernseher trotzdem IMMER NOCH das selbe, wieder 1,0925. Daher kann Seine Rechnung m. E. nicht stimmen. AUSSER, er meint jetzt, er hat mit einer TV/Video Karte aufgenommen. Dann macht diese Karte das vielleicht falsch.

Aber alle gekauften DVDs sind falsch encodet? Hmmm, ich weis nicht?  

Gruß
ANDREAS  

SHH  18:21 22.07.

Zitat  
Aspect-ratio habe ich mir noch nicht angeschaut. Offenbar hat der Karl aber die "neuen" Werte aus der IndustrieNorm für square-pixel noch nicht gelesen. (Das war ja auch ne interne Mod-Diskussion)

Mir ist da ein böser Verdacht gekommen, der die ganzen Ausführungen in capture_aspect.pdf vernichten könnte. (oder zumindest einen Großteil). Deswegen lese ich jetzt erstmal nicht weiter.
Gibts da schon einen öffentlichen thread, wo wir das mit dem Karl erörtern könnten?

Und zwar hat mich etwas stutzig gemacht, nämlich daß die ITU falsche Werte liefern soll. (wg 720x576 aktivem Bereich)
Die ITU muß aber nicht falsch sein. Man kann nämlich einfach mit den Werten der ITU weiterrechnen, ohne daß es zu einem Widerspruch kommt. Was das jetzt auf capture-Größe oder pixel-Form jetzt für einen Einfluß hat, habe ich erstmal noch nicht bedacht.

Es wird nämlich auch immer von 64µs pro Zeile ausgegangen, was nicht sein muß!
ITU-Werte (laut Karl)
- 864 Samples pro Zeile
- 144 Samples digital blanking
- 52µs aktiver Bereich
Einfach mal weiter rechnen:
144 + 720 Samples = 864 Samples (stimmt also)
Ein Sample hat dann: 52µs / 720 = 72.2222ns
Zeile hat dann: 72.2222ns * 864 Samples = 62.4µs
Vollbild hat dann: 625 Zeilen * 62.4µs = 39ms

Ja, wir wissen alle daß PAL 25fps hat, bzw 50Hz Halbbildfrequenz. Das widerspricht aber nicht meinen Ausführungen, weil durchaus am Anfang und/oder Ende eines PAL-Bildes (wie bei der Zeile) eine blanking-Spanne möglich ist.
Diese Halbbild-blanking-Spanne ist sogar ziemlich warscheinlich, damit der TV sicher die Grenze zwischen den Halbbildern erkennen kann und sich bei Störungen schnell wieder resynchronisieren kann.

Auch geht mir ein Bereich im PAL-Vollbild ab (ein "paar" ms) der signalisiert, was in dem analogen Strom ein top- oder bottom-field ist. So ein Signal ist meiner Meinung nach *nötig*, sonst müsste der Fernseher Halbbilder (analoges Material) zwischenspeichern. (Früher unmöglich). Gibt es so ein Signal nicht, könnte der TV ja willkürlich mal bei top oder bottom anfangen. Die Folgen fürs TV-Bild sind wohl jedem klar.

Ich komme somit mit der ITU- und PAL-Norm auf eine Halbbildlänge von 19.5ms + 0.5ms blanking. Oder vielleicht sowas fürs PAL-Vollbild: 0.7ms+19.5ms+0.3ms+19.5ms

Habe ich mich irgendwo vertan?? Was falsch ausgelegt?
Was bedeutet das nun für unsere bisherigen "Ergebnisse"?

Schönen Gruß SHH

Kika 22.07. 22:15

Zitat  

@SHH
Dieses Signal, das Du vermisst, steckt ja in dem Bereich zwischen den aktiven 52 us und der Gesamtdauer der Zeile von 64 us.

Meiner Meinung nach kannst Du bei einem Fernseher nicht so ohne weiteres das Signaltiming ändern, was Du aber tun müsstest, um auf Deine 62.4 us zu kommen.

Verdammt, ich glaube, wir brauchen jemanden, der absolut 100% genau weiß, wie das mit dem Timing läuft.


shh 23.07 11:28
Zitat  
Habs jetzt gefunden. (Man sollte wohl keinen Rechner anfassen, wenn man 39.05°C Fieber hat - zumindest gestern)

> Verdammt, ich glaube, wir brauchen jemanden, der absolut 100% genau weiß, wie das mit dem Timing läuft.

Tataaa! Bitteschön!
http://www.saunalahti.fi/~alamayry/video/pal_ntsc.html
Da ist wirklich alles drin:
Nominal line period (µs): 64
Field Period (ms): 20
Sogar die "Field Synchronization" steht da (auch wenn ich sie nicht verstehe)

> Signal, das Du vermisst, steckt ja in dem Bereich zwischen den aktiven 52 us und der Gesamtdauer der Zeile von 64 us.

Stimmt. Das kann man ja auch zB in die erste der 625 Zeilen packen.

Also, meine Panik hat sich in Luft aufgelöst, jeder kann wieder beruhigt schlafen (und ich mich auskurieren)

Schönen Gruß
SHH

Andreas 11:58  23.07.
Zitat  
Und was is mit Teeee?  

Ich werde mir die 720 Pixel noch mal genauer ansehen, denn wenn das stimmt, dann hätten wir alle falsch gerechnet.

Gruß
ANDREAS  


Kika 12:17 23.07
Zitat  
denn wenn das stimmt, dann hätten wir alle falsch gerechnet.

Wie kommst Du jetzt darauf? Dass wir falsch gerechnet hätten, kann ich daraus jedenfalls nicht ableiten.
Nach den Ausführungen dort stehen die Frequenzen fest, lassen sich also nicht ändern, wie ich das weiter oben auch schon vermutet hatte.
Und wenn dem so ist, stimmt doch das, was wir immer gesagt haben: ES GIBT KEINE analoge Auflösung mit 720x576, da dazu die Periodenzeiten anders sein müssten, SHH hat das ja vorgerechnet.  

Andreas 23.07 20:24
Hmmm, das verstehe ich jetzt aber nicht. 720 Pixel rechnet er nicht mit 1,0925 sondern mit 1,066 um. Damit gäbe es keinen Wert über 768 quadratische Pixel. Wir rechnen doch immer mit 1,0925 und damit hätte man 786,6 quadratische Pixel. DA liegt das Problem.

Gruß
ANDREAS

Kika 23.07  22:41
@Andreas

Das ist kein Problem, denn wenn man die Auflösungen zwischen qadratischen und nicht quadratischen Pixeln umrechnet, MUSS ein Kreis ein Kreis bleiben, was er nicht tut, wenn man von 720 = 768 ausgeht, also kann das mit den 1.066 einfach nicht stimmen.
Da man das jederzeit auch praktisch ausprobieren kann, gibt's da imho nicht viel zu überlegen.

Andreas  24.07. 10:26
Habe gestern auch noch probiert. Also bei 1,066 ist der Kreis nicht wirklich rund. Es kann NICHT stimmen, was der Karl da sagt. Man, da bin ich ja beruhigt.

Gruß
ANDREAS
_________________
Gruß BergH

[Kika]

So, ich habe das jetzt nochmal genau durchgelesen und auch durchgerechnet.

Karl hat mit seinem Rechenbeispiel und den 1.066 völlig Recht, wenn..., WENN man von einer DVD mit generic PAR ausgeht, die es ja wirklich gibt. Er hat auch Recht, wenn man von TV-Karten ausgeht, die bei 720x576 ebenfalls ein generic PAR erzeugen.
Das Rechenbeispiel trifft aber NICHT auf DV-Source und auch nicht auf richtig encodete DVDs zu.
Daher fehlt eigentlich nur ein Rechenbeispiel für Videos mit korrektem PAR. Den Rest erledigen eigentlich die Bilder, die das recht schön zeigen.

Gruß,
Kika

[Der Karl]

Jetzt ich ;)
Hallo Miteinander!
Danke für die rege Beteiligung.

Vermutlich beziehen sich eure Fragen zur Generic-PAR auf das _eine_ Beispiel mit der DVD.
Das hatte ich mal für BergH gerechnet und das Posting einfach übernommen - in dem Bereich muß ich auch
noch was machen. Das steht auch: (ja sowas gibts wirklich). Damit ist nicht gemeint, daß das häufig
oder Standard sei.

Zu diesem Thema hatte ich schon mal einen Disput mit Shh, wie diese "falsch" gemasterten DVDs nun
wirklich vom Player wiedergegeben werden. Quintessenz war, daß das nicht rauszukriegen ist.
Vermutlich werden die Player das aber auch mit 54/59 wiedergeben, also verzerrt.

Bzgl. DV-Format werde ich bei den Bildern neben D1 auch noch DV ranschreiben, daß jeder sich vorstellen
kann, wie das auszusehen hat.

@Andreas
>Habe gestern auch noch probiert. Also bei 1,066 ist der Kreis nicht wirklich rund. Es kann NICHT stimmen, was der Karl da sagt. Man, da bin ich ja beruhigt.

Kika hat ja schon was dazu geschrieben.

Wenn Du eine mit generic-PAR gemasterte DVD hast, mußt Du mit 1.06667 entzerren, sonst sind die Kreise
nicht rund. Ich habe mehrere DVDs und Captures vermessen und bin zum (vorläufigen) Ergebnis gelangt,
daß, wenn die 720 volle motion-area sind (also kein Overscan) ist von generic-PAR auszugehen.
FitCD berücksichtigt das auch (Haken Generic-PAR).

>720 Pixel rechnet er nicht mit 1,0925 sondern mit 1,066 um. Damit gäbe es keinen Wert über 768 quadratische Pixel.

Die 786 square sind tatsächlich nur theoretisch. Das braucht man dann, wenn man 720er Auflösungen umrechnen will,
ohne vorher den Overscan zu entfernen (cropping). Also 720 und PAR 54/59. Hat die 720 eine PAR 45/48
entspricht das 768 square.

@Shh

>Ein Sample hat dann: 52µs / 720 = 72.2222ns

Die 720 entsprechen nicht den 52µs. Das steht aber drin.

>Sogar die "Field Synchronization" steht da (auch wenn ich sie nicht verstehe)..

Das VBI (vertical blanking interval) signalisiert, daß ein neues Halbbild anfängt.
Je nach der (zeitlichen) Lage des VBI kann man unterscheiden, ob ein neuer 40ms-Zyklus (Sprung links oben
in die Ecke) anfängt, oder das zweite field im Zyklus (sprung oben in die Mitte).
Eine Capture-Karte muß das natürlich (richtig) auswerten.

@All
>Offenbar hat der Karl aber die "neuen" Werte aus der IndustrieNorm für square-pixel noch nicht gelesen. (Das war ja auch ne interne Mod-Diskussion)

Wo kann ich das nachlesen?

Ist sonst noch was offen/unklar?

Gruß Karl

[ANDREAS]

[Der Karl]

@Andreas

>95% aller DVDs, soweit meine Erfahrung, sind nicht mit einer motion area von 720 ausgestattet.

Ob es nun 95% sind, weiß ich nicht, Jedenfalls die überwiegende Mehrheit. Falls die tatsächliche
horizontale Auflösung "irgendwo in der Nähe" von 704 liegt, würde ich von 54/59 ausgehen.
Die "Ausreißer" z.B. links 10 rechts 22 Pix overscan muß man wohl im Einzelfall untersuchen.
Das ist aber rein wissenschaftlich - DENN: WIR ENCODEN KEINE DVDs ;)

>Wenn also eine DVD genau nach diesem Standard gemastert ist woher weis der DVD Player dass es so ist?

Ich schriebs oben schon mal:

---------------------Schnipp--------------------
Zu diesem Thema hatte ich schon mal einen Disput mit Shh, wie diese "falsch" gemasterten DVDs nun
wirklich vom Player wiedergegeben werden. Quintessenz war, daß das nicht rauszukriegen ist.
Vermutlich werden die Player das aber auch mit 54/59 wiedergeben, also verzerrt.
---------------------Schnipp--------------------

Shh hat, glaub ich, mal geschrieben, es gibt keine Info-flags (oder so) für die PAR.

>Somit gibt es nur eine Ausnahme die wirkliche 720 Pixel breite motion area DVD..

Falsch! ;)
Mir gings doch eigentlich um Capture-Karten. Da arbeiten fast alle TV-Karten (Treiberabhängig)
mit 1.0667 - teilweise noch extrem abweichender, damit es bei der Darstellung auf dem Monitor
keinesfalls irgendwelche schwarzen Balken gibt.

Gruß Karl



Zuletzt bearbeitet von Der Karl am Juli. 24 2002,17:38

[ANDREAS]

[shh]

[Sorry, hab den thread erst jetzt entdeckt; bin auch noch etwas angekränkelt]

> Generic-PAR bei DVDs

Ich denke wir hatten die Diskussion schon.
Ergebnis war doch, daß das ein einziges MixMax von 54/59, 45/48, ... ist.

>> >Offenbar hat der Karl aber die "neuen" Werte aus der IndustrieNorm für square-pixel noch nicht gelesen. (Das war ja auch ne interne Mod-Diskussion)

Das kam von mir. Und zwar sind ungefär im April "neue Erkenntnisse" über square-pixel "aufgetaucht" (die Seite mit der Tabelle hatte sich geändert. [das log mit "initial publication" stimmt nicht]). Tsunami hat mich netterweise darauf aufmerksam gemacht. Im Endeffekt muß man bei der Pixelform nur die dritte Kommastelle anpassen, aber wenn man schon mit Brüchen rechnet, sollten's schon die richtigen sein...

Im Groben erstmal: Die PAR von 59/54 und 10/11 stimmen nicht genau. D.h. auch daß Lurker's guide (etliche andere) und  FitCD etwas ungenau sind (dritte Kommastelle. Vermutlich hat das wg round-to-2 eh keinen Einfluss)
Infos & Diskussion:
http://forum.doom9.org/showthread.php?s=&threadid=25842
http://www.uwasa.fi/~f76998/video/conversion/#conversion_table

Zusammenfassend:
Es gibt tatsächlich eine Industrienorm für "square-pixel". Diese bisher immer hergenommenen [generischen] Werte dafür, eben 1.0000:1.0000 stimmt nicht 100%ig, weil die Industrie das in MHz ausdrückt.

[bergH]

tach auch !
@ALL
Dies ist nicht nur eine Moderatoren/Experten-Diskussion !

Der Karl wäre erfreut, wenn auch Fragen/Vertsändnisprobleme kommen, damit er sein Tutorial verbesser kann.

(Mene etwas harschen Worte oben , sollten nur ein Abdriften dieses Threads ins Belanglose /Herumblödeln vermeiden. Was leider in letzter Zeit zunehmend auftritt.)

Also nur zu !
_________________
Gruß BergH

[Der Karl]

Hallo Shh,

ach DAS meintest Du. Das kannte ich schon, bin aber absichtlich nicht drauf eingegangen.

Erstens wollte ich nicht noch zusätzliche Verwirrung stiften und zweitens hat das IMHO keine praktische Bedeutung.

Es ist bei Square nur 1 Pixel horizontal Unterschied, deutlich weniger als die häufigen
Mastering-Fehler.

----------- Schnipp ---------------
Man kommt bei PAL also mit drei verschiedenen PARs (1:1, 54/59 und 45/48) aus.
Wir belassen es mal dabei, damit es nicht zu kompliziert wird. Man kann damit schon auf 1 Pixel genau rechnen. Das reicht völlig ;-)
-----------Schnapp----------------

Im Capture-Bereich ist es ohnehin egal, da die square-Auflösunge aller mir bekannten
Karten durch scaling erzeugt werden.

14 + 10/13 MHz vs. 14.75 MHz spielt also bei meinem Thema keine Rolle.

Ich hatte auch schon mal (hier?) was dazu geschrieben. Ich glaube @YUV420

Gruß Karl

[std]

Hab mir das Turtorial runtergeladen. Aber bevor ich mitrede, les ichs lieber erst noch 4-10 mal. Ist kein einfacher Stoff. Das mit den Auflösungen kapier ich irgendwie nicht so ganz. Obwohl meine mathematischen Kenntnisse IMO nicht schlecht sind.



Zuletzt bearbeitet von std am Juli. 25 2002,16:07
_________________
MfG   Stefan

[bergH]

tach auch !

@STD
Meine Mathe Kenntnisse sind eher rostig ;) trotzdem kappiere ich es auch nicht ;)
Nein Spaß beiseite : Der Karl hatte mich um Verständniss Verbesserungen gebeten.

Leider fallen mir keine ein/auf.
Wenn ich es gelesen habe verstehe ich es , nur auf der Format-Umrechen Seite vernoten sich meine Neuronen und feuern wahllos in alle Richtungen.

Dabei ist es verständlich und einfach erklärt. Muß an meinem Gehirn liegen:)

@Der Karl
Ehrlich mir fällt nichts zum verbessern auf. Zum Verständniss ist alles Wesentliche enthalten.
Natürlich könnte man jeden Pukt ausführlicher erklären , nur dann wird ein Roman draus.


Ich werde mal eine Nacht drüber schlafen ! ;)
_________________
Gruß BergH

[Der Karl]

>nur auf der Format-Umrechen Seite vernoten sich meine Neuronen ..

Ist doch ein Wort, kort..;)

Das habe ich ja ohnehin noch nicht "implantiert" (oben schon mal geschrieben)

Das ist 1:1 aus einem Posting "gepasted".

Ich werds überarbeiten und versuchen, die Schritte anschaulich zu erläutern.

Gruß Karl

[std]

@Der Karl,

dann gib bitte Bescheid, wenn man sich 'ne neue Version runterladen kann. Das mit dem umrechnen (resizen) ist auch der Part bei dem mei "Betriebsystem" regelmässig abschmiert. Ansonsten ists schon recht Anschaulich beschrieben.
Bim allerdings immer noch nicht dazu gekommen mir das ganze noch mal anzusehen.
_________________
MfG   Stefan

[bergH]

tach auch !

@ALL & STD

Neu Version 0.99 ist UP, selber Link.(Erstes Post)
Bitte testen, ob es geht !

Hab es auch noch nicht gelesen, da zur Zeit eigentlich gar nicht da ! ;)  
_________________
Gruß BergH

[std]

Langsam fang ich an das mit dem croppen und resizen zu verstehen.
Kann ich die Berechnungen auch so für Half-D1 (352*576)übernehmen oder gibts da was zu beachten.
Manche Player könnens ja nicht richtig darstellen, was mir die Vermutung nahelegt das es da 'ne Gemeinheit gibt.
Oder liegt das einfach an schlampiger FW?
_________________
MfG   Stefan

[Der Karl]

>Langsam fang ich an das mit dem croppen und resizen zu verstehen.

Na, dann hats ja schon was gebracht ;)

Wenn ich VIEL Zeit habe, mache ich für die V1.0 noch ein Beispiel mit Half-D1.

Ich finde es aber immernoch zu unübersichtlich. Vielleicht fällt mir dazu noch was ein.

Sonstige Wünsche? Ich schließe das dann ab und werde in nächster Zeit
nix mehr dran tun - andere Vorhaben.

Gruß Karl

[std]

@DerKarl,

ich finds sehr verständlich wie Du's geschrieben hast. Man muss sich halt gedanklich "hineinversetzen". Und bis ichs flüssig hinkriege wird bestimmt noch einige Zeit vergehen.

Das mit Half-D1 ist mir sehr wichtig. Kannst Du das in ein paar Worten erklären? Ich schätze mal das der Player auch da streckt, wie bei 480*576. Aber um welchen Faktor? Genau 2 passt ja wohl nicht. Muss ich auf noch etwas achten?

Als Anregung für die Neuauflage: Warum macht z.B. FitCD zwischen anamorph und.... (ja und was eigentlich? Letterboxed?) einen Unterschied? Wäre Dir sehr dankbar, wenn Du auch das kurz anreissen, oder mich "verlinken" könntest.

P.S: Find es seltsam, dass so wenige an diesen wichtigen Grunlagen interressiert scheinen.
Warte schon auf den nächsten Thread: "wie richtig croppen?" oder "Warum hab ich Eierköpfe?"

P.P.S.: Viel Erfolg bei Deinen anderen Projekten!



Zuletzt bearbeitet von std am Aug. 01 2002,18:21
_________________
MfG   Stefan

[Markus71]

Hallo

@ std

Interresse ist schon vorhanden. Sehr sogar. Aber vielleicht spart man doch etwas zuviel an Lob und Danksagungen für gute Arbeit.

Deshalb :

@ Karl

Danke für die gute Arbeit und deine Mühe. Der Artikel ist gut gelungen.
Ich habe auch eine Frage. In dem Bild auf Seite 5 stellst du das Basisband dar, mit einer Zeitdauer von 53,33 E-6s und darunter mit den realen 52 E-6s. Nur gibt es doch nur Videoinformationen in den 52 E-6s, der Pfeil mit 53,33 E-6s müssste laut meinem Verständnis ein Stück über die Videoinformationen hinaus gehen ?

Gruß
Markus

[Der Karl]

Hi Markus,

Du hast recht. Hin und wieder braucht man etwas positive Bestätigung, damit man die Lust
zu Weitermachen nicht verliert.

Einiges lief nicht durch diesen Thread, sondern per Mail bzw. PM. Da hat es auch durchaus
positive Resonanz gegeben.

>Nur gibt es doch nur Videoinformationen in den 52 E-6s, der Pfeil mit 53,33 E-6s müssste laut meinem Verständnis ein Stück über die Videoinformationen ..

Stimmt, hab ich übersehen. Außerhalb der 52µS dürfte nur noch Schwarzpegel sein - das meintest Du doch?

Ich werds korrigieren.

Gruß Karl



Zuletzt bearbeitet von Der Karl am Aug. 05 2002,16:56