[live] [merged] Streamen von Aufzeichnungen im Browser

Hallo zusammen,

ich nutze selbst ein paar Patches, die vielleicht für den einen oder anderen von euch von Interesse sein könnten. Markus hat vorgeschlagen, solche Patches hier im Forum in jeweils einem Thread kurz vorzustellen und euer Votum einzuholen, ob sie ins Git sollen:

• 0014 Streaming of recordings into browser.zip
  (originaler Entwurf mit statischer Player-Größe, aber ohne die anderen Goodies)
• 0014g Streaming of recordings into browser.zip
  (mit responsiver Player-Größe und überarbeitetem Setup)

Der Patch für das Streamen von Aufzeichnungen im Web-Browser basiert auf dem gleichen Ansatz wie das Streamen von Sendungen im Browser. Über die ID einer Aufzeichnung, die im gelben Streamen-Knopf (2. v. l.) hinterlegt ist:

… liefert der StreamDev-Server den TS-Datenstrom, der für den Clappr-Player in einen HLS-Datenstrom (m3u8) konvertiert wird:

Wie beim Streamen von Kanälen, kann man per Auswahlliste direkt eine andere Aufzeichnung für die Wiedergabe wählen:

… oder die Links benutzen, um zur davor liegenden bzw. zu nächsten Aufzeichnung zu wechseln. Die Statusleiste unterhalb des Players liefert die gleichen Daten wie eine vorhandene Aufnahme in der Programmübersicht, was die Hover- und Detailinformationen mit einschließt. Die Darstellung der Statusleiste unterhalb des Players habe ich für das Streamen von Aufzeichnungen und Kanälen etwas übersichtlicher gestaltet:

Damit das Ganze funktioniert, muss man für die Konversion nach HLS den Datenstrom begrenzen. Andernfalls wandelt ffmpeg die Aufzeichnung schneller, als der Player sie abrufen kann. Für den HLS-Datenstrom wird im Verzeichnis /tmp/live-hls-buffer hierzu ein fortlaufender Puffer aus 6 Dateien verwaltet, den man sich wie ein über die Aufzeichnung gleitendes HLS-Fenster vorstellen kann. Bei der Konversion von Aufzeichnungen gleitet dieses Fenster – um im Bild zu bleiben – schneller, als der Player folgen kann. Anders als beim Streamen von Sendungen, bei denen die Datenrate des Senders als natürliche Begrenzung dient, werden die 6 Dateien bei Aufzeichnungen binnen einer Sekunde mehrfach "umgeschlagen":

• ffmpeg buffer roll-over log.txt (ca. 7 Dateisätze pro Sekunde)

Das führt dazu, dass der Player schon den Anfang der gestreamten Aufzeichnung verpasst. In ffmpeg kann man mittels einer zusätzlichen Option das Einlesen vom StreamDev-Server so begrenzen, dass das gelesene Datenvolumen der Frame-Rate der Aufzeichnung entspricht. Leider führt das beim Streamen von Kanälen aber zu Aussetzern bzw. Artefakten und kann deshalb nicht standardmäßig verwendet werden. Diese Option muss somit vor -i <input> eingefügt werden, wenn Aufzeichnungen gestreamt werden sollen, für das Streamen von Kanälen aber entfallen.

Bei der von mir genutzten Version 4.4 von ffmpeg ist dies die Option -re. Bei der aktuellen Version wäre laut Dokumentation aber die Kombination -readrate 1 -readrate_initial_burst 1 eventuell eine bessere Wahl. Damit jeder Nutzer dies auf seine Installation und die zur Verfügung stehende Version von ffmpeg abstimmen kann, ist es konfigurierbar ausgelegt. Deshalb gibt es im Setup ein zusätzliches Feld, bei dem man die Optionen zur Begrenzung der Lesegeschwindigkeit einstellen kann:

Ich habe zum Testen ein paar zig Minuten an Aufzeichnungen und Kanälen gestreamt, und soweit scheint alles zu funktionieren. Bitte testet doch einmal selbst und meldet euch, wenn es noch irgendwo knirschen sollte. Ich selbst bin zwar kein ffmpeg-Guru, aber mit unserem gesammelten Wissen bekämen wird das sicherlich zum Laufen.

Erst einmal viel Spaß mit dem Patch

Stefan

Hi JO,

du musst den Patch herunterladen, entpacken und dann folgendes Git-Kommando aufrufen:

• git apply <Datei mit dem entpackten Patch>

… also beispielsweise:

• git apply "0014g Streaming of recordings into browser.patch"

Achtung: Der Patch ist (wie die anderen auch) gegen den aktuellen Master (Commit 3cbdfe1) gebaut. Wenn du gegen einen anderen Commit zum Patchen benutzt, mag es Kollisionen geben, die du dann gegebenenfalls per git mergetool manuell auflösen musst.

Bevor du den Patch einspielst, sollte dein Workspace "clean" sein, also git status keine offenen Änderungen melden, vielleicht abgesehen von irgendwelchen PO-Dateien, die beim letzten Bauen aktualisiert wurden. Letztere kannst du ganz einfach per git checkout HEAD po/*.po entsorgen.

Die sicherste Methode wäre es, einen temporären Branch zum Testen zu verwenden, z.B. folgendermaßen:

• git commit -a -m "Saved workspace" – falls der Workspace nicht "clean" sein sollte
• git fetch – lädt die letzten Änderungen herunter
• git checkout -b test origin/master – legt einen Branch namens test an
• git reset --hard origin/master – nur zur Sicherheit, sollte nach Schritt 1 eigentlich unnötig sein

Git sollte an dieser Stelle melden, dass es jetzt auf dem obigen Commit steht. Nun folgt der Patch:

• git apply apply "0014g Streaming of recordings into browser.patch"

Und weil laut git status eine neue Datei hinzugekommen ist:

• git add pages/recordings_widget.ecpp
• git commit -a -m "Streaming of recordings into browser"

Dann wie üblich bauen und installieren.

Viele Grüße

Stefan

Welche genau meinst du denn? Der Media-Player braucht welche, und was hast du gegen visuelle Verbesserungen?

OK, jetzt verstehe ich was du meinst. Geht klar, kommt gleich.

Was mich am bestehenden Source-Code aber massiv nervt, ist, dass die Einrückung mal mit Tabs, mal mit Spaces erfolgt. wobei die Tabs an verschiedenen Stellen wohl auch noch unterschiedlich expandiert werden müssen (mal sind es 2, mal 4 Zeichen).

Könntest du nicht mal deine IDE anweisen, bei Einrückungen alle Tabs durch Spaces zu ersetzen und über den ganzen Code die gleichen Tabstops zu verwenden (typischerweise 4)? Das würde das Lesen des Codes doch deutlich erleichtern…

Danke & Grüße

Stefan

Quote from kfb77

Das liegt einfach daran, dass das Plugin schon viele Maintainer hatte und jeder seinen Teil anderes gemacht hat.

Ist mir schon klar, und das war auch keineswegs als Kritik an Markus gemeint. Ich hatte halt versucht, schon mal ein paar Schritte in diese Richtung zu gehen, aber die von dir genannten Unterschiede nerven dann natürlich Markus. Mea culpa.

Trotzdem Danke für die Unterstützung meines Gedankens.

Die Vorgaben zum Coding style (wozu das ja auch gehört) könnte man im Read-Me oder – besser noch – in einer eigenen Datei (CODING o.ä.) hinterlegen. Grundsätzlich fährt man immer besser, wenn man nur Spaces statt Tabs verwendet, selbst wenn das ein paar Bytes mehr kostet. Ist heute ja nicht mehr so wie zu der Zeit, in der ich mit Programmieren angefangen hatte…

Viele Grüße

Stefan

Quote from MarkusE

Bitte baue einen Patch, der nur die notwendigen Änderungen enthält, und keine Formatierungen ändert.

Hier ist er, ohne all die aufgehübschten Einrückungen im Source-Code:

• 0014h Streaming of recordings into browser.zip

Ein kurzer Retest war erfolgreich, sollte also passen.

Viele Grüße

Stefan

Quote from MarkusE

Könnte man die uOption nicht anders unterbringen, z.B. am Ende des Kommandos?

Leider nein. Diese Option ist positionsgebunden und muss vor -i kommen, da sie sich immer auf die danach angegebenen Input-Ströme bezieht.

Man könnte das -re bzw. die entsprechenden Optionen neuerer FFMPEG-Versionen aber auch in die Standard-Parameter integrieren, denn beim Streamen von Sendern stört sie wohl auch nicht. Allerdings müsste dann jeder, der Aufzeichnungen im Browser streamen möchte, einzeln dafür sorgen, dass die Parameterlisten entsprechend ergänzt werden. Bei Standard-Parameterlisten ist das einfach, weil man sie nur löschen und neu befüllen lassen muss. Wenn aber jemand individuelle Parameterlisten nutzt, erfordert das aber etwas mehr Arbeit.

Diese Lösung schmiegt sich bezüglich der Konfiguration unkompliziert ein, wenngleich ich sie – wohl aus den gleichen Gründen wir du – ebenfalls nicht wirklich glücklich finde.

Quote from MarkusE

was hat das mit diesem Patch zu tun?

Das gibt die untergeordneten Eingabefelder bündig aus, also ohne die überstehenden Linien. Außerdem vermeidet es, dass die Eingabefelder den hellblauen Rahmen oberhalb der Trennlinien zwischen den Optionen der ersten Ebene unterbrechen. Ist mir bei dem Patch zu den visuellen Verbesserungen halt (noch) nicht aufgefallen und reiche ich hiermit nach.

Quote from MarkusE

Das macht so keinen Sinn. Wenn dann müsste man RecordingsManager::GetByMd5Hash umbenennen.

Mag sein, dass ich den Recordings Manager und das Zusammenwirken seiner Komponenten noch immer nicht vollumfänglich verstanden habe. Jedenfalls braucht man an anderer Stelle ein RecordingsItemRecPtr-Objekt, deshalb diese Funktion. Die Funktion darüber liefert aber leider ein cRecording-Objekt des VDR. Keine Ahnung, wie man davon zu dem anderen kommt. Deshalb habe ich sie quasi abgekupfert. Wenn es besser geht, dann ändere das doch bitte einfach entsprechend.

Letzten Endes habe ich eine Lösung gewählt, die das Gewünschte mit möglichst wenigen Kollisionen beim Mergen ermöglicht. Wenn du das Interface hierzu generell verbessern möchtest, spricht aus meiner Sicht nichts dagegen. Wichtig ist nur, dass man das RecordingsItemRecPtr-Objekt der zu streamenden Aufzeichnung über die in der Liste der Aufzeichnungen vorhandenen Informationen (also den die Recording-ID des Managers) ermitteln kann.

PS: Oder wenn es nur um die Benennung der Funktion geht, wähle bitte einen Namen, der am besten passen würde.

Danke & Grüße

Stefan