@Shh bzgl. genric-PAR in Fitcd

[Der Karl]

Wußte nicht so richtig, wohin damit ;-)

Hallo Shh,

in der Readme zu Fitcd schreibst Du, daß in den Fällen, wo die ITU-R BT.601-4
nicht eingehalten wurde, eine "generische" pixel aspect ratio von 45/49 verwendet
wird. Das entspricht einem Faktor von etwa 1:1.0888.

Tatsächlich rechnet Fitcd intern aber mit ca. 1.0667 bzw. 45/48, was IMO auch
richtig ist.

Habe ich da was falsch verstanden, oder ist das nur ein Schreibfehler?


Etwas OT, aber eine Sache ist mir noch aufgefallen:
Lädt man im "resizer" ein BT-Capture (768*576), wird zwar richtig 1:1 Monitor
erkannt, die ITU-R...-checkbox aber deaktiviert. Das ist ja eigentlich richtig,
aber Fitcd zeigt einen falschen "real aspect" und rechnet dann auch falsch -
nämlich -vermutlich- intern mit 720 Punkten horizontal und PAR 1:1.0667.
Aktiviert man ITU-R.. manuell, stimmt wieder alles (hier rechnest Du wohl mit
704 und 54/59 ;-)).

Das ist natürlich nicht wirklich ein Problem - vielleicht hats nur noch keiner
bemerkt ;-).

Schlußendlich noch eine Bitte für die nächste Version:
Der resizer von Fitcd ist ja auch für MPEG4-Zielformat bestens geeignet.
Etwas störend ist, daß für das einzige "destination"-Format mit quadratischen Pixeln
(1:1 Monitor), die (resize)-Horizontalauflösung nur in 64er Schritten änderbar ist.
Wünschenswert wären 32er Schritte. Das scheint fest im Programm verankert zu sein,
denn eine Änderung der ini-Datei nützt nix.
Wäre schön, wenn Du das bei der nächsten Version ändern könntest.

Gruß Karl

[shh]

> 45/49 <> 45/48

Hast natürlich Recht. Das muß 45/48 heissen. [korrigier...]
Ist wohl ein Tippfehler (oder ich hatte das 54/59 noch im Kopf) :0

> BT-Capture (768*576)

So wie ich das sehe, funktioniert das richtig.
Eine 768*576-Aufnahme ist ja kein 100%iges 1:1, sondern wird bei der Wiedergabe am Fernseher noch etwas gestreckt. die real-aspect von 1.3657 dürfte also stimmen.
...oder?

> Schlußendlich noch eine Bitte für die nächste Version:
Der resizer von Fitcd ist ja auch für MPEG4-Zielformat bestens geeignet...

Eigentlich kann man die horizontale Größe gar nicht ändern. Die wird durch die Standards in der DropDown-box festgelegt (SVCD, VCD, DVD usw). Demensprechend werden auch im avisynth-script Ränder hinzugefügt.
Für deinen Wunsch müßte ich die die Horizontale von der Box entkoppeln, was mir so ziemlich alles durcheinander bringt; vom script bis zum richtigen croppen.
Ich muß dich daher vorläufig entäuschen, da würde ich mehr kaputt machen und der (Korrigier)Aufwand steht nicht dafür.
Weil ich aber wg einem Parallelprojekt gerade am Modularisieren der Programmelemente bin (u.a. der "resizing-engine"), werde ich versuchen das im Auge zu behalten.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Der Karl]

@Shh

>So wie ich das sehe, funktioniert das richtig.
>Eine 768*576-Aufnahme ist ja kein 100%iges 1:1....

Ich will jetzt nicht mit Dir über Fitcd-Interna streiten ;-) ..
768*576 ist echtes 4:3 mit PAR 1:1 und war niemals für Fernseher gedacht.

Es sind also auch 768*576 coded pixel - ohne jeglichen overscan.
Wenn ich die grundlegende Funktionsweise von Fitcd richtig verstanden habe, wird das
Quellformat erst entzerrt (coded pixel, PAR, Anamorph) und dann je nach Zielformat
wieder "verzerrt".

Man müßte also die 768*576 genauso behandeln wie 704*576 und PAR 1:1.0926 = 4:3 !
Die 704 müßten zwar eigentlich 702.9.. sein - aber wir wollen ja nicht übertreiben ;-)

Mit ITU...-Checkbox macht er auch alles richtig...
Resize auf 1:1 Monitor - kommt wieder 768*576/1.333333 raus und auf DVD mit 704*576
plus 2*8 Pixel Overscan mit 0.15% aspect error - das ist auch o.K..

Es ist aber, wie gesagt, kein Problem - nur ein Schönheitsfehler.
Ich cappe ohnehin mit Asus in 704*576..... Da stimmt alles :-))


>Für deinen Wunsch müßte ich die die Horizontale von der Box entkoppeln, was.....

Du hast mich, glaube ich, mist-verstanden ;-)
Die "addborders" aus dem avs zu schmeißen, ist ja kein Problem. Damit habe ich ein
computertaugliches Format mit PAR 1:1.

Hintergrund ist eigentlich, das ich selbst einen MPEG4-resizer schreiben wollte,
weil die Tipperei mir auf die Nerven ging und auch die zusammengestümperte Excel-
Tabelle so elegant nicht war. Beim Sammeln der Infos, was ich alles berücksichtigen
müßte, bin ich wíeder auf Fitcd gstoßen, was ich mir seit der - glaube ich - 0.91
nicht mehr angeschaut hatte. UND: Dein Fitcd macht im resizing alles, was ich eigentlich
auch implementieren wollte - und noch einiges mehr...

Der einzige "Störfaktor" ist der horizontale "round to"-Wert im "resizing", der bei
"destination 1:1 Monitor" auf einen festen Faktor von 64 eingestellt ist.
Das geht ja bei Ziel DVD bzw. SVCD mit 16 respektive 32 auch - sollte also keine
allzugroße Hürde sein.
Es soll also nix entkoppelt werden und ich finde die Funktionsweise absolut o.K..
Mein "resizer" wäre wohl nicht so gut geworden.

Guß Karl

[shh]

> 768*576 ist echtes 4:3 mit PAR 1:1 und war niemals für Fernseher gedacht

Stimmt. Jetzt sehe ich es auch:
http://www.uwasa.fi/~f76998/video/svcd/faq/#1.3
Für 768x576 sind vor dem Resizing nur Ränder auf ~787x576 hinzuzufügen, was heißt, daß 768x576 schon die gewünschte PAR 1:1 hat.
Danke, da muß ich wohl ein paar Zeilen korrigieren.

> nur ein Schönheitsfehler

Krampf. Das ist ein übler, böser bug der schnellstens gefixt werden muß! :0

> Der einzige "Störfaktor" ist der horizontale "round to"-Wert im "resizing", der bei
"destination 1:1 Monitor" auf einen festen Faktor von 64 eingestellt ist.

Hmm.
Das Problem ist, es ist nicht fest auf 64 eingestellt.
(Das sieht man auch wenn man Destination auf DVD stellt)
Das ist ein bug, der entstanden ist, während immer mehr Optionen hinzugekommen sind. Der Rechner wurde immer mehr mit der GUI verkoppelt (wg Komfort) und jetzt ist es leider so, daß zB der RundungsWert von 768 berechnet wird (768 div 64 = 0) und dann mit dem Rundungswert 64 weiter gerechnet wird. Das ist natürlich total hohl, hat bei den Standard-Auflösungen aber nicht gestört.
Ich werde mal schaun, ob ich den bug irgendwie auf die Schnelle richten kann. Gehts nicht, mußt du warten, bis die engine vom Parallelprojekt einfliesst. ;)

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Der Karl]

>Für 768x576 sind vor dem Resizing nur Ränder auf ~787x576 hinzuzufügen, was heißt...

768*576 ist eigentlich _die_ Referenz, die zu fast 100% stimmt. 768*(54/59)=702.91..

>Ich werde mal schaun, ob ich den bug irgendwie auf die Schnelle richten kann.
>Gehts nicht, mußt du warten.....

Bloß nicht zuviel "auf die schnelle richten". Denn:

>Das ist ein bug, der entstanden ist, während immer mehr Optionen hinzugekommen sind...

;-)

Hab ja noch meine Excel-Tabelle ...

Gruß Karl

[shh]

> 768*576 ist eigentlich _die_ Referenz, die zu fast 100% stimmt. 768*(54/59)=702.91..

Referenz von was?
Als Referenz für ein 100%iges 4:3-Bild kann man irgendwas hernehmen; eben auch ein 4x3 (=ein mit 192 gekürztes 768x576).
Referenz ist PAL: 575 Zeilen und wg pixel-clock eine PAR von 54/59. (bzw std-MPEG-PAL mit 576 Zeilen)
Und für den Monitor 100%ige quadratische pixel.
Dann steht nur noch zur Debatte, welche Zielgröße man überhaupt braucht, bzw in welche Richtung man resizen möchte.
Somit stimmt dein 768*576 sogar 100%ig für ein 4:3-Bild, nicht nur "fast".


> Bloß nicht zuviel "auf die schnelle richten".

Hab eh schon gesehen, daß das nicht auf die schnelle klappt.
Das andere mit PAR1:1 ist schon gefixt.

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Der Karl]

Oops, da habe ich aber eine heftige Reaktion mit meiner "harmlosen" Bemerkung provoziert.
Was ich eigentlich meinte, ist, daß sich aus den horizontalen 768 Pixeln über die
PAR 54/59 ganz einfach die "echte" Horizontalauflösung von 702.91525 lt. ITU-R BT.601-4
herleiten läßt. Deshalb "referenz". Es stimmt auch nicht ungefähr, sondern präzise.
War vielleicht nicht ganz glücklich formuliert.

>Somit stimmt dein 768*576 sogar 100%ig für ein 4:3-Bild, nicht nur "fast".

Ist ja klar, ich schrieb es weiter oben ja selbst schon.. ;-)

>Referenz ist PAL: 575 Zeilen und wg pixel-clock eine PAR von 54/59. (bzw std-MPEG-PAL mit 576 Zeilen)

Ich bin nun kein Fernsehtechniker und meine "aktive Zeit" diesbezüglich liegt auch schon
etwas zurück, glaube mich aber erinnern zu können, daß bei PAL zwei fields mit je 287,5
"aktiven" Zeilen übertragen werden. In Summe also IMHO nicht 575 sondern 574 und je eine
Halbe oben und unten. Insofern hätten die 576 schon ihre Berechtigung.

Jetz höre ich aber auf, bevor noch jemand merkt, daß ich eigentlich gar keine Ahnung habe.

;-)

Gruß Karl

[shh]

> Oops, da habe ich aber eine heftige Reaktion mit meiner "harmlosen" Bemerkung provoziert.

Nicht so ernst nehmen. Ich wollte dich nur ein bisschen reizen um Informationen zu entlocken. ;)

> [...] zwei fields mit je 287,5 "aktiven" Zeilen übertragen werden

Ja, sind das denn keine 575 Zeilen?
Aber beim zusammengesetzten Vollbild fehlt oben und unten je ne halbe Zeile (zumindest bei MPEGs), was ja insgesamt dann doch 576 "angefangene" Zeilen sind. Naja, Spitzfindigkeiten halt. Deine Erklärung trifft's warscheinlich besser. ;)

Ich habe "die Norm" nicht direkt vorliegen und kann mich nur an http://toolbox.sgi.com/TasteOf....ct.html halten. Wollte auch nur herauskitzeln, ob du's genauer weißt. In dem Dokument kann ich übrigens immer noch keine ITU-R BT.601-4 Standard-Auflösung wie deine 702.91525xYYY finden. Im Grunde werden nur Zeilen und Pixelformen definiert.
Bin ich blind?

Schönen Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Der Karl]

>Ich wollte dich nur ein bisschen reizen um Informationen zu entlocken...

Reizen ist bei mir nicht nötig, ich will es ja selbst im Grundsatz begreifen ;-)

>Ich habe "die Norm" nicht direkt vorliegen und kann mich nur an ...

Ich habe sie leider auch nicht. Insofern nehme ich einfach alle Infos, die ich kriegen
kann. Woher sie jeweils stammen, kann ich bei den Mengen an Material, was ich in den
letzten Tagen für meinen "resizer" gelesen habe, auch nicht mehr sagen.

>Ja, sind das denn keine 575 Zeilen?

Rechnerisch schon, optisch und "speichertechnisch" nicht. Ich halte das für wichtig, um das
gesamte "Konstrukt" zu begreifen. Habe deshalb noch ein paar Specs gelesen.

Micronas/Intermetall beschreiben in der Spezifikation für den VPX3225 sehr anschaulich,
welche Bereiche wirklich digitalisiert werden. (Mapping for 625/50 line systems)
Field 1: ~die Hälfte der ersten Zeile und 2-288 komplett, Field2: 1-287 und ~die Hälfte von 288.
Es sind also effektiv 576 Zeilen, auch wenn von der ersten und letzten nur die Hälfte
sichtbar ist.

In vielen specs wird auf diese "ominösen" 768 bezug genommen, obwohl effektiv mit anderen
Auflösungen und aspect ratios gearbeitet wird.

Langsam wird mir auch klar warum. Es gibt _DIE_ Auflösung gar nicht! Kanns gar nicht geben,
weil bei analogen TV mit Frequenzen gearbeitet wird. Die kann man abtasten, wie man will -
wichtig ist nur, daß dem Ergebnis die Info mitgegeben wird, _wie_ abgetastet wurde.

Der einzige Fixpunkt sind _die_576_! Zeilen. Alles andere sind "willkürliche" Festlegungen,
die nur für alle verbindlich sein sollten - es aber offensichtlich nicht sind, denn kein
Schwein hält sich dran.

Da wir über die Digitalisierung analoger informationen reden, muß es ein Bezugssystem geben,
was sich ganz einfach aus der fixen Zeilenzahl und dem Seitenverhältnis der Darstellung
ergibt. Für PAL bietet sich also 576*4/3 an.
Das hat nach der Digitalisierung noch den "nützlichen Nebeneffekt" in beiden Richtungen
durch 32 teilbar zu sein.

Interessant auch Formulierungen von Herstellern/Entwicklern der Digitalisierchips:
"768*576 pixels for Broadcast TV" bzw. "704*576 Input raster for MPEG-2"

Diese 768 (NTSC-640) tauchen wirklich überall auf.
Auch in dem sgi-toolbox Dokument ist die Umrechnung 702.(54/59) - 768 beschrieben (Grafik).
Brooktree benutzt es als Capture-Auflösung, Philips bezieht sich drauf, Micronas bezieht
sich drauf - da muß doch was dran sein. ;-)

Weiterhin interessant, daß PAL und NTSC trotz verschiedener ursprünglicher Auflösungen,
Horizontal im MPEG-2 die Gleiche benutzen. Das ist mit Sicherheit "künstlich" aus
Kompatibilitätsgründen.

In "DVD demystified" wird geschrieben, die "echte" PAL-DVD-Auflösung wäre (abzüglich
overscan) 704*576 mit eine PAR von 1:1.091 - und wieder die "ominösen" 768.

Es ist also nach wie vor nicht "wissenschaftlich" bewiesen, aber IMHO ziemlich offensichtlich.
Man braucht eine Referenz, warum nicht die Naheliedgenste?


Falls jemand hier mitliest, der Zugriff auf die ITU-R BT.601-4 hat, bitte unbedingt melden!!

Gruß Karl

[Kika]

Vielleicht liegt's daran, dass ich von der langen Autofahrt gestern noch etwas müde bin, aber ich sehe jetzt irgendwie nicht, wo Euer Problem liegt. Ihr nennt ja die ganze Zeit über die richtigen Zahlen, nämlich 768 und 704, was effektiv dieselbe Auflösung ist und sich nur im PAR unterscheidet.
Genau genommen sind es natürlich dann 702.xx und nicht 704, da aber die Größe durch 16 bzw. 32 teilbar sein muss, nimmt man halt das naheliegende, nämlich 704.

Und die "echte" DVD-Auflösung ist tatsächlich (sofern alles richtig gemacht wird) 704x576, der Rest, nämlich die Differenz zu 720 ist Overscan und auf dem TV niemals sichtbar. Das gilt auch für DV-Video. Na ja, soweit die Theorie, dass sich da nicht alle Hersteller dran halten, ist ja nicht neu :angry:

Für alle die's interessiert: ich hatte dazu ja schon mal was gepostet, nachzulesen hier:

http://www.dvdboard.de/forum/showthread.php?threadid=21834

[shh]

Nun, eigentlich haben wir ja kein Problem.
Der Begriff "Referenz-Auflösung" hat mich halt etwas gestört, weil die ITU nunmal die Norm für [bestimmtes] analoges Video darstellt, und da nie von einer Auflösung die Rede ist.

Nur, wenn man die Norm auf Pixel übertragen muß, geht man von einem 4:3-Bild (am Monitor) aus, was dann natürlich auch eine "Referenz-Auflösung" von 768x576 oder andere vergleichbare 1.333333:1-Auflösungen impliziert.

Hmm, aber das mit den fields interessiert mich jetzt. Weiß denn keiner, wie die genau aussehen oder definiert sind? - oder ist das schlicht irrelevant? ;)

Gruß
shh
_________________
shh >>> shh's MPEG-tools

[Kika]

Tja, die Fields, ich glaube mich erinnern zu können, mal eine noch ganz andere Zusammensetzung gesehen zu haben (288.5 und 287.5). Da kann ich mich aber auch irren. Ich werde heute Abend mal meine Unterlagen durchsuchen, befürchte aber, dass da über die Fields so detailiert nichts drin steht. Ich habe da ehrlich gesagt schon lange nicht mehr reingeschaut (seit FitCD nicht mehr ;) ).

Gruß,
Kika

[SVCDFan]

@Der Karl

Suche doch bei www.google.de nach "ITU-R BT.601-4"...
_________________
Gruß SVCDFan

[Der Karl]

@Kika

Es gibt kein Problem.
Es ist IMHO immer von Vorteil, eine Sache im Grundsatz zu verstehen und gelegentlich
auch "scheinbar Offensichtliches" zu hinterfragen.

Es gibt übrigens noch genügend Ungeklärtes (zumindest bei mir), z.B. die 720*576
ohne overscan mit PAR 1.06667, die angeblich CCIR-601 entsprechen soll bzw.
eine -hoffentlich allgemeingültige- Erkenntnis, ob man aus bestimmten Parametern
/Attributen herleiten kann, welche PAR beim Digitalisieren verwendet wurde.
Ich habe in letzter Zeit viel Material vermessen und fast nur schlimmste "Ausrutscher"
erlebt.

Allein zur "richtigen" nonsquare-PAR von PAL gibt es ungeheuer viele verschiedene Angaben.
Z.B.: 54/59, 45/48, 11/12, 1035/1132 .
Ich versuche einfach, die Logik dahinter zu entdecken.

@Shh

>Nur, wenn man die Norm auf Pixel übertragen muß, geht man von einem 4:3-Bild (am Monitor) aus..

Der Fernseher machts ja auch in 4:3, nur ohne Pixel *g*

Hast Du Dir mal die Micronas-Spec durchgelesen? Google search: VPX322XD.PDF

@SVCDFan

Da gibts ja ne Menge! Mal schaun, ob die echte spec dabei ist. Irgendwer hat mal geschrieben,
die "echte" spec wäre nicht offen verfügbar und ich habs geglaubt.
Mal schaun. Wären wir wieder bei dem "scheinbar Offensichtlichen". Danke!
[Kopf gegen die Wand renn]

Gruß Karl

[SVCDFan]

@Der Karl

Da wäre die eigentliche Dokumentation bekommen, leider gebührenpflichtig:

ITU-R BT.601-4
_________________
Gruß SVCDFan

[Kika]

@Der Karl

Da bin ich ja jetzt beruhigt. Irgendwie war mir nicht ganz klar, woher dieses Thema jetzt nochmal kam.

> z.B. die 720*576
ohne overscan mit PAR 1.06667, die angeblich CCIR-601 entsprechen soll

Das kann ja nun schlecht sein. Die CCIR 601 stammt aus einer Zeit, in der es noch gar kein DV/DVD-Video gab und spezifiziert somit mit Sicherheit keine 720er Auflösung, sondern die 704er, bzw. 702.xx.
Mit der 720er Auflösung habe ich eigentlich nur insofern Probleme als dass sie in meinen Augen eigentlich keinen Sinn macht, da ja eh das Motion Area mit 704x576 spezifiziert ist.
Und diese 1.06667..., die nimmt ja sogar Premiere, was aber jedlicher Norm (die ich kenne) widerspricht.
Einzig richtig ist demnach das PAR von 59/54 bzw. 1.0926:1.

http://toolbox.sgi.com/TasteOf....ct.html

[Der Karl]

@Kika

So einfach ist das leider nicht. Wir reden ja hier nicht ausschließlich über MPEG-2/DVD
bzw. DV - jedenfalls ich nicht - sondern generell über das Digitalisieren von analogem
Material.

Schau Dir mal an, was Deine BT-Karte bei 720*576 macht - PAR: 45/48!
BT behauptet z.B. in den specs für den 848 und 878, daß sie nach CCIR601 vorgehen.
Ati macht das auch so.

Jetzt ist schonmal klar, wo diese PAR 1:1.0667 herkommt. Das erklärt natürlich nicht,
warum sie so häufig -fehlerhaft- für MPEG-2 encoding benutzt wird.

Nächste Woche habe ich wieder etwas mehr Zeit (und einen ordentlichen Internetzugang)
und werde mal schaun, welche Normen ich -möglichst im Original- auftreiben kann und
was drinsteht.

Die vielen Infos aus zweiter und dritter Hand bergen ja immer das Problem, daß man
gar nicht weiß, _worauf_ sie sich überhaupt beziehen.

Gruß Karl

[Kika]

> Schau Dir mal an, was Deine BT-Karte bei 720*576 macht

Schon klar, bei 720x576 macht sie's schlicht und ergreifen falsch. Egal, was da irgendein Hersteller behauptet. Überprüfbar ist das auch, kann man ja jederzeit an etwas in einem Movie ausprobieren, was exakt rund ist.

Nach der reinen Lehre müsste man ja, um von TV eine SVCD zu erzeugen mit 704x576 aufnehmen, das Ganze auf 720x576 padden und dann auf 480x576 resizen.
Bei Half-D1 dagegen wird direkt von 704 auf 352 resized.

Irgendjemand hat wohl mal das Gerücht in die Welt gesetzt, 720x576 sei PAL-Vollbild mit einem anderen PAR, tatsächlich ist es aber PAL-Vollbild mit Overscan, was auch logisch ist, denn beim Fernseher kann man ja schlecht die Horizontalfrequenz ändern.

[SVCDFan]

Jetzt muß ich doch mal meine Frage los werden:

Ich capture mit AV.Master auf 768x576, weil andere Formate außer 352x288 gehen nicht.

Bisher habe ich nun im TMPGenc rechts 16 und unten 12 schwarz gefärbt, weil dort "Schrott" zu sehen ist, der am Fernseher eh nicht zu sehen ist. Das heißt, das liegt im overscan Bereich.

Bei eurer Diskussion mit dem aspect ratio usw.... habe ich nun gelesen, daß ich zu dem 768x576 eigentlich noch links und rechts zusätzlich 10 hinzufügen muß...?

Ich habe nicht den Eindruck, daß ich sogenannte "Eierköpfe" habe. Aber letztendlich habe ich auch nicht mittels Testbild mit Kreis nachgeprüft, was ich nun doch mal ausprobieren muß.

Wie müßte ich nun croppen und resizen, damit euer Meinung nach das richtig aspect ratio wieder herauskommt (von der Theorie her)?
_________________
Gruß SVCDFan

[Kika]

@SVCDfan

Wie das mit dem Croppen und Resizen geht, habe ich mal hier erklärt:

http://dvdboard.wpf.de/showthread.php?threadid=21834


> Ich habe nicht den Eindruck, daß ich sogenannte "Eierköpfe" habe.

Nun, der Unterschied ist auch so minimal, dass er im Normalfall praktisch nicht zu sehen ist.


> rechts 16 und unten 12 schwarz gefärbt

Hm, unten 12, das kann ich nachvollziehen, aber rechts 16? Klingt danach, als sei die Karte nicht richtig eingestellt (keine Ahnung, ob man das bei der AV Master einstellen kann, bei einer BT-TV-Karte geht's). Es gibt zwar Sender, bei denen das so ist, aber es darf auf gar keinen Fall immer so sein.