Ruckler und Aussetzer bei HD (free to air oder andere) nach heutigem update (Änderung seit 10.3)

Zitat von einnordlicht

Gibt es irgendwo ein Archiv der alten Stände?

Nein, gibt es nicht. Wir lösen Probleme vorwärts und gehen nicht zurück.

Trotz dem das Du viel geschrieben hast, habe ich nicht so richtig verstanden was Dein Problem ist. Du schreibst was von Bildruckeln, gehst aber detailliert auf Deine (USB?) DVB Devices ein, was hat das eine mit dem anderen zu tun? Oder gehst Du von schlechtem Empfang aus?

Ich vermute Du bist auf 0.4, welches VDR Frontend?

Regards
fnu

Mit Chance liegen die alten pakete noch in /var/cache/apt/archives ....

Sent from my iPad using Tapatalk

Hallo,

ich habe dasselbe Problem, allerdings mit vdr-sxfe@vdr-plugin-xineliboutput. Das Bild ruckelt stark, der Empfang ist ok (Ausgabe per Streamdev auf entferntem Rechner ist kein Problem), Der Effekt tritt auch beim Abspielen von Aufnahmen ab, sowohl bei neuen als auch bei alten, die definitiv ok sind.

Außerdem setzt nach einer gewissen Zeit der Ton aus, evtl., weil die Synchronisation flöten geht.

Per top meldet vdr-sxfe eine Prozessorlast von 70% auf einem Core2 Duo-System, Grafikkarte ist eine GF210. Bis zum letzten Update (Freitag) war alles gut.

Sebi

Bei euch beiden ist vdpau nicht aktiv - die Frage ist warum ? Funkt da irgendwie vaapi dazwischen - kann man das vielleicht über die Konfig abschalten ?

Zuerst mal ein paar grundsätzliche Dinge klären:

uname -a
dkms status nvidia-current
grep nvidia /var/log/Xorg.1.log

Den Inhalt von /tmp/vdr-frontend.log an einen Post hängen.

Gerald

Moin,

es scheint, als wäre vdpau nicht der Bösewicht:

root@dumbledore:/home/sebastian# uname -a
Linux dumbledore 2.6.38-13-generic #57-Ubuntu SMP Mon Mar 5 18:29:54 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

root@dumbledore:/home/sebastian# dkms status | grep nvidia
nvidia-current, 285.05.09, 2.6.38-13-generic, x86_64: installed

root@dumbledore:/home/sebastian# grep nvidia /var/log/Xorg.1.log
[	32.724] (II) LoadModule: "nvidia"
[	32.724] (II) Loading /usr/lib/xorg/extra-modules/nvidia_drv.so
[	32.724] (II) Module nvidia: vendor="NVIDIA Corporation"
[	33.102] (II) Loading /usr/lib/xorg/extra-modules/nvidia_drv.so

less /tmp/vdr-frontend.log
vo_vdpau: Use lock display synchronization for some vdpau calls
vo_vdpau: vdpau API version : 1
vo_vdpau: vdpau implementation description : NVIDIA VDPAU Driver Shared Library  285.05.09  Fri Sep 23 17:55:14 PDT 2011
vo_vdpau: maximum video surface size for chroma type 4:2:2 is 4096x4096
vo_vdpau: maximum video surface size for chroma type 4:2:0 is 4096x4096
vo_vdpau: maximum output surface size is 8192x8192
vo_vdpau: hold a maximum of 10 video output surfaces for reuse
vo_vdpau: using 4 output surfaces of size 1920x1080 for display queue
vdr-sxfe 1.0.90-cvs  (build with xine-lib 1.2.1, using xine-lib 1.2.1)
(...)
vo_vdpau: deinterlace: temporal
vo_vdpau: deinterlace: temporal
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0.000000, saturation=1.000000, contrast=1.000000, brightness=0.000000, color_standard=0 studio_levels=0
vo_vdpau: skip_chroma = 1

Das sieht für mich so aus, als wenn vdpau schon aktiviert ist. Bei Widergabe von sd-Inhalten hat vdr-sxfe ca. 2% CPU-Last. Beim Umschalten auf einen HD-Kanal steigt die Last sofort auf ca. 70% an und fällt beim weiteren Umschalten sofort wieder ab.

Ich werde heute abend mal einen aktuelleren Nvidia-Treiber probieren. Auf der Website von Nvidia habe ich gesehen, dass 295.33 aktuell ist. In der feature-list heißt es:

"Fixed a VDPAU bug where decoding some H.264 streams would cause hardware errors on lower-end products, resulting in corruption and poor performance."

Vielleicht ist das ja die Ursache. Ich werde berichten!

Zitat von sebixvi

Ich werde heute abend mal einen aktuelleren Nvidia-Treiber probieren. Auf der Website von Nvidia habe ich gesehen, dass 295.33 aktuell ist. In der feature-list heißt es:

"Fixed a VDPAU bug where decoding some H.264 streams would cause hardware errors on lower-end products, resulting in corruption and poor performance."

Vielleicht ist das ja die Ursache. Ich werde berichten!

Den findest du hier.

wget https://launchpad.net/~yavdr/+archive/main/+files/nvidia-current_295.33-0yavdr0%7Eprecise_amd64.deb
sudo dpkg -i nvidia-current_295.33-0yavdr0~precise_amd64.deb

sollte reichen.

Gerald

Zitat von sebixvi

Ich werde heute abend mal einen aktuelleren Nvidia-Treiber probieren. Auf der Website von Nvidia habe ich gesehen, dass 295.33 aktuell ist. In der feature-list heißt es:

Zitat von sebixvi

Vielleicht ist das ja die Ursache. Ich werde berichten!

So, habe den Treiber gerade aktualisiert, brachte leider keine Änderung. Nach Umschalten auf den HD-Kanal (hier Das Erste HD) direkt 74% CPU-Last und stotterndes Bild.

Sebi

Warum hast du eigentlich das dvbhddevice und das dvbsddevice installiert ?
Behaupte mal das ist nicht Yavdr Standard- v.a.du scheinst laut signatur weder eine SD noch eine HD-FF Card zu haben.

Zitat von DocViper

Warum hast du eigentlich das dvbhddevice und das dvbsddevice installiert ?

Ist beides Teil von yavdr-essentials und sollte keine Probleme machen. Ich könnte mir vorstellen, das evtl. die Settings für die Grafikkarte zu optimistisch sind, also z.B. "temporal_spatial" für eine Karte die das nicht kann ... ?

Regards
fnu

okay - sorry dass war mir nicht bewußt.

Andererseits steht in dem obigen Log-File dass temporal gewählt ist.

vo_vdpau: deinterlace: temporal

Zitat von DocViper

Andererseits steht in dem obigen Log-File dass temporal gewählt ist.

Auch das kann bei manchen Karten zu optimistisch sein

Regards
fnu

Wenn es diese Maschine ist: Ubuntu 12.04ß MCP78S [Geforce 8200]
dann könnte schon sein das temporal zu viel ist für die 8200'er Geforce

Hallo,

Zitat von DocViper

Wenn es diese Maschine ist: Ubuntu 12.04ß MCP78S [Geforce 8200]
dann könnte schon sein das temporal zu viel ist für die 8200'er Geforce

die Logs waren von meinem Rechner, dort werkelt ein Core2Duo E2500 mit einer GF210-Grafikkarte. Das sollte also mit temporal passen.

Außerdem erklärt eine Überforderung der Grafikkarte nicht die hohe CPU-Last beim Abspielen von HD-Material. Auch dann sollte allenfalls die Grafikkarte schwitzen, nicht aber der Prozessor.

Last not least wurde die Konfiguration, insbesondere der Deinterlacer, beim Update nicht angefasst (es sei denn, das Update hat automatisch was umgestellt, was ich aber nicht glaube). Bis zum letzten apt-get dist-upgrade lief HD auf diesem Rechner einwandfrei.

Sebi

Zitat von sebixvi

Außerdem erklärt eine Überforderung der Grafikkarte nicht die hohe CPU-Last beim Abspielen von HD-Material. Auch dann sollte allenfalls die Grafikkarte schwitzen, nicht aber der Prozessor.

Doch genau das passiert so, weil die Grafikkarte ein Peripherie-Gerät der CPU ist. Die Hauptarbeit des Systems übernimmt immer die CPU, die Grafikkarte unterstützt diese und übernimmt im Falle von VDPAU eben etwas mehr Aufgaben, wie z.B. Decoding, Bildaufbereitung, Deinterlacing etc. Die Grafikkarte ist aber nichts ohne CPU ...

Ein Grafikkarte ist keine AddOn Karte wie eine FF, DXR3, FF-HD, eHD, die an sich autark vor sich hinwerkeln und den Rest vom System als "Wirt" nutzen, wobei eine FF-HD inzwischen schon auch eine ordentliche CPU benötigt um befeuert werden zu können.

Regards
fnu

Zitat von fnu

Doch genau das passiert so, weil die Grafikkarte ein Peripherie-Gerät der CPU ist. Die Hauptarbeit des Systems übernimmt immer die CPU, die Grafikkarte unterstützt diese und übernimmt im Falle von VDPAU eben etwas mehr Aufgaben, wie z.B. Decoding, Bildaufbereitung, Deinterlacing etc. Die Grafikkarte ist aber nichts ohne CPU ...

Ein Grafikkarte ist keine AddOn Karte wie eine FF, DXR3, FF-HD, eHD, die an sich autark vor sich hinwerkeln und den Rest vom System als "Wirt" nutzen, wobei eine FF-HD inzwischen schon auch eine ordentliche CPU benötigt um befeuert werden zu können.

Regards
fnu

Eben, die Grafikkarte übernimmt das Deinterlacing, Decoding und Bildaufbereitung. Das Anreichen der Daten sollte aber aber ein C2Duo ohne nennenswerte Schwierigkeiten hinbekommen.

Außerdem habe ich mir gerade nochmal das Log nach dem Umschalten auf einen HD-Kanal angesehen. Dort steht:

vo_vdpau: deinterlace: bob
vo_vdpau: set_scaling_level=0
vo_vdpau: enabled features: inverse_telecine=0
vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.
vo_vdpau: vdpau_update_csc: hue=0.000000, saturation=1.000000, contrast=1.000000, brightness=0.000000, color_standard=1 studio_levels=0
vo_vdpau: skip_chroma = 1

Damit sollte der PC noch weniger ein Problem haben. Temporal wird nur bei SD benutzt (Voreinstellung von yavdr).

Testweises Umstellen des Frontends auf xine-plugin hat übrigens hier keinen Effekt, die HD-Sender ruckeln auch da.

Sebi

Zitat von sebixvi

Eben, die Grafikkarte übernimmt das Deinterlacing, Decoding und Bildaufbereitung. Das Anreichen der Daten sollte aber aber ein C2Duo ohne nennenswerte Schwierigkeiten hinbekommen.

Das ist immer noch nicht richtig. Die CPU reicht die Daten nicht an, sondern engagiert die GPU per Treiber, der per Xorg auf der CPU läuft, und derer Fähigkeiten. Die CPU ist immer für alles verantwortlich, sollte VDPAU nicht korrekt laufen, schießt die CPU Last logischerweise nach oben, weil sie dann die nötigen Aufgaben übernehmen muß, also Decodierung, Deinterlacing, sonstige Aufbereitung und zwar in dieser Reihenfolge.

Bei den AddOn Karten reicht "die CPU/das System die Daten an" ...

Mich würde das syslog und ein "htop" Screenshot interessieren und zwar in der Zeit wo Du auf einem HD Sender bist?

Regards
fnu