Dreamliveserver Problem

  • Hi hab seit gestern ein Problem mit der Server kann auf der DM7080 kein trascodieren mehr starten hat das noch wer ? Hab heute ein neues Image versucht geht nicht kann später mal ein altes versuchen im log sehe ich nix vernünftiges aber hier evtl. Hilft das schon bin grad nur am Pad wenn mehr benötigt mach ich später noch was am pc



    P.s. schnell ein Image vom 16.4 versucht da gehts



    MFG
    KURTI

    Edited once, last by Kurti79 ().

  • @Ghost, ich mache einfach mal hier weiter, dann brauchen wir das nicht im GstRtspServer Thread klären.


    Wie versprochen heute mein Test. Ich habe per rtsp zwar Ton, aber kein Bild. Per HLS funktioniert gar nichts.



    Error 22 bei SetGopOnSceneChange und SetSlices kommt nicht von meiner Config. Ich habe testweise die config gelöscht und es tritt auch mit den Defaults auf:


    Code
    Apr 27 13:22:58 dm820 dreamliveserver[31071]: DreamLiveServer: Couldnt load the settings, using default values!
    Apr 27 13:22:58 dm820 dreamliveserver[31071]: SetGopOnSceneChange - Error: 22
    Apr 27 13:22:58 dm820 dreamliveserver[31071]: SetSlices - Error: 22
    Apr 27 13:22:58 dm820 dreamliveserver[31071]: Play the RTSP stream using the URL "rtsp://192.168.0.57/stream"
    Apr 27 13:22:58 dm820 dreamliveserver[31071]: We use port 8081 for optional RTSP-over-HTTP tunneling.
    Apr 27 13:22:58 dm820 dreamliveserver[31071]: Play the HLS stream using the URL "http://192.168.0.57:8080/stream.m3u8"
    Apr 27 13:23:03 dm820 dreamliveserver[31071]: Shutting down DreamLiveServer!

    Benutze eine dm820, die gar keine Scene Detection und Slices kann. Da das Problem auch auftritt, wenn enigma2 gestoppt ist, kann es auch nicht an irgendwelchen Python Scripts liegen, sondern ist im Code von dreamliveserver.

  • RTSP sieht echt gut aus!


    Bei HLS gibt es aber noch ein paar Probleme:


    1) Mit dem alten Streamserver konnnte ich 6000kbit/s video und 256 kbit/s audio flüssig auch per HLS streamen. dreamliveserver scheint aber bzgl. der Übertragungsgeschwindigkeit um einiges langsamer zu sein, weshalb die segments nicht rechtzeitig ankommen, recht bald der Buffer aufgebraucht ist und es zu Aussetzern kommt.
    Ich habe mal schnell ein bisschen mit Video-JS rumgespielt und einen Web-Player gebastelt und man sieht in den Chrome Developer-Tools, dass die Übertragung der segments deutlich länger benötigt, obwohl diese sogar kleiner sind als beim alten Streamserver. Sogar bei 4000 kbit/s video und nur 1,1MB großen Segments, dauert die Übertragung immer über 2 Sekunden. Der alte Streamserver hat 1,7MB große Segments in unter 2 Sekunden übertragen. Und nein, das liegt nicht an Verbindungsproblemen bei mir - ich habe das mehrmals getestet und immer wieder mal den alten und mal den neuen Server installiert. (Habe übrigens einen 10 Mbit/s Upstream am Server, der zum Testzeitpunkt für nichts anderes benutzt wurde). Davon ab sieht die Zeitleise oben in den Developer Tools so aus, als ob der Server nach jedem Request die Verbindung schließt (ein Connection: close Header wird aber nicht gesendet).


    2) Übergibt man einen service und ruft bspw. http://[IP]:8080/stream.m3u8?ref=1%3a0%3a19%3a157F%3a41F%3a1%3aC00000%3a0%3a0%3a0%3a auf, kommt als Antwort { result: true }. Erst beim erneuten Aufruf erhält man die eigentliche m3u8


    3) Schließt man den Player wird oft (aber nicht immer) beim anschließenden Beenden von dreamliveserver der core gedumpt. Beispiel: https://www.dropbox.com/s/9yanpmal7mes9q9/core.17261?dl=0

  • Hm könnte das auch das Problem sein das ich bei einer App wo ich einen transcodierten Stream starte als erstes ein Fehlermeldung mit „Unresolved error“ „der Vorgang konnte nicht abgeschlossen werden „ bekomme und
    nach einen refresh gehts dann .



    MFG
    KURTI

  • Ich hoffe, dass vorallem bei Problem 1) noch nachgebessert wird. Die beiden anderen Probleme sind eher nebensächlich, da sie die Funktionalität an sich nicht beeinträchtigen.
    Problem 1) allerdings bewirkt deutliche Einbußen der Bildqualität, wenn man Unterwegs streamed, da man die bitrate viel niedriger Einstellen muss als es eigentlich nötig wäre.
    Dafür dürften die anderen beiden Probleme aber im Gegensatz zu 1) auch deutlich leichter zu beheben sein.

  • Nachtrag zu Problem 1)


    @Ghost: Kann es sein, dass ihr die segments nicht in einem Stück in den transport schreibt, sondern zwischendurch immer flushed und wartet bis der Client den Erhalt bestätigt? Ich habe nämlich jetzt einen Reverse-Proxy in StreamServerSeek eingebaut und kann damit wieder HLS mit einer Bitrate von 6000 streamen. Trotz dem Umweg über Python kommen die segments viel schneller beim Client an. Ich kann mir das nur so erklären, dass sich eine direkte Verbindung zum Streamserver durch flushen o.ä. verzögert, weil die Antwortpakete nunmal auch eine Latency haben, die nicht ins Gewicht fällt, wenn der Reverse-Proxy diese direkt lokal absetzen kann.


    Klappt ja jetzt mit Hilfe des Reverse-Proxies in StreamServerSeek trotzdem (einfach http://[IP]/streamserverseek/proxy/stream.m3u8 statt http://[IP]:8080/stream.m3u8 benutzen), aber wäre natürlich trotzdem schön, wenn das auch im dreamliveserver direkt gefixed wird :)