Beiträge von HTPC-Schrauber

    Kann ich nicht bestätigen. Bei mir sieht das RGB-Bild eigentlich genauso aus, wie über Composite. D.h. natürlich schärfer usw.
    Aber von pixelig kann ich nicht sagen.


    Ich hab den Digitainer an einem kalibrierten Philips 32PF9531 hängen. Das Bild sieht nach Einmessung genauso aus, wie der DVD-Player über RGB. Selbst Overscan und Bildposition sind absolut identisch.


    Oder meinst Du in dunklen Farbverläufen Abstufungen? Also kein weicher Übergang der Farbe, sondern wirkt irgendwie abgestuft? Das hatte ich nämlich. Nachdem ich im Softdevice Plugin von Farbraum i420 auf YUY2 umgestellt hatte, wars aber weg. Zumindest ist es mir bisher noch nicht wieder aufgefallen.
    Für TV wäre eigentlich YV12 als Farbraum korrekt. Komischerweise ergibt das Falschfarben.


    Ich hab aber gerade festgestellt, das ich mich zu früh gefreut hatte. Mit Software-Decoder geht zwar das Umschalten viel schneller und ohne Verblockung. Allerdings hat heute nach Start von VDR bis zum Bild wieder lange gedauert. Wieder etwa 10 Sekunden.
    Hast Du das auch? Oder evtl. ne Idee.
    Im Log find ich nur, das nach den 10 Sekunden softdevice den Videolayer ein zweites Mal konfiguriert.

    So, ich hab noch ein bißchen weiter experimentiert:


    Ich hatte noch folgendes Problem:
    Es hat nach dem VDR-Start sehr lange gedauert (ca. 10 Sekunden) bis ein Bild kam. Außerdem hatte ich teilweise sehr lange Umschaltzeiten (auch bis 10 Sekunden). Oft gings auch sehr schnell. Aber manchmal eben unerklärlicherweise nicht. Des weiteren hat mich genervt, das beim Umschalten das ganze Bild erstmal total verblockt ist.


    Ich hab dann mal das Log genauer analysiert. Es scheint am Hardwaredecoder zu liegen. Der scheint mit fehlerhaften MPEG2-Daten richtig aus dem Tritt zu kommen.


    Also versuchweise abgeschaltet, indem ich dem softdevice nur noch '-vo dfb:viatv' mitgebe anstelle von '-vo dfb:cle266:viatv'.
    Siehe da, Umschaltzeiten sind allgemein kürzer (nur noch ca. 1 Sekunde). Keine Verblockung beim Umschalten. Denkpausen beim Umschalten sind nur noch äußerst selten. Zeit von VDR-Start bis zum Bild hat sich halbiert (ca. 5 Sekunden).


    Nun zur CPU-Last: Ich hatte laut Top mit Hardware-Beschleunigung immer um die 30 % Last.
    Jetzt sind es 10 % mehr. Also 40 %.
    Der Digitainer kann das also eigentlich locker verkraften.
    Ich habs jetzt so gelassen. Es nützt mir ja auch nichts, wenn sich die CPU langweilt. Von daher ist es egal.
    Ruckler o.ä. hab ich dadurch auch keine. Die Bildqualität ist, wie gehabt, einwandfrei.

    Im Falle Technotrend ist das fürchterliche eigentlich:
    Die C-1500 funktioniert noch nicht mal unter Windows richtig. Zumindest meine alte hab ich unter Windows nie Aussetzerfrei mit BDA-Treibern zum Laufen gekriegt. Nur mit dem WDM-Treiber lief sie und war damit auch nur mit der mitgelieferten Software nutzbar.
    Lustigerweise läuft sie unter Linux reibungslos.


    Irgendwie scheinen einige Hersteller nicht nur kein Interesse daran zu haben, das ihre Hardware unter Linux läuft. Viel schlimmer noch, sie scheinen generell kein Interesse daran zu haben, das ihre Hardware überhaupt irgendwo problemlos läuft.


    Im Falle TT kann ich es aber gleich gar nicht verstehen. Schließlich ist im Falle ihrer FF-Karte wohl ein VDR das Haupt-Einsatzfeld. Gerade TT müßte eigentlich gemerkt haben, das es durchaus einen Markt dafür gibt.

    Hi,


    Ich stehe vor der Entscheidung, mir eine neue Budget DVB-C Karte zuzulegen. Das Problem ist nur welche.


    Ich habe eine Technotrend C-1500. Die funktioniert ganz hervorragend. Weiterhin hab ich eine Digital Everywhere FloppyDTV. Die läuft leider nicht. Es hat sich da leider noch keiner gefunden, der einen Treiber programmieren kann. Obwohl die Karte selbst hervorragend ist.


    Nach einigem Lesen fand ich, das die C-1500 inzwischen einen neuen Tuner hat. Und der wohl auch wieder Probleme bereitet.


    Alternativ stand noch die Satelco EasyWatch/ KNCone TVStation zur Wahl. Aber scheinbar scheint es auch da an den neuesten Modellen Änderungen gegeben zu haben, die wieder Probleme machen.


    Eine FullFeatured fällt leider aus, weil wir hier fast ausschließlich QAM256 Sender haben.


    Ach ja, dann noch, sehr interessant, die Twinhan Cab-CI. Darüber hab ich nur sehr wenig gefunden. Offenbar läuft sie. Aber das CI wird nicht unterstützt. Das brauch ich wegen Grundverschlüsselung aber zwingend.


    Ja, nun steh ich da und weiß nicht weiter.
    Kriegt man noch irgendwoher die 'alten' Modelle der C-1500 oder EasyWatch?
    Oder gibts noch ne andere empfehlenswerte Karte?
    Oder sind meine gefundenen Infos falsch?


    Grüße

    Entschuldigung.


    Meine Aussage mit Theorie und Praxis bezog sich aber auf die sog. Robustheit des Kabelnetzes. Was es da an Problemen gibt, ist alles andere als robust.


    Außerdem frag ich mich immer noch, was MyTheatre da zaubert. Irgendwas muss ja anders sein.

    Ansonsten schau Dir mal Arch an. Die Base-Installation ist auch recht klein. Und ansonsten wir nur genau das installiert, was man explizit auch will.


    Ist jetzt zwar keine wirkliche Mini-Distri. Im Vergleich zu anderen 'Normal' Distris ist es aber schon extrem schlank.

    Jo, das geht sicherlich. Wenn man noch einen COM-Port hat. Meiner ist belegt durch attric.


    Aber zurück zum Treiber-Patch:
    Ich hab nun noch einen Patch fertig gemacht. Wieder anzuwenden gegen das Original, nicht gegen die schon geänderte Version.
    Die Änderung bezieht sich auf die Konsole. Ich hab bei mir die Ausgabe auf der Konsole auch auf 720x576, allerdings ohne Overscan. Und das kam noch nicht als RGB raus. Deswegen ändert dieser Patch auch noch die Ausgabe ohne Overscan auf RGB.

    So und gleich nochmal:
    Ich hab gerade noch die Pinbelegungen vom Scart angeschaut und mit dem Datenblatt des VT1622 abgeglichen.
    Schlechte Nachrichten für alle, die bisher meinten, S-Video zu sehen:
    Am Scart des Digitainer kommt im Normalzustand des viafb-Treibers so kein S-Video raus. Da gibts nur Composite. Geht auch gar nicht anders, weil Scart Composite und S-Video nicht gleichzeitig übertragen kann. Bei S-Video wird nämlich die Composite-Leitung für das Luma-Signal verwendet.
    Um S-Video auszugeben, muss im Register 0x02 des VT1622 ein anderer Wert stehen. Und zwar 0x01.
    Ich kanns an meinem derzeitigen TV nicht verifizieren. Weil der am Digitainer immer gleich auf RGB geht. Und er hat nur RGB-Fähige Eingänge. Ich müsste den Digitainer erst wieder in ein anderes Zimmer tragen. Es wäre nett, wenn das mal einer verifizieren könnte.


    @Morone: Wenn Du wirklich den Treiber entsprechend änderst, dann sollten wir gleich auch noch S-Video vorsehen. Wäre dann echt stark, wenn man per Kernelparameter Composite, S-Video und RGB umschalten könnte.


    Ich will heute abend auch nochmal reinschauen, weil ja momentan bei RGB mit dem Patch die Konsole noch S/W bleibt. Ich hatte, wie gesagt, nur den No-Scale mit Overscan angepasst. In meinem Falle läuft die Konsole ohne Overscan. Und diese Tabelle hatte ich nicht gepatcht.

    Schade:
    Ich hab mich nochmal durchs Datenblatt gegraben. Der VT1622 bietet leider keine Möglichkeit, ein irgendwie schaltbares Ausgangssignal zu erzeugen. Mir gings um Automatische RGB-Umschaltung und evtl. sogar 16:9 Umschaltung. Aber vom TV-Encoder her bietet sich da nichts.


    Verschiedene Spannungen an die Pins zu legen ist ja nicht das Problem. Nur sie per Software schaltbar zu machen, dazu fällt mir nichts ein. Leider. Wäre natürlich genial gewesen, wenn man 16:9 und auch RGB hätte irgendwie automatisch schalten können.

    Uuuups, das hab ich übersehen.
    Folgendes:
    Ich habe bei mir, wie schon erwähnt, die Ausgabe vom Digitainer ziemlich Pixelgenau mit der Ausgabe meines DVD-Players (Grundig GDP5100) abgeglichen. Im Vergleich war das Bild beim Digitainer um ein paar Pixel zu weit rechts.
    Der zweite Parameter verschiebt das Bild um 9 Pixel nach links. Weiter nichts.


    Hier nochmal der Patch für den Original viafb.
    Ich hatte nicht dran gedacht, das ich den ja auch geändert hatte.


    EDIT:
    Morone: Wenn Du da nen Parameter draus machen kannst, das wär natürlich echt der Hit. Ich hatte an sowas gedacht: TVon=1 wie bisher CVBS und S-Video und TVon=2 gibt dann RGB. Dann braucht man keinen neuen Parameter.
    Ich hatte, wie gesagt, reingeschaut. Aber ich hab da keinen wirklich Durchblick.
    Das die Umschaltung nicht funzt, wenn man an nem RGB-Eingang ist, ist klar. Aber falls man mal umsteckt auch einen Nicht-RGB ist es hilfreich. Weil dann würde mit dem Patch nichts gescheites rauskommen. Auf jeden Fall mal kein S-Video. CVBS müßte trotzdem noch gehen.
    Ich nehme an, das der Digitainer immer die RGB-Schaltspannung liefert und den TV damit auf RGB zwingt. Schaltbar machen kann man das wahrscheinlich nicht. Aber das werd ich nochmal durchmessen.

    Der Treiber ist der linux-viafb von directfb.org
    Also ein reiner Framebuffer-Treiber.
    Bei mir läuft VDR auf der Konsole via Framebuffer. Deswegen dieser Treiber.


    Wahrscheinlich ist bei Dir noch ne Skalierung drin. Deswegen die schlechtere Quali. Der viafb ist direkt darauf optimiert, ohne Skalierung das TV-Bild auszugeben. Das ist gar nicht so simpel, weil der VT1622 eigentlich gar nicht darauf ausgelegt ist. Aber wie das unter Linux so ist, kann man jede Hardware vergewaltigen ;)
    Also erstmal musst Du eine Modline für PAL haben. Also 720x576.
    Dann müssen noch ein paar Register im VT1622 gesetzt werden.
    Vom Prinzip her läuft das folgendermaßen ab:
    Es wird ein normales VGA-Bild erzeugt. Der VT1622 captured dann das VGA-Bild und formt es so um, das PAL draus wird.
    Das bedeutet letztendlich, das man zuerst ein VGA-Bild erzeugen muss, das schon PAL entspricht. Dann muss der VT1622 noch überredet werden, das er das Bild nicht nochmals verwurschtelt, sondern es nimmt, wie es ist.


    Du kannst die Registersettings vom viafb übernehmen. Die sind eigentlich auf PAL optimiert. Nur musst Du dann Deine Modline so anpassen, das das Bild auch passt.
    Für den Framebuffer-Treiber ist halt schon ein passender Eintrag für die fb.modes dabei. Das ist der Vorteil.
    Aber grundsätzlich sollte unter X dieselbe Qualität erreichbar sein.


    Noch ein Hinweis für alles Framebuffer-Nutzer:
    Ich habe nur den Teil des Treibers gepatch, der sich auf eine Overscan-Ausgabe ohne Skalierung bezieht. D.h. wenn eine Konsole ohne Overscan angezeigt wird, dann ist es immer noch S/W. Wichtig ist eigentlich, das in der fb.modes das Flag 'bcast true' gesetzt ist.

    @Morone: Du kannst natürlich keine VGA-Qualität erwarten. Konsole am TV über TV-Ausgang ist auch nix. Dafür ist es nicht gemacht. Aber vergleiche mal das Videobild mit dem eines DVD-Players. Bei mir (jetzt an nem 32" LCD) ergeben sich da keine sichtbaren Unterschiede. Sollte es bei Dir deutliche Unterschiede geben, dann streut vielleicht eine Steckkarte im Digitainer in das Verbindungskabel ein. Also ich hab hier zumindest ein absolut scharfes und klares Bild.
    Versuch mal bitte den Wert 0x22 in dem Register. Das müßte eigentlich auch gehen. Und das schaltet den bei PAL eigentlich üblichen Composite Sync ein.


    @All: Hier der Patch. Probiert es aus. Er ist gegen den linux-viafb aus dem DirectFB.org CVS. Er setzt 0x22. Also RGB mit Composite Sync. Die erste Version war RGB mit Horizontal Sync.
    Ich bitte um Rückmeldung, ob es funktioniert. Sollte das bei einzelnen nicht hinhauen, dann muss ich nochmal andere Parameter setzen. Bei mir funktionert er ohne Probleme.


    Nochmal: Nach dem Patch funktioniert nur noch RGB. S-Video kommt dann nicht mehr raus.


    Und noch eins: Ich hab inzwischen rausgefunden, das man sogar Komponenten Video ausgeben könnte. Auch nett. Müßte man aber nen Scart-Adapter basteln/kaufen oder zusätzliche Buchsen in den Digitainer bauen. Allerdings seh ich da keinen Vorteil gegenüber RGB.


    Also genug geschwätzt. Anzuwenden ist der Patch mit
    patch -p1 -i linux-viafb-patch.diff

    @Morone: Ich hab grad nochmal ins Datenblatt geschaut. Also bei Dir war schon auf RGB konfiguriert, wenn da 2b drin stand. Aber es war Sync on Green eingeschaltet. Das funktioniert bei Scart-RGB nicht. Da kommt der Sync über die Composite-Leitung, soweit ich weiß.
    Außerdem war noch ein Parameter gesetzt, von dem ich nicht weiß, wozu er gut ist. Nennt sich 'Output for CSO'. Normalerweise ist 'Output for HSO' Default. So steht es jetzt auch, wenn man 0x02 rein schreibt. Mir fällt aber grad nicht ein, wofür CSO und HSO stehen könnten.


    EDIT: Grad gefunden:
    CSO steht für TV Composite Sync
    HSO steht für Horizontal Sync


    Eigentlich wäre CSO richtig, aber auf HSO funktionierts. Sehr komisch. Ich muss das heute nochmal austesten, bevor ich einen falschen Patch abliefere. Aber ich glaube, die CSO/HSO Einstellung ist egal, weil die auf nem extra PIN raus geht, der glaub gar nicht verbunden ist.
    Ich denke, es lag bei Dir an dem Sync on Green.

    Hmmpf,
    ich hab grad nochmal im Sourcecode vom viafb gewühlt. Also ich blick da nicht durch. Die Initialtabelle entsprechend zu ändern ist ja kein Problem. Aber was der dann damit treibt, das blick ich nicht. Was ich rein schreib, das funktioniert auch. Aber ich hab kein Durchblick, wie man den Sourcecode ändern könnte, damit man es per Parameter einstellen kann.

    Jo, ich hatte das nur beim Framebuffer-Treiber von DirectFB gemacht. Beim Openchrome kann natürlich logischerweise was anderes gesetzt werden.


    Was die Parameter angeht:
    Das ist mein Problem. Ich kanns nicht. Ich kann das eine Headerfile vom Treiber so anpassen, das RGB raus kommt. Wenn man es aber über Parameter steuern will, dann müsste man einen neuen Parameter für den Treiber erfinden. D.h. wirklich was programmieren. Ich kann zwar ein bißchen C, aber bei dem, was die da im Treiber veranstalten, hab ich echt keinen Durchblick. Deswegen kann ich nur einen harten Patch auf RGB zur Verfügung stellen. Bin gestern nicht mehr dazu gekommen. Heute abend mach ich den fertig.


    Was die Schaltspannung angeht:
    Eine Schaltspannung kann man vom VT1622 nicht abgreifen. Die gibt es einfach nicht. Deswegen wird das nicht gehen.
    Aber wenn mich nicht alles täuscht, dann liegt beim Digitainer die Schaltspannung permanent an, egal was eingestellt ist. Deswegen kommt an nem RGB-fähigen Eingang immer nur S/W raus, egal was man im Bios einstellt. Der Eingang wird glaub immer auf RGB geschaltet. Aber ich werd mir das nochmal reinziehen. Da muss ich mal mit nem Messgerät an den Digitainer. Wird aber noch dauern.


    Wie gesagt, heut abend kommt erstmal der Patch.


    @Morone: Wie sieht bei Dir das RGB-Bild mit dem Openchrome aus? Auch so ein deutlicher Unterschied?

    Also:


    ich habs heute ausprobiert. RGB funktioniert wunderbar. Es ist im Digitainer auch korrekt verkabelt und lief auf Anhieb.
    Wie gesagt besteht das Problem nur darin, das der TV Encoder VT1622 nur vier Ausgänge hat. Das reicht nicht, um Composite, S-Video und RGB gleichzeitig auszugeben. Deswegen werden über ein Register die Ausgänge auf den entsprechenden Modus umgeschaltet. Das betreffende Register hat die Numer Hex 02. Inhalt ist normalerweise 0x00, was bedeutet, das Composite und S-Video ausgegeben werden. Deswegen das Schwarz/Weiß Bild, wenn man den TV auf RGB stellt. Schreibt man den Wert 0x02 in dieses Register, dann kommt astreines RGB raus, aber eben kein Composite und S-Video mehr. Und die Farben stimmen auch.


    Das es wirklich RGB ist, sieht man sofort. An meinem Test-Fernseher (älterer Sony) ist die Ausgabe nicht mehr von der eines über RGB angeschlossenen DVD-Players zu unterscheiden. Außerdem kann man bei dem TV die Farbe nicht mehr regeln, wenn wirklich RGB eingespeist wird. Auch das war gegeben. Ich habe noch weitere Testbilder probiert. Da sind teilweise sehr feine Linien dabei. Normal waren die über den Digitainer nicht mehr zu erkennen. Nach der Umschaltung waren sie klar und einwandfrei zu erkennen.


    Wenn Interesse besteht, kann ich einen Patch für den viafb-Treiber fertig machen. Ändert dann zwar nur ein Hex-Wert in den Initialtabellen, aber gut. Ein so gepatchter Treiber geht dann aber nur noch für RGB.


    Um es richtig zu machen, müßte man irgendwie erkennen, was im Bios eingestellt wurde und anhand dessen die Register passend setzen. Leider reichen dafür meine Kenntnisse in Treiberprogrammierung bei weitem nicht aus. Wenn sich ein Entwickler dafür finden würde, dann kann ich aber gerne mit den Register-Settings behilflich sein.


    Grüße

    Zitat

    Original von linowsat
    Das Kabelnetz ist ja wesentlich robuster gegenüber Interferenzen und von daher kann auf den zusätzlichen Fehlerschutz durch Forward Error Correction verzichtet werden.


    Grüße
    Oliver


    Soweit die Theorie. In der Praxis siehts leider anders aus.
    Das erklärt auch das oben beschriebene Phänomen nicht.

    So, ich bin jetzt nochmal dran gewesen. Ich hab die Bildposition nun um 5 Pixel versetzt. Jetzt stimmt die Ausgabe vom Digitainer exakt mit der meines DVD-Players überein. Der riesen Overscan kommt offenbar vom Fernseher. Jedenfalls schneidet der bei DVD genauso viel ab.


    Was RGB angeht:
    Falsch verdrahtet wahrscheinlich nicht. Der Witz ist, das der VT1622 nur 4 Ausgänge fürs TV-Bild hat. Das bedeutet, das S-Video, Composite und RGB nicht gleichzeitig ausgegeben werden. Je nach Registereinstellungen werden die 4 Ausgänge umkonfiguriert. Der ViaFB-Treiber konfiguriert den Ausgang immer auf CVBS + S-Video. Egal, was im Bios eingestellt ist. Auf RGB stellt er nie.


    Ich werd das nochmal austesten. Die zugehörigen Registereinstellungen weiß ich schon. Ich bin nur noch nicht zum Test gekommen. Ich werde berichten.