PAL Video Signalschrieb

Ich habe auf meiner alten Homepage noch so eine Datei rumliegen. Ist allerdings nur ein Frame (1/25s), mehr gab meine Hardware von damals nicht her. Das Ganze ist mit 16Mhz abgetastet und mit 8 Bit quantisiert, das sind dann genau 625 Zeilen mit je 1024 Pixel:

Zu Burst, Filter und sonstigem steht da auch noch einiges...

Evtl. hilft Dir das ja etwas weiter.

Helge

=20

composite=20

=20

quantisiert,

Sehr sch=F6n. Habe ich nat=FCrlich sofort ausprobiert. Mit der Bilddekodierung (also insebesondere Farbe) scheine ich halbwegs klar zu kommen.

richtig

Stimmt.

Mich hat ITU-R BT.470-6 etwas verwirrt. Da ist u.a.a. von "Curve of pre-correction for receiver group-delay characteristics" die Rede, anscheinend bezogen auf die leicht asymetrisch Nennbegrenzung der=20 Bandbreite des Chroma-signals. Besonders selbsterkl=E4rend ist der Text=20 leider nicht.

Na ja, f=FCr meine Zwecke reicht das jetzt erstmal, wenn ich noch = irgendwo Infos =FCber die vertikalen Sync-Signale herbekomme. Eigentlich werden = die=20 gar nicht ben=F6tigt, weil bereits durch die Burststruktur=20

9 Zeilen ohne Burst I. 303 Zeilen mit Burst 9 Zeilen ohne Burst II. 303 Zeilen mit Burst 9 Zeilen ohne Burst III. 303 Zeilen mit Burst 9 Zeilen ohne Burst IV. 305 Zeilen mit Burst

gegeben.=20

Mir geht es aber darum, Videodaten an ein anderes Ger=E4t weiterzugeben, =

so da=DF ich wohl besser auch zus=E4tzlich passende vsyncs erzeuge (wie haben die auszusehen?).

Gruss

Jan Bruns

Ich kenne diesen Text jetzt nicht. Ich hatte damals allerdings den Eindruck, dass viele der erwähnten Korrekturen nur bei analoger Signalverarbeitung eine Rolle spielen (ein TP hat z.B. auch immer eine Verzögerung zur Folge). Ich habe bei mir nichts dgl. implementiert.

[...]

??? Wie meinen? Der Burst ist doch im horizontalen Sync-Bereich. Meinst Du die Codierung der Vor- und Nachtrabanten der V-Sync (mit doppelter Zeilenfrequenz). Dazu meine ich mich zu erinnern was im Datenblatt des LM1881 gelesen zu haben (da ging es um die odd/even-Erkennung, die damit zusammenhängt).

Helge

die

der=20

Text=20

=20

Hm. Wenn z.B. der Ausgang (d)eines Videorekorders diese Vorkorrktur verwendet, muss die aber gerade/nur dann, wenn man keine entsprechenden Analogfilter beim ADC verwendet, noch wieder herausgerechnet werden.

Die Curve ist um 4.4Mhz eine Gerade, und besagt:

3.75 MHz: 0 ns 4.43 MHz: -170 ns 4.80 MHz: -260 ns oder Alternativ -400 ns

Das w=FCrde wohl bedeuten, da=DF man in farbigen Bereichen mit starkem=20 Farbkontrast Farbfehler h=E4tte.

Zugegebenermassen habe ich bei deinen Messdaten tats=E4chlich noch solche Fehler (was allerdings auch an den verwendeten Filtern liegen = kann).

irgendwo

werden die=20

=20

Ja. Normalerweise schon. Nur bei Halbbildwechseln eben f=FCr 9 Zeilen = lang nicht. Wenn man die Zeilen mit Burst z=E4hlt, erh=E4lt man einen von 2 = M=F6glichen Werten. Einer dieser beiden Werte hat zur Folge, da=DF das auf den Burstfreien = Bereich folgende Halbbild das erste einer 4er-Sequenz ist.

So lese ich das jedenfalls in der ITU-R BT.470-6

Von einem "Weglassen"/Verschieben des horizontal-Sync (wie in der Mitte = deines=20 Messchriebes besonders deutlich zu sehen) ist in dem Text allerdings = nirgends=20 etwas zu erkennen, da gibt es allenfalls=20 "zus=E4tzliche horizontal-syncs mitten in der Zeile".

Gruss

Jan Bruns

"Jan Bruns":

Verschoben. Nochmal:

Nach diesem ITU-Dingens sollte die Sync-Struktur eigentlich ungef=E4hr = so aussehen:

v und leerzeichen =3D h-sync level

• =3D blanking oder black-level ? =3D signal, also mindestens black-level

I.1 :v ** **: I.2 :v ** **: I.3 :v ** *******: I.4 :v******* *******: I.5 :v******* *******: I.6 :v **************: ######################### 303 Zeilen Bild mit Burst I.310 :v???????????????: I.311 :v******* *******: I.312 :v******* *******: I.313 :v******* ***:II.313 II.314 :v *** ***: II.315 :v *** ***: II.316 :v******* *******: II.317 :v******* *******: II.318 :v***************: ######################### 303 Zeilen Bild mit Burst II.622 :v???????????????: II.623 :v??????? *******: II.624 :v******* *******: II.625 :v******* *******: III.1 :v *** ***: III.2 :v *** ***: III.3 :v *** *******: III.4 :v******* *******: III.5 :v******* *******: ######################### 305 Zeilen Bild mit Burst III.311:v******* *******: III.312:v******* *******: III.313:v******* ***:IV.313 IV.314 :v *** ***:=20 IV.315 :v *** ***:=20 IV.316 :v******* *******:=20 IV.317 :v******* *******:=20 IV.318 :v***************:=20 IV.319 :v *************:=20 ######################### 303 Zeilen Bild mit Burst IV.623 :v ?????? *******: IV.624 :v******* *******: IV.625 :v******* *******: I.1 :v ** **: I.2 :v ** **: I.3 :v ** *******: I.4 :v******* *******: I.5 :v******* *******: I.6 :v **************: ######################### 303 Zeilen Bild mit Burst

Wie man sieht, fehlt nirgends der h-sync. Was dieses eigenartige Muster soll, und wie wichtig seine Einhaltung = ist, weiss ich nicht. Die Zeichnung, der ich diese =DCbersicht entnommen = habe,=20 macht allerdings nicht den Eindruck, als h=E4tte dieses Muster eine=20 gesteigerte Bedeutung.

Gruss

Jan Bruns

Man darf keine Annahmen darüber treffen, von welchem Gerät das Signal stammt. Der Videorekorder würde auch allenfalls eine Nachkorrektur der Bandbreitenquetsche des Videobandes vornehmen, so dass ein angeschossener TV ein brauchbares Bild anzeigt.

Also meine Messdaten kamen direkt über Antenne -> TV -> Scart ->

Framegrabber. Der Signalweg über Antenne (HF) ist ja von sich aus verlustbehaftet im Sinne von signalverzerrend (Restseitenband-Modulaton). Bei mir habe ich auch leichte Farbfehler an Kontrasten, diese werden aber durch die PAL-Kompensation aufgehoben.

Ich wollte dies eben in meinem alten Vorlesungsskript nachlesen und kam nach einigem Suchen zu dem Schluss: Verleihe niemals etwas, was Du irgendwann nochmal brauchen könntest. Keine Ausnahme! Gibt es Deinen Text mit dieser komischen Nummer auch online?

[Du hast mittlerweile das Sync-Diagramm gepostet.] Also nun aus dem Gedächtnis. Man hat das Zeilensprungverfahren. Bei 625 Zeilen gibt es zwei V-Syncs, einer davon ist um eine halbe Zeile versetzt (Zeile II.313). Und dann ist da die alte Analogtechnik, wo man die V-Syncs mit billigen Filtern trennen möchte. Damit das Bild nicht wackelt, sollen die beiden Bereiche um die V-Syncs bei Zeile I.1 und II.313 möglichst gleich aussehen, also hat man zusätzliche H-Syncs bei der halben Zeile eingefügt (damit die Filter Zeit haben, sich einzuschwingen). Um das Verhältnis Sync Bild gleich zu lassen, sind die doppelten H-Syncs dafür kürzer. Die V-Syncs sind dann entsprechend darübermoduliert, indem in den betreffenden 5 Halbzeilen die H-Sync-Pulse verlängert wurden (die Signalwechsel Schwarz -> H-Sync bleiben dabei erhalten, so dass die horizontale Ablenkeinheit nicht gestört wird). Einige Zeiten dazu stehen in dem vom mir erwähnten Datenblatt (die Version von 1995 steht mal kurzfristig auf ).

Helge

=20

entsprechenden

=20

Signal

der

Stimmt. Aber man ein =DCbertragungssystem anhand von = Empf=E4ngereigenschaften definieren. Wenn dann ein Empf=E4nger eine solche Eigenschaft nicht hat, = muss er die Eigenschaft emulieren.

starkem=20

=20

kann). =20

Sieht auch nicht nach VHS-Qualit=E4t aus...

=20

kam

Ja, aber stressig:

Erst unter

"I wish to REGISTER in order to download up to three (3) Recommendations =

free of charge" w=E4hlen, und das folgende Formular ausf=FCllen.

Auf Passwort per email warten, und dann unter

-BT.470

downloaden. =20

Mitte deines=20

nirgends=20

=20

625

Schon, aber diese v-syncs scheinen keine physikalischen signale, sondern lediglich eine logische Bezeichnung zu sein.

nicht

bei

Verstehe ich nicht wirklich.

Du meinst, die alten SW-TVs haben mit einem Analogfilter die

2-(oder 4)-fache Zeilenfrequenz gesiebt, und dann je nach phasenlage (bezogen auf Zeilenfrequenz) entschieden, ob 1. oder 2. Halbbild?

Vielleicht hat deine konkrete Schaltung die Messwerte bei den vsyncs verf=E4lscht (wie gesagt, es ist in den Messwerten ein fehlender, und=20 mehrere zu kurze hsyncs zu sehen)?=20 Der ADC hatte ja anscheinend so eine AGC-Funktion, usw.

Gruss

Jan Bruns

Nun physikalisch sind sie schon irgendwie drin im FBA*S*-Signalgemisch. Die Idee damals war, dass man nach Synchronpulsabtrennung nur noch einen HP braucht, um die H-Syncs zu gewinnen, und einen TP für die V-Syncs.

[...]

Nein, wie oben beschieben. Der TV braucht nicht zu wissen, dass es Halbbilder gibt. Man hatte damals nur herausgefunden, dass bei den (gewünschten) billigen Filtern in den Endgeräten, die beiden Halbbilder nicht genau passig übereinanderlagen, eben weil bei den geraden Halbbildern der V-Sync wegen der überlagerten H-Syncs etwas zu früh/spät kam. Da lies man sich damals dieses Verfahren einfallen, dass es um den V-Sync herum doppelte H-Syncs gibt.

Nein, die Verkürzung der H-Syncs ist in dem Signal drin. Das Datenblatt des LM1881 gibt hier Werte von 4,7µs rsp. 2,4µs an (dürfte aber NTSC sein).

Das Einzige, was in dem Signal nicht ganz stimmen könnte, ist die erste Zeile, die u.U. nicht vollständig ist. Mein ADC hat tatsächlich ein AGC, dies ist allerdings videosignaloptimiert. Der Synchonimpuls wird auf knapp über 0 geklemmt und der Schwarzwert bei 64. Dafür musste ich den Chip mit entsprechenden Signalen aus dem LM1881 fütten, kommen diese Signale nicht, dann regelt auch nix.

Helge

Jan Bruns schrieb:

aussehen: ...

Helge hat das schon richtig beschrieben, als Ergänzung nochmal die Syncs und das Ergebnis des Tiefpasses im Fernseher:

Hier sind die Syncs invertiert, nach der Abtrennung vom Signal. Der Burst hat nur eine Bedeutung für die Phasennachregelung des Farbhilfsträger-Oszillator. Eine s/w Kamera erzeugt zB gar keinen Burst.

Gruß Jens

"Jens Dierks":

ungef=E4hr so aussehen: ...

ist,

=20

...hat mir aber gleichzeitig ein weitreres pdf geschickt, in dem erneut = das=20 Gegenteil erkennbar ist (kein ausbleiben des hsyncs beim vsync).

Eine Verk=FCrzung des hsyncs hingegen ist im ITU-Schrieb allerdings = erkennbar (nicht aber in der Reproduktion von mir).

Da ist nun aber ein ausgelassener hsync zu sehen.

Ansonsten ist uns wohl allen klar, da=DF zum vsync das Tastverh=E4ltnis = des sync-signals verwendet wird. =20

Das stimmt nicht. Man kann ihn, wie beschrieben, auch als vsync-quelle = nutzen. Das ist in Digitaltechnik evtl. auch einfacher. Zur Farbdekodierung muss = man ohnehin zwischen 1. und 2. *Voll*bild unterscheiden. Das geht (soweit = ich das sehe)=20 eigentlich nur =FCber die Burststruktur.

Die Unterscheidung zw. 1. und 2. Vollbild ben=F6tigt man wiederum zur = Deutung der Burst-Phasenlage.

Dann erzeugt sie auch kein PAL.

Gruss

Jan Bruns

Wo ist das ein Gegenteil? Ich habe nie geschrieben, dass die hysncs ausbleiben, Zitat: |(die Signalwechsel Schwarz -> H-Sync bleiben dabei erhalten, so dass | die horizontale Ablenkeinheit nicht gestört wird)

Ich sehe keinen. Überall, wo ein Z steht ist da auch eine Sync-Flanke.

[Burst]

Ich kann mir ehrlich gesagt nicht vorstellen, dass das tatsächlich gemacht wird. Zumal man dann auf die Abwärtkompatibilität zu S/W-Quellen (wie sie es auch heute noch z.B. bei Überwachungskameras gibt) verliert.

Helge

Hallo,

ich habe mal folgendenden Generator geschrieben. Verwendet beliebig grossen Bildspeicher im PAL-YUV-Format, und liefert f=FCr beliebige Zeitpunkte t dann die=20 Ausgangsspannung pal_out(t). Ich hoffe, die ist nicht allzuweit=20 vom realen Standard entfernt.

Gruss

Jan bruns

CONST framespersec =3D 25; linecount =3D 625; linefreq =3D framespersec*linecount; // =3D 15625

blanking_level =3D 0; black_level =3D blanking_level + 0; white_level =3D 100; sync_level =3D -43; burst_peakpeak =3D (white_level-blanking_level)*3/7;

pixelstart =3D 12/64; //horizontal sichtbarer Bereich pixelend =3D 64/64; hsyncstart =3D 1.5/64; hsyncend =3D hsyncstart + 4.7/64; burststart =3D hsyncstart + 5.6/64;=20 burstend =3D burststart + 2.25/64;=20

vsynclen =3D 25 + 12/64; // vsync umfasst einige blank-Zeilen eq_pulselen =3D 2.35/64; sncpulselen =3D 27.3/64;

feld2 =3D 311; feld3 =3D 623.5; feld4 =3D 311 +625; feld1 =3D 623.5+625;

cfreq =3D ( 1135/4 + 1/625 ) * linefreq; // 4.43 MHz

burst_U =3D cos(135/180*pi); burst_V =3D sin(135/180*pi);

pixelperline =3D 100; //bedeutungslos

VAR Pixel_Y, Pixel_U, Pixel_V : ARRAY[1..linecount,0..pixelperline-1] of real;

FUNCTION get_line_from_time(t : real) : integer; // bezogen auf Vollbild BEGIN get_line_from_time :=3D 1 + floor(t*linefreq) MOD (2*linecount); END;

FUNCTION get_fractional_line(t : real) : real; // x-Position in Zeile BEGIN get_fractional_line :=3D frac(t*linefreq); END;

FUNCTION chroma(u,v,t : real) : real; BEGIN chroma :=3D u*sin(2*PI*cfreq*t) + v*cos(2*PI*cfreq*t) END;

FUNCTION composite(y,u,v,t : real) : real; BEGIN composite :=3D y + chroma(u,v,t); END;

FUNCTION scaled_composite(y,u,v,t : real) : real; BEGIN scaled_composite :=3D black_level + composite(y,u,v,t) * (white_level - black_level); END;

FUNCTION no_burst(l : integer) : boolean; BEGIN case l of 1248,1249,1250, 1,2,3, 4,5,6, 310,311,312, 313,314,315, 316,317,318, 622,623,624, 625,626,627, 628,629,630, 936,937,938, 939,940,941, 942,943,944 : no_burst :=3D true; else no_burst :=3D false; end; END;

FUNCTION burst_sign(l : integer) : integer; BEGIN if (l MOD 2) =3D 1 then burst_sign :=3D 1 else burst_sign :=3D -1; END;

FUNCTION burstval(t : real) : real; BEGIN burstval :=3D (burst_peakpeak/2) * = chroma(burst_U,burst_sign(get_line_from_time(t))*burst_V,t); END;

FUNCTION burst(t : real) : real; BEGIN if (no_burst(get_line_from_time(t)) ) or (get_fractional_line(t)burstend ) then burst :=3D blanking_level=20 else burst :=3D burstval(t) + blanking_level; END;

FUNCTION pixelval(t : real) : real; VAR q : real; p,l,pl : integer; BEGIN q :=3D get_fractional_line(t); if (q>=3Dpixelstart)and(q=3Dpixelperline then p :=3D pixelperline;

l :=3D get_line_from_time(t) - 1; l :=3D l MOD linecount; pl :=3D (l MOD 314) * 2 + 1; if l>=3D314 then pl +=3D 1;

pixelval :=3D scaled_composite( pixel_Y[pl][p], pixel_U[pl][p], pixel_V[pl][p] * burst_sign(l+1), //PAL t ); end else pixelval :=3D blanking_level; END;

FUNCTION hsyncval(t : real) : real; BEGIN if (get_fractional_line(t) > hsyncstart) and (get_fractional_line(t) < hsyncend ) then hsyncval :=3D sync_level else hsyncval :=3D blanking_level; END;

FUNCTION pal_out(t : real) : real; VAR q,q2 : real; BEGIN pal_out :=3D blanking_level; q :=3D get_fractional_line(t) + get_line_from_time(t); q2 :=3D -1; if (q=3Dfeld2)AND((q-vsynclen)=3Dfeld3)AND((q-vsynclen)=3Dfeld4)AND((q-vsynclen)=3Dfeld1) then q2 :=3D q-feld1; if q2>=3D0 then begin // *********vsync*******************

if (q2=3D5)AND(q2

erneut das=20

=20

Oh, entschuldige. Da habe ich deine Aussage etwas =FCberinterpreiert:

|> Vielleicht hat deine konkrete Schaltung die Messwerte bei den vsyncs |> verf=E4lscht [..]?=20

|Nein, [..] |Das Einzige, was in dem Signal nicht ganz stimmen k=F6nnte, ist die = erste |Zeile, die u.U. nicht vollst=E4ndig ist.

Sorry.

=20

vsync-quelle nutzen.

=20

Wenn die Situation vorliegt, da=DF man ohnehin Zeile f=FCr Zeile die = Farbreferenz neu synchronsiert, kann man auch gleich mitz=E4hlen, wie oft man das = gemacht hat (Zur Unterscheidung 305/307 gen=FCgt ein 2-bit Z=E4hler).

verliert.

Die Abw=E4rtskompatiblit=E4t verliert man doch fr=FChestens, wenn man = auf die=20 Tiefpassmethode vollst=E4ndig verzichtet...

Hier mal einige Dinge, die ein digitales Fersehger=E4t sicherlich = brauchen wird:

1 samplecounter 1 comperator sync-detect 2 Adressdekoder farbabgleichsbeginn/ende 2 multiplizierer farbabgleich, ca. 8 Bit 1-2 koeffizientenroms ca. 16x8 2 farbabgleichsspeicher je ca. 16 bit

Zus=E4tzlich:

a) Burstfreiezeilenz=E4hlmethode: - zero-detects bei den farbabgleichsregistern - ein 2-bit Zeilenz=E4hler - ein AND-gate zw. Zeilenz=E4hler_MSB und Farbregister-zero-detect - ein 2-bit Z=E4hler f=FCr "Seitenwahl"

b) vsync-erkennungs-methode: - ein 1-bit Z=E4hler f=FCr "Seitenwahl" - ein AND-Gate zw. farbabgleichsbeginn und sync-detect

Es ist also vom Aufwand her vollkommen egal, ob nun die eine, oder die = andere,=20 oder beide methoden verwendet werden.

Dank noch mal, f=FCr die Bem=FChungen.

Gruss

Jan Bruns

Jan Bruns schrieb:

Die Hsyncs bleiben nicht aus, beim Vsync sind das alles Halbzeilenimpulse, an deren Anzahl vor oder nach den breiten Vsyncs kann man ganz gut

1. und 2. Halbbild erkennen.

Ja, weil es auch die doppelte Anzahl von Impulsen sind.

sehe)

Ne, wiegesagt ist die besondere Struktur der Syncs dazu gedacht. Die Anzahl der Bursts in den Halbbildern ist meines ersachtens auch nicht genormt. Farbkameras können zB auch unterschiedliche Zeilenanzahlen (mit Bildinhalt) haben, ob sie in den leeren Zeilen auch Bursts generieren weiss ich jetzt nicht. Würde ich mich aber nicht drauf verlassen.

Richtig, deswegen wäre es besser wenn man das an den dafür vorgesehenen Erkennungsmerkmalen feststellt.

Ne, aber BAS (Bild-Austast-Synchron). Bei FBAS kommt dann die Farbe dazu, die bei uns halt in PAL kodiert ist (phase alternated lines, oder so ähnlich). Alles andere ist wie gehabt, inklusive der Bildsynchronisation.

Gruß Jens