@Shh bzgl. genric-PAR in Fitcd

[SVCDFan]

Danke, Kika.

Ja das im DVDBoard hatte ich auch schon gelesen...

Was AV.Master mit dem rechten und unten Rand macht, weiß ich nicht. Nein ich kann diesbezüglich nichts einstellen. Ich schaue mal in den nächsten Tagen danach und probiere mal die Werte aus. Mal sehen was dabei raus kommt.
_________________
Gruß SVCDFan

[SVCDFan]

Da fällt mir gerade eben ein, daß AV.Master noch einen andern Modus kennt, nämlich ohne den overscan zu capturen. Das habe ich jedoch wieder fallengelassen, weil eben in der Wiedergabe der Rand in den overscan Bereich gegangen ist, d.h. ich müßte genau den fehlenden Rand auf volle 768x576 padden und dann resizen.

Das werde ich mal ausprobieren.

Danke im voraus!



Zuletzt bearbeitet von SVCDFan am Mai. 08 2002,17:37
_________________
Gruß SVCDFan

[Der Karl]

Hi Zusammen,

habe mir die ITU-R BT.601-4 mal besorgt und außerdem eine Menge gelesen.
Bilde mir jetzt ein, das PAR-Problem einigermaßen verstanden zu haben.

Zu den Fakten (nur PAL):
Gesamtzeilen Vollbild: 625
Periodendauer Vollbild: 40ms
Periodendauer Zeile: 64us
Anteil aktiver Videoinformationen (ohne blanking) - da sind sich die Experten einig: 52us

Link: http://www.epanorama.net/documents/video/pal_timing.html

Es ergibt sich also eine "echte" Motion-Area von 574 2/2 Zeilen mal 52us.
Da sich halbe Zeilen schlecht digital ablegen lassen, ist das "richtige" Format des
digitalen Endproduktes 576 Zeilen mal 52us, wobei von Zeile 1 und 576 die hälfte schwarz
bleibt (Zeilensprung).

Zur ITU-R BT.601-4 (CCIR Rec. 601-1 sagt diesbezüglich das Gleiche):

Number of samples per total line: 864
Sampling frequency (luminance): 13.5 MHz
Number of samples per digital aktive Line (luminance): 720

Und genau hier: "per digital aktive Line" liegt der Hase im Pfeffer. Sind damit die 52 us gemeint?
Ich meine nein!

Denn:
"864 samples per total line" und die "sample frequency" 13.5 MHz sind (als Kompromiß PAL/NTSC)
eindeutig spezifiziert. Dazu ein kleines Rechenbeispiel:

25 frames/s = 40 ms per frame
40 ms / 625 Zeilen = 64 us per Zeile
64 us * 13.5 MHz (Samplingfrequenz) = 864 samples pro Zeile (wie ITU!)
Ergibt Periodendauer für ein Pixel: 64us / 864 = 74.074 ns
74.074ns * 720 Pixel (lt. ITU) ergibt aber: 53.333 us / Zeile

Da eine Zeile aber maximal 52 us aktive Informationen enthält, _muß_ ein CCIR601 bzw ITU-R BT.601-4
konformes Capture-Device korrekterweise Blanking mitdigitalisieren (oder selbst "erzeugen").

52 us / 74.074 ns = 702.001 aktive Pixel
Die korrekte PAR wäre also: (576*4)/(702*3) = 1.094

Daraus kann man schließen: Die (rechnerisch) 702.9- bzw. gerundet 704*576 von MPEG-2 mit PAR 1.0926
sind "nahe dran". Ebenso die Capture-Devices, die mit 704*576 innerhalb des 52 us-Fensters arbeiten.

Capture-Devices, die 720 Horizontal benutzen, müßten also ca. 2*9 Pixel Overscan "produzieren".
ATI und BT arbeiten bei der 720er (PAL)-Auflösung also NICHT ITU- bzw. CCIR-konform.

Eine PAR von 1:1.0667 dürfte es also - zumindest lt. ITU - gar nicht geben!

Falls jetzt nicht jemand laut WIDERSPRUCH!! schreit, ist das Thema PAR für mich erledigt.

;-)

Gruß Karl



Zuletzt bearbeitet von Der Karl am Mai. 14 2002,22:02

[Kika]

Also von mir wirst Du da mit Sicherheit keinen Widerspruch hören, deckt sich ja ziemlich exakt mit den Werten, von denen ich (und bei weitem nicht nur ich) schon lange ausgehe.
Das mit den 52 us hat Gandalf der Graue im dvdboard mal recht gut erklärt.

> Eine PAR von 1:1.0667 dürfte es also - zumindest lt. ITU - gar nicht geben!

Richtig, leider hat das den Programmierern von Premiere wohl niemand gesagt...

[bergH]

tach auch !

Also ich verstehe nur Bahnhof, aber vieleicht meinte Kika diese beiden hier :

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

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

Gandalf_der_Graue mal wieder in Hochform !

Ich brauch jetzt erst mal wieder ein Aspirin ! ;)
_________________
Gruß BergH

[Lexx00]

Oje, hab ich mir gerade das Hirn verbogen beim Lesen dieses Thread´s.

Ums nochmal einfach zusammenzufassen, für alle die es interessiert aber Probleme haben bei den Rechnungen hier durchzusteigen :

Völlig unabhängig von irgendwelchen Auflösungen geht´s nur um die "korrekte" PAP, sehe ich das richtig?
Ok, also ein digitales Videosignal nach Rec. 601 wird immer mit 13,5 Millionen Pixeln pro Sekunde abgetastet. Wenn ein 625 Zeilen analoges PAL Signal (nach ITU-R BT.470-3) in quadratische Pixel zerlegt wird, sind dies nach gültigem Industriestandard 14,75 Millionen Pixel pro Sekunde. Daraus folgt das Pixel-Seitenverhältnis für den digitalen 625 Zeilen-Standard mit 13,5/14,75 = 54(13,5*4)/59 (14,75*4)und somit ein PAP von 1,0926(59/54).

[shh]

> Number of samples per digital aktive Line (luminance): 720

Da sind *auch* die 52µs pro sample gemeint.
Wenn die Pixelfrequenz gleich bleibt (es ist ja nichts anderes erwähnt; muß sie ja auch), kann sich nur noch die blanking-Spanne ändern. Da heißt's ja auch speziell *digitales blanking*. D.h. die blanking-Spanne ist bei digitaler Abtastung kürzer. Daher hat man auch mehr pixel, also auch 720 statt der 702.
=> Pixelform, also auch Pixelbreite ist gleich = 74.074 ns. Immer.
=> PAR ist auch immer gleich: 59/54

> Eine PAR von 1:1.0667 dürfte es also - zumindest lt. ITU - gar nicht geben!

Bin genau deiner Meinung. (die unterschiedl. blanking-Spanne steht übrigens nicht im Widerspruch zu deinen Rechenausführungen)

Das was letzlich zu einem Konflikt führt, ist nicht die 720x576 oder 702x576 und ihre PARs sondern die Tatsache, daß in der MPEG2-Norm eine 4:3 generic verabschiedet wurde und darin nicht festgelegt wurde, daß das Video nach der Empfehlung ITU-R BT.601-4 gefertigt sein muß.
Gerade auch die Festlegung der anderen generischen aspect-ratios von 16:9 und 2.21:1 führt zu Unklarheiten, weil wir zwar wissen, wie ein richtiges Video am PAL-TV und/oder nach ITU auszusehen hat, aber nicht, wie die generischen 4:3 zu deuten sind.
Bei MPEG1 wurden wenigstens die ganzen *echten* PARs möglich gemacht, bei MPEG2 ist man verlassen. Aber immerhin beim KomprimierAlgos haben die Normer das Köpfchen angestrengt.

Herzlichen Dank übrigens fürs Infos raussuchen.
bergH, das wär doch was für deine Linkliste. ;)

Schönen Gruß
shh

NACHTRAG zu Gandalfs Ausführungen:
Ist zwar böse in Gandalfs Abwesenheit, aber vielleicht liest er ja mit...
http://www.dvdboard.de/forum/showthread.php?threadid=31176

[Der Karl]

Offensichtlich habe ich das doch noch nicht richtig begriffen.
Bevor ich jetzt widerspreche, muß ich mir das nochmal ausführlich durch den Kopf (und Taschenrechner)
gehen lassen.

@Lexx00

Es geht natürlich um die PAR - was ist PAP? Pixel aspect proportion?
Habe ich noch nie gehört. Muß nix heißen - ich bin interresierter Laie.
Da man ein existierendes Video fast immer in anderer Form verarbeitet (cropping/resizing/
macroblockoptimierung) ist das Wissen um die (beim Digitalisieren) verwendete PAR wichtig.

@Shh

>Da sind *auch* die 52µs pro sample gemeint.

Du meinst sicher pro Zeile - oder? ;-)

>kann sich nur noch die blanking-Spanne ändern. Da heißt's ja auch speziell
>*digitales blanking*. D.h. die blanking-Spanne ist bei digitaler Abtastung ...

Verstehe ich nicht. Ich denke, da wird ein analoges Signal mit einem fixen Takt digitalisiert?
Wie kann sich da die blanking-spanne ändern?

>die Tatsache, daß in der MPEG2-Norm eine 4:3 generic verabschiedet wurde .....

Jetzt muß ich die MPEG2-Norm wohl auch noch lesen und vor allem begreifen :-((

>PAR ist auch immer gleich: 59/54

Wie in diesem Fall auszurechnen?



Klärt mich bitte auf! Ich WILL das begreifen.

Gruß Karl

[Lexx00]

[shh]

> die 52µs pro sample

Nein das ist komplett verkehrt. [Schande über mich].
Da hab ich wirklich <einen Wert> pro Zeile gemeint und so falsche Schlußfolgerungen gezogen. Ich war da auf die pixelclock aus.
Du hast da natürlich Recht, da muß der sichtbare Bereich (bei 720) breiter sein.
Also auch die blanking-Spanne kürzer sein - so meinte ich das.
Wir hatten im Grunde das Gleiche gemeint, nur ich habe mich verwirren lassen.
[Mensch, das ist aber auch kompliziert...]

> Verstehe ich nicht. Ich denke, da wird ein analoges Signal mit einem fixen Takt digitalisiert?
> Wie kann sich da die blanking-spanne ändern?

Wenn die Zeile immer 64µs hat und man einmal 52µs sichtbar (bei 702) und einmal mehr sichtbar (bei 720) hat, da hat sich die blanking-Spanne geändert. Wohlgemerkt, wir vergleichen hier aber Äpfel mit Birnen. Am TV bleibt das ja immer bei 52µs, der PC ist da flexibel und digitalisiert je nach Einstellung auch ein bischen mehr "Rand" mit.
(Im Grunde ändert sich die Spanne nicht, sie ist nur verschieden)

> MPEG2-Norm eine 4:3 generic

Norm kann ich dir "liefern".
Da steht aber nichts über die echte, wirkliche aspect-ratio drin. Diese Freiheit läßt die DVD-Macher natürlich auch machen was sie will.

>>PAR ist auch immer gleich: 59/54
> Wie in diesem Fall auszurechnen?

Welcher Fall?
Das Problem ist, daß es für die "generic 4:3" kein konstantes Umrechenschema gibt. Ob die Quelle nun ITU-konform war oder nicht, im MPEG-stream kann man die flags nur auf 4:3 generic oder 16:9 (=anamorphic) setzen.

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

[Kika]

Um nochmal was dazu zu sagen: eigentlich haben sich einige Leute (hauptsächlich wohl nur Leute wie wir) darauf geeinigt, nach der ITU zu rechnen, um überhaupt sowas wie einen gemeinsamen Ausgangspunkt zu haben.
Und selbst dann bekommt man noch sehr schnell einen Knoten ins Hirn.

> im MPEG-stream kann man die flags nur auf 4:3 generic oder 16:9 (=anamorphic) setzen

Was das betrifft bin ich ehrlich gesagt nicht sicher. Bei CCE ist es so, aber ich glaube, das TMPGEnc da auch anderes reinschreiben kann. Jedenfalls bekomme ich bei PowerDVD bei TMPGEnc-Streams nicht 4:3 Generic angezeigt, sondern was anderes.
Muss ich aber zu hause nochmal nachschauen. Also nicht verunsichern lassen ;)

[shh]

> > im MPEG-stream kann man die flags nur auf 4:3 generic oder 16:9 (=anamorphic) setzen
> Was das betrifft bin ich ehrlich gesagt nicht sicher

Nun, das ist so. Zusätzlich ist noch 2.21:1 und 1:1 möglich.
Zumindest im Sequence-header.

TMPGEnc steckt noch eine "Display Sequence Extension" rein, wo man "Pan and Scan"-Info über die Auflösung setzen könnte. Sowas wird aber von den meisten Playern ignoriert.

Mehr gibts nicht.

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

[Der Karl]

@Lexx00

>Wenn ein 625 Zeilen analoges PAL Signal (nach ITU-R BT.470-3) in quadratische Pixel zerlegt wird..

Kannst Du bitte mal sagen, worauf Du Bezug nimmst? Ich finde in der Rec. ITU-R BT.470-3 nichts
dergleichen.

>gültigem Industriestandard 14,75 Millionen Pixel pro Sekunde...

Genau dieses ist ja umstritten: "gültiger Industriestandard". Das Problem ist, das jeder was
anderes meint, aber denkt.....
...ich dachte auch mal....siehe Threadanfang....

>..digitalen 625 Zeilen-Standard mit 13,5/14,75 = 54(13,5*4)/59 (14,75*4)und somit ein PAP von 1,0926(59/54)...

14.75 digitalisiert _nicht_ den gleichen Bereich wie 13.5 MHz. Insofern ist diese Rechnung unzulässig.
Bezieht man sich auf die - hoffentlich richtigen - 52 us "aktiver Videoinformationen", würden in Deinem
Beispiel die 768 = 52.06780 us entsprechen, bzw. es wären nur ~767 "aktive" Pixel.
Und schon stimmt die PAR nicht mehr....

Die "korrekte" Samplingfrequenz wäre in diesem Fall 14 + 10/13² - angeblich CCIR+-Konform.
http://www.uwasa.fi/~f76998/video/conversion/
Immer vorausgesetzt, der reale Bezug sind die 52 us.

Es geht - wohlgemerkt - nicht ums Rechthaben, sondern darum, Grundlagen zu begreifen - mir zumindest ;-)
Die Differenzen sind ohnehin so klein, daß niemand den Unterschied sehen würde.


@Shh

>[Mensch, das ist aber auch kompliziert...]

Eben, eben.... ;-)

>Wenn die Zeile immer 64µs hat und man einmal 52µs sichtbar (bei 702) und einmal mehr
>sichtbar (bei 720) hat, da hat sich die blanking-Spanne geändert......

Klar meinen wir das Gleiche. Das Problem ist ja noch besser, denn es ist noch nicht mal klar, daß die 2*9
Pixel "Overscan" wirklich schwarz bleiben müssen. Da könnten durchaus noch ein paar mehr aktive Pixel sein,
je nachdem, was die Sendeanstalten da so treiben....

>Am TV bleibt das ja immer bei 52µs, der PC ist da flexibel und digitalisiert je nach Einstellung auch ein
>bischen mehr "Rand" mit.

Eben nicht. Alle Capture-Geräte, die ich kenne, die angeblich 720*576 nach CCIR bzw. ITU unterstützen,
machen das falsch. Es wird zu wenig digitalisiert - sprich: die 52 us werden auf 720 Pixel "gestreckt".
Das betrifft zumindest die weitverbreiteten BT-basierenden und die ATI-Grakas mit Video in.

>Norm kann ich dir "liefern".

Sehr willkommen! :-))
Geht das per Mail?
Vielen Dank.

>im MPEG-stream kann man die flags nur auf 4:3 generic oder 16:9 (=anamorphic) setzen

>Nun, das ist so. Zusätzlich ist noch 2.21:1 und 1:1 möglich.
>Zumindest im Sequence-header.

Da ich mich MPEG2 gar nicht auskenne, muß ich hier doch mal eine dumme Frage loswerden.
Wie werten die Wiedergabegeräte (Soft-/Hardware-DVD-Player) denn aus, wie das Bild zu entzerren
ist? Bzw. wird eine Generic-PAR von z.B. 1:1.0667 evtl. in jedem Fall falsch entzerrt?

Gruß Karl

[bergH]

tach auch !

@shh
Drin ! ;)
Eigentlich nehme ich nur Sachen auf die ich halbwegs verstehe! ?

[OffTopic]
Eigentlich wollte ich doch nur einen MP3 Player kaufen, Was es gibt auch DVD-Player die das können ?, Gut !, was ist den einen Video-CD ?, Super VCD ?, mal gucken ?,
TMPGenc ?, was sind das für komische Zeichen, ah ja japanisch, 4:3,16:9, interlaced, anamorph, Matrizen (Brrr) na gut, PAR, SAR, ITU-R ............= Bahnhof !

Und jetzt verdient Bayer an mir , wenn ich Eure Posts lese :angry: ==> Aspirin !

Zurück zum Thema .
_________________
Gruß BergH

[Kika]

@BergH

Oops, lass' bloß das SAR aus dem Spiel, damit wird's vollends kompliziert, und spätestens an diesem Punkt verliere ich die Bodenhaftung.
PAR und DAR sind schon kompliziert genung, aber das SAR... jauuuulll... ;)

@Karl

>Es wird zu wenig digitalisiert - sprich: die 52 us werden auf 720 Pixel "gestreckt".

Eben, eben, das versuche ich auch schon ewig den Leuten beizubringen. Nur kämpfe ich da gegen Windmühlen, da die Dokus was anderes aussagen...

shh hat aber duraus auch Recht wenn er sagt, dass z.B. die BT-Chips ein wenig mehr capturen. Zumindest laut Spezifikation tun sie das auch, aber eben nicht mit einem Timing, das für "echte" 720x576 nötig wäre.
Das Ergebnis ist dann ein von 704 auf 720 gestrecktes Bild, das somit ein falsches PAR hat.
Ist doch auch eigentlich logisch, denn mir ist keine einzige Spezifikation bekannt, bei der von analog mit mehr als 704 Pixeln ausgegangen wird.

[SVCDFan]

Da darf ich bloß nicht dran denken, was AV.Master bei 768x576 dann macht...??
_________________
Gruß SVCDFan

[Kika]

@SVCDFan

Keine Bange, der macht's ja halbwegs richtig, nimmt nur halt beim PAR 1:1 statt 1.0926:1. Als Ausgleich dafür nimmt er ja die 768 statt der 704 Pixel, und dann stimmt ja alles wieder.

704 bei PAR 1.0926:1 = 768 bei PAR 1:1
Nur diese 720 bei PAR 1.0667 (wegen DAR von 4:3), die sind verkehrt, da EXAKT das gleiche Bild aufgezeichnet wird wie bei der Einstellung 704 oder 768, dann aber eben mit einem falschen PAR.

[SVCDFan]

@Kika

Dann bin ich ja beruhigt

Habe eben den technischen Teil der Anleitung zu AV.Master angeschaut. Dort steht, daß mit 14,75 Mhz abgetastet wird, also 52 us x 14,75 Mhz = 767..

Aber ich glaube daß ich etwas offtopic zu diesem Thread bin. Deswegen ziehe ich mich in den Hintergrund zurück, da ich mich mit der Materie nicht so gut kenne...
_________________
Gruß SVCDFan

[shh]

> mehr/weniger capturen

Das kann ich leider nicht kontrollieren weil mir eine TV-Karte fehlt. Ich habe das nur den Norm-Worten entnommen.
704 und 720er MPEG-Formate müssen aber gleiche PAR haben sonst würden sie falsch dargestellt. Beide Videos haben dann nämlich das gleiche bit gesetzt (insgesamt gibts im seq.header nur 4(!) aspect-ratios: 1:1,4:3,16:9,2.21:1. Die Extenstion ist nicht notwendig)
704 und 720er MPEGs sehen übrigens am Player auch gleich aus.
=> PAR ist const 59/54 für 704 und 720er Auflösung.
Nur die capture-Karten (Treiber?) machen da anscheinend Mist.
Somit ist es auch richtig, beim Umwandeln von 704 zu 720pixel einfach 16pixel dranzukleben.

> Bzw. wird eine Generic-PAR von z.B. 1:1.0667 evtl. in jedem Fall falsch entzerrt???

Sowas ist nicht zu kontrollieren, weil die meisten TVs schon falsch justiert sind. Was möchtest du als Referenz hernehmen? Ein normales TV-TestBild? (traust du dem Sender?). Ein 704/720-Bild und den TV danach einstellen? (So habs ich gemacht)
> Generic-PAR von z.B. 1:1.0667
...kann man im übrigen nicht einstellen. Nur 4:3 und das muß dann vom DVD-Player richtig gedeutet werden. Außerdem hat man natürlich richtig zu resizen und den TV i.a. zu korrigieren.

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

[Lexx00]

@Der Karl