Beiträge von jrie

openSUSE 11.4 hat den xorg-server 1.9.3. Damit läuft aber der nvidia Treiber 195.30 nicht mehr. Dies ist aber der letzte mit dem xine ruckelfrei auf einer 8400 GS läuft.
Wer also ältere Grafikhardware hat, für den ist 11.4 mit vdpau nicht genießbar.
Der älteste Treiber, der geht, ist 256.53.
Die libxcb ist buggy, daher muss LOCKDISPLAY gesetzt sein. War bei 11.3 nicht nötig.
Nach der Installation ist ein Update zu empfehlen, da sonst der atd nicht gestartet wird.

Ich hatte das Problem mit nvram-wakeup im Kernel Bug Tracker gemeldet, und es gibt auch schon einen patch. Mit dem geht es wieder. Es lag an den Umbauten an der RTC.
link

Ja, das wäre eine gute Alternative.
Aber es interessiert mich trotzdem, wieso das bis 2.6.37 gut funktionierte, und mit 2.6.38 nicht mehr geht. Wenn ich erst mal in /sys/class/rtc/rtc0/wakealarm geschrieben habe, kann ich es auch mit nvram-wakeup wieder auslesen, aber nicht davor. Merkwürdig.

Sieht so aus, als ob da schon ein echo 0 > /sys/class/rtc/rtc0/wakealarm vorab gemacht wurde. Für nvram-wakeup ziemlich unpraktisch.

Bei mir geht mit 2.6.38 nvram-wakeup nicht mehr, er liest die Alarmzeit und Alarmdatum fälschlich als 0 aus.
Hat einer eine Idee?

Ich bin gestern mal kurz durch eine ZDF HD Aufnahme mit schnellem Vor- und Rücklauf gegangen, und siehe da, perfekt!!
Deswegen noch einmal ein großes DANKE SCHÖN!!! an Reinhard.
Ich bin sicher, dass sich alle hier freuen, dass die xine Entwicklung weiter geht!

Jörg

Zitat

Original von ciax

mit xinliboutput oder mit xine als ausgabedevice? für xine-ui gab's auch eine latte an patches.

gruß, ciax

Mit vdr-xine und allen neuen xine-ui Patchen.

Seitdem ich die ganzen Patche von Reinhard drin hab, wird (nur) manchmal das Bild beim Schnittmarken verschieben nicht mehr aktualisiert.

Zitat

Original von iNOB
ciax
Den Patch kannst du bei Nichtverwendung von LOCKDISPLAY sowieso weglassen.

Ist das nicht genau umgekehrt? Gerade wenn LOCKDISPLAY weglassen ist, wird mit dem Patch jetzt was übersprungen, was sonst ausgeführt würde. Oder?

Es gibt wieder neue Patche auf xine-devel.

Hat eigentlich schon mal jemand Erfahrungen mit dem vdpau_progressive_detection Patch von Seite 45 gesammelt?

Es ist der vdpau extensions patch von durchflieger, der bewirkt, dass versucht wird, den xine Prozess zu nicen. Aber frag mich nicht, warum das nicht klappt.

das kommt vom vdpau extensions patch

Diese Version vom slow_system Patch ist konfigurierbar, man kann ihn in der xine config an oder aus stellen. Das ist bequemer als jedes mal neu kompilieren und man kann dort auch slow_speed verändern.

diff -Nru a/src/xine-engine/video_out.c b/src/xine-engine/video_out.c
--- a/src/xine-engine/video_out.c	2011-01-22 15:19:08.000000000 +0100
+++ b/src/xine-engine/video_out.c	2011-01-22 04:00:07.000000000 +0100
@@ -62,6 +62,7 @@
  * vo driver). up to 25% less cpu load using deinterlace with film mode.
  */
 #define EXPERIMENTAL_FRAME_QUEUE_OPTIMIZATION 1
+#define SLOW_SYSTEM 1
 
 static vo_frame_t * crop_frame( xine_video_port_t *this_gen, vo_frame_t *img );
 
@@ -835,6 +836,39 @@
     pts = img->vpts;
     diff = cur_vpts - pts;
 
+#if SLOW_SYSTEM
+//    int slow_speed = 124000;
+    int slow_speed = this->xine->config->register_num (this->xine->config, "video_out.slow_speed",1000000, /* default */
+         _("default slow_speed"),
+         _("slow_speed while waiting for stable replay, 1000000=disabled, try 124000 on a slow system, avoid 50000, 25000, etc"), 20, NULL, NULL);
+    if (slow_speed < 1) slow_speed = 1;
+    if (slow_speed > 1000000) slow_speed = 1000000;
+    struct timeval start_slow_speed;
+    struct timeval stop_slow_speed;
+    int prev_speed = _x_get_fine_speed(img->stream);
+    if (!(slow_speed == 1000000) && (prev_speed == 1000000) && (diff > 25000)) { /* reduce speed, if diff is too high at normal speed */
+//    if ((prev_speed == 1000000) && (diff > 10000)) { /* reduce speed, if diff is too high at normal speed */
+      xine_log(this->xine, XINE_LOG_MSG,
+	         _("set speed slow because diff is too high\n"));
+      gettimeofday(&start_slow_speed, NULL);
+      xine_log(this->xine, XINE_LOG_MSG,
+	         _("slow speed started at: %u : %u \n"), start_slow_speed.tv_sec, start_slow_speed.tv_usec);
+      _x_set_fine_speed(img->stream, slow_speed);
+    }
+    if (!(slow_speed == 1000000) && prev_speed == slow_speed && (diff < 3000)) { /* check for slow_speed , and if diff is small enough, go back to normal speed */
+//    if (prev_speed == slow_speed && (diff < 3000)) { /* check for slow_speed , and if diff is small enough, go back to normal speed */
+      xine_log(this->xine, XINE_LOG_MSG,
+	         _("set speed normal because diff is low enough\n"));
+      gettimeofday(&stop_slow_speed, NULL);
+      xine_log(this->xine, XINE_LOG_MSG,
+	         _("slow speed stopped at: %u : %u \n"), stop_slow_speed.tv_sec, stop_slow_speed.tv_usec);
+      _x_set_fine_speed(img->stream, 1000000);
+      int64_t slow_speed_duration = ((stop_slow_speed.tv_sec - start_slow_speed.tv_sec) * 1e6 + (stop_slow_speed.tv_usec - start_slow_speed.tv_usec));
+      xine_log(this->xine, XINE_LOG_MSG,
+	         _("slow speed duration was %" PRId64 " microseconds\n"), slow_speed_duration);
+    }
+#endif SLOW_SYSTEM
+
     if (diff > duration || this->discard_frames) {
 
       if( !this->discard_frames ) {

Der dvbplayer.c Patch ist bei mir auch immer noch nötig.
Das Ganze ist vermutlich nur ein workaround, aber ohne macht es auf meinem langsamem System keinen Spaß, und mit geht es zufriedenstellend.

Hallo, mit den neuen Patches sind die Störungen, die man sonst ohne stream-start.patch hatte, bei mir nicht mehr da!
Falls es eine Rolle spielt, ich habe zusätzlich zu engine.decoder.disable_flush_at_discontinuity:1 noch engine.decoder.disable_flush_from_video_out:1 gesetzt.
Vielen Dank an Reinhard!
Jörg

Entweder index löschen und die Aufnahme so lange abspielen, bis die neue index Datei fertig ist oder vdr --genindex=Pfad benutzen (siehe vdr --help).

Wenn nvidia 260.x, dann würde ich den neuen offiziellen 260.19.29 empfehlen.
Der ruckelt zwar immer noch noch ab und zu, hat aber gegenüber dem 195.30 den Vorteil, dass vdr nicht gelegentlich (bei heftigem zappen) mit 100% Buffer stehen bleibt.

Wie schon gesagt, passiert das bei mir nur mit vdr-xine, nicht aber mit xineliboutput. Ich glaube auch, dass es was mit den I-Frames zu tun haben muss. Und vermutlich passiert es nur, wenn man vdpau verwendet. Oder ist das bei jemand anders?
Die Kette sieht glaube ich so aus:
vdr/dvbplayer <-> vdr-xine <-> xine <-> vdpau <-> nvidia.
Dabei fliessen die Frames nach rechts, aber auch Rückmeldungen über Zeitstempel nach links. Wenn also vdr-xine etwas so verarbeitet, dass es bei vdpau (oder an anderer Stelle) klemmt, kann sich das auf den dvbplayer auswirken, da ja alles zeitlich und Puffermäßig ineinander greift.
Ich bin aber kein Profi, und das ist mein (laienhaftes) Verständnis.

Es müsste sich wohl mal jemand, der sich auskennt, das ansehen. Wie es aussieht haben die aber alle wenig Zeit. Als workaround könnte man vdr so patchen, dass er nur noch an I-Frames pausiert.

Bei mir ist es auch der dvbplayer thread:
/var/log # grep -e 3388 messages
Dec 14 23:56:24 linux-b37t vdr: [3388] dvbplayer thread started (pid=3116, tid=3388)
Dec 14 23:56:24 linux-b37t vdr: [3388] cVideoRepacker: switching to MPEG1/2 mode
Dec 14 23:56:24 linux-b37t vdr: [3388] cVideoRepacker: operating in MPEG1/2 mode
Das war beim Abspielen einer Aufnahme. Mit Pause 96% Cpu, ohne Pause 1 bis 2%.

SHF: der Prozess ist vdr, oder was genau meinst du mit der Frage?
Ich nehme an, es hat etwas mit der Verbindung von vdr-xine und vdpau zu tun.
Was Stalker schreibt, ist etwas ganz anderes, denn hier geht es um die 100% Cpu, die nur während der Pause auftritt, nicht auch danach.

Soweit ich mich erinnere, habe ich bei nvnews gelesen, dass bei den 260ern das Einstellen der Power Modi nicht funktioniert. Testet mal ältere Treiber.