You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

stl

Intermediate

Posts: 456

Location: 14612 Falkensee

  • Send private message

21

Friday, July 18th 2008, 10:52am

Quoted

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" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

22

Friday, July 18th 2008, 11:04am

Hi Matthias,

Quoted

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

Quoted

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

Quoted

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!

Quoted

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.

Quoted

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.

Quoted

(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

This post has been edited 1 times, last edit by "sparkie" (Jul 18th 2008, 12:28pm)


  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

23

Monday, July 21st 2008, 7:53am

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 has attached the following files:

This post has been edited 3 times, last edit by "sparkie" (Jul 21st 2008, 10:33am)


  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

24

Monday, July 28th 2008, 11:00pm

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

Source code

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.

This post has been edited 3 times, last edit by "sparkie" (Jul 31st 2008, 3:17am)


  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

25

Tuesday, July 29th 2008, 8:05am

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

This post has been edited 2 times, last edit by "sparkie" (Aug 2nd 2008, 12:43pm)


  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

26

Saturday, August 2nd 2008, 12:48pm

Quoted

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

Sunday, August 3rd 2008, 12:45am

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

28

Sunday, August 3rd 2008, 10:44am

Hi sparkie,

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

Gruß Tom

  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

29

Sunday, August 3rd 2008, 11:15am

@Hitman47:

Quoted

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:

Quoted

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:

Source code

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

Source code

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

This post has been edited 2 times, last edit by "sparkie" (Aug 7th 2008, 6:22am)


30

Tuesday, August 5th 2008, 8:18pm

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

Gruß Tom

  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

31

Tuesday, August 5th 2008, 8:34pm

Quoted

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.

This post has been edited 2 times, last edit by "sparkie" (Aug 5th 2008, 9:08pm)


SHF

Sage

Posts: 3,862

Location: hessische Bergstrasse

  • Send private message

32

Wednesday, August 6th 2008, 11:51pm

@ 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 VDR:

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

33

Thursday, August 7th 2008, 7:27pm

Quoted

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?

Quoted

[*]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.

Quoted

[*]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.

This post has been edited 4 times, last edit by "sparkie" (Aug 7th 2008, 9:54pm)


SHF

Sage

Posts: 3,862

Location: hessische Bergstrasse

  • Send private message

34

Friday, August 8th 2008, 12:37am

Quoted

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.

Quoted

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

vdr-1.4.3-4 mit BigPatch und Plugin BigPack, SuSE 9.0, Kernel 2.4.21, DVB Treiber 06.07.2005 FullTS-Patch, noad 0.6.1
auf HP Vectra VLi8 (PIII 500, 256MB), 16GB 2,5" SSD (Sytem und Swap), 2TB HDD* (Video), 1x TT FF DVB-S 1.5 FullTS-Mod, 1x TT Budget DVB-S

(* Weil ich das inzwischen öfters gefragt wurde: Nein, das BIOS erkennt die grossen Platten nicht vollständig, das stört Linux aber nicht!)

This post has been edited 2 times, last edit by "SHF" (Aug 8th 2008, 12:42am)


35

Friday, August 8th 2008, 11:16am

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" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

36

Friday, August 8th 2008, 8:25pm

Hi Funzt

Quoted

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

Quoted

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

This post has been edited 1 times, last edit by "sparkie" (Aug 8th 2008, 8:27pm)


37

Friday, August 8th 2008, 8:47pm

Hi sparkie,

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

Grüße
Funzt

  • "sparkie" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

38

Friday, August 8th 2008, 9:09pm

Quoted

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" started this thread

Posts: 2,989

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

39

Friday, August 8th 2008, 9:36pm

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 has attached the following files:

This post has been edited 2 times, last edit by "sparkie" (Aug 8th 2008, 10:23pm)


Hibbelharry

Professional

Posts: 620

Location: Bremen

Occupation: Computer und Netzwerkdoktor

  • Send private message

40

Friday, August 8th 2008, 9:47pm

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.5 , Origen ae X15e, MCE Remote, Asus P5N7A-VM, 1x Mystique Satix Xpress Dual, Xbmc und vdr an Pana 46PZ85E
- SMT7020S und S100 mit Gentoo:vdr aus ebuilds,mms handgebaut,xfce4 + viel weiterer Unsinn, einige eigene Patches hier und da.
Auch gern Debian, aber wehe jemand kommt mir mit Suse.