Beiträge von jrie

gelöscht

Wie sieht es denn bei dir aus, wenn du z.B. auf ARD HD video.output.color_range auf Full statt Auto einstellst? Schlechter? Obwohl dein Monitor auf 0...255 steht?

video.output.color_range bezieht sich auf das Quellmaterial, also den Fernsehstream oder die Aufnahme, daher ist Auto normalerweise richtig.

Im xine hg ist jetzt auch für vdpau Farbmanagement drin.
Wenn man video.output.color_matrix:Signal+Size benutzt, wird auch auf Sendern, die keine ITU-R Kennung (Farbraumdefinition) senden wie z.B. ARD HD, anhand der Bildgröße die richtige Farbmatrix angewandt.
Näheres findet sich in color_matrix.c.

Welche Plugins laufen bei dir? Ich habe extrecmenu im Verdacht, das es bei mir manchmal zu ähnlichen Verzögerungen führt.
Tritt das nur mit softhddevice auf, oder auch mit vdr-xine oder vdr-xineliboutput?

Die 35° Temperaturunterschied sagen aber nur etwas über das Kühlsystem aus.
Bis man mit den von tecfreak gemessenen 4W Unterschied den Anschaffungspreis ausgeglichen hast, vergehen je nach täglichem Konsum sagen wir mal 30 Jahre. Solange wird man die Karte kaum behalten
Wenn man die Leistungsreserve braucht, und sie einem den Preis wert ist, ist es was anderes.

Mit 304.84 und 313.26 geht es wieder.

In vielen Jahren ist mir noch nie usbremote abgestürzt.
Jetzt das:

Feb 13 21:55:42 vdr kernel: [ 6916.760568] vdr[3550]: segfault at a9 ip b6c37a40 sp acdf628c error 4 in libvdr-usbremote.so.1.7.37[b6c36000+3000]

Kann das an den Änderungen mit lirc remote liegen?
Ich frag nur, weil das so ungewöhnlich ist, und jetzt mit 1.7.37 auftritt.
Die Fernbedienung hab ich gar nicht angefasst in dem Zeitraum, war während einer Aufnahme in Abwesenheit, die dann natürlich abbrach.

Nachdem ich alles upgedatet habe (kernel -> 3.7.6, ffmpeg -> 1.1.2, xine-lib und xine-ui cvs) geht es wieder mit 310.32.
Keine Ahnung wo da der Wurm drin war.

Edit: Und nachdem ich 313.18 installiert habe und gleich danach wieder 310.32 ohne sonstige Änderungen, geht er wieder nicht.
Und der 304.51 läuft (auch ohne sonstige Änderungen).
Verstehe ich nicht.

Ja, bin auf dem neuestem Stand.

Nach Kernel Update 3.7.2 -> 3.7.4 geht es wieder nicht.
Ich werd noch verrückt.
xorg.conf hatte ich auch schon probiert, half auch nicht.

bei mir tut´s auch 1.0.2

Ja, so mache ich es auch (bis auf den reboot, wobei es mit auch nicht geht).
Der 313.18 läuft bei mir trotzdem nicht. Bin noch auf der Suche nach der Ursache.
Interessanterweise läuft der neue 310.32 bei der gleichen Vorgehensweise.
Da auch die vorigen 310er nicht liefen, muss nvidia da irgendetwas bezüglich meines Problems verbessert haben.

und jetzt auch im 310er Zweig:
http://www.nvidia.com/object/l…y-ia32-310.32-driver.html

Also an der Reihenfolge liegt es nicht. Habe darauf geachtet und neu gebaut, aber der selbe Fehler.

Ja , danke für den Hinweis, es könnte an der Reihenfolge des Kompilierens liegen.
Sobald ich zu hause bin, baue ich noch mal, und achte darauf.
Werde dann berichten.

Danke für die Info.
Bei mir ist es so: 295.75 installieren => xine läuft, 313.18 installieren => xine hängt, 295.75 installieren => xine läuft. Ohne sonstige Änderungen.
Welches ffmpeg verwendest du?
Was könnte ich sonst noch probieren??

Mit den nvidia Treibern 295.75 und 304.51 spielt xine VDR Aufnahmen *.ts problemlos ab.
Mit den nvidia Treibern ab 304.60, 310.14 und 313.x bleibt xine hängen, und ein Cpu Kern hat 100% Last. xine lässt sich dann nur mit -KILL abschiessen. Das vdr-xine plugin geht dann auch nicht.
Dieselben Dateien werden von mplayer und xineliboutput mit sxfe problemlos abgespielt, also auch mit den neueren nvidia Treibern.

Kann das jemand bestätigen? Wie könnte ich das debuggen?

openSuse 12.2 und verschiedene xine cvs Versionen.

Danke für den Tipp!
Nach einem Sprung wird das Video kurz in Zeitlupe abgespielt wird. Viele meiner Aufnahmen haben ca. 300 - 400 ms Audio/Video Versatz und die Zeitlupe dauert entsprechend. Ich springe häufig schnell durch Aufnahmen (mit +10 sec Sprüngen). Wenn ich viel springe, stört mich das.
Mit diesem Patch gibt es keine Zeitlupe mehr, sondern das Video spielt sofort los (und der Ton auch).

diff -Nru softhddevice.orig/audio.c softhddevice/audio.c
--- softhddevice.orig/audio.c   2013-01-17 16:13:07.000000000 +0100
+++ softhddevice/audio.c        2013-01-18 21:36:03.497900314 +0100
@@ -2286,9 +2286,16 @@


        // buffer ~15 video frames
        // FIXME: HDTV can use smaller video buffer
+       // for nicer jumps in recordings we need an increased skip (and no buffers)
+       if (!IsReplay()) {
        skip =
            pts - 15 * 20 * 90 - AudioBufferTime * 90 - audio_pts +
            VideoAudioDelay;
+       } else {
+       skip =
+           pts + 45 * 20 * 90 - audio_pts +
+           VideoAudioDelay;
+       }
 #ifdef DEBUG
        printf("%dms %dms %dms\n", (int)(pts - audio_pts) / 90,
            VideoAudioDelay / 90, skip / 90);
diff -Nru softhddevice.orig/softhddev.c softhddevice/softhddev.c
--- softhddevice.orig/softhddev.c       2013-01-17 16:13:07.000000000 +0100
+++ softhddevice/softhddev.c    2013-01-18 21:26:25.584866242 +0100
@@ -3283,3 +3283,8 @@
 }


 #endif
+
+void IsReplay(void)
+{
+    return !AudioSyncStream || AudioSyncStream->ClearClose;
+}

Hallo johns,
dank deines Tipps

Zitat von johns

Um Wiedergabe zuerkennen:

int Poll(int timeout) wird nur bei Aufnahmen und DVD Wiedergabe aufgerufen.
Dort setze ich bereits das Flag "VideoClearClose", damit bei der Wiedergabe
die Sprünge nicht nachlaufen.

Das könntest du verwenden. (Mußt es natürlich erstmal global verfügbar machen).

Johns

Alles anzeigen

hatte ich einen Patch für schönere Sprünge erstellt (hier).
Nach dem PIP Umbau funktioniert der nicht mehr, und ich blick nicht durch, wie ich MyVideoStream->ClearClose in audio.c deklariere.
Kannst du mir da helfen, oder einen Tipp geben, bitte?
Danke,
Jörg