Search the Community

Hallo Tjod, hallo liebe Entwickler, hallo lieber MarkusK, hallo liebe Nutzer, Bezug ist hier der Thread http://www.DVBViewer.tv/forum/topic/56197-rec-service-app-ios-8x-9x/page-12 . Gerne steige ich ein :-) . Was bisher nur ein "Stochern im Dunkeln" war, ist durch etwas Lesen für mich konkreter geworden, insbesondere dank der konstruktiven Art von Tjod. Genau wie MarkusK bin ich manchmal ein bisschen langsam >>> Freizeit und so, also nichts für ungut ;-) Deshalb erstmal noch mehr Vorschläge ins Blaue, die ich aber - falls gewünscht - umsetzen könnte. Grundsätzlich finde ich das/die Webinterfaces nämlich ausreichend bis gut ... :-D 1. Vorschlag: Browserweiche einbauen, bevor irgendwas geladen wird >>> dann wird außer bei bewusst verstellten/exotischen Konfigurationen ("Profis") automatisch die für das Gerät geeignete Seite serviert (die App / Apps könnten eigenen Filter erhalten) Vorteile: lässt sich meines Wissens einfach im HTML / JavaScript - Code umsetzen und die vorherige Arbeit war nicht umsonst >>> z.B. dank MarkusK, Automatisierung ermöglichen 2. Vorschlag: Browswerweiche durch Plugin-Abfrage ergänzen Vorteil: bisheriger Code lässt sich einfach benutzen, Warnung statt Fehler für die Benutzer (sofort, statt in dem Moment, in dem es nicht funktioniert), Automatisierung ermöglichen 3. Vorschlag: Codierung mit "if"-Abfrage on-the-fly festlegen Vorteil: warum nicht die ffmpegprefs.ini und iphoneprefs.ini einfach in den HTML / Javascript-Code dynamisch einbauen, Automatisierung ermöglichen Kombination aus 1. / 2. / 3. = deutlich bessere Nutzererfahrung, Automatisierung! Jetzt kommt der Teil, über den ich weniger weiß: Es scheint mir so zu sein, dass es außer HLS + DASH wirklich nur ziemlich finstere Hacks gibt (oder Flash natürlich) und deswegen sind das wohl die beiden richtigen Wege. (z.B. http://stackoverflow.com/questions/21921790/best-approach-to-real-time-http-streaming-to-html5-video-client) Fragen: Warum muss der Server eigentlich so viele Protokolle und Auflösungen beherrschen? Letzten Endes funktionieren beide obige Möglichkeiten über http, wenn ich richtig verstanden habe. 800 x 600 (hab ich in den .inis gefunden) ist überhaupt keine Video-Auflösung, soviel ich weiß, sondern eher eine Bildschirmauflösung. Zur Erklärung: Für mich würde z.B. die DVB-T-Auflösung völlig reichen, andere brauchen vielleicht Full HD oder so. Wenn man sich auf gängige Auflösungen beschränkt, muss man viel weniger codieren. Das Video wird nämlich nicht besser, wenn es toll dem Bildschirm entspricht ... ;-) Aufnahmen macht ihr ja hoffentlich in Original-Auflösung auf dem Server selber ... Möglich wären Standardauflösungen abhängig von der Quelle + völlige Freigabe durch Selbsteingabe in ein Web-Frontend-Formular für "Profis". Zu bedenken geben möchte ich den Punkt, dass für das Streaming übers WWW ohnehin eher die Netzwerkgeschwindigkeit zählt, oder? Technisch könnte man dann eher an eine Codierung nach Netzgeschwindigkeit denken, die wie ich gelesen habe, offensichtlich in die obigen Methoden implementiert ist. Daraus würde folgen: statt zu puffern >>> eher messen. Warum also nicht automatisch in bestmöglicher Qualität streamen? Ich hoffe, damit konstruktiv gewesen zu sein, und freue mich auf weitere Diskussionen.