Immer diese Steinzeit Libraries. ...
Vlt. solltest Du halt irgendwo mal schreiben, welche Versionen verwendet werden soll(t)en?
softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin
-
-
Immer diese Steinzeit Libraries. Dann kann ich es später auch nicht für den Downmix verwenden.
Hmmm...mein System ist eigentlich recht aktuell...was ist denn aus der Steinzeit?
Edit: soll heißen im GIT gefixt.Danke...schneller als die Feuerwehr
Ciao Louis
-
johns: Hast du eine Idee, warum es in Post #977 um 10:55:55 zu den 'decoder render too slow' Meldungen kommt?
Hat das was mit 'using device '51to20'' zu tun? Und was bedeutet das? -
Quote from johns
Wer mutig ist kann noch den neuen TS (Transportstream) Parser verwenden, der ist noch mal schneller.
Im Makefile -DUSE_TS_AUDIO auswählen. Dazu noch alle 216 in audio.c durch 116 ersetzen.
Kann es sein, dass es den Wert "216" in der aktuellen audio.c nicht mehr gibt?Codevdr01 softhddevice # grep 216 codec.c vdr01 softhddevice # -
C3po: les mal Posting #974
-
Kann es sein, dass es den Wert "216" in der aktuellen audio.c nicht mehr gibt?
Würde sagen ja, johns hat den Wert auf 336 gestellt.
Außerdem wirst du mit dem grep nichts finden, du suchst in der codec.c.Codevdr01 softhddevice # grep 216 codec.c
Wahrscheinlich ein Vertipper
Wobei sich jetzt die Frage stellt, ob wir die 336 ms in Verbindung mit dem neuen Parser testen sollen - oder die 116 ms nehmen müssen.
johns:
Das soll jetzt keine Kritik sein, nicht falsch verstehen
Ich denke louis Problem ist ein nicht aktuelles ffmpeg Packet, der normale Weg wäre wenn louis sein ffmpeg updatet, und nicht der Entwickler auf ältere Lib's zurückgeht.
Das hätte zur Folge, das eben Features in dem Projekt fehlen würden. -
Das kannst ja nicht wissen, aber es ist beides der Gleiche Aufwand, bzw. die Gleichen Routinen.
Mach solange es noch nicht drin ist: xrandr --rate 50. Nach dem X-Server start.
Johns
klar das mach ich ja schon. manchmal passiert das aber parallel. so das dein video bild hängen bleibt. dann muss ich SUSP/RESU'en
-
Bei Prosieben HD funktioniert bei mir das Spulen nur sehr sprunghaft. Kann das jemand bestätigen?
Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und dann steht erstmal alles still. Ein paar Sekunden später schaltet der VDR zurück auf Wiedergabe. -
Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und dann steht erstmal alles still. Ein paar Sekunden später schaltet der VDR zurück auf Wiedergabe.Ich habs eben mal getestet...das kann ich nicht bestätigen. Sowohl mit einer aktuellen Aufnahme als auch mit einer älteren Aufnahme absolut problemlos.
Ciao Louis
-
QuoteDisplay More
Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird
erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und
dann steht erstmal alles still. Ein paar Sekunden später schaltet der
VDR zurück auf Wiedergabe.QuoteIch habs eben mal getestet...das kann ich nicht bestätigen. Sowohl mit
einer aktuellen Aufnahme als auch mit einer älteren Aufnahme absolut
problemlos.Hab es gerade getestet und auch keinerlei Probleme.
Grüße
-
Hmm, könnte das eventuell am 60Hz-Modus liegen? Ich teste das mal.
Edit: Auch ohne 60Hz-Mode habe ich die Probleme.
-
Seit wann haste das Problem? VDR Wechsel zum 1.7.24 ér oder Plugin-Version?
-
Keine Ahnung. Ich habe gestern mal wieder etwas auf Prosieben aufgenommen und ab da wars. Das letzte Mal, wo ich eine Aufnahme von Prosieben geschaut habe war noch mit der HD-FF
-
johns: Der Testlog mit akuteller git Version:
CodeFeb 24 19:18:12 linux-i3n6 vdr: video: 18:58:51.117 -21 158 0/\ms 32 v-buf Feb 24 19:19:12 linux-i3n6 vdr: video: 18:59:51.117 -21 158 0/\ms 31 v-buf Feb 24 19:20:12 linux-i3n6 vdr: video: 19:00:51.117 -21 158 0/\ms 35 v-buf Feb 24 19:21:12 linux-i3n6 vdr: video: 19:01:51.117 -21 126 0/\ms 35 v-buf Feb 24 19:21:58 linux-i3n6 vdr: audio/alsa: wait underrun error? Feb 24 19:22:12 linux-i3n6 vdr: video: 19:02:51.117 +28 208 0/\ms 30 v-buf
Test bei 1080i DD - beim "underrun error" war ein kurzer unsauberer Ton zu hören.
Meine Theorie:
Der Default (Start) Audio Buffer Wert liegt bei 336 ms, im Log kann man sehen, das dieser Wert immer weiter dekrementiert wird, bei 126 ms geht alsa dann in den underrun mode.
Danach sind es wieder 208 ms.
Kann es sein, daß der Algo im Plugin etwas zu optimistisch rechnet ? -
Vlt. solltest Du halt irgendwo mal schreiben, welche Versionen verwendet werden soll(t)en?Eigentlich jede ab 0.7, deshalb habe ich es ja wiederherausgenommen.
johns: Hast du eine Idee, warum es in Post #977 um 10:55:55 zu den 'decoder render too slow' Meldungen kommt?
Hat das was mit 'using device '51to20'' zu tun? Und was bedeutet das?Da passiert was im Stream. An der Meldung kann man erkennen das sich gerade der Tonkanal geändert hat.
Ich vermute die Werbung war aus und nun geht der Film los. Kann durchaus sein, das sich das Videoformat auch geändert hat und so vdpau aus dem Takt kommt.Es ist alles fest: 336 für PES und 226 für TS.
War ja nichts wichtiges, war der Rest vom Test Dolby Digital lauter zumischen und ich habe es drin gelassen, da man damit noch den Downmix wie Alsa konfigurieren kann. Ab ffmpeg 1.0 gibt es keinen Support für altes Zeug, dafür aber länger 1.0.
Ich habe das nochmal überprüft. Es ist nur beim Zurückspulen. Es wird erst in etwa 30sec Schritten gespult (ca 2 Bilder sind zu sehen) und dann steht erstmal alles still. Ein paar Sekunden später schaltet der VDR zurück auf Wiedergabe.Ja, habe hier eine Aufnahme leider nur 1:30, damit kann man nicht schön testen. Aber genau so wie du es beschreibst, bin mir nur nicht sicher ob es nicht so von VDR kommt.
Test bei 1080i DD - beim "underrun error" war ein kurzer unsauberer Ton zu hören.
Meine Theorie:
Der Default (Start) Audio Buffer Wert liegt bei 336 ms, im Log kann man sehen, das dieser Wert immer weiter dekrementiert wird, bei 126 ms geht alsa dann in den underrun mode.
Danach sind es wieder 208 ms.
Kann es sein, daß der Algo im Plugin etwas zu optimistisch rechnet ?Wenn sich dies wiederholen lässt, sendet entweder der Sender zulangsam oder die Soundkarte spielt schneller ab.
Sollte dies die Regel sein, ich kann es auf 3 Rechner nicht nachvollziehen, dann muß der Tonteil, noch eine Geschwindigkeitsanpassung vornehmen.Johns
-
Hi,
ich hatte jetzt den ganzen Abend mit der aktuellen git Version und aktiviertem DUSE_TS_AUDIO keinen einzigen Tonaussetzer mehr...auch auf 1080i mit DD5.1 nen ganzen Film lang
Ciao Louis
PS: die Umschaltzeiten sind echt der Knaller...sogar meine Frau meinte: "Das ist ja fast wie früher"...und das soll was heissen, da kannste dir was drauf einbilden Johns
-
Hi, ja es schaut viel besser aus, der VDR lief die Nacht durch, SKY-HD DD.
Und läuft jetzt noch, ohne Neustarten zu müssen oder ähnliches.
Einmal war dies wieder im Log:CodeFeb 25 03:50:30 linux-i3n6 vdr: audio/alsa: wait underrun error? Feb 25 03:50:30 linux-i3n6 vdr: audio/alsa: buffer size 4608 96ms, period size 1152 24ms Feb 25 03:50:30 linux-i3n6 vdr: audio/alsa: delay 216 ms Feb 25 03:50:30 linux-i3n6 vdr: video: 20:24:15.583+88888 144 240/\ms 3 v-buf Feb 25 03:50:30 linux-i3n6 vdr: video: 20:24:15.603+88888 144 240/\ms 3 v-buf Feb 25 03:50:30 linux-i3n6 vdr: video: 20:24:15.623+88888 144 240/\ms 2 v-bufSollte dies die Regel sein, ich kann es auf 3 Rechner nicht nachvollziehen, dann muß der Tonteil, noch eine Geschwindigkeitsanpassung vornehmen.
Wenn dies technisch machbar ist - wäre schon gut.
Ich werde demnächst mein produktives System neu bauen, dort läuft die Audiowiedergabe über die Rechner Soundkarte und 5.1 Lautsprecherset.
Dort ist auch die Hardware deutlich besser.
Evtl. ändert sich dann was.Im Log ist auch ab und zu dies drin:
CodeFeb 25 04:51:07 linux-i3n6 vdr: video/vdpau: decoder render too slow 135 ms Feb 25 04:51:07 linux-i3n6 vdr: video: missed frame (116/2112133) Feb 25 04:51:07 linux-i3n6 vdr: video: 6:11:11.738 -159 159 0/\ms 37 v-buf
Du hast dafür auch schon eine Lösung parat:QuoteWerde demnächst meinen Eigenen TS Parser für Video einbauen. um zusehen ob der VDR TS Parser nicht noch mehr Bugs hat.
-
Hallo,
Dies habe ich in der aktuellen GIT Version:
QuoteDisplay MoreFeb 25 09:45:07 vdr-kle vdr: video: display buffer empty, duping frame (100/11722) 4
Feb 25 09:45:11 vdr-kle vdr: video: 5:31:07.763 +76 241 240/\ms 5 v-buf
Feb 25 09:45:12 vdr-kle vdr: video: 5:31:09.003 +45 249 240/\ms 6 v-buf
Feb 25 09:45:12 vdr-kle vdr: video: 5:31:09.023 +75 325 240/\ms 11 v-buf
Feb 25 09:45:12 vdr-kle vdr: video: dropping frame (1/11974)
Feb 25 09:46:11 vdr-kle vdr: video: 5:32:07.803 +116 305 240/\ms 3 v-buf
Feb 25 09:46:34 vdr-kle vdr: video: display buffer empty, duping frame (101/16038) 2
Feb 25 09:46:46 vdr-kle vdr: video: display buffer empty, duping frame (102/16640) 0
Feb 25 09:46:46 vdr-kle vdr: video: 5:32:42.443 +56 294 240/\ms 4 v-buf
Feb 25 09:46:46 vdr-kle vdr: video: 5:32:42.463 +56 274 240/\ms 4 v-buf
Feb 25 09:46:46 vdr-kle vdr: video: dropping frame (2/16644)
Feb 25 09:47:11 vdr-kle vdr: video: 5:33:07.783 +96 242 240/\ms 4 v-buf
Feb 25 09:48:11 vdr-kle vdr: video: 5:34:07.783 +97 307 240/\ms 4 v-buf
Feb 25 09:48:53 vdr-kle vdr: video: 5:34:50.003 +57 230 240/\ms 3 v-buf
Feb 25 09:48:53 vdr-kle vdr: video: 5:34:50.023 +97 307 240/\ms 5 v-buf
Feb 25 09:48:53 vdr-kle vdr: video: dropping frame (3/23020)
Feb 25 09:48:53 vdr-kle vdr: video: 5:34:50.083 +137 287 240/\ms 3 v-buf
Feb 25 09:49:11 vdr-kle vdr: video: 5:35:07.803 +117 275 240/\ms 8 v-buf
Feb 25 09:49:22 vdr-kle vdr: video: display buffer empty, duping frame (105/24424) 3
Feb 25 09:49:39 vdr-kle vdr: video: display buffer empty, duping frame (106/25302) 0Was mir vor allem auffällt sind die extrem kleinen V-Bufferwerte.
Peter
-
Hallo,
Was mir vor allem auffällt sind die extrem kleinen V-Bufferwerte.Ja. Eigentlich sollte das Plugin Frames verdoppeln um mit dem Ton gleichzuziehen.
Dadurch würden sich die Buffer füllen, das Plugin schmeißt aber Frames wech und dadurch wird der Buffer leerer.
Ist es ein bestimmer Sender und dieser immer?
Oder ist es nur nach dem Umschalten passiert?
Wenn ich es richtig sehe, habe ich da kein Rücksetzen drin, obwohl das bisher bei mir noch keinen Ärger machte.Johns
-
Also ich teste gerade aktuelle Git-Version mit einem Ion-330+GT210 und hier schmiert das Plugin nach einer gewissen Zeit ab. Hier das Log bei Discovery HD:
Code
Display MoreFeb 25 14:31:28 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated twice - Feb 25 14:31:28 [vdr] [4149] ERROR: TS packet not accepted in Transfer Mode Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated twice - Feb 25 14:31:28 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated twice - Feb 25 14:31:28 [vdr] [4150] ERROR: driver buffer overflow on device 1 Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated twice - Feb 25 14:31:28 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated 2 times - Feb 25 14:31:28 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated 2 times - Feb 25 14:31:28 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:28 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated 3 times - Feb 25 14:31:28 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:29 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated 3 times - Feb 25 14:31:29 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:29 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated 2 times - Feb 25 14:31:29 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:29 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ - Last output repeated 2 times - Feb 25 14:31:29 [vdr] audio/alsa: broken driver 32_ Feb 25 14:31:29 [vdr] video: 9:13:47.369+3728 3200 80/\ms 0 v-buf_ ^C vdr01 ~ # DISPLAY=:0 nvidia-settings -q GPUCoreTemp Attribute 'GPUCoreTemp' (vdr01:0.0): 43. 'GPUCoreTemp' is an integer attribute. 'GPUCoreTemp' is a read-only attribute. 'GPUCoreTemp' can use the following target types: X Screen, GPU.Was läuft hier schief?
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!