Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Sonntag, 1. März 2009, 10:51

Synchronisation und Deinterlacing bei Ausgabe via xine

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, yaVDR 0.5 plus media_build_experimental, ONKYO TX-SR 606, Panasonic TH-42PZ85E via HDMI

sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

2

Sonntag, 1. März 2009, 18:14

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:

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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.

Zitat

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).

Zitat

Ich hoffe auf eine lebhafte Diskussion


das hoffe ich auch:)

- sparkie

3

Sonntag, 1. März 2009, 19:27

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


4

Montag, 2. März 2009, 20:23

Zitat

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.

Zitat

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, yaVDR 0.5 plus media_build_experimental, ONKYO TX-SR 606, Panasonic TH-42PZ85E via HDMI

sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

5

Dienstag, 3. März 2009, 21:31

Zitat

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'.

Zitat

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

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »sparkie« (4. März 2009, 09:42)


6

Dienstag, 3. März 2009, 23:03

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.
MLD 3.0.3 Server. Aufnahmen schaue ich mit einem separaten XBMC (OpenElec Distribution) im Wohnzimmer am 47 Zoll HD Fernseher

SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

7

Mittwoch, 4. März 2009, 00:45

Zitat

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.

Zitat

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 ;).

Zitat

]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 (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

8

Mittwoch, 4. März 2009, 06:38

Zitat

Originally posted by SHF

Zitat

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

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »sparkie« (4. März 2009, 07:54)


SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

9

Donnerstag, 5. März 2009, 00:13

Zitat

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.

Zitat

- 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 (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

10

Donnerstag, 5. März 2009, 01:57

Zitat

Originally posted by SHF

Zitat

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.

Zitat

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

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

Zitat

Zitat

- 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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sparkie« (5. März 2009, 02:00)


SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

11

Freitag, 6. März 2009, 01:08

Zitat

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?

Zitat

Bei VGA2SCART mit FRC bekommt der CRT Controller im Gegensatz dazu ein weaved Frame angeboten.
Also beide Fields in eine Frame kopiert?

Zitat

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.

Zitat

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 (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

12

Freitag, 6. März 2009, 01:43

Zitat

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.

Zitat

Also beide Fields in eine Frame kopiert?

richtig. Das vereinfacht die Handhabung ohne Nachteile zu haben.

Zitat

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

Zitat

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?

Zitat

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.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sparkie« (6. März 2009, 07:28)


13

Freitag, 6. März 2009, 09:53

Zitat

Original von sparkie

Zitat

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


sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

14

Freitag, 6. März 2009, 11:33

Zitat

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'

Quellcode

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)

Quellcode

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]

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sparkie« (6. März 2009, 11:58)


SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

15

Freitag, 6. März 2009, 23:03

Zitat

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.

Zitat

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.

Zitat

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 (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

sparkie

Erleuchteter

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

16

Samstag, 7. März 2009, 06:01

Zitat

Originally posted by SHF

Zitat

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:)

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »sparkie« (7. März 2009, 10:54)


17

Samstag, 7. März 2009, 10:51

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
yavdr 0.5 auf M3N78-EM, Cine S2

SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

18

Montag, 9. März 2009, 00:21

Zitat

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.

Zitat

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 (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

19

Montag, 9. März 2009, 10:18

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »durchflieger« (9. März 2009, 10:18)


SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

20

Dienstag, 10. März 2009, 00:34

Zitat

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 (neuer) VDR:

Software:
Debian Wheezy mit Kernel 3.14
VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
noad 0.8.6

Hardware:
MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

Immortal Romance Spielautomat