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.

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

1

Wednesday, July 9th 2008, 11:09pm

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

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


Joe_D

Professional

Posts: 977

Location: Kuchen

  • Send private message

2

Thursday, July 10th 2008, 7:51am

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

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

3

Thursday, July 10th 2008, 7:52pm

Hi Joe_D,

Quoted

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.

Quoted

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

This post has been edited 2 times, last edit by "sparkie" (Jul 10th 2008, 7:59pm)


Posts: 3,490

Location: mitten im Ruhrgebiet

Occupation: Dipl. Ing.

  • Send private message

4

Thursday, July 10th 2008, 9:53pm

Scheint als wurde es sich langsam lohnen das vga-scart kabel für meine 9200se fertig zu bekommen...
Bin jedenfalls gespannt wie es weitergeht mit diesem Treiber!

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

5

Saturday, July 12th 2008, 8:29am

Quoted

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.

6

Saturday, July 12th 2008, 2:39pm

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:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Jul 12 14:08:03 vdrclient_mediapc 2008-07-12_5
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_since.tv_usec: 7279
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_now.tv_usec: 253663
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_trim: 200
Jul 12 14:08:03 vdrclient_mediapc 2008-07-12_5
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_since.tv_usec: 12493
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_now.tv_usec: 298869
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_trim: 200
Jul 12 14:08:03 vdrclient_mediapc 2008-07-12_5
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_since.tv_usec: 6744
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_now.tv_usec: 333109
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_trim: 0
Jul 12 14:08:03 vdrclient_mediapc 2008-07-12_5
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_since.tv_usec: 4750
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_now.tv_usec: 371113
Jul 12 14:08:03 vdrclient_mediapc vdr: [8014] vsync.vbl_trim: 200


video-xv.c (softdevice-0.5.0)

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
nt cXvVideoOut::PutXvImage(XvImage *xv_image,
int edge_width, int edge_height) {

#ifdef SYNC_FIELDS

static int fd;
static drm_radeon_vsync_t vsync;
int errno;

if (!fd && (fd = drmOpen("radeon", 0)) < 0) {
esyslog("drmOpen: %sn", strerror(errno));
}

if (ioctl(fd, DRM_IOCTL_RADEON_VSYNC, &vsync)) {
esyslog("DRM_IOCTL_RADEON_VSYNC: %sn", strerror(errno));
}


/*
* here we continously monitor and correct placement of xine-lib's
* xv_display_frame() call in relation to vertical blanking intervals (VBI)
* of graphics card.
*
* to achieve a maximum amount of immunity against jitter
* we always center the call to xv_display_frame() in the middle
* of 2 consecutive VBIs.
*
* there are no special hysteresis requirements:
* we even can choose another vbl_trim value each adjacent call
*
* theory of operation:
*
* - a vbl_trim value of 0 yields in a slower graphics card frame rate
*
* - thus increasing the time between 2 VBIs
*
* - as a result from xv_display_frame()-call point of view the
* time distance to the last VBI decreases
*
* - dependend on value of vsync.vbl_since.tv_usec (the elapsed
* time since last VBI) we decide whether to increase
* or to decrease graphics cards framerate.
*
* - illustration of how VBI of graphics card wander into
* the center of xines xv_display_frame() calls, if graphics card framerate
* is a little slower than xine's call to xv_display_frame()
*
* xine reference clock (calls to xv_display_frame())
* ______ ________ ________ ________
* |________| |________| |________| |_______
* ^ ^
* | |
* graphics card clock (VBLANK edges): |
* _______| _________ _________| ________
* |_________| |_________| |_________| |__
* | |
* out of center centered
* | |
* | <--- edge drifts into the middle ---> |
* | of xine reference clock phase |
*
*
*/

esyslog("vsync.vbl_since.tv_usec: %d", vsync.vbl_since.tv_usec);
esyslog("vsync.vbl_now.tv_usec: %d", vsync.vbl_now.tv_usec);
esyslog("vsync.vbl_trim: %d", vsync.vbl_trim);
/*
* RGB PAL is 50Hz and cycle duration of 20000us
* i.e. 10000us tip the balance
*/

if (vsync.vbl_since.tv_usec < 10000) {
vsync.vbl_trim = MAX_DRIFT_TRIM;
} else {
vsync.vbl_trim = 0;
}

#endif

// if (useShm)
// return XvShmPutImage(dpy, port,
// win, gc,
// xv_image,
// sxoff+edge_width, syoff+edge_height, /* sx, sy */
// swidth, sheight, /* sw, sh */
// lxoff, lyoff, /* dx, dy */
// lwidth, lheight, /* dw, dh */
// False);
// else
return XvPutImage(dpy, port,
win, gc,
xv_image,
sxoff+edge_width, syoff+edge_height, /* sx, sy */
swidth, sheight, /* sw, sh */
lxoff, lyoff, /* dx, dy */
lwidth, lheight /* dw, dh */
);
};



field_sync_drm_V2.patch (linux 2.6.25-ARCH)

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
diff -rupN orig/linux-2.6.25/drivers/char/drm/radeon_drm.h patch/linux-2.6.25/drivers/char/drm/radeon_drm.h
--- orig/linux-2.6.25/drivers/char/drm/radeon_drm.h 2008-04-17 04:49:44.000000000 +0200
+++ patch/linux-2.6.25/drivers/char/drm/radeon_drm.h 2008-07-10 10:43:15.000000000 +0200
@@ -485,6 +485,7 @@ typedef struct {
#define DRM_RADEON_SETPARAM 0x19
#define DRM_RADEON_SURF_ALLOC 0x1a
#define DRM_RADEON_SURF_FREE 0x1b
+#define DRM_RADEON_VSYNC 0x1c

#define DRM_IOCTL_RADEON_CP_INIT DRM_IOW( DRM_COMMAND_BASE + DRM_RADEON_CP_INIT, drm_radeon_init_t)
#define DRM_IOCTL_RADEON_CP_START DRM_IO( DRM_COMMAND_BASE + DRM_RADEON_CP_START)
@@ -513,6 +514,7 @@ typedef struct {
#define DRM_IOCTL_RADEON_SETPARAM DRM_IOW( DRM_COMMAND_BASE + DRM_RADEON_SETPARAM, drm_radeon_setparam_t)
#define DRM_IOCTL_RADEON_SURF_ALLOC DRM_IOW( DRM_COMMAND_BASE + DRM_RADEON_SURF_ALLOC, drm_radeon_surface_alloc_t)
#define DRM_IOCTL_RADEON_SURF_FREE DRM_IOW( DRM_COMMAND_BASE + DRM_RADEON_SURF_FREE, drm_radeon_surface_free_t)
+#define DRM_IOCTL_RADEON_VSYNC DRM_IOWR(DRM_COMMAND_BASE + DRM_RADEON_VSYNC, drm_radeon_vsync_t)

typedef struct drm_radeon_init {
enum {
@@ -735,6 +737,14 @@ typedef struct drm_radeon_surface_free {
unsigned int address;
} drm_radeon_surface_free_t;

+typedef struct drm_radeon_vsync {
+ struct timeval vbl_now; /* time when this ioctl() has been called */
+ struct timeval vbl_since; /* time since last vertical blank */
+ unsigned vbl_received; /* continously counting blanking intervals */
+ unsigned vbl_trim; /* graphics card frame rate adjust */
+} drm_radeon_vsync_t;
+
+#define MAX_DRIFT_TRIM 200
#define DRM_RADEON_VBLANK_CRTC1 1
#define DRM_RADEON_VBLANK_CRTC2 2

diff -rupN orig/linux-2.6.25/drivers/char/drm/radeon_drv.h patch/linux-2.6.25/drivers/char/drm/radeon_drv.h
--- orig/linux-2.6.25/drivers/char/drm/radeon_drv.h 2008-04-17 04:49:44.000000000 +0200
+++ patch/linux-2.6.25/drivers/char/drm/radeon_drv.h 2008-07-10 10:44:10.000000000 +0200
@@ -307,6 +307,10 @@ typedef struct drm_radeon_private {
/* starting from here on, data is preserved accross an open */
uint32_t flags; /* see radeon_chip_flags */
unsigned long fb_aper_offset;
+
+ /* field sync circuitry */
+ struct timeval vbl_last;
+ u32 trim;
} drm_radeon_private_t;

typedef struct drm_radeon_buf_priv {
diff -rupN orig/linux-2.6.25/drivers/char/drm/radeon_irq.c patch/linux-2.6.25/drivers/char/drm/radeon_irq.c
--- orig/linux-2.6.25/drivers/char/drm/radeon_irq.c 2008-04-17 04:49:44.000000000 +0200
+++ patch/linux-2.6.25/drivers/char/drm/radeon_irq.c 2008-07-10 10:47:28.000000000 +0200
@@ -62,6 +62,8 @@ static __inline__ u32 radeon_acknowledge
* tied to dma at all, this is just a hangover from dri prehistory.
*/

+#define RADEON_CRTC_H_TOTAL_DISP 0x0200
+
irqreturn_t radeon_driver_irq_handler(DRM_IRQ_ARGS)
{
struct drm_device *dev = (struct drm_device *) arg;
@@ -102,8 +104,24 @@ irqreturn_t radeon_driver_irq_handler(DR
(vblank_crtc & DRM_RADEON_VBLANK_CRTC2)))
atomic_inc(&dev->vbl_received);

+ do_gettimeofday(&dev_priv->vbl_last);
+
DRM_WAKEUP(&dev->vbl_queue);
drm_vbl_send_signals(dev);
+
+ /*
+ * if issued we inject a few horizontal lines
+ * with modified length to trim frame rate as needed.
+ *
+ * don't try this at home:-)
+ */
+ if (dev_priv->trim) {
+ udelay(200);
+ RADEON_WRITE(RADEON_CRTC_H_TOTAL_DISP, 0x00590068);
+ udelay(dev_priv->trim);
+ RADEON_WRITE(RADEON_CRTC_H_TOTAL_DISP, 0x0059006e);
+ }
+
}

return IRQ_HANDLED;
diff -rupN orig/linux-2.6.25/drivers/char/drm/radeon_state.c patch/linux-2.6.25/drivers/char/drm/radeon_state.c
--- orig/linux-2.6.25/drivers/char/drm/radeon_state.c 2008-04-17 04:49:44.000000000 +0200
+++ patch/linux-2.6.25/drivers/char/drm/radeon_state.c 2008-07-10 11:45:11.000000000 +0200
@@ -2099,6 +2099,42 @@ static int radeon_surface_free(struct dr
return 0;
}

+static int radeon_vsync(struct drm_device *dev, void *data, struct drm_file *file_priv)
+{
+ drm_radeon_private_t *dev_priv = dev->dev_private;
+ struct drm_radeon_vsync *t = data;
+ drm_radeon_vsync_t vsync;
+
+ printk(KERN_INFO "2008-07-12_5n" );
+
+/**
+ if (DRM_COPY_FROM_USER(&vsync, (drm_radeon_vsync_t __user *)data, sizeof(vsync))) {
+ DRM_ERROR("copy_from_usern");
+ return -EFAULT;
+ }
+*/
+ memcpy(&vsync,t,sizeof(vsync));
+
+ if (vsync.vbl_trim != ~0) {
+ if (vsync.vbl_trim > MAX_DRIFT_TRIM) {
+ printk(KERN_DEBUG "[drm] clipped radeon drift trim to max of %dn", MAX_DRIFT_TRIM);
+ vsync.vbl_trim = MAX_DRIFT_TRIM;
+ }
+ if (dev_priv->trim != vsync.vbl_trim) {
+// printk(KERN_DEBUG "[drm] changed radeon drift trim from %d -> %dn", dev_priv->trim, vsync.vbl_trim);
+ dev_priv->trim = vsync.vbl_trim;
+ }
+ }
+ do_gettimeofday(&vsync.vbl_now);
+ if (vsync.vbl_now.tv_usec < dev_priv->vbl_last.tv_usec) {
+ vsync.vbl_since.tv_sec = vsync.vbl_now.tv_sec - dev_priv->vbl_last.tv_sec - 1;
+ vsync.vbl_since.tv_usec = vsync.vbl_now.tv_usec - dev_priv->vbl_last.tv_usec + 1000000;
+ } else {
+ vsync.vbl_since.tv_sec = vsync.vbl_now.tv_sec - dev_priv->vbl_last.tv_sec;
+ vsync.vbl_since.tv_usec = vsync.vbl_now.tv_usec - dev_priv->vbl_last.tv_usec;
+ }
+ vsync.vbl_received = atomic_read(&dev->vbl_received);
+
+/**
+ if (DRM_COPY_TO_USER((drm_radeon_vsync_t __user *)data, &vsync, sizeof(vsync))) {
+ DRM_ERROR("copy_to_usern");
+ return -EFAULT;
+ } else {
+ return 0;
+ }
+*/
+ memcpy(t,&vsync,sizeof(vsync));
+
+ return 0;
+}
+
static int radeon_cp_clear(struct drm_device *dev, void *data, struct drm_file *file_priv)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
@@ -3186,7 +3222,8 @@ struct drm_ioctl_desc radeon_ioctls[] =
DRM_IOCTL_DEF(DRM_RADEON_IRQ_WAIT, radeon_irq_wait, DRM_AUTH),
DRM_IOCTL_DEF(DRM_RADEON_SETPARAM, radeon_cp_setparam, DRM_AUTH),
DRM_IOCTL_DEF(DRM_RADEON_SURF_ALLOC, radeon_surface_alloc, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_SURF_FREE, radeon_surface_free, DRM_AUTH)
+ DRM_IOCTL_DEF(DRM_RADEON_SURF_FREE, radeon_surface_free, DRM_AUTH),
+ DRM_IOCTL_DEF(DRM_RADEON_VSYNC, radeon_vsync, DRM_AUTH),
};

int radeon_max_ioctl = DRM_ARRAY_SIZE(radeon_ioctls);


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

7

Saturday, July 12th 2008, 4:13pm

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

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

8

Saturday, July 12th 2008, 5:31pm

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
sparkie has attached the following file:
  • messreihe.txt (20.98 kB - 333 times downloaded - latest: Aug 18th 2014, 11:33am)

This post has been edited 3 times, last edit by "sparkie" (Jul 13th 2008, 10:46am)


  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

9

Saturday, July 12th 2008, 5:51pm

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

Quoted

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.

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

10

Saturday, July 12th 2008, 8:37pm

Hallo Matthias,

da sind wir wieder:)

Quoted

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.

Source code

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

This post has been edited 3 times, last edit by "sparkie" (Jul 13th 2008, 6:23am)


11

Sunday, July 13th 2008, 1:59pm

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

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Jul 13 12:36:40 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:40 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:41 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:41 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:42 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:42 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:47 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:47 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:50 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:50 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:51 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:51 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:53 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:53 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:55 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:55 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:56 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:56 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:57 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:57 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0
Jul 13 12:36:58 vdrclient_mediapc [drm] changed radeon drift trim from 0 -> 200
Jul 13 12:36:58 vdrclient_mediapc [drm] changed radeon drift trim from 200 -> 0



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?

Source code

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



So long,

Matthias

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

12

Sunday, July 13th 2008, 2:36pm

Hi Matthias,

Quoted

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

Quoted

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.

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

Quoted

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

Source code

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


-sparkie

13

Sunday, July 13th 2008, 3:10pm

Quoted

Original von sparkie

Quoted

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

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

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

14

Sunday, July 13th 2008, 3:28pm

Quoted

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.

This post has been edited 1 times, last edit by "sparkie" (Jul 13th 2008, 4:05pm)


15

Sunday, July 13th 2008, 7:20pm

Hallo sparkie,

Quoted

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.

Quoted

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.


Quoted

Original von sparkie

Quoted

Original von Hitman47
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.

Source 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

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

16

Sunday, July 13th 2008, 10:17pm

Quoted

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!

17

Monday, July 14th 2008, 9:59pm

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

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

18

Tuesday, July 15th 2008, 8:18am

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

Quoted

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:

Source code

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

Source code

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

Source code

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

  • "sparkie" started this thread

Posts: 2,984

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

19

Tuesday, July 15th 2008, 9:11pm

Hallo Matthias,

zu deinen Anmerkungen:

Quoted

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.

Quoted

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.

Quoted

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.

Quoted

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.

Quoted

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?

Quoted

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.

Quoted

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

This post has been edited 2 times, last edit by "sparkie" (Jul 15th 2008, 9:21pm)


20

Thursday, July 17th 2008, 9:43pm

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.


Quoted

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

This post has been edited 1 times, last edit by "Hitman47" (Jul 17th 2008, 9:47pm)