[Wunschkonzert] Livebuffer-plugin

Zitat von gda

Ach so, der Nurnutzer darf das, der Entwickler nicht. Kann ich doch nicht ahnen.

Also bis jetzt habe ich hier noch regelmäßig mitgelesen, aber was hier teilweise an gegenseitigen Beschimpfungen und Schuldzuweisungen abläuft macht es echt lästig, den Thread weiter zu lesen.

Daher mein Vorschlag: bitte markiert nicht zum Thema gehörige Äußerungen deutlich, so daß ich das schnell überspringen kann ("Kindergarten on/off" in Rot, wie von "kamel5" benutzt ist schon mal ein guter Anfang ;-).

Ansonsten bin ich hier weg...

Klaus

Zitat von kls

Daher mein Vorschlag: bitte markiert nicht zum Thema gehörige Äußerungen deutlich, so daß ich das schnell überspringen kann ("Kindergarten on/off" in Rot, wie von "kamel5" benutzt ist schon mal ein guter Anfang ;-).
Ansonsten bin ich hier weg...

An mir soll es nicht liegen, ich habe aufgeräumt.

Gerald

<Kindergarten>Full ACK</Kindergarten>

Gerald

Zitat von googles

Das währ dann der livebuffer

Wenn ich so drüber nachdenke hast Du natürlich absolut recht, weil da läuft die Aufnahme schon und muß nicht erstellt werden, wie beim "normalen" Timeshift ...

Zitat von gda

An mir soll es nicht liegen, ich habe aufgeräumt.

An mir auch nicht ...

Zitat von hotzenplotz5

nur damit das nicht verloren geht in den untiefen des langen threads.

Was sollen wir zusammenfassen?

Sollte sich je die Chance für eine Umsetzung ergeben, würde die schon bestehenden Timeshift-Funktion erweitert und ist aktivierbar unter dem existierenden Menüpunkt "Zeitversetze Aufnahme löschen: [ja|nein|bestätigen|permanent timeshift]" ... ?

Ich bin ja nun nicht die Zielgruppe, würde es dennoch aber als logischer empfinden wenn der "permanente Timeshift" mit setzen der entsprechenden Setup-Option sofort aktiv ist und kein zusätzlicher "Pause"-Druck notwendig wäre. Wer das möchte hätte ja noch die klassische Funktion, oder?

Selbstverständlich würde ich auch aktiv mittesten.

Regards
fnu

kls

Zitat von fnu

Zitat von »Dumpfbacke«

Zur Pausenfunktion: Das dauert bei mir sehr lange, von "Live-Signal wird angehalten" bis zum Stopp 8 Sekunden (auch auf SD Kanälen). Ist das normal? Oder habe ich da auch etwas falsch eingestellt?

Zitat von fnu

Ja, das ist in der Tat auch bei mir ein wenig holprig, hatte ich weiter oben mal mit "gurgelt noch ein wenig rum bis Standbild" beschrieben. Das könnte in der Tat etwas "fluffiger" vonstatten gehen, im Idealfall mit Druck der Pausetaste sofort ins stabile Standbild. Ich hege die Vermutung, das hat was mit der Umstellung vom PES Containerformat (VDR 1.6.0) auf TS zu tun, aber da weiß jemand anderes bestimmt mehr zu ...

Könntest Du das Verhalten verbessern? Unabhängig ob LiveBuffer oder nicht?

Ansonsten hatte Mini73 ja schon einen Grundstock an Konsens resümiert
[Wunschkonzert] Livebuffer-plugin

Oder meine Wunschvorstellung eines möglichen Funktionsumfangs

Hier (mit SoftHDDevice und vdr 1.7.26) gurgelt da wenig. Es wird "Das Livesignal wird angehalten" geschrieben, dann noch ca 2 Sekunden normales Bild und dann schwarzes Bild, das ist aber eher etwas was ich zuersteinmal im softhddevice Thread posten würde. Xine und sxfe habe ich noch nicht gegentesten können. In einem der vorherigen Releases war ja noch etwas dazu was erstmal (?) wieder zurückgenommen wurde weil es einen negativen Effekt hatte.

[geloest] Timeshift Problem mit 1.7.x

Generell ist das Pause Handling schon so sehr gut - man kann es benutzen und wieder Stoppen und wieder benutzen. Bei mir wie gesagt ohne Gurgeln, und zum ersten mal seit sehr langem das man es einfach so benutzen kann, vorher hatte man eine 50/50 Chance das es einfach weiterlief oder man komplett im Nirvana landet.

Ich habe das Gefühl weitere Diskussion und Tests zum normalen Pausefunktion sollten in einem seperaten Thread geführt werden. Ich würde hier gerne systematische Tests auf verschiedener Hardware mit verschiedenen Ausgabearten (shd, xine, sxfe, ffhd, ffsd) zusammentragen wollen. Auch wüsste ich gerne welches Problem genau diese zurückgenommene Änderung beheben sollte.

Hallo,

um nochmal auf die Frage, Was ist jetzt schon mit dem vorhandenen VDR-Code möglich?, zurückzukommen, habe ich mal einen 2-Zeiligen Code-schnipsel zum Spielen beigefügt, der eigentlich nur zeigen soll, das ein Kanalwechsel mit folgender Aufnahme und Wiedergabe tatsächlich jetzt schon möglich wäre.

--- vdr-1.7.26/vdr.c	2012-03-09 10:55:15.000000000 +0100
+++ vdr-1.7.26.T/vdr.c  2012-03-23 11:06:32.357778236 +0100
@@ -1014,6 +1014,10 @@
               	}
            	else
               	cDevice::SwitchChannel(NORMALKEY(key) == kChanUp ? 1 : -1);
+//#ifdef USE_TIMESHIFT
+            	if (cRecordControls::PauseLiveVideo())
+              	cRemote::Put(kPlay, true);
+//#endif /* TIMESHIFT */
            	key = kNone; // nobody else needs to see these keys
            	break;
       	// Volume control:

Das Ganze ist natürlich nur minimalistisch und geht auch nur mit der Ch+ und Ch- Taste und vor dem nächsten Kanalwechsel muss man händisch noch die Stop-Taste drücken.
Leider fehlt mir in diesem Zusammenhang ein tiefgründigerer Einblick in den VDR. Ein "Wissender" könnte hier sicher noch die Ch+ und Ch- Taste während der Wiedergabe zur Verfügung stellen und dann noch die Stop-Taste automatisieren, und man hätte eine minimalistische permanete Timeshift-Funktion die aus einer handvoll Code-Zeilen besteht.

Zumindest kann man mit diesen beiden Zeilen schon mal das Umschaltverhalten verifizieren.

Bei mir dauert es damit bis zu einer laufenden Wiedergabe bis zu 5sec, wobei sich der Wiedergabezeiger bei ca. 2-3s vor Ende einpegelt, allerdings noch etwas ruckelig, stabile Wiedergabe findet dann so ab etwa 4-5s vor Ende statt.

Karl

Bei mir hat der Livebuffer von der 0.4 pre 2 einwandfrei funktioniert. Bin jetzt total geschockt das es bei der >Final nicht geht. Ich finde permanentes Timeshift ist eines der wichtigsten Funktionen eines <VDRs.

Zitat von krumpholzb

Bei mir hat der Livebuffer von der 0.4 pre 2 einwandfrei funktioniert. Bin jetzt total geschockt das es bei der >Final nicht geht.

Öhem, hier geht es nicht um yaVDR und was wir da einbauen oder nicht, das ist nicht Thema dieses Threads.

Zitat von krumpholzb

Ich finde permanentes Timeshift ist eines der wichtigsten Funktionen eines <VDRs.

Ok verstanden, es werden noch händeringend Leute gesucht die sich drum kümmern würden ...

Regards
fnu

Ich habe mir gestern abend den ganzen Thread durchgelesen und mir dann im Bett meine eigenen Gedanken gemacht. Auch wenn einiges davon redundant zu dem bereits hier gesagten ist, würde ich mich freuen, wenn sie nicht ganz unbeachtet blieben.

Was erwarte ich von einem Livebuffer?

Von einem Livebuffer erwarte ich, dass ich die Wiedergabe jederzeit anhalten kann. Darüber hinaus, dass ich einige Minuten zurück spulen kann, wenn ich spontan abgelenkt wurde oder das Ende einer Werbepause auf dem Klo verpasst habe. Außerdem sollte man durch vorspulen zum Beispiel während einer Werbepause nahtlos zurück in die Livewiedergabe gelangen können.

Angesprochene Punkte wie eine Anpassung der EPG-Anzeige oder das direkte Umwandeln in eine Aufnahme sind für mich unnötiger Luxus, den die meisten glaub ich auch gar nicht so sehr haben wollen.

Was kann VDR?

VDR kann durch einen Druck auf die Pausetaste das Livesignal aufzeichnen, in den Wiedergabemodus wechseln und innerhalb dieses Navigieren. Mit dem entsprechenden Patch (der bei mir übrigens nicht zuverlässig funktioniert) wird die Aufnahme beim Beenden des Wiedergabemodus gelöscht.

Was ist kaputt?

Das ganze Konzept. Ein Livebuffer ist keine Aufnahme, und die Verwendung der entsprechenden Routinen sorgt für jedemenge Nebeneffekte: Es gibt beim Starten und Beenden kurze Verzögerungen durch den Moduswechsel, die Tastenbelegung ändert sich für den Anwender unbemerkt, und wenn man Umschaltet ohne die Aufnahme zu Beenden sind bei DVB-S nur ein Bruchteil der Kanäle verfügbar. Besonders fies, wenn man eigentlich noch eine andere Aufnahme programmiert hat, die dann u.U. nicht oder verspätet startet.

Für den normalen Anwender ist es zudem verständlicher, dass der Livebuffer beim Umschalten verloren geht, als dass er erst den Wiedergabemodus beenden und ggf. den Timer löschen muss.

Um mal das andere, von MythTV implementierte Extrem zu betrachten: Alles ist eine Aufnahme. Ist meiner Meinung nach genauso kaputt, denn für Daten, die ich in 95% aller Fälle niemals brauche, wird die Festplatte belastet. Eine Ramdisk für die Live-Aufnahmen macht spätestens dann Probleme, wenn man eine getimerte Aufnahme live ansieht, da die Datei dann in der Ramdisk landet und beim Reboot weg ist (und/oder die Ramdisk irgendwann voll). Außerdem sorgt es dafür, dass der Kanalwechsel in MythTV extrem lange dauert.

Und was denke ich?

Meiner Meinung nach gehört der Livebuffer in einen Ringbuffer im Arbeitsspeicher, und zwar architektonisch so weit wie möglich nach Vorne! Bei einer normalen VDR-Konfiguration also irgendwo direkt vor der Weitergabe der Daten an den TV-Ausgang bzw. libxineoutput etc., bei einer streamdev-Konfiguration in den Clienten, bei einer XBMC-PVR-Installation ins PVR-Addon von XBMC. Würde man das irgendwo tief in den Server verstecken kriegt man unschöne Sonderfälle z.B. bei gleichzeitigen Aufnahmen des selben Kanals rein, und wenn viele Clients auf dem selben Server arbeiten könnte sie dessen Ringbuffer mal eben fluten, obwohl sie selbst vielleicht noch viel Arbeitsspeicher frei hätten.

Implementierung

Ich habe mich mit dem VDR-Source bisher nur oberflächlich beschäftigt. Den Ringbuffer selbst einzubauen stelle ich mir recht einfach vor, wenn man die passende Stelle gefunden hat. Irgendwo müssen die Streamdaten ja an die dekodierende Einheit weitergegeben werden, vielleicht kommt dort sogar sowieso schon ein kleiner Buffer zum Einsatz?! Ansonsten schreibt man an der entsprechenden Stelle die Daten halt in den Buffer rein und liest sie dem Zeitcode entsprechend von einer anderen Position wieder aus.

Die entsprechenden Tastenfunktionen bräuchten dann Zugriff auf die Datenstruktur, die den Livebuffer und die aktuelle Position verwaltet. "Pause" müsste ein Flag setzen, dass den aktuellen Frame in ein Standbild umwandelt oder Null-Bytes sendet oder etwas in der Art. "Zurück" würde die aktuelle Position nach hinten verschieben, aber maximal bis zur Größe des Livebuffers (beim Füllen des Buffers müsste diese Position natürlich angepasst werden, wenn der Ringbuffer vollständig gefüllt wurde). "Vorwärts" würde die aktuelle Position nach vorne Verschieben, aber ebenfalls nur bis zum maximalen Füllstand des Buffers.

Zitat von Cybso

Eine Ramdisk für die Live-Aufnahmen macht spätestens dann Probleme, wenn man eine getimerte Aufnahme live ansieht, da die Datei dann in der Ramdisk landet und beim Reboot weg ist (und/oder die Ramdisk irgendwann voll).

Das passiert dir bei einem "Live-Buffer" im RAM genauso, wenn aus irgend einem Grund VDR neu startet.
Wer einen Live-Buffer im RAM fordert, wird diesen Wunsch sofort verfluchen, wenn er ihn das erste Mal verloren hat.

Klaus

Nur zu, wir sind die Letzten die sich gegen eine vernünftig implementierte Lösung sperren würden.

Gerald

Zitat von kls

Wer einen Live-Buffer im RAM fordert, wird diesen Wunsch sofort verfluchen, wenn er ihn das erste Mal verloren hat.

Das ist allerdings wahr und würde doch für ein normales File sprechen, dass man ja in eine RAM-Disk legen kann.

Gerald

Zitat von kls

Das passiert dir bei einem "Live-Buffer" im RAM genauso, wenn aus irgend einem Grund VDR neu startet.
Wer einen Live-Buffer im RAM fordert, wird diesen Wunsch sofort verfluchen, wenn er ihn das erste Mal verloren hat.

Ne, eben nicht. Ich habe in der Definition ja beschrieben, dass die Umwandlung eines Livebuffers eigentlich nur für wenige Fälle relevant ist, das wichtigste ist die Möglichkeit, jederzeit zurückspringen zu können. Deswegen wird aus einem Livebuffer nach diesem Konzept niemals eine Aufnahme werden; wenn man dieses will muss man sie manuell starten und dann erfolgt sie auf dem ganz normalen Weg(*). Also auch kein Frust. Außer man lässt den Buffer solange auf Pause stehen bis der RAM voll ist, aber bei 4 GB passen da mehrere Stunden SD und doch noch eine ganze Menge HD-Material rein.

Zitat von gda

Nur zu, wir sind die Letzten die sich gegen eine vernünftig implementierte Lösung sperren würden.

Gibt es irgendwo eine Übersicht über den Aufbau des Quellcodes? Es fällt mir schwer, den Einstieg zu finden, um einen Proof-of-Concept entwickeln zu können.

Edit 1: *) Will man unbedingt die Möglichkeit erhalten, den Inhalt des Buffers ebenfalls in die Aufnahme einfließen zu lassen, müsste man der Aufnahmefunktion aber auch nur einen Pointer auf die Livebuffer-Datenstruktur mitgeben, damit sie diese Daten vor den aktuellen Stream hängen kann. Aber das fände ich wieder sehr unsauber und wäre auch nur in dem einen Sonderfall "Ich gucke gerade eine Sendung und stelle fest, dass sie doch recht interessant ist, aber es gibt keine Wiederholung" relevant.

Edit 2: Wenn der VDR neu gestartet wird, dann wäre in der Aufnahme so oder so eine Lücke drin. Ich glaube, diesen Fall kann man getrost ignorieren. Ich glaube auch nicht, dass besonders viele Anwender damit rechnen würden, in einem solchen Fall den Livebuffer zu behalten.

Zitat von Cybso

Ich habe mich mit dem VDR-Source bisher nur oberflächlich beschäftigt. Den Ringbuffer selbst einzubauen stelle ich mir recht einfach vor, wenn man die passende Stelle gefunden hat. Irgendwo müssen die Streamdaten ja an die dekodierende Einheit weitergegeben werden, vielleicht kommt dort sogar sowieso schon ein kleiner Buffer zum Einsatz?! Ansonsten schreibt man an der entsprechenden Stelle die Daten halt in den Buffer rein und liest sie dem Zeitcode entsprechend von einer anderen Position wieder aus.

Ok, streicht das "einfach". Ich hab mir gerade die Methode cDvbPlayer::Action in der Datei dvbplayer.c angeschaut. Das scheint schon die richtige Stelle zu sein, aber... das ist ein 300-Zeilen-Codeblob mit ein paar Zeilen Kommentare :-/ Mag mir jemand vielleicht den Datenfluß genauer erklären, ggf. auch im Chat (allerdings nicht mehr heute)?

Zitat von Cybso

Aber das fände ich wieder sehr unsauber und wäre auch nur in dem einen Sonderfall "Ich gucke gerade eine Sendung und stelle fest, dass sie doch recht interessant ist, aber es gibt keine Wiederholung" relevant.

Dieser ganze Thread ist gestartet worden wegen eines Patches, den wir bei uns raus genommen haben, der gerade für diesen Sonderfall gemacht wurde. Alle die diesem Patch nachweinen, wollen diesen Sonderfall.

Gerald

2

Zitat von gda

Dieser ganze Thread ist gestartet worden wegen eines Patches, den wir bei uns raus genommen haben, der gerade für diesen Sonderfall gemacht wurde. Alle die diesem Patch nachweinen, wollen diesen Sonderfall.

Beim Lesen des Threads hatte ich eher den Eindruck, dass es den meisten eher um die Möglichkeit des spontanen zurückspulen ging, die ebenfalls durch diesen Patch verschwunden ist. Meine Vorstellung ist aber ja im Prinzip auch nur eine (vermutlich einfacher zu implementierende) Teilmenge des Problems.

Lässt dieses Forum wohl Umfragen zu?

Zitat von hotzenplotz5

so in der art war er mal im vdr paket in yavdr (jetzt nicht mehr)
https://github.com/yavdr/vdr/blob/573b60…fer12-rmm.patch

Ist das der Patch den gda meint? Warum ist er rausgeflogen? Am Anfang des Threads stand mal was davon, dass er mit 1.7 nicht mehr stabil gewesen sei, aber was genau war das Problem?

Wir können diese Korrespondenz auch gerne per PM fortführen, wenn hier jemand den Eindruck hat, dass wir uns wieder im Kreis bewegen.

Zitat von Cybso

Lässt dieses Forum wohl Umfragen zu?

Ja. Einfach neuen Thread erstellen und als Umfrage aufsetzen...