Synchronisation und Deinterlacing bei Ausgabe via xine

Trainee

Sunday, March 1st 2009, 10:51am

Es gibt ja diverse Threads und einige ausgezeichnetes Patches, die sich mit der Verbesserung der VDR-Ausgabe über Grafikkarten beschäftigen. Ich möchte hier mal einen kleinen - mehr theoretischen - Denkanstoß geben, indem ich das Problem mal ein wenig aus der Sicht der Nachrichtentechnik beleuchte.

Als die Digitalisierung in den Telefonnetzen Einzug hielt, stand man vor einem ähnlichen Problem, wir wir es haben. Wie sorgt man dafür, dass alle Multiplexer, Übertragungssysteme etc. so miteinander synchronisiert, werden, dass ein einziges Bit an Information verloren geht. Es gab zwei Möglichkeiten:

a) synchrone Netze, d.h. alle Komponenten laufen mit dem selben Mastertakt und definierter Phasenlage

b) plesiochrone Netze, d.h die Komponenten laufen alle mit ähnlichem Takt, der aber Toleranzen aufweist.

Lösung a) ist enorm aufwendig, da die Verteilung des Taktes weltweit kaum möglich ist und daher immer nur Teilnetze wirklich synchron realisierbar sind.
Man hat sich daher zu Anfang der Digitalnetze für ein plesiochrones System entschieden und erst viele Jahre später auf synchrone Netze umgestellt.
Fernsehen ist insgesamt immer plesiochron. Es ist schlichtweg unmöglich, jede Außenkamera, die in eine Live-Sendung zugeschaltet wird, immer auf den Studiotakt zu synchronisieren. Natürlich treiben die Broadcaster schon einen sehr hohen Aufwand um so synchron wie möglich zu sein.
Ich möchte daher unseren VDR mal mit einem plesiochronen Empfänger vergleichen:

Als erstes muß ich im Empfänger eine Taktrückgewinnung aus dem Empfangssignal machen. Das erledigt die DVB-Karte. Dann wird das Empfangssignal mit diesem Takt abgetastet. Das abgetastete Signal geht durch einen Dejitterizer, in dem das Phasenrauschen des Taktes und Signales beseitigt wird. Danach erfolgt die Übergabe an die weitere Prozessstufen wie z.B. einem DeMultiplexer, die mit dem abweichenden lokalen Takt läuft. Die Anpassung erfolgt dadurch, dass innerhalb eines Rahmens sogenannte Stopfbits, die keine Signalinformation tragen, weggelassen oder hinzugefügt werden. Das gleiche machen sparkie und durchflieger mit ihren Patches letztendlich, indem sie die Blank- oder Synchronsignale verlängern bzw. verkürzen.
Wo wir meines Erachtens Verbesserungspotential haben, ist bei der Taktrückgewinnung und dem Dejitterizer.
Dazu möchte ich ein wenig rechnen. Die Toleranz für die Zeilen- und Bildfrequenzen im Fernsehsignal beträgt 10e-6. Wenn ich eine gleich genaue Videoausgabe hätte, wäre die maximale Abweichung 1 Halbbild in 166 Minuten ! Das bedeutet, es sollte grundsätzlich kein Problem sein, eine Grafikkarte selbst im Interlace-Mode frei laufen zu lassen. Man müsste nur ganz selten ein Halbbild fallen lassen oder verdoppeln. Selbst, wenn unsere Grafikkarte nur 10e-5 Genauigkeit hat, wäre ein Halbbild in 16 Minuten immer noch kein Problem. Die Praxis sieht ganz anders aus. Das Bild springt im Minutentakt, manchmal sogar im Sekundentakt, zwischen richtiger und falscher Field-order. Schaut man sich das Regelverhalten der durchflieger Patche an, sieht man, dass wir keineswegs eine konstanten Drift ausregeln, sondern es geht ziemlich hin und her. Eine Ursache dürften Schnitte und Übertragungsfehler im DVB-Signal sein, aber ich vermute, dass vor allem die schwankende Durchlaufzeit des Signals durch den VDR + xine +++ hier für viel Unruhe sorgt.
Aus meiner Sicht sehe ich folgenden Weg für interessant an:

1. Das Timing der Videoausgabe muß möglichst genau auf echte 50 Hz eingestellt werden. Dazu wäre es interessant, wenn wir mal messen würden, wie genau die Quarze auf den Karten wirklich sind, und evt. Abweichungen des Quarzes dauerhaft über die Modeline kompensieren.

2. Der Mastertakt für die Ausgabe muss aus dem DVB-Signal der DVB-Karte gewonnen werden. Das könnte eventuell im Treiber oder möglichst früh im Signalweg des VDR erfolgen. Auf diesen Takt müssen wir unsere Ausgabe synchronisieren.

3. Wenn wir einen vernünftigen Pufferspeicher für einige Frames so steuern, dass die Durchlaufzeit vom Mastertakt bis zur Videoausgabe konstant gehalten wird, bräuchten wir nur noch ab und zu (Halb-)Bilder zu verdoppeln oder löschen, um eine Regelung zu bekommen. Aufgrund der vielen beteiligten Software-Komponenten ist das nicht gerade trivial, würde dann aber auch z.B. mit vdpau funktionieren, ohne dass wir in den Treiber müssen.

Ich hoffe auf eine lebhafte Diskussion

hemonu

Don't Panic !!!

Zotac IONITX-P-E, DD Cine CT V6, Debian Squeeze, Backport-Kernel 3.2.0 plus media_build_experimental, e-tobi VDR 1.7.28 + vdpau, ONKYO TX-SR 606, Panasonic TH-42PZ85E via HDMI

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

2

Sunday, March 1st 2009, 6:14pm

Hi hemonu,

eine sehr informative Diskussionsgundlage, die du hier gepostet hast :tup

Sie bringt die Sache auf den Punkt. Folgendes faellt mir auf Anhieb dazu ein:

Quoted

Originally posted by Hemonu
Wo wir meines Erachtens Verbesserungspotential haben, ist bei der Taktrückgewinnung und dem Dejitterizer.
Dazu möchte ich ein wenig rechnen. Die Toleranz für die Zeilen- und Bildfrequenzen im Fernsehsignal beträgt 10e-6. Wenn ich eine gleich genaue Videoausgabe hätte, wäre die maximale Abweichung 1 Halbbild in 166 Minuten ! Das bedeutet, es sollte grundsätzlich kein Problem sein, eine Grafikkarte selbst im Interlace-Mode frei laufen zu lassen. Man müsste nur ganz
selten ein Halbbild fallen lassen oder verdoppeln. Selbst, wenn unsere Grafikkarte nur 10e-5

Anmerkung 1
die Vertikalfrequenz von Grafikkarten laesst sich nur in einem gewissen Raster ueberhaupt einstellen. Mit dem Radeon Patch komme ich auf eine rechnerische Aufloesung von 0.0014Hz.
Diese wird durch die Praxis bestaetigt. D.h. selbst wenn wir eine unendlich hohe Quarz-Frequenz-Genauigkeit haetten, wuerde das Videotiming einen (wenn auch konstanten) Drift gegen 50Hz aufweisen. Weil wir das Videotiming eben nur in 0.0014Hz Schritten justieren koennen.

Anmerkung 2
Einen Fieldverlust duerfen wir uns leider gar nicht erlauben. Auch nicht 1 Halbbild in 166 Minuten. Weil sich durch einen einzigen Halbbildverlust die Fieldpolaritaet umkehrt. Das bedeutet, wenn sich ein Halbbildverlust anbahnt muss immer zu einem kompletten Frame ergaenzt werden, was dann natuerlich nicht mehr zu vertuschen ist.

Quoted

und falscher Field-order. Schaut man sich das Regelverhalten der durchflieger Patche an, sieht man, dass wir keineswegs eine konstanten Drift ausregeln, sondern es geht ziemlich hin und her. Eine Ursache dürften Schnitte und Übertragungsfehler im DVB-Signal sein, aber ich vermute, dass vor allem die schwankende Durchlaufzeit des Signals durch den VDR + xine +++ hier für viel Unruhe sorgt.

richtig. Es sind viele Faktoren, die hier eine 'schwankende Durchlaufzeit' hervorrufen. Es steckt ja letztlich das ganze Prozess-Scheduling dahinter. In der Praxis sind diese Schwankungen aber erstaunlich gering. Man kann auf einem D945GCLF sogar einen Kernel-Build neben Live-TV herlaufen lassen, ohne dass dies nennenswerte Schwankungen verursacht.

Quoted

1. Das Timing der Videoausgabe muß möglichst genau auf echte 50 Hz eingestellt werden. Dazu wäre es interessant, wenn wir mal messen würden, wie genau die Quarze auf den Karten wirklich sind, und evt. Abweichungen des Quarzes dauerhaft über die Modeline kompensieren.

wie gesagt, das Raster der EInstellgenauigkeit macht so eine Messung eigentlich gar nicht mehr notwendig. Man muss immer mit einem Drift leben. Aber man wird versuchen diesen durch die Regelautomatik immer minimal zu halten. Indem man den Drift so steuert, dass er gemittelt ueber die Zeit zu Null wird.

Quoted

2. Der Mastertakt für die Ausgabe muss aus dem DVB-Signal der DVB-Karte gewonnen werden. Das könnte eventuell im Treiber oder möglichst früh im Signalweg des VDR erfolgen. Auf diesen Takt müssen wir unsere Ausgabe synchronisieren.

gegenwaertig synchronisieren die FRC Patche auf die presentation time stamps (PTS) im MPEG-2 Transport Stream. Indirekt geschieht dies dadurch, dass einfach die Aufruffrequenz der Putimage() Routinen im Xserver als Referenz-'Takt' hergenommen werden. Ich denke schon, dass dieses Vorgehen eigentlich bereits optimal sein muesste.

Quoted

3. Wenn wir einen vernünftigen Pufferspeicher für einige Frames so steuern, dass die Durchlaufzeit vom Mastertakt bis zur Videoausgabe konstant gehalten wird, bräuchten wir nur noch ab und zu (Halb-)Bilder zu verdoppeln oder löschen, um eine Regelung zu bekommen.

ich hatte dies am Anfang sogar genauso implementiert! Hatte am Ende aber feststellen muessen, dass es prinzipiell leider nicht funktioniert, nur ein einziges Halbbild auszulassen (Begruendung siehe oben).

Quoted

Ich hoffe auf eine lebhafte Diskussion

das hoffe ich auch

- sparkie

Go to the top of the page

durchflieger

Professional

Posts: 651

3

Sunday, March 1st 2009, 7:27pm

Es wäre mal interessant wie die FF-Karten die Synchronisation genau machen. Die funktioniert ja bekannter maßen hervorragend. Sowie mir bekannt ist dort die "Master clock" per Hardware regelbar. Hier wäre interresant wie denn genau die Regelspannung gewonnen wird. Auch nur durch Überwachung des Puffersfüllstandes des DVB-Stream oder vielleicht doch durch eine Art Taktrückgewinnung?

Um die bereits in den FRC-Patches implementierte Regelungen zu verbessern hätte ich noch die Idee, die xine "master clock" direkt auf dem Timing der Graka basieren zu lassen.

Bisher funktioniert es ja im xine so:
Die xine "master clock" basiert auf der "system clock".
Anhand der master clock und dem relativen presentation stamp des frame im mpeg stream wird im xine ein virtueller presentation stamp berechnet der im Prinzip den absoluten Zeitpunkt darstellt, anhand dem die PutImage Routine ausgelöst wird. Weiterhin wird im xineliboutput plugin zur Zeit der Pufferfüllstand der mpeg Packete überwacht und daraus die xine "master clock" nachgeregelt in dem ein offset zur system clock hinzugerechnet wird.

Zukünftig dann so:
Die xine "master clock" basiert weiterhin auf der "system clock".
Im radeon Treiber können wir die aktuelle vertikale Position des crtc bestimmen und so einen offset zur system clock berechnen damit die ersten vpts direkt so liegen das die Frame/Fields genau zum richtigen Zeitpunkt kommen. Es wären dann keine Verzögerungsroutinen im Treiber mehr notwendig und insbesondere wäre der Einregelvorgang gleich null.
Die vertikale Position wird weiterhin beobachtet und so der offset (=regelspannung) zur system clock korrigiert.
Die "Regelspannung" die aus der Überwachung des Pufferfüllstand gewonnen wird dient jetzt direkt zur Nachregelung des Graka Timing in bekannter weise. Damit wäre der Regelkreis geschlossen.

Ich hoffe auch auf lebhafte Diskussion.

Gruss durchflieger

Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

Go to the top of the page

Hemonu

Trainee

Posts: 160

4

Monday, March 2nd 2009, 8:23pm

Quoted

Original von durchflieger
Es wäre mal interessant wie die FF-Karten die Synchronisation genau machen. Die funktioniert ja bekannter maßen hervorragend. Sowie mir bekannt ist dort die "Master clock" per Hardware regelbar. Hier wäre interresant wie denn genau die Regelspannung gewonnen wird. Auch nur durch Überwachung des Puffersfüllstandes des DVB-Stream oder vielleicht doch durch eine Art Taktrückgewinnung?

Das läuft aufs gleiche hinaus. Da Puffereingang mit dem Datentakt und -ausgang mit Master clock erfolgt, ist die erste Ableitung des Pufferfüllstandes proportional der Frequenzdifferenz. Natürlich muss man die Reglerkonstante langsam genug wählen um stabil zu werden.

Quoted

Zukünftig dann so:
Die xine "master clock" basiert weiterhin auf der "system clock".
Im radeon Treiber können wir die aktuelle vertikale Position des crtc bestimmen und so einen offset zur system clock berechnen damit die ersten vpts direkt so liegen das die Frame/Fields genau zum richtigen Zeitpunkt kommen. Es wären dann keine Verzögerungsroutinen im Treiber mehr notwendig und insbesondere wäre der Einregelvorgang gleich null.
Die vertikale Position wird weiterhin beobachtet und so der offset (=regelspannung) zur system clock korrigiert.
Die "Regelspannung" die aus der Überwachung des Pufferfüllstand gewonnen wird dient jetzt direkt zur Nachregelung des Graka Timing in bekannter weise. Damit wäre der Regelkreis geschlossen.

Den zweiten Teil würde ich bei einer NVIDIA Karte (wegen vdpau zur H264 Dekodierung) gegen eine Algorithmus ersetzen, der um ein Halbild verzögert/beschleunigt. Dann geht es auch ohne Eingriff in den Treiber. Wenn die Taktfrequenz der Grafikkarte genau genug eingestellt werden kann, dass das nur alle paar Minuten passiert, halte ich das für einen vertretbaren Kompromiss. Besser wäre natürlich, wenn wir den Takt frei verändern könten, aber dann müssten wir den Quarzoszillator gegen eine VCO ersetzen

Weiss jemand wie genau man den Pixeltakt bei Radeon und NVIDIA einstellen kann ?
Ich hätte evt. eine Idee, wie wir den Takt absolut messen können. Als Referenzsignal nehmen wir ein GPS-Zeitsignal und zählen die VBLANK-Interrupts. Wenn man lang genug laufen lässt, müsste man genau genug werden.

hemonu

Don't Panic !!!

Zotac IONITX-P-E, DD Cine CT V6, Debian Squeeze, Backport-Kernel 3.2.0 plus media_build_experimental, e-tobi VDR 1.7.28 + vdpau, ONKYO TX-SR 606, Panasonic TH-42PZ85E via HDMI

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

5

Tuesday, March 3rd 2009, 9:31pm

Quoted

Originally posted by durchflieger
Im radeon Treiber können wir die aktuelle vertikale Position des crtc bestimmen und so einen offset zur system clock berechnen damit die ersten vpts direkt so liegen das die Frame/Fields genau zum richtigen Zeitpunkt kommen. Es wären dann keine Verzögerungsroutinen im Treiber mehr notwendig und insbesondere wäre der Einregelvorgang gleich null.

diese Idee finde ich sehr gut. Sie laesst sich ausserdem recht einfach realisieren. Ich hatte sowas Aehnliches hier schon mal gepostet/getestet, aber dann zu meiner Schande nicht weiterverfolgt

IMHO ist der kurze Einregelvorgang eigentlich der einzige noch verbesserungswuerdige Punkt der aktuellen FRC-Loesungen. Ansonsten finde ich die Regelungen bereits jetzt schon recht optimal.

Die restlichen Themen, die man noch angehen sollte haben weniger mit dem Regel-Algorithmus selbst zu tun. Sondern betreffen mehr das Environment und die Bugs in xine. Beispielsweise verursacht ein eingeblendetes OSD bisweilen Putimage() Calls, die voellig ausser der Reihe daherkommen.

Das faellt mit einem konventionellen System (ohne VGA2SCART) nur deswegen nicht auf, weil sowieso alles ruckelt und/oder der Software-Deinterlacer das Bild 'vermatscht'.

Quoted

Originally posted by Hemonu
Dann geht es auch ohne Eingriff in den Treiber. Wenn die Taktfrequenz der Grafikkarte genau genug eingestellt werden kann, dass das nur alle paar Minuten passiert, halte ich das für einen vertretbaren Kompromiss.

ist zwar ein verlockender Gedanke, es geht aber leider nicht. Die Taktfrequenz aller mir bekannten Grafikkarten laesst sich nicht einfach im laufenden Betrieb softwareseitig justieren. Dafuer sind die Karten nicht vorgesehen. Man muss auf einigen Grakas sogar zuerst eine Art Sleep-Mode anfahren, bevor man die Frequenz aendern darf.

Befolgt man das nicht, friert die Kiste beim Umprogrammieren der Register augenblicklich ein

.

Einzige Moeglichkeit waere in der Tat noch hardwareseitiges Trimmen des Quarzoszillators. Wobei hier unbekannt ist, welche Seiteneffekte dies wieder haben wird. Ausserdem ist es relativ aufwendig zu realisieren.

- sparkie

This post has been edited 3 times, last edit by "sparkie" (Mar 4th 2009, 9:42am)

Go to the top of the page

jarny

Professional

Posts: 1,399

6

Tuesday, March 3rd 2009, 11:03pm

Hi
Ich kann die rein technische Diskussion gar nicht weiterführen, will aber trotzdem was allgemeines zum Thema sagen:
Die Synchronisations-Lösung wie sie bisher im FRC-Patch realisiert wurde ist absolut brauchbar. Man kann getrost behaupten: FRC läuft in der Praxis sehr gut. Auch wenn es in der Theorie vielleicht noch besser oder anders ginge. Wünschenswert wäre eine andere Lösung eigentlich nur, wenn dadurch das Ganze unabhängig von der benuzten Grafikkarte ist. D.h. Ohne Eingriffe in die Treiber, so dass man auch noch alle NVidia-User mit an Board hätte.
Bemerkenswert an der Sache ist auch, dass zur Zeit immens viele Leute Budget-only-Systeme mit FRC nutzen wollen. FRC scheint mir für viele der Wegbereiter für ein Budget-only-System zu sein. Durchflieger und Sparkie haben damit wirklich einen Meilenstein gesetzt.
Die Frage ist, wie es nun weiter geht wenn man mal das Gesamtziel im Auge behält. Neben dem (durch FRC gelösten) Synchronisationsproblem gibt es meiner Meinung nach nur noch das mindestens genauso wichtige OSD-Skalierungsproblem bei der Ausgabe über xinelibout.
Ich hatte mal gestern versucht in diesem Thread eine Diskussion darüber zu starten, und hoffe dort auch um rege Beteiligung.

Gruß
Jarny

PS: @Hemonu: Hoffe du bist nicht sauer, weil ich vom Thema Synchronisierung auf das Thema Skalierung gelenkt habe. Meiner Meinung nach sollten neue Ideen/Ansätze lieber dort reinfließen, damit das Problem gelöst wird.

Zur Zeit (seit August 2009) kein VDR. Aber mittlerweile nen HD-Fernseher (seit April 2011) angeschafft an dem ein XBMC hängt

Go to the top of the page

SHF

Sage

Posts: 3,772

Location: hessische Bergstrasse

7

Wednesday, March 4th 2009, 12:45am

Quoted

Original von durchflieger
Es wäre mal interessant wie die FF-Karten die Synchronisation genau machen. Die funktioniert ja bekannter maßen hervorragend. Sowie mir bekannt ist dort die "Master clock" per Hardware regelbar. Hier wäre interresant wie denn genau die Regelspannung gewonnen wird. Auch nur durch Überwachung des Puffersfüllstandes des DVB-Stream oder vielleicht doch durch eine Art Taktrückgewinnung?

Details zum VCXO der FF wurden hier schon mal diskutiert.

Der AV7110 scheint den Takt anhand der Program Clock Reference des DVB-Streams zu stellen (S. 14 u. 25 im Datenblatt). Wie genau das gemacht wird, wird aber nicht erläutert.

Quoted

Original von sparkie
Einzige Moeglichkeit waere in der Tat noch hardwareseitiges Trimmen des Quarzoszillators. Wobei hier unbekannt ist, welche Seiteneffekte dies wieder haben wird. Ausserdem ist es relativ aufwendig zu realisieren.

Bei einer Onboard-Graka ist nicht sicher was da eventuell noch alles an dem Oszillator hängt.
Und eine Lösung, bei der man an teurer Hardware löten muss ist sowiso eher nicht mehrheitsfähig

.

Quoted

]Original von jarny
Man kann getrost behaupten: FRC läuft in der Praxis sehr gut. Auch wenn es in der Theorie vielleicht noch besser oder anders ginge. Wünschenswert wäre eine andere Lösung eigentlich nur, wenn dadurch das Ganze unabhängig von der benuzten Grafikkarte ist. D.h. Ohne Eingriffe in die Treiber, so dass man auch noch alle NVidia-User mit an Board hätte.

Das Kernelmodul von NVidia ist offen, dient aber wohl nur dazu die Daten an den Closedsource-Teil weiter zu leiten (ist verdächtig wenig Code in den Funktionen). Wenn man an die Interrupts ran will müsste sich das da eigentlich machen lassen, ich verstehe davon aber nicht genug um das wirklich beurteilen zu können.

Das Problem, was bleibt ist, ob man es schafft dem Treiber neue Modlines unter zu schieben, ohne dass es sichtbar ist.

Gruss
SHF

Mein VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

8

Wednesday, March 4th 2009, 6:38am

Quoted

Originally posted by SHF

Quoted

Original von jarny
Man kann getrost behaupten: FRC läuft in der Praxis sehr gut. Auch wenn es in der Theorie vielleicht noch besser oder anders ginge. Wünschenswert wäre eine andere Lösung eigentlich nur, wenn dadurch das Ganze unabhängig von der benuzten Grafikkarte ist. D.h. Ohne Eingriffe in die Treiber, so dass man auch noch alle NVidia-User mit an Board hätte.

Das Kernelmodul von NVidia ist offen, dient aber wohl nur dazu die Daten an den Closedsource-Teil weiter zu leiten (ist verdächtig wenig Code in den Funktionen). Wenn man an die Interrupts ran will müsste sich das da eigentlich machen lassen, ich verstehe davon aber nicht genug um das wirklich beurteilen zu können.

richtig. Es ist kein Problem beispielsweise das M2NPV-VM mit VGA2SCART zu betreiben und dabei den 50Hz Interrupt im nVidia Kernelmodul abzugreifen. Habe ich hier bereits so am laufen.

fuer eine erfolgreiche Portierung von FRC auf nVidia muessen jedoch noch folgende entscheidenden Probleme geloest werden:

- Fieldpolarity kann nicht ermittelt werden
- es ist unbekannt, welche Register sich zum Trimmen der Framerate eignen

This post has been edited 5 times, last edit by "sparkie" (Mar 4th 2009, 7:54am)

Go to the top of the page

SHF

Sage

Posts: 3,772

Location: hessische Bergstrasse

9

Thursday, March 5th 2009, 12:13am

Quoted

Original von sparkie
- Fieldpolarity kann nicht ermittelt werden

Das ist dann aber ein generelles Problem bei der Interlaced-Ausgabe auf nVidia?
Für das Synchronisieren des Taktes dürfte es ja nicht relevant sein.

Quoted

- es ist unbekannt, welche Register sich zum Trimmen der Framerate eignen

Kann man da nicht über die Schnittstelle gehen, über die die Modline zB. per "xvidtune" geändert wird oder kann man das dann sehen?

Gruss
SHF

Mein VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

10

Thursday, March 5th 2009, 1:57am

Quoted

Originally posted by SHF

Quoted

Original von sparkie
- Fieldpolarity kann nicht ermittelt werden

Das ist dann aber ein generelles Problem bei der Interlaced-Ausgabe auf nVidia?

es ist kein generelles Problem bei Interlaced-Ausgabe.

Bei VGA2SCART ohne FRC bekommt der CRT Controller immer ein progressives Frame zu Gesicht => es gibt hier also gar keine Fieldpolarity mehr

Bei VGA2SCART mit FRC bekommt der CRT Controller im Gegensatz dazu ein weaved Frame angeboten. Das muss abhaengig von der Fieldpolarity zum genau richtigen Zeitpunkt geschehen.

Quoted

Für das Synchronisieren des Taktes dürfte es ja nicht relevant sein.

richtig. Aber der Takt alleine ist hier eben nicht genug.

Quoted

Quoted

- es ist unbekannt, welche Register sich zum Trimmen der Framerate eignen

Kann man da nicht über die Schnittstelle gehen, über die die Modline zB. per "xvidtune" geändert wird oder kann man das dann sehen?

xvidtune programmiert alle am Videotiming beteiligten Register neu. Aufgrund der Vielzahl der Register kann dies ausserdem nicht mehr punktgenau genug erfolgen.

=> bei die Aenderung des Timing ueber xvidtune bricht kurzzeitig die Synchronisation mit dem Display (hier TV) komplett weg.

This post has been edited 1 times, last edit by "sparkie" (Mar 5th 2009, 2:00am)

Go to the top of the page

SHF

Sage

Posts: 3,772

Location: hessische Bergstrasse

11

Friday, March 6th 2009, 1:08am

Quoted

Original von sparkie
Bei VGA2SCART ohne FRC bekommt der CRT Controller immer ein progressives Frame zu Gesicht => es gibt hier also gar keine Fieldpolarity mehr

Es wird also erst deinterlaced und die Grafikkarte gibt dann jede immer nur jede zweite Zeile aus um wieder auf das Interlaced-Ausgabe-Signal zu kommen?

Quoted

Bei VGA2SCART mit FRC bekommt der CRT Controller im Gegensatz dazu ein weaved Frame angeboten.

Also beide Fields in eine Frame kopiert?

Quoted

Das muss abhaengig von der Fieldpolarity zum genau richtigen Zeitpunkt geschehen.

In dem Falle muss das Frame immer zum Richtigen Zeitpunkt kommen, weil sonst die Fields vertauscht würden, das dürfte unschön aussehen.

Wobei sich das auch umgehen lassen dürfte in dem man immer ein zwischen Frame einschiebt, das aus dem (zeitlich) zweiten Field des letzten und dem ersten Field des nächsten Frames besteht.
Die Frage ist nur, ob sich das mit den vorhandenen Möglichkeiten einigermassen unaufwändig (CPU und Arbeitszeit) realisieren lässt.

Quoted

xvidtune programmiert alle am Videotiming beteiligten Register neu. Aufgrund der Vielzahl der Register kann dies ausserdem nicht mehr punktgenau genug erfolgen.

=> bei die Aenderung des Timing ueber xvidtune bricht kurzzeitig die Synchronisation mit dem Display (hier TV) komplett weg.

xvidtune selber wird wohl nicht das wahre sein, das dachte ich mir schon.
Aber klappt es denn auch nicht, wenn man sich nur der Schnittstelle bedient, die xvidtune nutzt?

Gruss
SHF

Mein VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

12

Friday, March 6th 2009, 1:43am

Quoted

Originally posted by SHF
Es wird also erst deinterlaced und die Grafikkarte gibt dann jede immer nur jede zweite Zeile aus um wieder auf das Interlaced-Ausgabe-Signal zu kommen?

genauso ist es. Qualitativ entspricht das was dabei herauskommt den Varianten VGA/DVI. Jedoch mit dem Vorteil, dass eine Framerate von 50Hz zum EInsatz kommt.

Quoted

Also beide Fields in eine Frame kopiert?

richtig. Das vereinfacht die Handhabung ohne Nachteile zu haben.

Quoted

In dem Falle muss das Frame immer zum Richtigen Zeitpunkt kommen, weil sonst die Fields vertauscht würden, das dürfte unschön aussehen.

wovon man ja genug im Forum lesen kann

Quoted

Wobei sich das auch umgehen lassen dürfte in dem man immer ein zwischen Frame einschiebt, das aus dem (zeitlich) zweiten Field des letzten und dem ersten Field des nächsten Frames besteht.

das verstehe ich jetzt nicht. Zu welchem Problem stellt das eine Loesung dar?

Quoted

Aber klappt es denn auch nicht, wenn man sich nur der Schnittstelle bedient, die xvidtune nutzt?

halte ich fuer unwahrscheinlich. ABer ohne eine Loesung fuer das Fieldpolarity Problem brauchen wir uns sowieso nicht darum zu kuemmern.

This post has been edited 2 times, last edit by "sparkie" (Mar 6th 2009, 7:28am)

Go to the top of the page

durchflieger

Professional

Posts: 651

13

Friday, March 6th 2009, 9:53am

Quoted

Original von sparkie

Quoted

Wobei sich das auch umgehen lassen dürfte in dem man immer ein zwischen Frame einschiebt, das aus dem (zeitlich) zweiten Field des letzten und dem ersten Field des nächsten Frames besteht.

das verstehe ich jetzt nicht. Zu welchem Problem stellt das eine Loesung dar?

Hierzu gibts im mythtv Forum eine interresante Diskusion:

http://mythtv.org/pipermail/mythtv-dev/2…ber/063105.html

Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

14

Friday, March 6th 2009, 11:33am

Quoted

Originally posted by durchflieger

Hierzu gibts im mythtv Forum eine interresante Diskusion:

http://mythtv.org/pipermail/mythtv-dev/2…ber/063105.html

die Idee ist sehr interessant. Hat aber leider einen dicken Hacken, der im ersten Posting bei der Betrachtung nicht beruecksichtigt wird. Dort wird immer vom 'correctly synced' und 'badly synced' Zustand ausgegangen. Innerhalb dieser beiden Zustaende verhaelt sich die 'adjacent pairing method' tatsaechlich optimal.

Das Problem entsteht aber genau beim Wechsel von 'correctly synced' auf 'badly synced' und umgekehrt. Hier geht immer ein volles Frame verloren, was in jedem Fall eine sichtbare Stoerung verursacht.

Ich muss deswegen leider bei meiner Feststellung von oben bleiben: es ist grundsaetzlich *nicht* moeglich nur ein einzelnes Field (bedingt durch fehlende Synchronisation etc.) auszulassen. Der Field-Verlust weitet sich immer sofort zu einem Frame-Verlust aus, damit sich die weiteren Fields oertlich und zeitlich wieder an der richtigen Stelle befinden koennen.

Das bedeutet, man darf sich schlicht keinen Field-Verlust erlauben, moechte man ruckelfreie Wiedergabe haben. Und das kann letzlich nur durch Verfahren erreicht werden, wie sie in den aktuellen FRC-Patches implementiert wurden.

- sparkie

[edit]
um es am Beispiel zu verdeutlichen:

Ablauf 'correctly synced'

	Source code
1	[1/2] 1/ [3/2] /2 [3/4] 3/ [5/4] /4 [5/6] 5/

Uebergang 'correctly synced' -> 'badly synced' ([3/2] wird ausgelassen)

	Source code
1	[1/2] 1/ [3/4] /4 [5/4] 5/ [5/6] /6

das bedeutet die 'adjacent pairing method' laesst die Fields 2 und 3 komplett unter den Tisch fallen.
[/edit]

This post has been edited 1 times, last edit by "sparkie" (Mar 6th 2009, 11:58am)

Go to the top of the page

SHF

Sage

Posts: 3,772

Location: hessische Bergstrasse

15

Friday, March 6th 2009, 11:03pm

Quoted

Original von sparkie
das verstehe ich jetzt nicht. Zu welchem Problem stellt das eine Loesung dar?

Für das Problem die Fieldpolarity der Graka zu erkennen.
Meine Idee war praktisch genau das, was da in dem mythtv Forum vorgestellt wurde.
Ich wollte aus dem 25Hz weaved Material, mit den Zwischenframes, 50Hz weaved machen und das dann an dem 50Hz Interrupt synchronisieren.

Quoted

Das Problem entsteht aber genau beim Wechsel von 'correctly synced' auf 'badly synced' und umgekehrt. Hier geht immer ein volles Frame verloren, was in jedem Fall eine sichtbare Stoerung verursacht.

Ich ging davon aus, dass sich die Fieldorder nicht dauernd ändert.

Quoted

Ich muss deswegen leider bei meiner Feststellung von oben bleiben: es ist grundsaetzlich *nicht* moeglich nur ein einzelnes Field (bedingt durch fehlende Synchronisation etc.) auszulassen. Der Field-Verlust weitet sich immer sofort zu einem Frame-Verlust aus, damit sich die weiteren Fields oertlich und zeitlich wieder an der richtigen Stelle befinden koennen.

Da Stimme ich voll zu.
Bei dem Verlust eines Frames würden die Positionen der Fields entweder örtlich oder Zeitlich getauscht.

Gruss
SHF

Mein VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

Go to the top of the page

sparkie

Master

Posts: 2,927

Location: a child of the universe

Occupation: duct tape programmer

16

Saturday, March 7th 2009, 6:01am

Quoted

Originally posted by SHF

Quoted

Das Problem entsteht aber genau beim Wechsel von 'correctly synced' auf 'badly synced' und umgekehrt. Hier geht immer ein volles Frame verloren, was in jedem Fall eine sichtbare Stoerung verursacht.

Ich ging davon aus, dass sich die Fieldorder nicht dauernd ändert.

die 'Fieldorder' aendert sich mit der 'Schwebungsfrequenz', die sich zwischen der Stream- und VGA- Framefrequenz ausbildet.

Die Stream- Framefrequenz (basierend auf PTS) ist eine unbekannte Groesse. Die ist nie exakt 50Hz. Obendrein driftet sie noch recht unmotiviert durch die Gegend. Wenn die VGA Framefrequenz konstant bleibt (wie ohne FRC Patch der Fall) hat man deswegen praktisch keinen Einfluss darauf, wie oft sich die Fieldorder pro Zeiteinheit aendert.

Da weder der Stream noch die Modeline mit exakt 50Hz daherkommen, habe ich in der Praxis nie bessere Werte als ca 1 Fieldorderwechsel/Minute gesehen.

Jede Minute ein Frame zu verlieren waere mir persoenlich etwas zuviel

This post has been edited 5 times, last edit by "sparkie" (Mar 7th 2009, 10:54am)

Go to the top of the page

henfri

Sage

Posts: 2,807

Location: Bremen

17

Saturday, March 7th 2009, 10:51am

Hallo,

mal eine kurze Exkursion:
Wenn ich lese, dass die Graphikkartenhersteller an deinterlacern für HDTV arbeiten (in VDPAU z.B.) und diverse Karten dies nicht schaffen, dann frage ich mich, warum nicht gleich progressiv gesendet wird?

Statt einmal zu deinterlacen (beim Sender), bzw. gleich das p-aufgenommene Signal zu senden muss jetzt jeder TV deinterlacen (oder ist das nur bei LCDs/Plasmas nötig?).

Was ist der Grund hierfür?

Gruß,
Hendrik

gen2vdr 3 beta8 und yavdr 0.3a auf M3N78-EM, Airstar 2 und TT1500 als DVB-T-in

Go to the top of the page

SHF

Sage

Posts: 3,772

Location: hessische Bergstrasse

18

Monday, March 9th 2009, 12:21am

Quoted

Original von sparkie
die 'Fieldorder' aendert sich mit der 'Schwebungsfrequenz', die sich zwischen der Stream- und VGA- Framefrequenz ausbildet.

... da wir aber die Takte aus o.g. Gründen Syncronisieren wollen, sollte das nicht auftreten.

Quoted

Original von henfri
.... dann frage ich mich, warum nicht gleich progressiv gesendet wird?

Warum es interlace überhaupt gibt hat historische Gründe, bei der Entwicklung des Fernsehens war das anders nicht möglich.

Warum man diese Altlast bei digitalem HDTV mit schleppt entzieht sich auch meinem Verständnis.

Gruss
SHF

Mein VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

Go to the top of the page

durchflieger

Professional

Posts: 651

19

Monday, March 9th 2009, 10:18am

Unsere öffentlich rechtlichen Provider haben sich bisher auf 1280x720p als Übertragsungsstandard geeinigt. Der Zug geht also Richtung progressiver Übertragung bei HDTV.

- durchflieger

Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

This post has been edited 1 times, last edit by "durchflieger" (Mar 9th 2009, 10:18am)

Go to the top of the page

SHF

Sage

Posts: 3,772

Location: hessische Bergstrasse

20

Tuesday, March 10th 2009, 12:34am

Quoted

Original von durchflieger
Unsere öffentlich rechtlichen Provider haben sich bisher auf 1280x720p als Übertragsungsstandard geeinigt. Der Zug geht also Richtung progressiver Übertragung bei HDTV.

Na immerhin.
Bleibt zu hoffen, dass es so weitergeht, interlaced macht auf einen LCD nämlich nun wirklich keinen Sinn.

Gruss
SHF

Mein VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

Go to the top of the page

VDR Portal