Springen beim transcodierten Streaming von Aufnahmen

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Springen beim transcodierten Streaming von Aufnahmen

      Es gibt zwar ein paar alte Threads zu dem Thema, aber ich mache lieber mal einen neuen auf.

      Ich verwende aus dem Internet das transcodierte Streaming von einer uno4kse, was mit LIVE TV und auch mit Aufnahmen ganz gut funktioniert. Machen ja auch viele andere so.

      Wenn man das mit einer APP macht, vermisse ich bei allen Apps, dass sie einem nicht nur die Filme in den Lesezeichen anbieten sollten, sondern einem auch die Verzeichnisse anbieten sollten, die z.b als Symlink auf die ausgelagerten NAS HDD zeigen, um dann auch an alle Filme ranzukommen. Dafür alles Lesezeichen zu definieren, ist einmal sehr lästig und zum anderen macht es ja auch keinen Sinn, dass sich die APP alle Filmenamen holt, die dann über alle Lesezeichen gehen. Das kann recht viel sein. Ich würde mir wünschen, dass man einfach die Verzeichnisse anwählen kann, die man so hat. So wie im OpenWebIF. Das aber nur am Rande.

      Das größere Problem ist, dass man beim transcodierten Streamen nicht sinnvoll Springen oder Spulen kann, beim direkten streamen geht das ja.

      Ich habe das jedenfalls schon probiert mit dreamdroid, dreamplayer (Android), enigmote und tellymote (OS) und VLC auf Windows.
      Dann habe ich mir mal angeschaut, was da eigentlich passiert und warum das klemmt.
      Die APPs machen einen HTTP Get request auf den aufzuspielenden Film und lassen sich dann über diese TCP Verbindung den stream liefern. Wenn man nun auf die Idee kommt, einfach mal mit dem Schieberegler zu springen, dann macht die APP einen erneuten GET Request auf den Film mit einer anderen Position, wo es losgehen soll. Das passiert auf einer neuen TCP Verbindung. Die alte TCP Verbindung bleibt aber einfach offfen stehen und wird weiterhin mit den transcodierten Daten versorgt, bis die mal in einen Timeout läuft, weil die APP die Daten nicht mehr abnimmt. Da beim transcodierten Streamen ja in der Box eine HW Einheit benötigt wird, ist diese die ganze Zeit durch den alten unnötig laufenden Stream belegt und wird erst freigegeben, wenn der TCP Timeout kommt. Für die neue Verbindung dauert das aber alles viel zu lange und daher klappt das einfach gar nicht. Vor allen Dingen, wenn die Box nur einen Stream transcodieren kann, ist man verloren. Kann gut sein, dass eine Ultimo4k oder Duo4k das mit ihrer zweiten Transcodierungs-HW ausbügeln kann und es dann auf solchen Boxen sogar geht, wenn nicht zwei Personen gleichzeitig die Box zum transcodierten Streamen nutzen.

      Aus meiner Sicht müsste sich das lösen lassen, wenn die APP oder auch der VLC vor dem neuen Request auf den Film mit anderer Startposition einfach die alte TCP Verbindung korrekt schließen. Dann bekommt die Box das mit und wird die Transcodierungs-HW freigeben. Dann hat man zwar immer noch jedesmal eine längere Wartezeit wie am Anfang ja auch, aber es würde gehen.

      In einer Diskussion mit einem Entwickler vom openpli für den Streamproxy (das ist der Prozess, der das Transcodieren verwaltet, ich glaube beim vti nennt der sich transproxy) kam heraus, dann man für eine richtig gute Lösung eigentlich die gleiche TCP Verbindung weiter nutzen müsste und einfach ein Austausch zwischen APP und Box laufen sollte, wo dann die neue Positon oder eventuell auch eine Spulgeschwindigkeit gefordert wird. Dann könnte die Box viel besser mit der Transcoding-HW und der Aufnahme das ganze verwalten und als Benutzer hätten wir ein viel schöneres Spulverhalten. Um das zu realisieren, müssten sich aber beide Entwicklerseiten (APP und Box) auf etwas einigen, um das zu opimieren.

      Für mich wäre es schonmal ein großer Schritt, wenn die APPs einfach die alte TCP Verbindungen schließen bevor der neue Get request gestellt wird, damit man überhaupt springen kann.


      Oder kennt einer von euch eine APP, mit der das problemlos geht von einer Box, die einmal transcodieren kann? Wäre schon, wenn sich der ein oder andere APP Entwickler dieser Sache mal annimmt, wenn Zeit vorhanden ist.
    • Dann würde ich das aber doch der Einfachheit an die entsprechenden App-Entwickler schicken. Das dürfte doch zielführender sein,oder? Oder glaubst du, die Lesen hier alle mit?
    • Dem ein oder anderen APP Entwickler hatte ich das auch mitgeteilt, aber ich wollte das auch hier mitteilen, damit der ein oder andere APP Benutzer, der das gleiche Problem hat, zumindest eine Erklärung findet, warum das so ist.