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.

stl

Fortgeschrittener

Beiträge: 456

Wohnort: 14612 Falkensee

  • Nachricht senden

21

Freitag, 18. Juli 2008, 10:52

Zitat

Original von Hitman47

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.


Softdevice versucht natürlich auch sich auf den Bildwechsel zu synchronisieren. So sollte in softdevice verhindert werden, das versucht wird Verzögerungszeiten kleiner als 1 Frame auszugleichen. Dies kann durch Setzen der Variablen displayTimeUS (im Konstruktor) auf die Zeit, die das Display für 1 Frame benötigt, erreicht werden (Angabe in Microsekunden).
Der Ausgleich der Zeiten über drm sollte nur dann erfolgen, wenn der Anfängliche-Sync (nach Senderwechsel) erreicht ist:
if (offsetInHold || frame >= 200) { /* do drm adjustment */}

Gruß Stefan

sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

22

Freitag, 18. Juli 2008, 11:04

Hi Matthias,

Zitat

Originally posted by Hitman47
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.


Mit diesem Fund hast du genau ins Schwarze getroffen! Ich habe leider immer nur mit demselben Testmaterial gearbeitet. Ich konnte aber inzwischen die von dir bereits hier

Zitat

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.


bemerkten Probleme reproduzieren. Den Grund dafuer konnte ich jetzt auch herausfinden:

In allen bis heute veroeffentlichen Versionen des Treibers 'xf86-video-ati' befindet sich ein Scaler Bug. Dieser betrifft aber nur den 'Overlay Adapter'. Der Bug ist vermutlich bislang nur deswegen niemand aufgefallen, da die dadurch auftetende vertikale Verschiebung der Scanlines im Framebuffer minimal ist. Mit aktiviertem Deinterlacer hat man keine Chance, den Fehler zu bemerken.

Da wir in unserem System nicht mehr deinterlacen, machen sich die Ueberschreiber der Even/Odd Fields sofort in den von dir erkannten Verzerrungen bemerkbar. Der Bug tritt aber nur bei bestimmten Senderaufloesungen z.B. 480x576 in Erscheinung. Darum habe ich es bislang nicht bemerkt.

Dieser Xserver Bug sollte sich aber fixen lassen. Andererseits ist es jetzt gar nicht mehr unbedingt noetig. Deine Erfahrung

Zitat

Aber guter Dinge bin ich trotzdem, denn der Bildfluss ist genial; wie man es nun einmal von einer "normalen" TV-Umgebung gewohnt ist.


kann ich teilen. Der in Version 6.9.0 von 'xf86-video-ati' erstmalig eingefuehrte 'Textured Adapter', der alternativ zum 'Overlay Adapter' eingesetzt werden kann, hat diesen Bug nicht!

Zitat

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?


durch den VDR sind wir wohl eine der wenigen mit der speziellen Anforderung, das VGA Signal mit einem externen Signal (Stream) zu synchronisieren. Ich weiss nicht, ob/wann wir da jemals einen Upstream-Support erhalten. Aber in einer speziellen LowCost Budget VDR Distribution koennte man das Erfordernis entsprechend beruecksichtigen.

Zitat

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


richtig. Konnte ich auch sehen. Der 'Textured Adapter' hat in dieser Version noch keine Tearing Protection. Leider komme ich erst am Wochenende dazu, den Tearing Patch, der das Problem behebt, zu testen.

Zitat

(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?


ja, vermutlich ein Problem in der DRM Library. Ich konnte bislang keine negativen Folgen sehen und bin dem deswegen nicht weiter nachgegangen.

Fuer das Wochenende habe ich geplant, ein LowCost Budget Referenzsystem mit Pentium 800MHz, TT-S1401, und Radeon 9600SE zu bauen. Wenn hier alle Tests erfolgreich abgeschlossen sind, kann ich dir gerne wieder einen Software-Update (fuer den Pundit) zukommen lassen.

Ich werde dann mal versuchen hier im Forum eine umfassende Hardware/Software-Beschreibung dieses Referenzsystems zu posten, um den Nachbau zu erleichtern.

- sparkie

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sparkie« (18. Juli 2008, 12:28)


sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

23

Montag, 21. Juli 2008, 07:53

anbei ein Update der Patches/Tools rund um das Thema. Neu ist:

- Portierung auf Debian Lenny mit Kernel 2.6.24
- Upgrade des xserver-xorg-video-ati auf Version 6.9.0 + letzte Patches (z.B. experimental texture tearing fix etc.)
- Implementierung noch feinerer 50Hz PAL Timing Justierschritte
- explizites Einschalten der VBLANK Interrupts (ist ab Kernel 2.6.24 erforderlich)
- ein paar kleine Tools

Ich verwende 2 verschiedene diskless Hardware-Testumgebungen, jedoch mit dem gleichen Softwarestand:

System 1:
Prozessor: celeron 2,0GHz
Speicher: 512MB
Grafik: integrierte Radeon 9100 IGP
Budget: TT-S1401

System 2:
Prozessor: Pentium III (Coppermine) 800MHz
Speicher: 512MB
Grafik: AGP Radeon 9200 SE (RV280)
Budget: TT-S1401

Die interlaced PAL-Wiedergabe ist auf beiden Systemen absolut gleitend und ohne Fieldverluste. Selbst die Rechenleistung des kleineren Systems reicht also fuer das Verfahren aus.

Versuchsweise verwende ich jetzt den Textured- statt den Overlay- XV-Adapter. Die Tearfree Acceleration fuer den xserver-xorg-video-ati Treiber, die seit dem 16. Juli als Patch erhaeltlich ist (siehe auch hier) kann mich in diesem fruehen Entwicklungsstadium aber noch nicht ueberzeugen. Dennoch habe ich diesen Patch, der noch zusaetzliche Aenderungen von mir enthaelt, mal in den Anhang gestellt.

Vielmehr lassen sich inzwischen die variablen 50Hz Timings der VGA-Grafik derart exakt einstellen, dass man sie bedingt sogar als Tearing-Fix missbrauchen kann:)

Fuer ein Produktivsystem ist noch folgendes zu implementieren:

- Erkennung der initial field parity
- Tearfree Acceleration fuer Textured XV-Adapter (durch Grafik-Hardware)
- schnellerer Regel-Algorithmus fuer die Erkennung der variablen 50Hz Framerate
- umfangreicheres + besseres Toolset

@Matthias:
mit dem 'intron.c' aus dem Toolset solltest du die VBLANK Interrupts aktivieren koennen.
»sparkie« hat folgende Dateien angehängt:

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »sparkie« (21. Juli 2008, 10:33)


sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

24

Montag, 28. Juli 2008, 23:00

so, wieder ein entscheidendes Problem geloest. Dank der Mithilfe der Radeon-Entwickler (siehe auch dieser Post) konnte ich das von mir oben beschriebene Problem bzgl. 'Scaler Bug' im Radeon-Xserver fixen.

Dieser Patch

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
diff -ru xserver-xorg-video-ati-6.9.0.org/src/radeon_video.c xserver-xorg-video-ati-6.9.0/src/radeon_video.c
--- xserver-xorg-video-ati-6.9.0.org/src/radeon_video.c 2008-05-28 22:35:06.000000000 +0200
+++ xserver-xorg-video-ati-6.9.0/src/radeon_video.c     2008-07-28 22:27:45.000000000 +0200
@@ -2859,7 +2899,7 @@
     OUTREG(RADEON_OV0_P23_V_ACCUM_INIT, p23_v_accum_init);
     OUTREG(RADEON_OV0_P23_H_ACCUM_INIT, p23_h_accum_init);

-   scale_cntl = RADEON_SCALER_ADAPTIVE_DEINT | RADEON_SCALER_DOUBLE_BUFFER
+   scale_cntl = RADEON_SCALER_VERT_PICK_NEAREST | RADEON_SCALER_ADAPTIVE_DEINT | RADEON_SCALER_DOUBLE_BUFFER
         | RADEON_SCALER_ENABLE | RADEON_SCALER_SMART_SWITCH | (0x7f<<16) | scaler_src;
    switch(id){
         case FOURCC_UYVY:
loest also das Problem. Bezueglich der Wiedergabequalitaet sind im Moment keine weiteren Probleme offen. Ich weiss nicht, was man da noch verbessern koennte.

@Matthias:
damit ist auch in den von dir beobachteten Problemfaellen die Wiedergabe absolut gleitend (und jetzt eben sogar mit dem Overlay XV Adapter).
Dieser ist im Moment zu bevorzugen, da er double buffers einsetzt. Und somit im Gegensatz zum textured Adapter keinerlei 'tearing' Probleme hat (siehe oben).
Falls du noch mal testen willst muss ich dir allerdings das komplette 'radeon_video.c' geben, da ich dort noch was anderes gefixt habe.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »sparkie« (31. Juli 2008, 03:17)


sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

25

Dienstag, 29. Juli 2008, 08:05

weitere Diskussionen zum Thema gibt es inzwischen auch auf der vdr- ML:

[vdr] RGB/PAL over VGA at variable frame rate

und auf der xorg-driver-ati- ML:

Problem with persistent scaling/shifting in RADEONDisplayVideo()
(Dieses Problem ist bereits gefixt. EIn herzliches Dankeschoen an die Radeon-Entwickler, insbes. an Roland Scheidegger fuer den entscheidenden Hinweis)

Damit ist mit dem hier vorgestellten Verfahren auf Radeons bereits eingeschraenkter Produktivbetrieb moeglich. Die Bildqualitaet des interlaced PAL am VGA-Port ist einfach sagenhaft.

Zur Vollendung fehlen jetzt nur noch ein paar Fleissaufgaben. Weitere Patches poste ich wieder hier. Mal schauen, wie weit ich am Wochenende komme...:)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sparkie« (2. August 2008, 12:43)


sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

26

Samstag, 2. August 2008, 12:48

Zitat

Fuer ein Produktivsystem ist noch folgendes zu implementieren:

- Erkennung der initial field parity


auch das letzte, mir bekannte Problem mit dem Radeon-Chipsatz ist jetzt geloest. Siehe auch hier:

How to get current field polarity of interlaced video output?

die naechsten Tage gibt's wieder 'nen aktualisierten all-inclusive Patch:)

27

Sonntag, 3. August 2008, 00:45

Hi sparkie,

ich bin bis jetzt leider nicht mehr dazu gekommen zu testen. Es ist sagenhaft, wie du dich da reinhängst und es lohnt sich ja offensichtlich.
Hoffentlich komme ich heute noch zum Testen.

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: DD Cine S (2x DVB-S2); DVB2: Sundtek USB DVB-S2.; DVB3: DVB1: DD Cine S (2x DVB-S2);, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

28

Sonntag, 3. August 2008, 10:44

Hi sparkie,

funzt dein Patch auch mit 'nem Mobility-Chipsatz ( konkret: X700 Mob.) ?

Gruß Tom

sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

29

Sonntag, 3. August 2008, 11:15

@Hitman47:

Zitat

Hoffentlich komme ich heute noch zum Testen.

am besten du wartest meinen naechsten Patch noch ab. Ich habe alles noch deutlich robuster gemacht. Z.B. hinsichtlich der Streuung der Quarzfrequenzen verschiedener Hardware. Es sind dann auch alle mir bislang bekannten Probleme gefixt. Ich hoffe ich schaffe es bis heute abend. Muss heute naemlich noch paar andere Dinge != VDR erledigen;)

@8N1:

Zitat

funzt dein Patch auch mit 'nem Mobility-Chipsatz ( konkret: X700 Mob.) ?

konkret getestet habe ich bislang nur mit Radeons wie 7000, 9200SE, 9250, 9600SE, IGP-9100.
Aber es sollte mit jedem Radeon Chipsatz funktionieren, der von xf86-video-ati bzw. xserver-xorg-video-ati unterstuetzt wird. Und das sind mittlerweile eine ganze Menge. Siehe auch 'man radeon' oder ganz aktuell:

Quellcode

1
wget -q 'http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=blob;h=03622a0c4af391e5f3ef4bd8b8f810eb2d1eff59;hb=1f3eee3682f3598a303c9c3accfbe01b245cacf9;f=man/radeon.man' -O -|nroff -man|less

Am besten erst VGA/SCART ohne alle Patches testen. Wenn das geht, sollte der Patch auch funzen.

Ich muss mal irgendwo die Doku konzentriert zusammenfassen. Als Kabel verwende ich derzeit dieses (also ich glaube, einfacher geht es nun wirklich nicht mehr:)):

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
   VGA                                                SCART

     1 -O------------------------------------------O- 15 R
     2 -O------------------------------------------O- 11 G
     3 -O------------------------------------------O-  7 B

     6 -O---------------------------------------+--O- 13 R Gnd
     7 -O---------------------------------------+--O-  9 G Gnd
     8 -O---------------------------------------+--O-  5 B Gnd
    10 -O---------------------------------------+--O- 17   Gnd
                                                +--O- 14   Gnd
                                                +--O- 18   Gnd
               ------
     9 -O-----|  75R |-----------------------------O- 16
               ------
-VS 14 -O-----------------------+
                                |
                             | /
               ------        |C
-HS 13 -O-----| 680R |-----B-|     BC 547 B
               ------        |E
                             | \
                                |       ------
                                +------| 680R |----O- 20 -CS
                                        ------
  shell-O------------------------------------------O- 21 shell

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sparkie« (7. August 2008, 06:22)


30

Dienstag, 5. August 2008, 20:18

Danke für die Infos. Wenn die neue FP für's Notebook kommt greif ich es mal an.

Gruß Tom

sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

31

Dienstag, 5. August 2008, 20:34

Zitat

Originally posted by 8N1
Danke für die Infos. Wenn die neue FP für's Notebook kommt greif ich es mal an.


alles klar. Ausserdem: das Kabel schon mal vorab zu bauen ist ja nie verkehrt.

leider habe ich es letztes Wochenende nicht mehr geschafft, einen aktuellen Patch rauszugeben. Mir fallen leider immer wieder neue Optimierungen ein, die ich noch reinpacken moechte:)

Mitterweile verliere ich absichtlich ein Field, naemlich wenn ich zu Beginn einer Wiedergabe auf eine andere Fieldparity synchronisieren muss. Naja dadurch konnte ich immerhin einen weiteren Patch in der xine-lib einsparen:D

Ausserdem habe ich anfaenglich den Programmier- und Testaufwand fuer die Synchronisation etwas unterschaetzt. Es soll ja auch auf anderen Maschinen (nicht nur auf meiner) problemlos laufen.
Aber es sieht alles schon sehr gut aus.

Die naechsten Tage gibt's aber in jedem Fall was... auch wenn ich dann vielleicht noch nicht alle Ideen reingepackt habe.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sparkie« (5. August 2008, 21:08)


SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

32

Mittwoch, 6. August 2008, 23:51

@ sparkie
Erstmal super Arbeit, du scheinst eines der Hauptprobleme bei der Wiedergabe von Live-TV am Computer gelöst zu haben! :respekt

Obwohl ich momentan, als FF-Besitzer, mit dem Problem nicht viel zu tun habe, lese ich hier gespannt mit. Spätestens beim Umstieg auf HDTV werde ich mich damit wohl auch beschäftigen müssen.

Zwei Fragen habe ich aber noch:
  1. Wie sieht es mit anderen Programmen unter X aus, laufen die dann auch noch oder läuft X dann nur noch in Kombination mit einem gepatchten Xine-Player?
  2. Wie sind die Chancen, das sich auch andere Grafikkarten benutzen lassen? Konkret die von Nvidia, könnte es mit den Closedsource-Treiber klappen (an ein paar Stellen kommt man ja doch dran)?
    Wenn ich es richtig verstanden habe ist es wohl am wichtigsten den Grafiktreiber einen Vsync-Interrupt zu entlocken. Meine GF2 scheint den schon von sich aus zu liefern (laut Interruptcounter).
    [/list=1]
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

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

33

Donnerstag, 7. August 2008, 19:27

Zitat

Originally posted by SHF
du scheinst eines der Hauptprobleme bei der Wiedergabe von Live-TV am Computer gelöst zu haben!

oh - danke:) Naja, auf einem gewissen, von uns allen so geliebten proprietaeren "sog. Betriebssystem", laeuft sowas ja schon laenger. Umso mehr hat es mich immer geaergert, dass Live-TV und MPEG2 Dekodierung ueber Grafikkarten auf Linux ziemlich vernachlaessigt wird.
Dabei ist die Dekodierung gar nicht so das Problem. Da reichen auch kleine Prozessoren. Das beste Beispiel hierfuer sind die SMTs. Also warum ueberhaupt den nicht vorhandenen GPU Spezifikationen der Grafikkarten hinterherlaufen, wenn alleine die Interlaced-Ausgabe schon die meisten Probleme behebt?

Zitat

[*]Wie sieht es mit anderen Programmen unter X aus, laufen die dann auch noch oder läuft X dann nur noch in Kombination mit einem gepatchten Xine-Player?

mein aktueller Patch, der kurz vor dem Release steht:) geht nur noch gegen das Xserver-DDX xf86-video-ati und das Radeon-DRM Modul. Im Xserver wird dabei nur die XV-Putimage Funktion angefasst. D.h. volle Kompatibilitaet des Xservers bleibt erhalten.

Zitat

[*]Wie sind die Chancen, das sich auch andere Grafikkarten benutzen lassen? Konkret die von Nvidia, könnte es mit den Closedsource-Treiber klappen (an ein paar Stellen kommt man ja doch dran)?
Wenn ich es richtig verstanden habe ist es wohl am wichtigsten den Grafiktreiber einen Vsync-Interrupt zu entlocken. Meine GF2 scheint den schon von sich aus zu liefern (laut Interruptcounter).

die Frage ist halt, inwieweit man sich in den proprietaeren nVidia-Treiber einklinken kann. Vielleicht ein Binaer-Patch? Oder vielleicht ist das Nouveau Projekt eine bessere Grundlage?

Ich habe absichtlich keine radeon-spezifischen Features verwendet, damit der Port auf andere Hardware moeglichst einfach wird.

Konkret habe ich vor einiger Zeit mit xf86-video-intel (allerdings mit GM965/GL960 - ist gerad' nix anderes griffbereit) angefangen. Leider funktioniert dort der XV-Putimage() offenbar im Interlaced Mode nicht richtig. Bin dem aber nicht weiter nachgegangen.

Im Moment kann ich mich mangels Urlaub nicht um alle Baustellen intensiv genug kuemmern. Auch eine Portierung auf DirectFB waere schliesslich sehr interessant. Teilweise habe ich schon damit angefangen. Aber vielleicht hat ja auch sonst noch jemand Lust dazu?

Da alle hardwarespezifischen Probleme fuer die Radeons geloest sind, bleibe ich jetzt erst mal bei denen. AUsserdem sind die inzwischen recht guenstig (ab 8EUR mit Porto), da braucht man gar nicht immer unbedingt die Onboard-Grafik bemuehen. Die Radeons gibt's ab 15EUR ja sogar fuer PCIe - und solche Slots hat man als typischer VDR-User (bis jetzt) eh meistens frei:)

Zudem gibt es die meisten Radeons auch im Low-Profile Format. Zusammen mit einer Low-Profile Budget kann man also kleine Gehaeuse niedriger Bauhoehe einsetzen.

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »sparkie« (7. August 2008, 21:54)


SHF

Erleuchteter

Beiträge: 3 962

Wohnort: hessische Bergstrasse

  • Nachricht senden

34

Freitag, 8. August 2008, 00:37

Zitat

Original von sparkie
Naja, auf einem gewissen, von uns allen so geliebten proprietaeren "sog. Betriebssystem", laeuft sowas ja schon laenger.
Dafür fehlt da das EPG, oder haben die das inzwischen ans laufen gebracht :hat2.

Zitat

die Frage ist halt, inwieweit man sich in den proprietaeren nVidia-Treiber einklinken kann.
Auf der Kernelseite gibt es Quellcode, der ist wohl als Schnittstelle zu dem Binär-Teil.
Da könnte man einklinken, die Frage ist halt, ob das reicht.
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

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »SHF« (8. August 2008, 00:42)


35

Freitag, 8. August 2008, 11:16

Hi sparkie,

klasse Arbeit!
Eine vielleicht doofe Frage:
Mein HD-Ready Fernseher zeigt m.M. mit 1080i über HDMI gefüttert das beste Bild,
obwohl das Panel nur 1024x768 hat. Der interne Deinterlacer ist super.

Wenn ich es richtig verstanden habe, dann ist deine Arbeit hier auf eine Ausgabe von 576i ausgelegt.

Könnte man, bei Ausgabe über xineliboutput, PAL von 576i auf 1080i ohne Qualitätseinbußen wandeln
(ohne Deinterlacing) und so quasi SDTV und HDTV ausschließlich über 1080i ausgeben?

Grüße
Funzt

sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

36

Freitag, 8. August 2008, 20:25

Hi Funzt

Zitat

Originally posted by Funzt
Wenn ich es richtig verstanden habe, dann ist deine Arbeit hier auf eine Ausgabe von 576i ausgelegt.


naja, die Arbeit befasst grundsaetzlich erst einmal nur mit der Regelung des VGA Videotimings durch ein externes Signal. Dass man dadurch unter gewissen Umstaenden (eben genau nur bei 576i) das Deinterlacen einsparen kann, ist sozusagen nur ein 'Abfallprodukt'.

Zitat

Könnte man, bei Ausgabe über xineliboutput, PAL von 576i auf 1080i ohne Qualitätseinbußen wandeln
(ohne Deinterlacing) und so quasi SDTV und HDTV ausschließlich über 1080i ausgeben?


ohne entsprechenden Graka SUpport sehe ich da keine Chance. Selbst bei meiner einfachen SCART Loesung hatte ich schon jede Menge Probleme zu bewaeltigen, damit vertikal keinerlei Skalierung stattfindet. Sonst wuerden sich die Even/Odd Fields gegenseitig ueberschreiben. Vorallem stoesst man hier auf Bugs die sonst niemandem auffallen, weil sonst keiner diesen Modus benutzt:)

-sparkie

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sparkie« (8. August 2008, 20:27)


37

Freitag, 8. August 2008, 20:47

Hi sparkie,

aber 576i über HDMI sollte doch gehen, oder?

Grüße
Funzt

sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

38

Freitag, 8. August 2008, 21:09

Zitat

aber 576i über HDMI sollte doch gehen, oder?


richtig. Jetzt muessten wir nur noch eine entsprechende GraKa finden, die hier gut genug dokumentiert ist:) Ich habe da im Moment nicht so den Ueberblick.

sparkie

Erleuchteter

  • »sparkie« ist der Autor dieses Themas

Beiträge: 3 046

Wohnort: a child of the universe

Beruf: duct tape programmer

  • Nachricht senden

39

Freitag, 8. August 2008, 21:36

so, ich haenge ohne grossen Kommentar mal meine aktuellen Patches hier an. Ich habe alles nochmal komplett ueberarbeitet. Die Regelung arbeitet jetzt wie eine echte PLL, aber halt in Software:)

die Referenzfrequenz auf die gelockt wird, ist die Framerate des DVB Streams. Der VCO ist die Fieldrate, die die VGA produziert.

Das Regelverhalten gefaellt mir schon sehr gut. Die Utility 'drift_control.c' arbeitet standalone (also ohne VDR - nur mit dem gepatchten Xserver und DRM Modul). Damit habe ich das ganze debuggt.
Witzig ist, wenn man mit dem Tool 'trim.c' Stoerungen simuliert und beobachtet wie die Regelung das in moeglichst kurzer Zeit wieder ausgleicht.

Die Fieldparity wird jetzt korrekt erkannt. Die Korrektur der Fieldparity muesste eigentlich in der Xine-Library erfolgen, damit keine sichtbaren Stoerungen auftreten (ist aber wenn ueberhaupt nur einmal beim Start). Damit ich die xine-lib im Moment nicht zu patchen brauche, mache ich diese Korrektur auch gleich im Xserver.

Fuer reine Wiedergabe (ohne gesteckte DVB Karte) liefert der Patch bereits optimale Ergebnisse.

Es ist aber noch ein Problem aufgetreten: Wenn im Rechner eine SAT Karte steckt (egal ob mit oder ohne SAT Kabel), reissen die DVB Treiber sporadisch fuer ueber 21ms die CPU an sich. Ich weiss nicht, was die da wieder programmiert haben. Aber fuer ein Produktivsystem , das auch Aufnehmen kann, reicht das noch nicht.

Durch die Loggings der genauen Zeitmessungen bekomme ich diese Probleme jetzt endlich schwarz auf weiss geliefert. Bei solchen Bugs in den Treibern wundert mich die ganze Ruckelei ueber die sich die Leute bei Budgetloesungen oft beschweren gar nicht mehr:)
»sparkie« hat folgende Dateien angehängt:

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »sparkie« (8. August 2008, 22:23)


Beiträge: 637

Wohnort: Bremen

Beruf: Computer und Netzwerkdoktor

  • Nachricht senden

40

Freitag, 8. August 2008, 21:47

Ich verfolg das ja mit Hochspannung was du da treibst und bin einmal ums nächste begeistert. Wenn du das jetzt nochmal für den Intel Xorg Treiber portieren würdest, da würd ich erst Luftsprünge machen ;)
- HTPC mit zerbasteltem Yavdr 0.6 , Origen ae X15e, MCE Remote, Asus P5N7A-VM, 1x Digibit R1, Kodi und vdr an Pana 46PZ85E
- Diverse HTPCs im Umfeld bei Familie und Freundenm die sich vor mir fürchten, mit allen möglichen gruseligen Konfigurationen.
Auch gern Debian, aber wehe jemand kommt mir mit Suse.

Immortal Romance Spielautomat