[gelöst] Das Abspielen von Aufnahmen wird erst nach einiger Zeit stabil oder nie, betrifft auch Sprünge

  • Hallo, ich habe ein langsames System mit Celeron III @1333 und eine Geforce 8400 GS PCI.
    Beim Abspielen einer 720p Aufnahme dauert es 10 bis 60 Sekunden bis die Framedrops aufhören und der Ton stabil kommt. Dabei wird der letzte Wert diff in den „throwing away …“ Meldungen langsam immer kleiner, bis diese nicht mehr kommen.
    Dies betrifft auch Sprünge in Aufnahmen mittels Gelb/Grün Taste um +/- 60 Sekunden.


    Manchmal hören die Framedrops gar nicht auf; das ist aber nicht gezielt reproduzierbar. Dabei geht der Wert diff in den „throwing away …“ Meldungen immer weiter hoch statt runter.


    In beiden Fällen nimmt sich xine, solange die Meldungen „throwing away …“ kommen, fast die gesamte verfügbare cpu.


    Beim Umschalten auf einen 720p Sender wird die Anzeige praktisch sofort stabil. Das Problem tritt also nicht bei live TV, sondern nur beim Abspielen von Aufnahmen auf.


    Wenn ich beim Abspielen einer Aufnahme die Geschwindigkeit reduziere, stabilisiert sich das Abspielen viel schneller und auch zuverlässig (also selbst wenn vorher diff hoch ging), und wenn ich danach wieder auf normale Geschwindigkeit gehe, bleibt es stabil.
    Das mache ich mit 2mal „Pfeil runter“, und nach dem stabilisieren wieder 2mal „Pfeil hoch“ auf der Tastatur. Oder auf der Fernbedienung mit „runter“, „rechts“, warten bis stabil, „hoch“.


    Es wäre natürlich viel schöner, wenn xine das in der Software automatisch machen könnte.


    Bin ich der Einzige, oder gibt es noch andere mit dem gleichen Problem?
    Falls jemand mit vergleichbar langsamer Hardware dieses Problem nicht hat, wüsste ich gerne die Einstellungen der config Dateien. Da ich aber schon alles ausprobiert habe, glaube ich eher, dass xine auf langsamer Hardware nicht optimal arbeitet.


    Wenn xine die schnellen Framedrops bei hohem diff überwachen würde, und solange die Geschwindigkeit stark reduziert, wäre das Problem gelöst.
    Leider bin ich kein Programmierer und kann das nicht selbst flicken.
    Falls jemand, der sich auskennt, mir hilft, wäre ich sehr dankbar.
    Ich hatte schon überlegt, mir ein schnelleres System zu kaufen, aber nachdem ich dies heraus gefunden habe, bin ich sicher, dass es ein Softwareproblem ist.


    Jörg


    vdr 1.7.15, vdr-xine oder xineliboutput, vdpau und xine cvs pur oder mit diversen patches, nvidia treiber 195.30 – 256.44.

  • Hallo, mit diesem Patch geht es. Damit kann ich durch HD Aufnahmen springen, und das Abspielen stabilisiert sich kurz nach dem Sprung. Vorher dauerte das mindestens 10 bis 60 Sekunden, oder es wurde gar nicht mehr stabil.
    Falls es noch jemandem hilft, würde ich mich über ein feedback freuen.
    Jörg


    anzuwenden auf /xine-lib/src/xine-engine/video_out.c

  • Der o.g. Patch dürfte aber wirklich nur für leistungsarme VDR's Sinn machen. Auf meinem System hakelt es mit diesem Patch beim starten von HD-Aufnahmen 2-3 mal. Ohne Patch laufen die Aufnahmen problemlos sofort ...ohne Ruckeln.


    Gruß
    iNOB

  • Bei mir ist es beim Starten des Abspielens einer HD Aufnahme so:
    Zuerst kurz Ton und stehendes Bild,
    dann 1-2 Sekunden kein Ton und Zeitlupe,
    dann normal Ton und Bild.
    Die zweite Phase kommt vom Patch und dies erscheint vermutlich als hakeln.


    Bei mir macht allerdings erst dieser Patch mein langsames System voll HD tauglich.
    Ein weiterer positiver Effekt ist, dass ich damit auch HD Aufnahmen während der Aufnahme abspielen kann, das ging ohne Patch meistens gar nicht.
    Und der Cpu Peak ist jetzt nur noch ganz kurz.


    Ich finde es aber gut zu wissen, dass der Patch auf schnellen Systemen ungünstig ist. Deswegen sollte man ihn vermutlich an/abschaltbar machen.


    Würdest du mal die Ausgabe von xine --verbose=2 mit Patch und dem mehrmaligen Hakeln posten, und auch die Ausgabe ohne patch zum Vergleich?

  • Hier die letzte Version von meinem patch:


    Er ist auch nützlich um die xine config Parameter zu optimieren, einfach Parameter ändern und schauen, ob slow_speed_duration länger oder kürzer wird (greift nur bei manchen Parametern).
    Damit habe ich z.B. gemerkt, dass bei mir video_num_frames 30 besser ist als 22. Mehr als 30 oder weniger als 22 macht keinen Sinn, da es bei vdpau in xine abgefangen wird. Auch video_num_buffers kann man damit schön optimieren.


    Nun noch etwas merkwürdiges:
    Ich habe beobachtet, das Sprünge auf eine Zeit (Goto) nicht von dem Problem betroffen sind, sondern nur Vor/Rück-Sprünge (SkipSeconds).
    Mit dieser Änderung in dvbplayer von vdr erziele ich auch eine Verbesserung (abgesehen von der Nebenwirkung, dass wenn man aus einem Standbild springt, er nicht automatisch weiterspielt).


    Möglicherweise deutet das darauf hin, dass irgendwo ein Puffer geflusht werden müsste?
    Aber das ist mir zu hoch, ich bin schon froh, dass ich überhaupt so weit gekommen bin, und überlasse den Rest den Entwicklern (vdr, xine-vdr und xine).

  • Noch einige Anmerkungen.


    Das Problem existiert auch, wenn ich eine Aufnahme direkt in xine abspiele, also vdr und vdr-xine umgehe. Der Start und Sprünge mittels C-x oder <-,-> sind genauso betroffen. Erstmal sieht es also nach einem Problem in xine aus.


    Andererseits haben Goto-Sprünge in vdr mittels Rot und Zeitangabe dieses Problem nicht, und SkipSeconds-Sprünge mit Gelb/Grün nach dem Patch auch nicht mehr, so dass eine Änderung in vdr das Problem löst. Liegt es also doch an vdr?


    Was mir noch fehlt, ist eine Lösung in vdr für das Starten.


    Ich vermute, dass schnelle Systeme genauso betroffen sind, nur dass hier die Störungen so kurz sind, dass es nicht weiter auffällt.


    Ich habe 99% mit vdr-xine getestet, mit xineliboutput ist es aber genauso.

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



    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.

  • Hier ein eleganterer dvbplayer.c patch, da sieht man klarer was hilft. Das warum ist mir immer noch nicht klar.


    Mit patch sieht der xine log bei einem Sprung +1 Minute so aus:


    Ohne patch dagegen so:


    Mir ist noch etwas aufgefallen. Im Problemfall wird immer zuerst das video plugin geladen, und dann das audio plugin.

    Code
    load_plugins: plugin vdpau_h264 will be used for video streamtype 4d.
    load_plugins: plugin a/52 will be used for audio streamtype 00.


    Mit patch ist das immer umgekehrt, zuerst audio, dann video.

    Code
    load_plugins: plugin a/52 will be used for audio streamtype 00.
    ...
    load_plugins: plugin vdpau_h264 will be used for video streamtype 4d.


    Was das Starten des Abspielens betrifft, wäre es schön, dies richtig in Ordnung zu bringen, denn mein xine slow_system patch hat den Nachteil, dass das Abspielen gleich nach dem Starten eine knappe Sekunde auf Zeitlupe ohne Ton ist. Ist eben nur ein workaround.

  • Das Starten des Abspielens habe ich jetzt auch gelöst.
    Der angehängte patch löst alle beschriebenen Probleme.
    Kein dropped frames mehr beim Starten vom Abspielen, auch nicht bei Sprüngen oder nach schnellem Vorspulen etc.
    Der patch für xine ist nicht mehr nötig.


    Bei mir funktioniert es mit dem patch bestens, ich kann fünf HD Sender gleichzeitig aufnehmen (mehr habe ich nicht gleichzeitig), und während dessen durch die laufenden Aufnahmen zappen, ohne irgendwelche Störungen. Ohne den patch gab es besonders bei laufenden HD Aufnahmen Probleme beim Zappen durch HD Aufnahmen (framedrops, continuity errors, Störungen in Aufnahmen, starke Verzögerungen, längere Cpu Vollauslastung).


    Ich bitte alle Tester um Feedback.

  • Nur zur info: So ganz kompatibel mit dem Jumpplay Patch dürfte dieser Patch nicht sein. Vielleicht hast ja Zeit das bei Gelegenheit mal anzupassen ...


    Code
    g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_TTXTSUBS -DUSE_WAREAGLEICON -DUSE_YAEPG -DUSE_JUMPPLAY -DREMOTE_KBD -DREMOTE_LIRC -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\" -I/usr/include/freetype2   -I/usr/src/v4l-dvb/linux/include dvbplayer.c
    dvbplayer.c: In member function ‘virtual void cDvbPlayer::Action()’:
    dvbplayer.c:433: error: ‘LastMarkPause’ was not declared in this scope
    dvbplayer.c:524: error: ‘cutIn’ was not declared in this scope
    dvbplayer.c:599: error: ‘LastMarkPause’ was not declared in this scope
    make: *** [dvbplayer.o] Fehler 1

    Mein VDR: Software: vdr 1.7.30 vdr-xine, xine-lib-1.2, Ubuntu 10.04, 2.6.35 Hardware: GT 220, TT-PCI S2-1600 + Mystique SaTiX-S2 V2

  • Ja, die setzten beide an derselben Stelle in Action() an.
    Da ich den Jumpplay Patch nicht verwende, und dieser komplexer als mein Patch ist, wäre es mir lieber, wenn ein Jumpplay Patch Benutzer (bei Bedarf) meinen Patch integriert.

  • Nur zur info: So ganz kompatibel mit dem Jumpplay Patch dürfte dieser Patch nicht sein. Vielleicht hast ja Zeit das bei Gelegenheit mal anzupassen ...


    g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_TTXTSUBS -DUSE_WAREAGLEICON -DUSE_YAEPG -DUSE_JUMPPLAY -DREMOTE_KBD -DREMOTE_LIRC -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/video\" -DCONFDIR=\"/video\" -DPLUGINDIR=\"./PLUGINS/lib\" -DLOCDIR=\"./locale\" -I/usr/include/freetype2 -I/usr/src/v4l-dvb/linux/include dvbplayer.c
    dvbplayer.c: In member function ‘virtual void cDvbPlayer::Action()’:
    dvbplayer.c:433: error: ‘LastMarkPause’ was not declared in this scope
    dvbplayer.c:524: error: ‘cutIn’ was not declared in this scope
    dvbplayer.c:599: error: ‘LastMarkPause’ was not declared in this scope
    make: *** [dvbplayer.o] Fehler 1


    Das verstehe ich nicht. Jries Patch benutzt diese Variablen nicht, noch löscht er die Deklarationen dafür. Ich denke du hast die Patches nicht richtig gemerged. Außerdem ist es nicht Aufgabe von jrie mit seinem Patch Rücksicht auf andere Patches zu nehmen. Das ist Sache desjenigen, der die Patches zusammenführt. Ein Patch-Entwickler muss immer gegen den Vanilla-VDR patchen.


    Dank an jrie für seinen Beitrag!


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Der Preis für die niedrige Cpu Last beim Starten vom Abspielen ist eine gewisse Verzögerung. Ohne Patch ist es schneller. Daher habe ich das Verhalten jetzt konfigurierbar gemacht. Ohne laufende Aufnahmen lieber schnell, mit laufenden Aufnahmen lieber sicher.


    Mit vdr-xine funktioniert das bei mir sehr gut. Bei einem Test mit xineliboutput hat es nicht so viel gebracht.


  • Ist es möglich, die Verzögerung oder die 100% Cpu Phase mit leichtem Ruckeln durch die dropped frames loszuwerden?
    Eine gründlichere Analyse hat Folgendes ergeben. Nach einem Sprung werden die ersten Bilder vom Decoder verzögert angeliefert. Dies führt in der video_out loop zu einer hohen Cpu-Last. Dies führt aber wiederum dazu, dass hereinkommende Bilder zu spät verarbeitet werden. Dies hält die Cpu-Last oben, und so weiter.
    Optimierungsversuche bei der Verarbeitung zu später Bilder haben nicht genug gebracht, sodass ich jetzt auf ein AM3 Board mit zu 2 Kernen freigeschaltetem Sempron 140 umgestiegen bin. Damit wird das Abspielen nach einem Sprung praktisch sofort fließend fortgesetzt, sogar mit der PCI-Karte 8400 GS. Den Pentium 3 Rechner benutze ich jetzt nur noch für DVB-T, die SD-Auflösung packt er problemlos.

  • Mit dem softhddevice plugin treten diese Probleme nicht auf.
    Für ältere langsame Hardware ist Softhddevice also sehr empfehlenswert.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!