ich habe ein spannendes Problem. Ich habe ein Amazon Fire 10" Tablet, inkl Playstore und allem PiPaPo…
Wenn ich in Chrome die TileVisu aufrufe kann ich mir Videostreams anzeigen lassen. Öffne ich aber die Symcon App (oder die IPSView Beta) bekomme anstelle des Streams folgende Meldung
Unable to RTCPeerconnection::setRemoteDescription(): peerConnectionSetRemoteDescription(): WEBRTC_SET_REMOTE_DESCIPTION_ERROR: Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='O'
Bei IPSView kommt hinzu, das der Symcon Server gnadenlos abschmiert. Anbei ein Debug ipsview.txt (4,0 KB)
Android ist nicht das problem, sondern das fire os 7. Ich vermute es liegt an der webview version. Es wird dort eine „amazon webview“ eingesetzt.
Leider kann ich die nicht durch „android system webview“ ersetzen. Installiert ist die zwar, aber ich bekomme die nicht als default
Edit 11:27 Uhr
Also ich habe ein wenig getestet, Chrome UND der Silk Browser zeigen die Streams an. Bin mir also nicht mehr sicher ob es die Webview Version ist, die die Probleme macht.
Bei einem Freund der ein Fire Table neuerer Version hat, besteht das Problem jedoch nicht.
ich bin dabei einiges zu testen, wie hier berichtet scheint es mit Android 9 Probleme zu geben (darauf basiert das Fireos 7.x). Zudem habe ich die Vermutung geäußert, das ggf der ipmagic Dienst bzw der Wechsel zwischen interner/externer IP eine Rolle spielen könnte.
Mit der Symcon App bekomme ich bei Streams immer den Fehler
Unable to RTCPeerconnection::setRemoteDescription(): peerConnectionSetRemoteDescription(): WEBRTC_SET_REMOTE_DESCIPTION_ERROR: Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='O'
mit Chrome klappt das ganze. Ich habe mal in meinem DNS die ipmagic.de auf meine Symbox umgebogen und es passiert folgendes:
Sowohl in der App als auch im Chrome bekomme ich zuerst die Meldung „Verbindung mit (ICE) wird hergestellt“ und anschließend nach einigen sekunden die Meldung: Waiting for session Description timed out
Neu ist Meldung in der Symcon App, das erst, wie im Chrome, versucht wird eine Verbindung aufzubauen bevor diese mit einem Time out abbricht. Vielleicht hilft es Dir @paresy weiter, den Fehler einzugrenzen?
Ich hatte letztens ein simpleres HTML Problem innerhalb Fully welches ich durch separates Updaten des webview System-Programms lösen konnte. Hast du mal überprüft, welche Webview Version überhaupt installiert ist?
Die idee hatte ich auch, aber dafür wären auch die mindest versionen wichtig.
Du kannst bei fire tablets nämlich die webview nicht einfach verändern. Bzw du kannst zwar google webview installieren aber in den entwickleroptionen die standardeinstellungen nicht verändern.
@paresy
ich möchte das Thema nochmal hochholen, ein neues Amazon Fire Tablet funktioniert. Die neue unterscheidet sich wie folgt:
Fire OS 8 (die aktuelle Generation)
basierend auf Android 11,
API-Level 30
122.amazon.webview-v122-6261-tablet.6261.140.27
Symcon Visualisierung und Chrome funktionieren. IPSView Beta kann leider nicht getestet werden.
Fire OS 7 (die Vorgeneration)
basierend auf Android 9,
API-Level 28
122.amazon.webview-v122-6261-tablet.6261.140.26
die Streams laufen in Google Chrome und sogar im Amazon Silk-Browser
Symcon Visualisierung und IPSView Beta auf den Fehler:
Unable to RTCPeerconnection::setRemoteDescription(): peerConnectionSetRemoteDescription(): WEBRTC_SET_REMOTE_DESCIPTION_ERROR: Failed to set remote offer sdp: Failed to set remote video description send parameters for m-section with mid='O'
Ich habe hier einen möglichen Grund gefunden, leider verstehe ich den als nicht Programmierer nicht.
Ich kann mir nicht vorstellen, das es am Webview liegen soll…
Ich wäre sehr dankbar wenn wir da Klarheit schaffen könnten, woran es liegt.
Viele Grüße
Edit…
ich glaube ich verstehe es doch. Der im o.g. Codeschnipsel sorgt dafür das auch wirklich H.264 verwendet werden soll, ansonsten wird vp8 auch verwendet.
The actual winning lines in the peerConnectionFactory was defining the encoderFactory and the decoderFactory and specifying the correct flags to tell WebRTC that we want to use h264HighProfile.
This is seen in this line: VideoEncoderFactory encoderFactory = new DefaultVideoEncoderFactory(rootEglBase.getEglBaseContext(), true, true);
Where the first true boolean is to enable VP8 encoding and the second is for H264.
Die alte Generation kann vp8 aber nur in Software dekodieren, das neue auch in Hardware
neu
ich führe meinen monolog mal fort… Ich kann ja leider nur raten,@paresy hat wahrscheinlich zuviel um die Ohren. Aber ich vermute das die Symcon app versucht eine Art Hardwarebeschleunigung zu verwenden. Ich habe die Probleme auch im Android Studio wenn ich einen Android Emulator benutze (Android 14 mit und ohne PlayStore)…
ich habe auf meinem Testtsystem die main.dart.js und bei setRemoteDescription die type manipuliert um Fehler sehen zu können, der Fehler ist bei Nutzung der Visu App eine andere als bei chrome.
Das ist ein guter Tipp, wie wir es „nachstellen“ können. Mich wundert ein wenig, warum er auf dem Tablet die Hardware Beschleunigung nicht nutzen will/kann. Denn laut Specs sollte ja h264 problemlos gehen.
@Parzival Schaut sich aber mal in der App an, wie wir sauber das Downgrade auf Software Decoding hinbekommen, sofern die Hardwarebeschleunigung nicht geht.
Spannend wäre ja zu wissen, ob der Browser die Hardware Beschleunigung macht, oder dort der Downgrade auf Software Decoding zufällig funktioniert.
Wir haben heute etwas intensiver getestet. Der Emulator scheint gar kein h264 als Dekoder anzubieten. Wir werden zur nächsten größeren Beta (7.2) mal einen Check einbauen, der alle verfügbaren Codecs anzeigt und auch eine bessere Fehlermeldung liefert, noch bevor der Stream gestartet wird.
Was dein Tablet angeht: Ich vermute, dass wir das nicht zum Laufen bekommen werden. Der Chrome, den du nutzt, wird bestimmt eine ganze Reihe von eigenen (Software/Hardware) Dekodern mitliefern. Ich bin mir unsicher, ob wir dies auch könnten ohne sehr hohen Aufwand zu haben bei der Integration. Aktuell nutzen wir nämlich die nativen APIs von Android ohne zusätzliche Dekoder auszuliefern.
Im SO Artikel steht auch, dass Chrome (wie von mir vermutet) einen anderen Dekoder nutzt als das Standard Android, weshalb genau dieser Unterschied zustande kommt. Leider sehe ich uns nicht im Stande den Dekoder für WebRTC in unserer App einfach zu tauschen - das gibt das von uns genutzt Framework leider nicht her.
Gibt es eine Möglichkeit, dass du das Fire OS gegen ein neueres Android OS tauschen kannst?
zwar nicht schön, aber wenigstens eine Erklärung. Ggf könntet Ihr das als Systemvoraussetzung aufnhemen. So in der Art „WebRTC wird für MediaTeks CPU erst ab Android 10 unterstützt“ o.ä
Ich habe bei einem Tablet gestern auf Chrome mit Fully Kiosk umgestellt, da meine Symbox immer bei über 60% CPU Last hat (drei gleichzeitige Streams), dank Chrome und Fully bin ich jetzt bei 25%.
Ich habe dann spaßeshalber Firefox auf dem Tablet getestet, damit kann ich die Visu nicht anzeigen, die Streams stottern wie bekloppt, also passt das (leider) mit den eigenen Codes. Warum es beim Silk klappt… keine Ahnung.
Leider nein, die neue Generation wäre Android 11 ist aber nicht auf die alte Generation portierbar. LineAgeOS o.ä klappt derzeit nur mit der 9 Generation (Vorgänger zu meinen 11th Generation).
Mal sehen ob da was in Zukunft was machbar ist. Bis hierhin schonmal großen Dank!
