Recording Service - Vorschläge für ein responsives Webdesign

[dkdvb]

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.

 

 

 

 

[Tjod]

Grade bei Responsive Webdesign sollte eine generelle Browserweiche unnötig sein. Da sich die Größe ja automatisch an die Display Größe anpasst.
(Browserweiche klingt für mich irgendwie nach 90er Jahre Web kurz nach dem "Die Webseite ist Optibiert für x bei einer Auflösung y" )

 

Da ist halt nur die ganz große Frage, wer gestaltet ein neues oder überarbeitetes Webinterface für den RS.

Es muss sich halt jemand mit Lust, Zeit und den passenden Fähigkeiten finden. Ich wüste derzeit niemanden der sich dafür anbietet. Weiß du da jemanden oder willst du da gar übernehmen (und erwarte nicht dass da jemand groß für bezahlt werden kann. Sogar Griga der hier einen großteil macht hat einen andern Job um seinen Lebensunterhalt zu finanzieren. Und abgesehen von Christian machen das sonst hier alle ohne was daran zu verdienen)

Die derzeitigen Templets kann sich ja jeder RS ohne Problem angucken und auch bearbeiten.

Wie mrphlox dass z.B. bei der Timeline gemacht hat.

http://www.DVBViewer.tv/forum/topic/47641-recording-service-verbesserungen-timeline/

 

Live Streaming Formate
Und zu der Plugin Geschichte, optimal wäre da natürlich ein HTML5 Player mit Flash Fallback.
Aber da haben wir das Problem das HTML5 live streaming bisher noch nicht wirklich ausgereift ist.
(HTML5 Live Streaming sollte da nicht mit HTML5 Video wiedergab verwechselt werden, was schon recht gut geht)
Bei Live Streaming gibt es HLS (iOS, Android, Safari und Edge) und MPEG-DASH (Chrom, IE11 und Edge) Firefox unterstützt das derzeit generell nicht da bleibt nur Flash.

 

Das heißt man braucht 2-3 Sachen um alle gängigen Browser abzudecken. Und bei Flash ist das Sender einstellen und umschalten wahrscheinlich mit Abstand am schnellsten.

 

Aber die Techniken sind auch nicht wirklich für den RS geeignet. Sie eignen sich sehr gut wenn ein Stream gestartet wird. Und sich dann Später Clients dazu verbinden. Aber wenn der Stream erst gestartet wird wenn er angefordert wird (z.B. Senderwechsel im RS) muss der Client erst mal waren bis ein Segmente vor Produziert sind. Und im Gegensatz zur Dateiwiedergabe kann man das auch nicht beschleunigen da die Daten nur in Echtzeit eintreffen.

 

Und der RS muss ermitteln wann kein klickt mehr mit einem Stream verbunden ist. Um die Hardware z.B. für einen Senderwechsel wieder frei zu geben. Und das ist bei Formaten wie HLS wo nicht zwingend eine konstante Verbindung besteht auch nicht so leicht. Da sich jeder Client anders verhält.
Ein bisschen hatten wir das hier schon beschrieben.

HLS und Konstante Streaming Formate sind mit dem RS möglich. Und zumindest für nicht HLS gibt es jetzt schon eine API mit der mehr oder weniger alles was kontinuierliche streams angeht möglich sein sollte. Bei HLS geht das ab der nächsten Version das wird Grade grundlegend umgestaltet.

Aber mit MPEG-DASH Support würde ich nicht so schnell rechnen. Aber alles was kein HLS kann unterstützt eigentlich Flash.

Und wer die Möglichkeit hat sollte wegen den Problemen HLS eher vermeiden

Das heißt Flash verwenden oder einen Anderen player verwenden der z.B. auch mit einem nicht zerhackten TS stream umgehen kann.

 

Auflösungen

Zu den Verschiedenen Auflösungen. Es macht wenig Sinn die Video Auflösung weiter zu vergrößern als die Ursprungsauflösung. Da man nicht wirklich was an Qualität gewinnt.

 

Aber es macht sehr wohl Sinn kleinere Auflösungen anzubieten. Da bei einer geringeren Auflösung ja auch die Datenrate sinkt (und die Prozessor last auf dem Server). Und es macht wenig Sinn die Video Auflösung höher ist als die von dem Fenster/Bildschirm auf dem das wiedergegeben werden soll.

 

Und dabei ist zu beachten, Das die Auflösung mit die entscheidendste Größe ist über die man die Datenrate beeinflussen kann. Da man alles was ohne Qualitätsverluste im Bild geht sowieso immer macht. Und die anderen stellschrauben die weniger auffallen als die auflösung doch recht beschränkt sind.

 

Aber der Webdesigner könnte natürlich die Display Größe automatisch per JavaScript ermitteln und so die passenden Auslösungen anfordern. Das heißt die Einstellung ist nicht wirtlich nötig.

 

Und nur wenn das nicht ganz klar ist der RS erstellt den Stream nur dann er er Grade von einem Client genutzt wird und nur in der einen Auflösung die der Client Grade angefordert hat.

 

Automatische Auswahl der Datenrate

Dabei ist zu beachten das der RS einen Sender nur dann streamt wenn ein Client den angefordert hat und mit dem Server verbunden ist. Und auch nur einmal also genau mit den Parametern die für den Client genutzt werden.

 

Deshalb muss für einen wechsle der Datenrate der stream gestoppt und mit neuen Daten neu gestartet werden.

Und das dauert mit allem darum und dran 3-20 Sek. Und wenn das mehrfach nacheinander passiert stört das wahrscheinlich mehr als es nützt.

 

Und dabei muss man beachten das der Server keine Ahnung hatt welche Geschwindigkeit die Verbindung hat. Das heißt die Auswahl ist Sache des Clients.

 

Und das ist bei HLS und DASH ja auch im Format vorgesehen. Aber wenn man das wirklich nutzen will müste der Server immer alle Formate erstellen so das jederzeit der Client wechseln kann.

 

Aber ich sehe nicht das es Sinn mach für einen Client der eventuell mal wechselt immer 5 Formate zu encodieren und den Prozessen konstant stark auszulassen oder zu überfordern.

 

Das ist was anderes wenn man einen Server betreibt der konstant wenige Sender für viele Clients bereitstellt.

Das ist aber nicht die Haupt Funktionsweise vom RS.

Der RS stellt meist auf anfrage aus einer großen Auswahl (meist mehrere Hundert Sender) wenige Sender (1-2 pro Client) für wenige Clients (1-6) bereit.

 

 

Aber bei den ganzen Ideen bleibt die große Frage, wer setzt vor allem die dafür nötige Oberfläche/Webinterface Änderungen um?

Was streaming angeht sind die nötigen Möglichkeiten ja weitgehend schon vorhanden. Und die Parameter in der ffmpegprefs.ini und iphoneprefs.ini könne bei bedarf ja von jedem leicht angepasst werden. Wenn er weiß was er genau braucht

 

Und wenn da jemand was macht und kleinere Änderungen im RS brauch stehen die Chance dafür nicht um bedingt schlecht:

http://www.DVBViewer.tv/forum/topic/57185-audiospuren-beim-transkodierten-streaming-waehlen/

Man muss aber Grade wenn es um das Webinterface geht sehr genau sagen was der Server genau wie macht. Und wie es er genau in der Situation in Zukunft machen soll.

Da es Niemanden mehr gibt der den mit der Zeit "natürlich" gewachsenen Webserver Code kennt.

[dkdvb]

Naja, sicher, der Begriff Browserweiche ist ziemlich oldschool. Der Sinn darin, hier dynamisch auf die Art des Browsers zu reagieren sollte aber gar nicht sein, das Design im Sinne von >>> Aussehen zu verändern, sondern rauszufinden, welches Streaming man verwenden kann.

 

Auflösung muss selbstverständlich Originalauflösung des Materials UND kleiner gleich Bildschirmauflösung ein. >>> Das ist dann effizient & responsive ...

 

Mein Vorschlag geht, trotz der Begrifflichkeit "Browserweiche" eher in Richtung AJAX, d.h. Server und Client kommunizieren nicht einmal, und dann ist der Stream etabliert, sondern häufiger, was z.B. auch beim Wechseln der Bildschirmausrichtung sinnvoll wäre.

 

Ich schlage etwas vor, das ich für sinnvoll halte. Ob ich es implementiere, weiß ich noch nicht. für die halbe Stunde am Tag, die ich überhaupt Medien geniesse, reicht mir eigentlich Service und App, so wie sie sind ... ;-)

 

Worauf ich hinweisen möchte, ist halt, dass es SEHR viele Möglichkeiten gibt, die bereits implementiert sind. Wenn man sich hier beschränkt, wird EINE Möglichkeit vielleicht perfekt.