[patch] RGB/PAL ueber VGA mit variabler Framerate

  • vormals hat sich dieser Beitrag hier befunden. Vielen Dank an alle, fuer die dort eingebrachten Ideen.


    Da es mit dem urspruenglichen Thema nicht mehr so ganz viel zu tun hat, habe ich jetzt einen neuen Thread aufgemacht.


    Aufgabe
    Entwicklung eines Budgetkarten basierten VDRs mit VGA-Grafik-Ausgabe und RGB/PAL Ausgang in FF-Qualitaet.


    Problem
    die mir bislang bekannten Grafikkartensysteme arbeiten mit festem Videotiming, das nicht mit dem Stream synchronisiert ist. Dies fuehrt zwangslaeufig zu Frame/Field- verlusten, die sich stoerend bemerkbar machen (z.B. durch sporadisches Ruckeln)
    Durch Software-Deinterlacing kann man dieses Problem weitgehend kaschieren, jedoch auf Kosten schlechterer Bildqualitaet bei Darstellung von Interlaced-Material und bei deutlich hoeherer Rechenlast.


    Loesung
    Grafikkarten sind grundsaetzlich nicht fuer variable Frameraten konzipiert. Man kann sich nur mit Hardware- oder Software Tricks behelfen. Wie es jetzt aussieht, reicht bereits eine reine Softwareloesung aus.


    Ich habe den Radeon-DRM Treiber so modifizieren koennen, dass im erforderlichen Rahmen beliebige, von 50Hz leicht abweichende Timings am VGA-Port meiner Test-Radeon (IGP9100) ausgegeben werden. Genau so, wie eine FF Karte das auch macht. Durch ein neues Verfahren konnte ich inzwischen die sichtbaren Stoerungen am Roehren-TV aus meinem letzten Versuch (siehe hier) komplett eliminieren.


    Dabei habe ich versucht die Zahl der Eingriffe ins System zu minimieren. Letztlich brauche ich im Moment nur noch 2 sehr ueberschaubare Patches in xine-lib und im Radeon DRM-kernel Modul. Der Xserver muss derzeit nicht mehr angefasst werden.


    Grundsaetzlich funktioniert es so, dass die xine-lib, wenn sie einen PutImage() an den Server absetzt, nebenbei noch kontrolliert ob die Framerate des Xservers zu erhoehen/erniedrigen ist.


    Auf diese Weise kann die xine-lib ihre PutImage() Calls immer wieder genau in die Mitte zwischen zwei Blanking-Intervallen driften lassen. Sollte die Framerate vom Stream Schwankungen unterworfen sein, ist das kein Problem da das Videotiming des Xservers sofort nachgefuehrt wird. Es gehen so bei gleichzeitig maximaler Stoersicherheit ueberhaupt keine Fields mehr verloren.


    Da jetzt erstmalig auch unter Verwendung der xine-lib nicht mehr deinterlaced werden muss, fallen auch alle damit verbundenen Nachteile weg. Insbesondere wird der Prozessor dadurch deutlich entlastet. Mein betagter 2Ghz Celeron (400MHz 128KB Socket 478 CPU) langweilt sich inzwischen mit 80% idle bei SD Wiedergabe.


    Ich konnte meine 1/2h Fussball-Testaufzeichung, die ich jetzt schon in und auswendig kenne:) ohne einen einzigen Field-Verlust anschauen. Bei bester interlaced PAL Qualitaet an einem Roehren-TV.


    Das ganze ist natuerlich noch experimentell. Ich muss das Coding noch aufraeumen und an manchen Stellen allgemeiner formulieren. Weiterhin muss bei der Initialisierung noch eine Erkennung fuer das initiale Even/Odd Field eingebaut werden.


    Dennoch glaube ich, darf man sich langsam vom Vorurteil verabschieden, eine Grafikkarte koenne angeblich keine echte interlaced 50Hz RGB/PAL Ausgabe mit variabler Framerate ;)


    Somit sind jetzt erstmalig Budget-Systeme auf Grafikkartenbasis auch mit geringer Prozessorleistung moeglich. Ohne dabei auf RGB PAL in FF-Qualitaet verzichten zu muessen.


    Bei Gelegenheit werde ich alles mal besser dokumentieren und in die linuxtv.org ML einkippen. Wer sich vorab dafuer interessiert, im Anhang sind die aktuellen Patches.


    viel Spass



    [EDIT] ##############################################################


    UPDATE VOM 10.08.2008:
    EINE AKTUELLE VERSION DES PATCHES IST AB JETZT IMMER HIER ZU FINDEN


    http://lowbyte.de/vga-sync-fields/


    ############################################################## [/EDIT]

  • Prima Arbeit sparkie!


    Nun Frage ich mich natürlich, ob das auch mit neueren IGPs funktioniert, da die 9100er ja doch schon etwas betagter ist.


    Leider besitze ich ein Motherboard mit Nvidia-IGP (nur closed-source), würde es aber sofort gegen eins tauschen mit AMD/ATI, wenn es z.B. auch mit radeonhd funktionieren würde.


    Gruß


    Joe_D

  • Hi Joe_D,


    Zitat

    Nun Frage ich mich natürlich, ob das auch mit neueren IGPs funktioniert, da die 9100er ja doch schon etwas betagter ist.


    es ist halt erst mal Treibersupport fuer den VBLANK-Interrupt Voraussetzung. Ein Blick in 'linux-2.6-*/drivers/char/drm' sagt dann schnell, was los ist :weinen
    Fuer das, was hier nicht drin steht, gibt's meist auch keine Herstellerdocu.


    Zitat

    würde es aber sofort gegen eins tauschen mit AMD/ATI, wenn es z.B. auch mit radeonhd funktionieren würde.


    leider hat Radeon und RadeonHD nicht viel miteinander zu tun.


    Bleibt zu hoffen, dass fuer TV Anwendungen im Allgemeinen und VDR im Besonderen in Zukunft mehr auf bessere Synchronisation zwischen Decoder, Displaytreiber (z.B. Xserver) und Display geachtet wird.
    Irgendwie wurde da selbst in den aktuellen Treibern einiges verschlafen.


    -sparkie

  • Zitat

    Originally posted by netvista-fan
    Bin jedenfalls gespannt wie es weitergeht mit diesem Treiber!


    bin schon munter dabei:)


    nachdem meine Tests auf Etch bereits so gut laufen, habe ich jetzt meine Testumgebung spasseshalber auf Lenny umgezogen. Und prompt lief der Radeon-Xserver nicht mehr im Interlaced Mode X(


    EIne kurze Recherche hat ergeben, dass sich in die aktuelle Version xserver-xorg-video-ati_6.8.0 tatsaechlich ein Bug eingeschlichen hat. Siehe auch dieser Thread:


    https://bugzilla.redhat.com/show_bug.cgi?id=437700


    Dort ist netterweise gleich ein Patch dabei, der das Problem behebt. Anscheinend kann Alex Deucher (Maintainer des Radeon Treibers), das Problem bei sich nicht reproduzieren. Darum wurde es noch nicht offiziell gefixt.


    Ich werde als naechstes mal testen, ob das ganze mit ATI-Rage auch so gut funktioniert.


    Da diese alten Karten heute fast nichts mehr kosten, koennte man damit billigste VDR Rechner mit RGB/PAL Ausgang bauen.

  • Hallo sparkie,


    ich verfolge deine Arbeit sehr interessiert und habe versucht die Patches auf mein System anzuwenden.


    Dabei verwende ich Archlinux mit Kernel 2.6.25. Somit musste der Patch natürlich etwas angepasst werden.
    Ich muss erwähnen, dass dies mein erstes kernel hacking ist und es nicht reibungslos funktioniert hat.
    Bei mir war es nur möglich erfolgreich zu kompilieren, nachdem ich libdrm-2.3.0 auf libdrm-2.3.1
    aktualisiert hatte.
    DRM_COPY_FROM_USER und DRM_COPY_TO_USER geben die volle Anzahl Bytes zurück. Schlägt also komplett fehl.
    Mit __get_user konnte ich die Daten zwar vom Client beziehen, jedoch nicht mit __put_user zurückschreiben.
    In jedem Fall ist das für ein struct ohnehin unpraktisch.
    Nun habe ich das Makro memcpy angewandt und was soll ich sagen, damit funktioniert es.
    Wird da irgendwo automatisch die Übersetzung der Adresse von userspace nach kernelspace vorgenommen?


    Desweiteren verwende ich vdr-softdevice und versuchte deinen Patch anzupassen.
    In der Funktion cXvVideoOut:: PutXvImage habe ich also den Code eingefügt.


    Nachdem das nun augenscheinlich funktioniert, sieht es nun so aus, dass das Bild horizontal zittert.
    Bei Betrachtung der Senderlogos erkennt man es sehr gut. Es dürfte wohl das trimmen um 200 sein, das
    den Ausschlag bewirkt.
    Bei einer Betrachtung einer Fußballaufzeichnung zeigte sich auch noch die typische Streifenbildung, wenn
    das Deinterlacing abgeschaltet ist.
    Die Patches funktionieren wohl grundsätzlich, jedoch mit dem falschen Timing.



    Ich lasse vdr-softdevice einige Werte ausgeben, nachdem ioctl aufgerufen wurde.
    Log-Ausgabe von vdr-softdevice:



    video-xv.c (softdevice-0.5.0)



    field_sync_drm_V2.patch (linux 2.6.25-ARCH)


    Ich will mich auch noch für deinen scheinbar unermüdlichen Einsatz bedanken. Ich kann echt froh sein, dieselbe Hardware wie du zu haben :)


    So long,


    Matthias

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

  • Hi,


    ich lese hier (wie auch in dem ursprünglichen Thread) fasziniert mit, obwohl ich eigentlich gar kein "Abnehmer" für dein Werk bin.


    Da ich es nicht beurteilen kann:
    Bringt deine Arbeit eigentlich potentiell auch Vorteile für den 576p-Betrieb mit AMD/ATI-Karten?


    Gruß
    Holger

  • Hallo,


    nachfolgend mal eine Messung (siehe Anhang) von meinem System. Der Messpunkt befindet sich im Xserver unmittelbar bevor die DoubleBuffer umgeschaltet werden.
    Damit werden auch alle moeglichen Stoereinfluesse zwischen dem xine-lib Timer und dem 'Sichtbarmachen' des Bildes erfasst.
    Die Messung habe ich kurz nach Start einer Wiedergabe begonnen.


    Man kann schoen sehen wie die VBLANK Interrupts immer in 2er Schritten hochzaehlen, da ein Frame eben aus 2 Fields (== Interrupts) besteht.


    Da der Start der Wiedergabe voellig asynchron durch den Benutzer erfolgt, haben wir einen (zufaelligen) Wert von vbl_since == 9604 usec zu Beginn.
    Deswegen bleibt die VideoTiming Korrektur erst mal eine ganze Weile auf konstant 200. Erst wenn wir in die Zeile mit vbl_received == 2646
    gelangen, beginnt xine mit den beiden VideoTimings des Xservers zu oszillieren. Der Wert fuer vbl_since == 11860 ergibt sich aus 10000 + 1860.
    1860 usec ist offenbar die Latenz des Datenpfades zwischen XvShmPutImage() in Xine und dem Xserver RADEONPutImage(), da wir ja im Xserver messen.


    Man kann an den Zeitstempeln (vbl_now) auch gut erkennen, die Frames kommen aus der xine-lib wie aus dem Uhrwerk.
    Die Werte von vbl_now zaehlen ohne groessere Schwankungen um ca. 40000usec (== 25Hz) pro Schritt weiter.


    Das Programm gibt eine Fehlermeldung aus, wenn Fieldverluste auftreten.. Meine Testfilme (ungeschnittene Sportaufzeichnungen bis ca. 1/2 Stunde Laenge) laufen
    mit der Synchronisation jedoch ohne einen Aussetzer durch.


    Zur Erklaerung


    vbl_received - Zahl der VBLANK Interrupts seit Xserver Start
    vbl_since - Zeit in usec seit letztem VBLANK Interrupt
    vbl_now - Absolutzeit (nur usec Anteil) der Messung
    vbl_trim - 'pulse width modulation' der 2 Xserver Videotimings

  • Holger
    deine Frage zuerst (ist schneller beantwortet:) )


    Zitat

    Bringt deine Arbeit eigentlich potentiell auch Vorteile für den 576p-Betrieb mit AMD/ATI-Karten?


    nur fuer die 'alten' Radeons (also nicht RadeonHD)


    wie ich die Sache sehe, gibt es derzeit nirgendwo eine Synchronisation zwischen Videotiming der GraKa und Stream.


    Insofern duerfte die Arbeit fuer alle derzeitigen Softdekoder etwas bringen.


    Hitman47
    sorry, ich muss noch kurz weg. Ich schaue mir deine Dumps aber spaeter noch durch. Vielleicht helfen dir in der Zwischenzeit meine Messwerte schon weiter.

  • Hallo Matthias,


    da sind wir wieder:)


    Zitat

    Nun habe ich das Makro memcpy angewandt und was soll ich sagen, damit funktioniert es.


    in 'radeon_state.c' befinden sich noch andere ioctls() die Daten zwischen user und kernel space kopieren.
    Ich wuerde die entsprechenden Macros einfach sinngemaess kopieren.


    Code
    1. Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_since.tv_usec: 7279
    2. Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_now.tv_usec: 253663 -+
    3. Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_trim: 200 |
    4. Jul 12 14:08:03 vdrclient_mediapc 2008-07-12_5 45206usec Zeitdifferenz
    5. Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_since.tv_usec: 12493 |
    6. Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_now.tv_usec: 298869 -+
    7. Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_trim: 200


    bei diesen Werten ist schon irgendwas grundsaetzlich im Argen. Aus irgendeinem Grund sind hier
    starke Abweichungen (ueber 5msec) nach oben und unten von den erwuenschten 40000usec zwischen
    den Frames zu sehen. Wenn die Frames hier schon derart unregelmaessig ankommen, kann das durch
    variables Videotiming nicht ausgeglichen werden.


    Das deutet evtl. auf einen Bug in Softdevice (oder davon verwendeten Libraries) hin. Ich habe mit softdevice leider keine Erfahrung.
    Aber dass so unregelmaessige Anlieferung von Frames zu Ruckeln fuehren muss, liegt auf der Hand.


    In meinem obigen Trace (den ich uebrigens mit einem aelteren CVS Stand von xineliboutput und xine-lib Version 1.1.8 erstellt habe)
    sind hier vergleichsweise nur Ausreisser um die 40usec zu sehen.


    Was ich noch vergessen habe zu sagen:
    Es ist wichtig, die vertikale Skalierung zu deaktivieren, da sich sonst die Scanlines
    der Even/Odd Fields im Framebuffer gegenseitig ueberschreiben.


    Typisches Fehlersymptom: Das Bild wird in breiten horizontalen Streifen versetzt dargestellt.


    Also am besten erst mal jegliche Skalierung (auch die horizontale) komplett abschalten.


    - sparkie

  • Hallo sparkie,


    Ich denke, ich muss mein System an Deines anpassen,
    da ich mit der Thematik bei Weitem nicht so vertraut bin wie Du.


    vdr-softdevice skaliert vielleicht intern irgendwo oder es liefert die Daten zu schnell oder
    zu langsam, so dass ich dort den Kammeffekt zu sehen bekomme, der eben nur durch De-
    Interlacing wegzubekommen ist.
    Ich entnehme Deinem vorherigen Posting, dass Du es ähnlich siehst.
    Das wäre dann die nächste Hürde, weil ich vdr-softdevice doch sehr gerne nutze.
    Dabei kann das Fernsehprogramm im Hintergrund und Musik im Vordergrund gleichzeitig
    abgespielt werden -> es flimmert und macht gut krach.


    Mit xineliboutput habe ich ohne De-Interlacing denselben Kammeffekt, allerdings geht es dort
    durch Einschalten der Skalierung weg. Das liegt wahrscheinlich an der Auflösung des Input-
    Materials. Es war eine Aufzeichnung von dmax (520x576).
    Da hört mein Wissen aber bereits auf und mehr als Probieren konnte ich da nicht.


    Ruckeln und Zuckeln ist bei Laufschriften in gewissen Abständen (alle paar Sekunden) noch sichtbar.



    Ich habe eine interessante Webseite entdeckt:
    <http://www.kingcot.eclipse.co.uk/unichrome/tvoutTest.html>


    Dort liegt ein Testvideo mit interlaced Material vor und auch detaillierte
    Erklärungen zu dem Sachverhalt.
    Ich spiele es mit oxine und der gepatchten xine-lib (1.1.14) ab.


    Upper und Bottom fields ergänzen sich scheinbar gut. Dort gibt es wohl keine Probleme.
    Der Balken zuckt hier zeitweise, was mit Sicherheit auf die Synchronisation, die Dein
    Patch beheben wird (da bin ich mir doch sehr sicher ;-) ), zurückzuführen ist.


    Im syslog tauchen dabei z.B. folgende Zeilen auf, die mich vermuten lassen, dass
    der Patch grundsätzlich arbeitet (natürlich könnte es sein, dass fehlerhafte
    Werte zu Grunde liegen. Das sollte ich noch prüfen):




    In der unteren Bildhälfte tauchen alle paar "Zentimeter" vertikale, schattige Streifen (Wellen)
    auf. Könnte da die Modeline vielleicht falsch sein, das VGA-SCART-Kabel oder ist es normal?


    Code
    1. Modeline "720x576i" 13.875 720 744 808 888 576 580 585 625 interlace composite



    So long,


    Matthias

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

  • Hi Matthias,


    Zitat

    Ich denke, ich muss mein System an Deines anpassen,


    da faellt mir gerade ein, ich koennte dir ein all-inclusive Tarfile bauen. Mein komplettes System
    benoetigt (mit Sourcen) laut 'df -k' etwa 2GB. Dann hast du gleich alle Patches
    dabei.


    Nachdem du die gleiche Hardware hast, sollte es eigentlich sofort bei dir laufen.
    Dann koennten wir zusammen weiterentwickeln...


    Warum sind wir da nicht eher drauf gekommen:) ?


    Zitat

    Das wäre dann die nächste Hürde, weil ich vdr-softdevice doch sehr gerne nutze.
    Dabei kann das Fernsehprogramm im Hintergrund und Musik im Vordergrund gleichzeitig


    das geht unter xineliboutput aber auch. Habe es gerade getestet.


    VDR Wiedergabe + Webradio z.B.

    Code
    1. wget -q -O - http://relay01.128kbps.uk.vocal.trancefm.co.uk/ | lame --mp3input --decode - - | sox -t .wav - -t alsa default


    laeuft parallel. Der geniale Alsatreiber mixt den Ton von VDR und sox einfach uebereinander.


    Zitat

    auf. Könnte da die Modeline vielleicht falsch sein, das VGA-SCART-Kabel oder ist es normal?


    nein, das ist nicht normal.
    ich nutze ja inwischen ein VGA->SCART Kabel das den Composite selber erzeugt. Weil ich VGA->SCART auch fuer
    nVidia Karten nutze und diese den Composite nicht auf dem CHip erzeugen koennen. Darum lasse ich die 'composite'
    Option weg. Weiterhin gebe ich explizit '-HSync -Vsync' an. Ansonsten habe ich die Modeline ja ohnehin von Dir .
    Diese Modeline ist im uebrigen 1. Sahne - sie hat 50.01Hz!


    meine Modeline also

    Code
    1. Modeline "720x576i" 13.875 720 744 808 888 576 580 585 625 -HSync -Vsync interlace


    -sparkie

  • Zitat

    Original von sparkie


    nur fuer die 'alten' Radeons (also nicht RadeonHD)


    warum? - liegt das daran, dass der Patch auf das Modul "radeon" gemünzt ist?
    Also könnte man (theoretisch) auch andere Module ähnlich anpassen oder gibt es einen anderen Grund, warum ausgerechnet nur die 'alten' Radeons?

    vdr1: yavdr 0.5 | Intel DH77EB MSI B75MA-E33 | Celeron G540 | GT 630 passiv | DD Cine CT v6 | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse
    vdr2: yavdr 0.5 - GA-MA78GM-S2H - BE-2350 - GT 520 passiv - Seagate 250GB - Terratec Cinergy C/T Dual

  • Zitat

    Originally posted by aragorn
    warum? - liegt das daran, dass der Patch auf das Modul "radeon" gemünzt ist?
    Also könnte man (theoretisch) auch andere Module ähnlich anpassen oder gibt es einen anderen Grund, warum ausgerechnet nur die 'alten' Radeons?


    ich habe im Moment halt nur alte Radeons zum Testen. Und diese scheinen den Trick mit den verkuerzten Scanlines klaglos hinzunehmen. Wenn irgendwelche anderen Grafikkarten das (oder was aehnliches) ebenfalls zulassen, dann koennte man die Arbeit sinngemaess auch auf voellig andere Hardware anwenden.


    Ich wollte halt erstmal nicht zuviel versprechen:)


    Mich erstaunt halt nur immer wieder, dass einerseits sich bislang kaum jemand fuer die Synchronisation des VGA-Timings mit einem externem Signal interessiert hat.


    Kein Wunder, dass andererseits die Wiedergabe mit Softdecodern zu den vielzitierten Rucklern fuehrt...


    Eigentlich moechte ich mit dem Projekt nur zeigen, dass es nicht das Privileg von FF-Karten ist, ein einwandfreies PAL Bild zu liefern.


    Ich bin davon ueberzeugt, dass stromsparende und kostenguenstige VDRs mit 'kleinen' Prozessoren grundsaetzlich auch mit VGA Karten moeglich sind.

  • Hallo sparkie,


    Zitat

    Original von sparkie
    da faellt mir gerade ein, ich koennte dir ein all-inclusive Tarfile bauen. Mein komplettes System
    benoetigt (mit Sourcen) laut 'df -k' etwa 2GB. Dann hast du gleich alle Patches
    dabei.


    Das klingt gut. Ich habe zwar keinen dicken Internetanschluss, aber das passt schon und da ich sowieso über NFS boote, könnte ich es parallel installieren und bei Bedarf umschalten.


    Zitat

    Nachdem du die gleiche Hardware hast, sollte es eigentlich sofort bei dir laufen.
    Dann koennten wir zusammen weiterentwickeln...


    Warum sind wir da nicht eher drauf gekommen:) ?


    Ich weiß es auch nicht.



    Zitat

    Original von sparkie


    das geht unter xineliboutput aber auch. Habe es gerade getestet.
    VDR Wiedergabe + Webradio z.B.

    Code
    1. wget -q -O - http://relay01.128kbps.uk.vocal.trancefm.co.uk/ | lame --mp3input --decode - - | sox -t .wav - -t alsa default


    laeuft parallel. Der geniale Alsatreiber mixt den Ton von VDR und sox einfach uebereinander.


    Ich denke da an plugins, wie z.B. podcatcher. Wichtiger wäre mir aber auch ein feines Bild. Den Rest kann man dann auch noch zurechtbiegen.



    So long,


    Matthias

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

  • Zitat

    Das klingt gut. Ich habe zwar keinen dicken Internetanschluss, aber das passt schon und da ich sowieso über NFS boote, könnte ich es parallel installieren und bei Bedarf umschalten.


    ok - wunderbar. Ich mache bis morgen ein tar File fertig. Du bekommst dann eine Email mit der URL zum Download. Kann aber schon abend werden, da ich morgen erst was fuer meinen 'echten' Job fertig machen muss. Bis dann!

  • Hallo sparkie,


    Deine Installation lief bei mir auf Anhieb. Mit den von dir genannten Kommandos war auch schnell ein Bild
    auf dem Fernsehgerät und ich konnte dieses berühmte Fußballvideo auch wieder sehen.
    Wenn man einen Langpass beobachtet, fliegt der Fußball völlig ruckelfrei. In den Logs konnte ich nun auch
    selbst beobachten, wie nachgeregelt wird. Dabei sind die Abstände wirklich sehr konstant, abgesehen vom Start
    xines. Denn da sieht es aus wie bei meinen Messungen zu vdr-softdevice.


    Im live-Modus kommt dann das Pufferproblem zu Tage. vsync.vbl_since wurde dabei immer zügig durchgezählt.
    Bei "Das Erste" fing es sich aber und pendelte genau so wie bei der Wiedergabe. Subjektiv betrachtet sah
    das Bild und die dazugehörige Bewegung gut aus. Am Bildschirmrand treten aber Verzerrungen auf, die bei
    Kameraschwenks immer etwas irritieren. Das Bild müsste wohl verkleinert werden.



    Ich habe auch eine Neuinstallation meines eigentlichen vdr-systems durchgeführt:
    archlinux-Basisinstallation; vdr-install-script; vdr-softdevice;
    Damit bin ich etwa da, wo ich vorher auch schon war. Mir fiel aber auf, dass vsync.vbl_received überhaupt
    nicht hochgezählt wird. Erst wenn ich glxgears starte, werden die vblanks gezählt.
    Ich frage mich nun, warum bei der vorherigen Installation hochgezählt wurde und nun nicht mehr. Dazu muss
    ich in den Quellcode schauen oder besser die vdr-softdevice-Entwickler befragen.
    Wenigstens habe ich den Kammeffekt bei Bewegeungen mit softdevice ohne Deinterlacing wegbekommen (autom.
    Umschaltung 4:3/16:9 - aus; Bildausschnitt 4:3). Ein paar Sender sind dann etwas zu groß für das Fernsehgerät,
    es würde mich aber nicht einmal stören (alles noch im Geräterahmen :-) ).



    Ich muss mir die Mechanismen bezüglich des DRM-Patches alle noch genauer Anschauen und Verstehen. Mir sind
    nämlich noch ein paar Dinge ein-/aufgefallen:
    Sobald das OSD eingeschaltet wird, ist der Sendestrom nicht mehr gleichmäßig und es versetzt das Bild (es zuckt).
    Der Trim-Wert (aktuell 200) sollte vielleicht degressiv gestaltet werden, um zügiger den Mittelwert er-
    reichen zu können.



    Wir sollten uns weiter damit beschäftigen. Eine rage128 liegt bei mir auch noch im Schrank. Es wäre wirklich
    toll, ließe sich ein low-budget VDR damit aufbauen.



    So long,


    Matthias

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

  • Hallo Matthias,


    vorab schon mal vielen Dank fuer deinen ausfuehrlichen Testbericht. Da ich keinen Urlaub habe, kann ich im Moment nur auf den letzten Punkt eingehen (der Rest kommt abends).


    Zitat

    Eine rage128 liegt bei mir auch noch im Schrank. Es wäre wirklich toll, ließe sich ein low-budget VDR damit aufbauen.


    zum Testen habe ich mir inzwischen einen diskless Budget VDR mit Teilen aus der Schrottkiste zusammengebaut:


    Prozessor: Pentium III (Coppermine) 800MHz
    Speicher: 512MB
    LAN: e100 intel pro/100
    Grafik: ATI Rage Fury Pro/Xpert 2000 Pro


    Folgende Beobachtungen konnte ich machen:


    - der Mechanismus, ueber das r128 DRM Modul das Modeline-Timing zu justieren, funktioniert auch hier
    - leider scheinen aber bei der Rage interlaced Modi generell (noch) ein Problem zu sein. Ein Roehren-TV synchronisiert vertikal nicht (Bild laeuft durch). Ein mit demselben Timing betriebenes TFT (Siemens 5110FA) zeigt jedoch ein stehendes Bild. So konnte ich grundsaetzlich erst mal weitertesten.
    - es gibt allerdings keinen besonderen Grund eine Rage zu verwenden. In einem grossen Auktionshaus werden einem z.B. low profile Radeons 9200SE fuer 8EUR (incl. Porto) nachgeworfen.


    Und jetzt kommts:


    Ich habe auf dem obigen Budget System eine Sportaufzeichnung vom ZDF (live Tour de France) abgespielt. Bitrate: ueber 6 Mbit/s. Das PAL Bild war ruckelfrei!
    Der 'Gewinn' an Prozessorleistung durch den kompletten Wegfall von Deinterlacing wird durch folgende Messung verdeutlicht:


    Code
    1. # vmstat 1
    2. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
    3. r b swpd free buff cache si so bi bo in cs us sy id wa
    4. 3 0 0 374508 0 103812 0 0 0 0 301 753 47 4 49 0
    5. 2 0 0 372716 0 105612 0 0 0 0 1589 783 45 9 46 0
    6. 3 0 0 372708 0 105628 0 0 0 0 298 763 44 5 51 0
    7. 2 0 0 370908 0 107436 0 0 0 0 1627 868 47 12 40 0
    8. 3 0 0 369116 0 109236 0 0 0 0 988 1056 49 7 45 0
    9. 3 0 0 369108 0 109228 0 0 0 0 1063 824 46 10 44 0
    10. 4 0 0 367316 0 111028 0 0 0 0 1510 866 46 11 42 0


    Selbst der 800MHz Prozessor idled hier noch mit ca 45%, wenn er nur dekodieren aber nicht mehr deinterlacen muss.


    Aktiviere ich das OSD (skaliert und transparent)


    Code
    1. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
    2. r b swpd free buff cache si so bi bo in cs us sy id wa
    3. 3 0 0 365696 0 111064 0 0 0 0 1646 704 79 7 14 0
    4. 2 0 0 365696 0 111064 0 0 0 0 347 636 82 1 17 0
    5. 4 0 0 371832 0 104636 0 0 0 0 1626 674 78 8 14 0
    6. 3 0 0 371832 0 104636 0 0 0 0 343 702 80 0 20 0
    7. 2 0 0 370032 0 106484 0 0 0 0 1637 686 76 9 15 0
    8. 4 0 0 370032 0 106476 0 0 0 0 352 704 80 1 19 0
    9. 4 0 0 368232 0 108280 0 0 0 0 1641 695 79 6 15 0


    habe ich sogar immer noch ca. 15% 'Luft'.


    Zum Vergleich: wenn ich das inzwischen ueberfluessige Deinterlacing spasseshalber aktiviere (OSD wieder deaktiviert):


    Code
    1. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
    2. r b swpd free buff cache si so bi bo in cs us sy id wa
    3. 2 0 0 370408 0 106512 0 0 0 0 657 463 62 2 36 0
    4. 2 0 0 368616 0 108312 0 0 0 0 1684 591 92 8 0 0
    5. 2 0 0 368608 0 108324 0 0 0 0 384 475 97 3 0 0
    6. 2 0 0 366816 0 110124 0 0 0 0 1688 603 92 8 0 0
    7. 2 0 0 366808 0 110140 0 0 0 0 390 538 95 1 4 0
    8. 2 0 0 365016 0 111940 0 0 0 0 1669 584 92 7 1 0
    9. 2 0 0 365008 0 111936 0 0 0 0 388 473 98 2 0 0


    sind bereits alle Leistungreserven aufgebraucht und es beginnt zu Ruckeln.


    Welches enorme Einsparpotential sich durch den Wegfall von Deinterlacing ergibt, kann jeder mit Budget VDR leicht selbst nachpruefen.


    Es sieht wohl so aus, als koennte man jetzt Budget VDRs mit Teilen vom Grabbeltisch zusammenbauen, die ZDF-Bitraten meistern, mit denen selbst die vielgelobten FF-Karten ohne Full-TS Mod ihre Schwierigkeiten haben.


    - sparkie

  • Hallo Matthias,


    zu deinen Anmerkungen:


    Zitat

    Deine Installation lief bei mir auf Anhieb. Mit den von dir genannten Kommandos war auch schnell ein Bild
    auf dem Fernsehgerät


    oh danke, vielleicht der Anfang einer neuen Distribution fuer LowCost Budget VDRs - nein war bloss ein Scherz:)


    Ich habe das meiste auf meinem VDR, wofuer es schon fertige Plugins in C/C++ gibt, durch awk-Scripte realisiert. Kann mir nicht vorstellen, dass sowas jemand haben will.


    Zitat

    Dabei sind die Abstände wirklich sehr konstant, abgesehen vom Start
    xines. Denn da sieht es aus wie bei meinen Messungen zu vdr-softdevice.


    dass der Start noch deutlich optimiert werden kann, ist ganz klar. EIne Idee waere, dass in diesem Fall ausnahmsweise die xine-lib Ruecksicht auf die VBIs nimmt und einmalig den eigenen Timer auf die Grafikkarte synchronisiert. Von diesem Zeitpunkt an muss es sich dann genau umgekehrt verhalten und der Takt der Grafik wird an den Takt von xine angepasst.


    Zitat

    Ich habe auch eine Neuinstallation meines eigentlichen vdr-systems durchgeführt: archlinux-Basisinstallation; vdr-install-script; vdr-softdevice; Damit bin ich etwa da, wo ich vorher auch schon war. Mir fiel aber auf, dass vsync.vbl_received überhaupt nicht hochgezählt wird. Erst wenn ich glxgears starte, werden die vblanks gezählt.


    mit archlinux statt debian machen wir wohl gleich noch die naechste Parallel-Baustelle auf:)


    Wenn man die Mailing Listen so durchgeht, gab es zu Recht einige Beschwerden, dass frueher die VBI Interrupts unnoetigerweise auch im 2D Betrieb aktiv waren. Was einen suspend verhindert hat. Wahrscheinlich werden in deinem Fall die Interrupts erst durch 'glxgears' aktiviert.


    Zitat

    Wenigstens habe ich den Kammeffekt bei Bewegeungen mit softdevice ohne Deinterlacing wegbekommen (autom.
    Umschaltung 4:3/16:9 - aus; Bildausschnitt 4:3). Ein paar Sender sind dann etwas zu groß für das Fernsehgerät,
    es würde mich aber nicht einmal stören (alles noch im Geräterahmen :-) ).


    das sieht ja trotzdem schon gut aus. Zu softdevice kann ich leider wenig sagen. Ich habe immer nur xine-lib verwendet. Und da gibt es das Problem nicht.


    Wie im Post weiter oben begruendet, darf vertikal nicht skaliert werden. Horizontal ist jedoch kein Problem! Auf diese Weise kann man per Software fuer ein 16:9 Fernsehgeraet sogar die Formatumschaltung 4:3/16:9 automatisch per xine-lib machen lassen. Man muss sich also hier nicht mal mit Wide Screen Signaling herumaergern.


    Zitat

    Sobald das OSD eingeschaltet wird, ist der Sendestrom nicht mehr gleichmäßig und es versetzt das Bild (es zuckt).


    das kann ich leider nicht nachvollziehen. Was genau muss ich da machen, um es zu reproduzieren?


    Zitat

    Der Trim-Wert (aktuell 200) sollte vielleicht degressiv gestaltet werden, um zügiger den Mittelwert er-
    reichen zu können.


    Klar, die Trimmung der Framerate koennte man z.B. in vielen kleinen Zwischenstufen vornehmen. Momentan wird ja nur auf primitivste Weise mit 2 fixen Werten aehnlich einer PWM gearbeitet, um im Mittel die gewuenschte Frequenz zu erhalten. Umso erstaunlicher ist aber, wie gut selbst das bereits funktioniert.


    Zitat

    Wir sollten uns weiter damit beschäftigen. Eine rage128 liegt bei mir auch noch im Schrank.


    da wuerde ich im Moment nicht zuviel Zeit investieren. Es ergibt sich eigentlich kaum ein Preisvorteil.


    PS:
    Ich habe mir jetzt bei einem uns gut bekannten Auktionshaus verschiedene Radeons gekauft. Ich kann es kaum erwarten diese in meinem obigen 800MHz LowCost Budget-System zu testen.


    - sparkie

  • Hallo sparkie,


    Ich habe folgende Website entdeckt:
    No more tears


    Ich konnte es auch aus dem git-repository kompilieren und installieren.
    Dabei sind dann auch die Mikroruckler weg, die bei mir mit Xv-Overlay auftreten. Der VBI muss aber trotzdem noch getrimmt werden, da z.Bl Laufleisten zeitweise zu zittern beginnen.
    Das würde dein Patch wohl beheben. Wenn es aber von offizieller Seite her gemacht wird und das von R100-R500-Chips ist das ja auch nicht schlecht, nicht wahr?
    Einsetzen kann ich diese Methode trotzdem nicht, da auf den hochbittigen Sendern ein breiter, vertikaler Streifen mit Datenmüll angezeigt wird und es ist erkennbar, dass etwa drei vertikale Segmente dargestellt werden, die aber nicht Synchron arbeiten -> Tearing
    Das sollte aber laut Headline nicht mehr sein. Aber guter Dinge bin ich trotzdem, denn der Bildfluss ist genial; wie man es nun einmal von einer "normalen" TV-Umgebung gewohnt ist.



    Zitat

    Wenn man die Mailing Listen so durchgeht, gab es zu Recht einige Beschwerden, dass frueher die VBI Interrupts unnoetigerweise auch im 2D Betrieb aktiv waren. Was einen suspend verhindert hat. Wahrscheinlich werden in deinem Fall die Interrupts erst durch 'glxgears' aktiviert.


    Das kann ich nun bestätigen. Ich weiß allerdings nicht, wie es programmatisch steuerbar ist und habe es daher im DDX-Modul überall aktiviert. Somit wurde wieder fleißig gezählt.


    Ich habe weiterhin auf der Kopie deines Systems vdr-softdevice installiert, jedoch kommt auch hier keine konstante Abfolge in der Messung zustande.
    Seltsam ist aber, dass xine-lib auf archlinux ähnlich unregelmäßig arbeitet. Daher muss es wohl etwas anderes sein.



    In der Datei Xorg.log wird folgende Fehlermeldung festgehalten:
    (EE) RADEON(0): drm: could not allocate surface for front buffer!


    Die Meldung tritt auch auf der Kopie deines Systems auf. Ist das bei dir genauso?



    So long,


    Matthias

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI 16.1. Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2;  DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von Hitman47 ()