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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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


  • Zitat

    Originally posted by SHF


    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

  • 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


  • Zitat

    Originally posted by SHF

    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

    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.

  • 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


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

  • Zitat

    Originally posted by durchflieger


    Hierzu gibts im mythtv Forum eine interresante Diskusion:


    http://mythtv.org/pipermail/my…008-September/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'

    Code
    [1/2] 1/ [3/2] /2 [3/4] 3/ [5/4] /4 [5/6] 5/


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

    Code
    [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]

  • 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


  • Zitat

    Originally posted by SHF

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

  • 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

  • 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


  • 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


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!