RS Webinterface Streaming

[Tjod]

Ich denke es wäre eine gute Idee die Streaming Geschichte RS Webinterface mal auf eine aktuellere Basis zu stellen.

 

Das ist aber sicher (wie alles was das Webinterface betrifft) keine Geschichte für Griga dass heißt es muss sich jemand anderes um die nötigen Änderungen am Webinterface kümmern.

 

Nach dem ich gesehen habe das der Player nur in der streamint.html eingebunden ist, halte ich das ganze gar nicht für so unrealistisch.

 

Meine Überlegung ist den jetzigen reinen Flaschplayer z.B. durch den HTML5/Flashplayer hier zu ersetzt:

http://mediaelementjs.com/

https://github.com/johndyer/mediaelement/

 

oder weiß da jemand einen besseren oder was gegen den spricht?

 

Und wenn ich richtig liege sollte es reichen die streamint.html und danach die ffmpegprefs.ini (für das Video Format h.264) anzupassen.

Ob und wann ich dazu komme mit dem weiter anzunehmen kann ich Grade nicht einschätzen.

 

Vielleicht gibt es dazu ja noch Ideen und Anregungen oder gar jemand der Lust und Zeit hat sich um Teile davon zu kümmern.

 

[Nanohcv]

Die ursprüngliche Idee mit dem FlowPlayer habt ihr ja mir zu verdanken . Lars hatte diese aufgegriffen und etwas perfektioniert in den RS eingebaut. Der Flowplayer war damals wohl der einzige, dessen Lizenz es erlaubte, ihn mit dem RS zu vertreiben.

 

Nach einer Lösung auf reiner HTML5 Basis habe ich lange gesucht und hab dann frustriert aufgegeben.

Folgende Probleme sind mir da über den Weg gelaufen:

• Fehlende Codecs: Manche Browser können nur Webm, manche nur H264
• Kein Live-Streaming Support. Außer Safari mit HLS. Bei HLS wird der Livestream in Segmente zerhackt und an den Client ausgeliefert. D.h. der LiveStream kann nicht einfach vom FFMPEG Prozess per Pipe an den Webserver übergeben werden. Das hat den Nachteil, dass der FFMPEG Prozess manuell gestoppt werden muss, falls man den Videoplayer beendet. Müsste bei der IOS-App auch so sein, dass man es manuell stoppen muss.
• Inzwischen gibt es ja MPEG-DASH für Live-Streams. Das funktioniert im Prinzip wie HLS und hat somit die selben Nachteile. Außerdem wird es auch nicht von jedem Browser unterstützt

 

Folglich ist Flash die einzige brauchbare Variante, die derzeit noch auf fasst allen Browsern geht (abgesehen von den mobilen Browsern).

Einen anderen Flashplayer ins Webinterface einzubauen, sollte ja kein Problem sein. Möglichst einen ohne Wasserzeichen . Was da aber in Bezug auf Lizenzen beachtet werden muss, kann ich mangels Wissen nicht sagen.

 

Es gibt dann noch paar Dirty-Tricks. Und zwar in einem HTML5 Canvas Element per Javascript-Mpeg-Decoder und Websockets Livestreaming zu realisieren. Aber da hab ich mich noch nicht durch gefrickelt

[Tjod]

H.264 geht inzwischen in eigentlich allen aktuellen Browsern https://html5test.com/compare/feature/video-h264.html

 

Und ein Player unter der MIT Lizenz lässt sich problemlos verwenden.

 

Das heißt mit dem mediaelement Player hätte man zumindest schon mal einen Player ohne Wasserzeichen. Und die bisherigen .flv Streams müssten genau so weiter funktionieren.

 

Aber an das Livstreaming Problem hatte ich nicht gedacht. Hier mal ein Link zum HLS/MPEG-DASHSupport in verschiedenen Browsern.

https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/Live_streaming_web_audio_and_video#Streaming_File_Format_Support

 

Dafür müsste man aber wahrscheinlich nach einem andern Player suchen. Und auch die Streaming Anpassungen sind da schwieriger.

[Tjod]

Eventuell wäre video.js dann eine bessere Wahl.

http://www.videojs.com/

https://github.com/videojs/video.js

Die Apache License ist denke ich auch unproblematisch.

 

Und der ist über Erweiterungen HLS und DASH fähig.

https://github.com/Dash-Industry-Forum/dash.js/tree/v1.2.0/contrib/videojs

https://github.com/videojs/videojs-contrib-hls

 

Auch wenn erst mal der Player ausgetauscht werden muss und man dann gucken kann was sich beim streaming Format machen lässt.

[Nanohcv]

Ich werde mal mit dem videojs ein wenig rumspielen. Mal sehen ob der geeignet ist.

[Tjod]

Also in einem ersten Test mit fester URL geht es schon mal.

<video id="player" class="video-js vjs-default-skin" controls preload="auto" autoplay width="460" height="280" data-setup="{}">
<source src="flashstream/stream.flv?Preset=2&aspect=16:9&ffPreset=medium&maxwidth=&maxheight=&chid=0" type='video/flv' />
</video>

 

Aber {sourceipenc} liefert bei mir die URL Encoded, was der Player nicht mag.

Das habe ich auf die schnelle noch nicht hin bekommen und für das Sender wechsle ist auch noch mehr nötig.

 

Und ob das 10 Sek. vor Puffern was derzeit gemacht wird damit möglich ist weiß ich auch noch nicht.

 

Und wenn ist HLS als zukünftiges Format wohl realistischer. Das kann der RS schon für iOS (ffmpeg kümmert sich um den ts Stream und der RS um den rest) inzwischen könnte das ffmpeg aber glaube ich auch komplett.

MPEG-DASH kann derzeit weder ffmpeg derzeit erzeugen noch der RS.

Das heißt nur mit Safari auf OS X und mit Microsoft Edge geht dass dann ohne Flash (für die Mobilen Geräte ist das Webinterface derzeit nicht wirklich geeignet )

[Nanohcv]

So klappt es auch mit {sourceipenc} (geht bestimmt auch schöner/besser):

<video id="player" class="video-js vjs-default-skin" controls preload="auto" autoplay width="460" height="280" data-setup="{}">
<script>document.write('<source src="' + decodeURIComponent('{sourceipenc}') +'" type=\'video/flv\' />')</script>

</video>

 

 

Mir kommt es bei diesem Player aber so vor, dass es mit Vollbildmodus leicht ruckelt.

 

Für den Senderwechsel und für das transcodierte Streamen von Aufnahmen ist noch einiges an Javascript-Arbeit nötig.

 

So wie es aussieht tut sich was bei ffmpeg in Bezug auf MPEG-DASH. Im Changelog steht jedenfalls, dass seit Version 2.5 ein MPEG-DASH Segmenter dabei ist.

Was die optimale Lösung für die Zukunft ist, weiß ich nicht.

Ich vermute mal, dass sich Apple schwer tun wird, Dash zu unterstützen.

Dageg wird HLS ja inzwischen auch von mehr und mehr Browsern unterstützt. Android kann es inzwischen auch.

[Tjod]

ffmpeg kann im Bezug auf MPEG-DASH nach allem was ich gefunden habe nur teile. Das heißt man braucht wenn noch weitere Tools um alles nötige zu erstellen.

 

Und das mit dem Ruckeln habe ich auch hin und wieder keine Ahnung ob das am fehlenden Puffern liegt oder an andern Problemen.

 

Eventuell muss man auch weiter gucken. Die Player waren nu die ersten die in Fragekommen können.

[loretta80]

kann eigentlich anstatt ffmpeg auch ein GPU basierender Encoder genutzt werden? Habe eine nvidia und somit würde sich doch nvenc aus CUDA anbieten oder?

Evtl. auch auf H265 zu encodieren?

Edited August 22, 2015 by loretta80

[Tjod]

Zu CUDA habe ich nichts gesehen, keine Ahnung was man da Lizenz mäsig braucht um drauf zu zu greifen. Zumindest unter Linux sollte mit Intel QSV-accelerated, VAAPI und VDPAU was möglich sein.

https://raw.githubusercontent.com/FFmpeg/FFmpeg/release/2.8/Changelog

 

Nachtrag: Da wird alles zu FFMpeg und Hardware Unterstützung erklärt https://trac.ffmpeg.org/wiki/HWAccelIntro

 

Eigentlich schreibe ich hier weil wir Grade intern die Probleme von HLS (und MPEG-DASH) im Bezug auf den RS hatte.

 

Da der RS ja in der Regel erst anfängt einen Sender zu streamen wenn der eingestellt wird hat man mit den Formaten sehr lange umschalte Zeiten.

 

Da der RS erst mal 1-2 Sek. braucht biss er er Daten von der TV Karte bekommt die er weiterreichen kann. Und dann brauchen die auch noch 1-2 Sek. biss die aus ffmpeg raus kommen.

Und jetzt müssen bei HLS noch drei Segmente a 15 Sek. erstellt werden bevor es zum Client geschikt werden kann. Das heißt es müssen noch 15 Sek. gewartet werden.

 

Das ist ein Problem was es nur bei Live TV gibt. Bei der Datei wiedergebe muss man nicht 15 Sek. warten um die ersten drei Segmente zu erstellen. Da man die Datei ja deutlich schneller einlesen kann.

 

Und wer mit anderen Formaten experimentieren will hat ja seit RS 1.31 eine Möglichkeit hinzu bekommen

http://www.DVBViewer.tv/forum/topic/19628-recording-service-beta/?p=431017

 

http://127.0.0.1:8089/transcodedchannels.m3u?tvpreset=WP%201536%20kbit&rpreset=WP%20audio%20128%20kbit&keepres=hv

Edited September 23, 2015 by Tjod

[Griga]

Ich habe mal etwas in Richtung Recording Service & HTML 5 Video geforscht.

 

- MP4 kann man für Live Streams vergessen. Das ist halt ein Dateiformat. FFmpeg will das nicht mal in die Pipe schreiben: "muxer does not support non seekable output".

 

- WebM- und Ogg-Streaming lassen sich bereits mit dem aktuellen RS Release 1.31 realisieren. Für Tests habe ich die aktuelle 64-Bit-Version von FFmpeg verwendet. Man ergänze die folgenden Presets in der ffmpegprefs.ini:

 

 

 

[WebM 2000 kbit]
Cmd=-analyzeduration 1M -threads {threads} {offset} {realtime} -i "{infile}" -threads {threads} -f webm -vcodec libvpx -quality realtime -bufsize 1024k -b:v 1500k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -acodec libvorbis -ab 128k -ar 44100 -ac 2 -async 1 -y "{outfile}"
maxWidth=720
maxHeight=576
MimeType=video/webm
Ext=.webm

 

[Ogg 2000 kbit]
Cmd=-analyzeduration 1M -threads {threads} {offset} {realtime} -i "{infile}" -threads {threads} -f ogg -vcodec libtheora -bufsize 1024k -b:v 1500k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -acodec libvorbis -ab 128k -ar 44100 -ac 2 -async 1 -y "{outfile}"
maxWidth=720
maxHeight=576
MimeType=video/ogg
Ext=.ogv

 

 

 

Anschließend den Service stoppen / starten und in Firefox oder Chrome eine URL der folgenden Machart eingeben:

 

WebM: http://127.0.0.1:8089/flashstream/stream.webm?Preset=WebM%202000%20kbit&chid=0

 

Ogg: http://127.0.0.1:8089/flashstream/stream.ogv?Preset=Ogg%202000%20kbit&chid=0

 

Die Browser spielen dann den ersten Sender (Nummer 0) aus der Senderliste direkt ab. Bei Ogg in Firefox kann es eventuell passieren, dass es kräftig ruckelt. Das behebt ein kleiner Rückwärtssprung mit dem Slider oder ein Klick auf Pause/Play. Zukünftige RS-Versionen können das verhindern, indem sie anfangs zwei Sekunden lang Daten puffern.

 

Der Internet Explorer spielt ab Version 9 WebM ab. Allerdings nur, wenn man vorher eine Erweiterung installiert und die URL in eine HTML-Seite einbettet (kann ich bei Bedarf genauer erläutern). Bei einem Test unter Android lief Ogg in Firefox, nicht in Chrome. WebM lief in FireFox und Chrome. Opera soll das angeblich auch können. Richtig außen vor bleibt nur Safari. Das hat Apple dann davon

 

Apropos Safari: Zukünftige RS-Versionen werden eine verbesserte HLS-Unterstützung bieten, u.a. HLS Live Streams über eine URL (bisher geht es nur mit einer App als Vermittler). Die von Tjod angesprochene Problematik lässt sich nicht vermeiden, aber deutlich lindern. Davon wird auch Markus' iOS-App profitieren. Inzwischen funktioniert HLS über eine master.m3u8 URL mit diversen Clients bestens (VLC, Android Video Player, LAV Sourcefilter, DVBViewer GE, TransEdit). Nur bei Safari unter OS-X hakt es. Bislang scheint die einzig sichere Lösung zu sein, dass der Browser die URL erst zu sehen bekommt, wenn der RS ein paar Segmente angesammelt hat, was wieder eine App als Vermittler braucht. Der Browser ist sowas von pingelig... das hat Apple dann davon

[Nanohcv]

Lang lebe Flash

Ähm nein

 

WebM klingt gut. Auch der neue Browser von MS (Edge) soll Webm in Zukunft unterstützen.

 

Wie läuft das den in den zukünftigen RS Version mit HLS. Wenn ein Client einen Stream anschaut und dann die Verbindung zusammenbricht (oder den Browser einfacht schließt), rödelt ffmpeg dann weiter und der RS produziert weiter die Segmente? Man muss doch sicherlich die Streams manuell stoppen oder? Wüsste nicht wie man das sonst machen soll.

[Griga]

Wie läuft das den in den zukünftigen RS Version mit HLS. Wenn ein Client einen Stream anschaut und dann die Verbindung zusammenbricht (oder den Browser einfacht schließt)

 

Ich habe im Konverter-Objekt einen RefCount eingerichtet. Wenn keine Verbindung mehr das Objekt referenziert, wird es nach einem Timeout abgeräumt. Ein Timeout ist nötig, weil manche Clients für jede verdammte Playliste und jedes verdammte einzelne Segment eine neue Verbindung aufbauen und wieder beenden. Die haben offenbar noch nie was von HTML 1.1 bzw. Connection: keep-alive gehört. So kann es passieren, dass beim Streamen zeitweise überhaupt keine Verbindung den Konverter referenziert. Besonders der VLC und der LAV Sourcefilter tun sich in der Hinsicht unrühmlich hervor. IMO ist der DVBViewer GE sowieso der einzig wirklich brauchbare HLS Client

 

Es wird im RS auch die Möglichkeit geben, über das API einen permanenten HLS Stream verfügbar zu machen, der nicht von bestehenden Verbindungen abhängt. Allerdings muss der dann auch über das API gestoppt werden. Ich hoffe, dass Safari zumindest damit funktioniert. Bislang hat sich allerdings niemand bequemt, das zu testen Ich habe keine Apple-Hardware zur Hand, und Safari unter Windows kann kein HLS.

[Griga]

P.S. @Nanohcv: Wo wir uns gerade hier treffen - in der nächsten RS Version wird mit Sicherheit die Versionsnummer der ffmpegprefs.ini erhöht, d.h. sie ersetzt dann die vorhandene Version (die in .bak umbennant wird). Das wäre die Gelegenheit, andere / zusätzliche Presets für das Windows Phone zu integrieren. Also falls es in der Hinischt Bedarf gibt, sollten wir darüber kommunizieren...

[Nanohcv]

Also die drei die es jetzt gibt, reichen mir. Bei mir sind auch keine Wünsche eingegangen.

Grundsätzlich funktionieren aber alle, die h264 ts Streams erzeugen.

 

Edit:

Schön wäre es, wenn die bestehenden an gleicher Position bleiben. Da ich die (noch und historisch bedingt) über den Index anspreche und die User sonst nach dem RS Update die Presets neu auswählen müssten.

Edited October 11, 2015 by Nanohcv

[Griga]

Ok, aber auf den Zugriff per Index solltest du dich in Zukunft möglichst nicht mehr verlassen.

 

Nach Betrachtung der durch den [WP 768 kbit] erzeugten Bildverstümmelung in TransEdit habe ich die Parameter übrigens etwas angepasst - insbesondere die maximale Auflösung auf 512 x 288.

[Nanohcv]

Ja das mit dem Index lässt sich leicht ändern. Ich nehme mal an das der neue RS nicht schon morgen kommt

 

Danke für die Anpassung. Die Presets waren ursprünglich Flash-Presets und stammen noch von Lars. Hab nur den Container, MimeType usw. angepasst.

[epsy]

Ich habe mal eine Zeit lang mit dem internen Segmenter von FFmpeg experimentiert:

 

[Medium HLS 1024 kbit]
Cmd=-threads {threads} {offset} -i "{infile}" -threads {threads} -f segment -vcodec libx264 -crf 22 -maxrate 900k {framerate} -map 0:0 -map 0:1 -deinterlace -vf "scale={scalex}:{scaley}" -preset fast -tune film -vprofile main -level 30 -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -flags -global_header -segment_format mpegts -hls_wrap 6 -segment_list list.m3u8 -segment_time 10 segment-%03d.ts
maxWidth_IPhone=640
maxHeight_IPhone=480
maxWidth_IPad=800
maxHeight_IPad=640

Das Problem war nur, dass die Stream-Dateien (segment-xxx.ts), wie auch die m3u8-Datei (list.m3u8) im Hauptverzeichnis vom DVBViewer abgelegt werden!

 

Mit einem kleinen Webserver (HFS) habe ich dieses Verzeichnis freigegeben.

Habe das allerdings nicht für das RS Webinterface Streaming genutzt, sondern zwecks Nutzung für's iPhone! Damals schmierte der HLS-Stream recht schnell ab.

 

 

Zwei Dinge:

• mit einem externen Webserver legt man das Verzeichnis vom DVBViewer frei!! Eine sehr große Sicherheitslücke!!! Vor allem, wenn man den Port im Router auch für außerhalb öffnet. Habe den Port mit der Fritzbox von 80 auf irgendeinen anderen Port gelegt. Dennoch unsicher!
• Habe das nur für's iPhone genutzt. Der interne Segmenter von FFmpeg hat allerdings sehr gut funktioniert! Möglicherweise kann das jemand in diesem Zusammenhang sinnvoll nutzen.

 

Übrigens, meine Erfahrung mit WebM waren sehr bescheiden. Die Bildqualität ließ doch sehr zu wünschen übrig!

Edited October 12, 2015 by epsy

[Moses]

Wenn du statt einfach nur den Dateinamen in der Kommandozeile ganze Pfade angibst, oder zumindest einen Unterordner davor, dann landen die Dateien auch woanders und du hast nicht so viele Probleme mit der Freigabe.

[epsy]

Ich hatte damit einige Zeit experimentiert und war froh als es lief. Das war Februar 2013. Dort hatte ich mich mit dem leider verstorbenen Lars_MQ ausgetauscht. Er hat diese Lösung allerdings abgelehnt, da der ffmpeg Segmenter auf "echte" Dateien basiert, was nicht wirklich akzeptabel sei, da ständig die Festplatte angesprochen wird und die gesamte Verwaltung aufwendiger wäre. Davon abgesehen muxt FFmpeg (angeblich) den TS stream mit unnötigen zusätzlichen Daten (SDT etc).

 

In Zeiten von SSD wäre zumindest das Thema mit echten Dateien vom Tisch. Sollte auch nur als Anreiz dienen. Möglicherweise hat ja jemand Lust aufgrund meiner gemachten Erfahrung hier weiter zu machen, bzw. hilft der Ansatz in dem ein oder anderen Fall.

 

Im übrigen meine ich mich erinnern zu können, dass die Pfadangabe ein Problem darstellte. Bin mir aber nicht ganz sicher.

[RobertSmith]

P.S. @Nanohcv: Wo wir uns gerade hier treffen - in der nächsten RS Version wird mit Sicherheit die Versionsnummer der ffmpegprefs.ini erhöht, d.h. sie ersetzt dann die vorhandene Version (die in .bak umbennant wird). Das wäre die Gelegenheit, andere / zusätzliche Presets für das Windows Phone zu integrieren. Also falls es in der Hinischt Bedarf gibt, sollten wir darüber kommunizieren...

Hallo,

 

dazu würde ich gerne einen Vorschlag machen:

ersetzt den aktuell verwendeten ABR Modus "-bufsize 1024k -b:v 4250k -bt 4500k" (-bt gibt es für libx264 gar nicht mehr).

 

Die FFmpeg Entwicklern empfehlen den qualitätsbasierten Modus mit Bitratebeschränkung für Streaming.

"-bufsize 9000k -maxrate 4500k -crf 20" (bufsize definiert die Puffergröße (maxrate * Sekunden), der crf Wert definiert die gewünschte Qualität und wird, wenn die Bitrate nicht ausreicht automatisch nach oben hin angepasst)

In meinen Tests sind die Ergebnisse damit besser.

 

Weitere Ideen:

• Die Bildqualität der Presets [Low*] kann man steigern, wenn man die Framerate um 1/5 auf 20 fps reduziert.
• Wenn die vertikale Auflösung des Ziels um mehr als die Hälfte kleiner ist als das Original, spart man sehr viel Rechenleistung und erhält ein schärferes Bild mit dem Filter "field" statt "yadif".

  (Verwendet einfach jedes 2. Halbbild, spart das Deinterlacing)

• Ton: AAC liefert bei gleicher Kompatibilität bessere Ergebnisse als MP3, bei Profilen mit geringen Bitraten ist Mono ausreichend.
• Profile Main und Level 3.1 wird mittlerweile von nahezu allen Geräten unterstützt

Edited October 14, 2015 by RobertSmith

[dkdvb]

Oh, hallo, es tut sich was ... Was ich nicht verstehe, ist, dass Ihr weitermacht, wie bisher. Mauern, nicht offen sein, Spezialitäten basteln. ;-)

 

1. In einer App kann man beliebige Befehle koppeln, d.h. z.B. Fenster schließen = senden, dass der Stream nicht mehr benötigt wird. Das funktioniert prinzipiell immer, solange die App nicht abstürzt. In einem Browserfenster kann man die Funktion auch festlegen.

 

2. Warum wollt ihr denn die .prefs partout hart eincodieren? Lasst den Rechner doch rechnen. Dafür ist er da.

 

3. Warum fragt ihr nicht ab, was der Browser unterstützt, und liefert das dann einfach.

 

4. Soweit ich weiß, liefert der Recording Service viel mehr Möglichkeiten, als wirklich nötig. Das ist für Programmierer toll, aber für normale Nutzer einfach schlimm zu konfigurieren. Also: ein Spielzeug für Programmierer oder ein Produkt?

 

5. Warum möchtet ihr den Player mitliefern? Fragt doch den Client erstmal, was da ist und lasst das Programm entsprechend liefern ...

 

Damit ihr nicht glaubt, dass ich euch (nur) trollen möchte, frage ich, was ich wissen müsste, um mir ernsthafte Gedanken zu machen.

 

- Was soll der Recording Service können? Audio, Video, + Livestreaming? - Ja, ne?

- Was genau liefert der Recording Service? Audio? Video? Text? XML? >>> Daten ..., aber was für welche?

 

Ich hab jetzt einige Vorschläge gemacht, einen Fred gestartet, und bisher nur "ja aber" zu hören bekommen ... Mal Butter bei die Fische, und ich helfe Euch wirklich bei der Problemlösung ...

 

Wenn ihr einfach hobbymäßig auschecken wollt, was noch alles möglich ist, machts ohne mich, bitte.

 

-Ironie an- Man kann die Knöppe bestimmt auch blinken lassen oder Seitenverhältnisse 1/pi ausprobieren ... Dann baut aber bitte ein sehr großes Schild "Spielwiese für große Jungs" auf, damit auch wirklich niemand meint, es läge an ihm selbst, wenn's mal nicht klappt. -Ironie aus-

 

Und nein, ich möchte niemands Andenken beschädigen, (bin halt jetzt erst eingestiegen), ich mag Leute, die programmieren, weil sie gerne programmieren ...

 

Und es geht mir um die Sache. Ich weiß, dass das Projekt grade falsch aufgestellt ist, und würde gerne beitragen. Verzeiht mir bitte den Ton, manchmal :-)

[dkdvb]

Ähm, und auch wenn ihr mich für bekloppt haltet, aber ich möchte Punkt 2 von oben noch konkretisieren:

 

Welchen Sinn macht es überhaupt, "händische" Auflösungen anzubieten? Für normale User: Keinen.

 

Es ist nie sinnvoll, eine Auflösung zu streamen, die größer ist, als das Original.

 

Es ist nie sinnvoll, mehr Daten zu streamen, als die Verbindung hergibt. Es gilt höchstens das Gegenteil, nämlich das man evtl. ein bisschen freie Bandbreite behalten möchte.

 

Es ist nie sinnvoll, ein Video in schlechterer Qualität zu gucken, als möglich ist.

 

Es gibt deshalb eigentlich nur eine "richtige" Streamingqualität (+ natürlich Spezialfall-Expertengedöns), die sich idealerweise zwischendurch immer wieder nachjustiert.

 

Das gleiche gilt für Audio, Games, wasauchimmer.

 

Erfahrungsgemäß ist es für Menschen schwer, die erforderliche Balance abzuschätzen ... Also lasst die Computer was aushandeln ...

Und kommt mir jetzt nicht damit, dass einige bei einem Film lieber HD-Audio und andere eher HD-Video hätten ...

 

Das wäre mal ein konkreter Algorithmus, den man schreiben könnte.

Edited October 14, 2015 by dkdvb

[Griga]

Übrigens, meine Erfahrung mit WebM waren sehr bescheiden. Die Bildqualität ließ doch sehr zu wünschen übrig!

 

WebM ist nicht gleich WebM. Es kommt auf den Codec an und wie man ihn konfiguriert. Theora ist nach meinen Erfahrungen wirklich nicht so berühmt, aber der von Google gepushte VP8 erreicht IMO zumindest H.264 Baseline. Allerdings habe ich in der Hinsicht keine präzisen Messungen durchgeführt, sondern gehe nach dem subjektiven Bildeindruck.

 

ersetzt den aktuell verwendeten ABR Modus "-bufsize 1024k -b:v 4250k -bt 4500k" (-bt gibt es für libx264 gar nicht mehr).

 

Diese Flash Presets stammen nicht von mir. Ich halte sie auch für renovierungsbedürftig, aber bei Änderungen bin ich prinzipiell vorsichtig . Was für den einen richtig ist, findet der andere falsch. Every Change breaks someone's workflow - und wer sich wie du etwas auskennt, kann ja die Presets in den Konfigurationsdateien selbst anpassen. -bt habe ich schon vor ein paar Tagen rausgeworfen.

 

Die Bildqualität der Presets [Low*] kann man steigern, wenn man die Framerate um 1/5 auf 20 fps reduziert.

 

Ist mir bekannt. Ich habe mal Internet HLS-Streams mit 15 fps gesehen und bin zu dem Ergebnis gekommen, dass ich lieber ein paar Blockartefakte in Kauf nehme.

 

Wenn die vertikale Auflösung des Ziels um mehr als die Hälfte kleiner ist als das Original, spart man sehr viel Rechenleistung und erhält ein schärferes Bild mit dem Filter "field" statt "yadif".

 

Ich werde CiNcH darauf aufmerksam machen - das ist sein Spezialgebiet. Er hatte letztlich schon eine neue Yadif-Konfiguration vorgeschlagen, die unnötiges Deinterlacing vermeidet und übernommen wurde. Ein Problem ist, dass der Recording Service die Auflösung des Quellmaterials nicht kennt (bzw. es würde die Zeit bis zum Wiedergabestart deutlich verlängern, wenn er sie ermitteln würde). Er kann also die Kommandozeile nicht entsprechend frisieren. Allerdings kennt FFmpeg die Quellauflösung - sie steht in Variablen zur Verfügung (iw und ih = Input Width / Input Height), die sich in Ausdrücken innerhalb der Kommandozeile verwenden lassen, die zur Laufzeit berechnet werden. Außerdem gibt es ow und oh = Output Width / Height. Womöglich lässt sich damit was anfangen?

 

Ton: AAC liefert bei gleicher Kompatibilität bessere Ergebnisse als MP3, bei Profilen mit geringen Bitraten ist Mono ausreichend.

 

Der interne AAC Codec läuft bei FFmpeg immer noch unter "strictly experimental", und die Macher sind selbst nicht so ganz von seiner Qualität überzeugt (siehe hier). Die höherwertigen AAC Codecs dürfen aus Lizenzgründen nicht in Binaries enthalten sein. Nichtsdestotrotz werden FFmpeg-Presets mit dem "native FFmpeg AAC Encoder" intern getestet. Bislang waren keine großen Nachteile sichtbar, aber auch keine großen Vorteile. Im Zweifelsfall bleibt es erst mal bei MP3.

 

Profile Main und Level 3.1 wird mittlerweile von nahezu allen Geräten unterstützt

 

Die Presets mit höherer Auflösung wurden inzwischen gemäß einem Vorschlag von CiNcH auf Main Profile umgestellt.

 

Danke jedenfalls für die Anregungen

 

@dkdvb: Deine Posts verstehe ich zum größten Teil nicht, bzw. ich kann damit nichts anfangen. IMO tragen die sehr allgemein gehaltenen Äußerungen hier nichts konkret Verwertbares bei. Ich werde deshalb nicht weiter darauf eingehen.

[dkdvb]

@Griga: Ich schlage ja auch etwas Allgemeines vor. Ihr experimentiert mit Auflösungen, ganz konkret. Mit Codecs, ganz konkret. Gut, dass ihr Euch die Arbeit macht. Ihr experimentiert darüber, was die Software kann. Wozu Presets, frage ich nochmal?

 

Wenn nach Euren Reihentests dann im Interface wieder Knöpfe zu sehen sind, mit denen man zwischen Pest und Cholera wählen kann, anstatt dass man die Maschinen den "objektiv" besten Handschlag machen lässt, hast du nix verstanden, von dem was ich gesagt habe.

 

Ihr steckt schon so tief drin, dass ihr blind seid, scheint mir. Wen kümmert Rechenleistung? Wen kümmern ein paar Sekunden eher oder später Bild, wenns dafür dann mal 2 Stunden ohne Ruckeln funktioniert?

 

Denk doch mal an den ganz normalen User, der ein angenehmes Erlebnis haben möchte, ohne CODEC und Gefrickel. Stell dir vor, du drückst auf nen Knopf, und dann erscheint das technisch beste mögliche Bild ;-)

 

Ganz oben ^^^ Wird auch das Interface - die GUI noch erwähnt ...

 

Also, wozu brauchst du Presets? Wenn du mir jetzt sagst: Damit das Programm Alternativen hat, aus denen es wählen kann, bin ich froh.

 

Ich hab mitbekommen, dass du hier wer bist, also bitte: antworte oder sag explizit "verzieh dich", dann bin ich weg.

Vielleicht seid ihr über den Schritt ja schon längst hinaus, dann solltest du aber verstehen, was ich meine ... ;-)

Edited October 14, 2015 by dkdvb

[nuts]

Verstehe deine Posts auch nicht.

Jeder Streamingdienst bietet verschiedene Qualitätsstufen an und das ist über presets doch vernünftig?

Irgendwo muss das doch hinterlegt werden?

Wenn du einen allgemeingültigen Algo hast, der das überflüssig macht, kannst du den ja mal vorstellen ...

[dkdvb]

Ich bin mir sicher, dass ich Euren Widerstand an diesem Punkt nicht verstehe. Welchen Grund sollte es geben, sich Medien in schlechterer Qualität anzutun, als möglich ist?

 

Es gibt vielleicht einen: Kosten im Mobilfunknetz, wenn überhaupt. Dann würde ich aber eine Netzauswahl anbieten, und keine Auswahl der Medienqualität.

 

Was soll allgemeingültig heißen? Die Qualität des Ausgangsmaterials ist bekannt, sonst kann nicht recodiert werden, die Bildschirm-/Fenstergröße der Ausgabe lässt sich ermitteln, bleibt noch das Problem der Verbindung. Die Geschwindigkeit lässt sich messen, evtl. abfragen. Wir möchten keine Artefakte sehen oder hören. Ergibt in Abwägung eine "objektiv" beste Codierung für den Stream. Details legt der Programmierer fest. <<< Bitteschön, in Pseudocode.

 

Dass youtube HD-Videos meist nur auf Anfrage streamt, liegt wohl an den Kosten, die das für die produziert. Und die "illegalen" Streamer wollen halt auch ihre Mark machen ... ;-)

Edited October 14, 2015 by dkdvb

[nuts]

Es gibt doch unterschiedlichste Anwendungsbereiche?

WLAN extern (Hotel/Arbeit), LAN intern, WLAN intern, Mobilfunktnetz usw.

 

Nebenbei läuft der Recordingservice auch auf unterschiedlicher Hardware und ffmpeg benötigt je nach Einstellungen mehr oder weniger Rechenleistung. Was auf dem einen PC läuft ist für den anderen PC zu viel.

Das alles objektiv zu messen dürfte unmöglich sein.

 

Man kann versuchen die gelieferten Presets so zu wählen, dass es für die meisten Bereiche passt und das wird ja auch gemacht.

Edited October 15, 2015 by nuts

[dkdvb]

Und genau da liegt die Chance bzw. der Charme meiner Lösung!

 

Durch die Fülle der möglichen Konfigurationen ist es sinnvoll, programmiererisch einen Rahmen vorzugeben, und den Rest die Software ausrechnen zu lassen. Mit fünf oder so Konfigurationen bildest du nie alle Fälle ab. Wenn du aber die sinnvollen Grenzen festlegst, und dann das Programm entscheiden lässt ...

 

Was nämlich stimmt ist, dass du zur Laufzeit wie die meisten von uns nicht die erforderlichen Berechnungen vornehmen kannst. Und grobes Schätzen ist suboptimal.

 

Genau für diese Art von Problemlösungen sind Computer aber entwickelt worden: mehrere veränderliche Parameter >>> eine "richtige" Lösung ... Die können nix, aber das können sie richtig.

 

Das ich jetzt so auf dem "einen" richtigen Streaming rumreite setzt die Prämisse voraus, dass wir alle unsere Medien in bestmöglicher Qualität genießen möchten, und was bestmöglich ist, gibt einerseits unsere Wahrnehmung und programmatisch der oben genannte Rahmen vor.

 

Ich möchte nochmal auf die User verweisen. Was brauche ich als User? Wenn ich z.B. Live-TV streamen möchte, brauche ich sowas wie die EPG-Timeline zum Wählen (evtl. einen Knopf aufnehmen) und den Knopf "Jetzt wiedergeben". Wenn ich dann das bestmögliche Bild stabil bekomme, interessiert mich doch das ganze Gefrickel nicht ...

Stop-Knopf.

 

Und danke, ja es gibt den Punkt Rechenleistung für die Codierung auf dem Server, den ich noch nicht als Parameter bedacht habe. Alle Parameter, die wir nun aufgezählt haben, sind aber zugänglich.

 

Man könnte, das habe ich schon einmal geschrieben, auch an zwei Oberflächen denken: völlige Freigabe der Parameter durch Freihand-Texteingabe für Profis und automatische Auswahl für normale Menschen wie mich ;-)

Edited October 15, 2015 by dkdvb

[Derrick]

..schöner ansatz, der wohl wenig gehör finden wird. Ich lass das lieber gleich ganz, denn langes gefrickel mit presets, die bei der nächsten gelegenheit wieder überholt sind, ist nicht meine sache Streamen vom eigenen server übers internet zu einem handy ist imho sowieso abartig. Zu hause im wlan mache ich es allerdings auch und da reicht mir SD, was meist prima läuft. Smart TV etc. sind drahtgebunden, sodass sich die eindampferei inkl. UHD erübrigt

[nuts]

Mit allgemeinen Ratschlägen wie ein Computer funktioniert hilfst du wenig ...

 

Wie ermittelst du den "richtigen" Stream für einen Client der mal extern über das Mobilfunktnetz, extern über WLAN (mal schnell / mal langsam je nach Hotspot) und intern über WLAN zugreift? Zur Laufzeit Geschwindigkeitsmessungen machen und raten? Und wenn es schief geht Pech gehabt?

Derzeit kann man über Presets wählen und so die äußeren Umstände berücksichtigen. Das ist imho die beste und einfachste Möglichkeit.

 

Und selbst bei konstanter Geschwindigkeit der Anbindung ist "bestmögliche" Bildqualität äußert subjektiv.

Man kann z.B. die framerate senken oder die Bitrate. Was ist besser? Hatten wir intern auch gerade "Streit" darüber.

[epsy]

Ich fand die Auswahl auch immer sehr bescheiden und habe in der ffmpegprefs.ini nur 3 Bandbreiten zur Auswahl gestellt.

die mitgelieferte Konfigurationsauswahl empfand ich schon immer als sehr unglücklich... Seitenverhältnis, Videobitrate, FFmpeg Voreinstellung, Vorlauf...

Meiner Frau bräuchte ich nicht erklären was sie einstellen müsste um Live-TV zu schauen.

 

Daher habe ich das für mich mal so optimiert. Leider läuft diese Version mit als Web-App mit iOS9 nicht mehr.

 

 

 

Je nach Verzeichnis in zwei Versionen:

- War ich im Verzeichnis Live-TV, wurde ein Pre-Load-Video gestreamt, dass ein Rückwärtszähler von 20 auf 0 zeigte. Danach folgte Live-TV.

- Habe ich eine Aufnahme bzw. einen Film ausgewählt, wurde nach dieser Auswahl ein Video ohne Pre-Load-Video angezeigt.

 

Eine Automatik verbunden mit einer manuellen Auswahl fände ich am besten. Wenn ich unterwegs mir etwas anschauen möchte und streame mit 600kBit/s, dann sind das in 60 Minuten auch über 250 Megabyte an Daten, bei meinen Voreingestellten 1800kBit/s sogar fast 800 Megabyte! Noch ist Traffic außerhalb des WLANs relativ teuer.

 

- Seitenverhältnis (bringt doch eh nichts was ich da einstelle oder? ich sehe keine Veränderung),

- FFmpeg Voreinstellung (das könnte man doch auch in den Einstellungen hinterlegen und muss das nicht immer wieder zur Auswahl stellen. Je nach CPU)

- Vorlauf (könnte man doch auch fest in den Einstellungen hinterlegen. Und warum wird bei Aufnahmen und Videos das zur Verfügung gestellt?)

 

Das sind doch Dinge die ich schon für mich mal geändert habe. Habe meinen HTML-Code ja auch mal jemanden hier vom Team zur Verfügung gestellt. Hat man nichts daraus gemacht... Schade

Edited October 15, 2015 by epsy

[Nanohcv]

Ich finde viele Einstellungen schaden nicht unbedingt. Man sollte für den User halt eine vernünftige Vorauswahl treffen, dass dieser i.d.R. an den Einstellungen nichts ändern braucht, er es aber kann. Nichts ist schlimmer als wenn ich bevormundet werde. Ein Firma ist ja dafür bekannt

 

Klar eine Bandbreitenerkennung fände ich auch toll, aber sowas hat auch Nachteile -> Es dauert wieder länger bis es los geht.

[nuts]

Beim Streaming über die Webseite sehe ich folgende Einstellungen:

 

Vorgabe: Low / Medium / High usw. also Bitrate

Die werden ja wohl gebraucht und müssen schon vom Benutzer mit Sinn und Verstand gesetzt werden. Bandbreitenerkennung gibt es schließlich nicht und ist imho auch kaum sinnvoll zu realisieren ...

Ob man soviele verschiedene Presets per Default anbieten sollte? Ist vielleicht ein Punkt ...

 

Seitenverhältnis: Nicht so sicher ob die sinnvoll ist.

 

Voreinstellung: Finde ich nicht unnötig nochmal zur Quelle zu unterscheiden. Was etwas blöd dabei ist: Man kann den Default nicht global vorgeben oder? Meint ihr das vielleicht?

Bei SD und HD Quelle können je nach Hardware aber schon unterschiedliche Voreinstellungen sinnvoll sein ... wollt ihr das wirklich entfernen?

Der RS hat übrigens nicht besonders viele Informationen über die Quelle. Zumindest nicht beim Livestreaming ...

 

Breite / Höhe: Schadet das?

[Griga]

Seitenverhältnis: Nicht so sicher ob die sinnvoll ist.

 

Die Einstellung ist sowieso grob irreführend. Sie hat überhaupt nichts mit dem Seitenverhältnis zu tun. Siehe dazu hier:

 

• Ergänzt: Transkodiertes Streaming: Zusätzlicher URL-Parameter keepres (keep resolution) für das von FFmpeg ausgegebene Bildformat. Er ersetzt den missverständlichen Parameter aspect (der nicht das Seitenverhältnis des Outputs beeinflusst) und bietet folgende Optionen:

• keepres=h (Standard, entspricht aspect=16:9): Die horizontale Auflösung der Quelle wird beibehalten, sofern nicht durch den Wert MaxWidth aus dem Preset begrenzt, und die vertikale Auflösung gemäß dem ursprünglichen Bildseitenverhältnis so berechnet, dass die Pixel quadratisch sind (nicht-anamorphe Ausgabe). MaxHeight wird ignoriert.

• keepres=v (entspricht aspect=4:3). Die vertikale Auflösung der Quelle wird beibehalten, sofern nicht durch den Wert MaxHeight aus dem Preset begrenzt, und die horizontale Auflösung gemäß dem ursprünglichen Bildseitenverhältnis so berechnet, dass die Pixel quadratisch sind (nicht-anamorphe Ausgabe). MaxWidth wird ignoriert.

• keepres=hv (oder vh): Die horizontale und vertikale Auflösung der Quelle wird beibehalten, sofern nicht durch die Werte MaxWidth und MaxHeight aus dem Preset begrenzt. Das Resultat kann anamorph mit nicht-quadratischen Pixeln sein und erfordert Player-Software auf dem Client, die damit umgehen kann.

Das in den Video-Headern angegebene Quell-Seitenverhältnis wird auf jeden Fall beibehalten. Bei Angabe von keepres wird der alte Parameter aspect ignoriert.

 

 

 

Ich bin auch eher dafür, die Einstellmöglichkeiten im UI bzw. Web Interface zu verringern. IMO besteht da einiger Renovierungsbedarf. Mal sehen, ob sich Markus der Sache annimt - ich bin hinsichtlich HTML und Javascript nicht so talentiert.

[dkdvb]

Naja, man könnte die Verbindungsgeschwindigkeit z.B. über die Unterscheidung interne oder externe IP "raten". Normalerweise sind interne Adressblöcke doch bekannt.

 

Man kann auch messen. Da bin ich im Moment überfragt, wieviel Bandbreite eine permanente Messung selbst verbrauchen würde. Den Datendurchsatz in einem Netzwerk messen ist doch nicht soooooo schwierig?

 

Meine Idee wäre, den Stream-Output zu steigern, bis es zum Fehler kommt oder abzusenken, bis es nicht mehr zum Fehler kommt. (Ist wahrscheinlich besser.) Ob die Verbindung fehlerfrei ist, teilen sich die Partner doch wohl mit ...

Zappen ist übers Netzwerk nicht möglich, wie hier schon oft beschrieben, und man könnte vielleicht die Anlaufzeit nutzen. Einen Teststream senden, der bereits fertig ist, oder so.

So wenig Ruckeln wie im Moment bekommt man damit wohl hin. ;-)

 

Auf jeden Fall wäre die Auswahl der Verbindung die bessere Einstellung, und nicht die Videobitrate. (Kostenfrage wäre dann mitgeklärt.) Ich finds nicht so abwegig, seinen eigenen Stream anzuzapfen auf dem Mobilgerät, wenn man z.B. mit der S-Bahn pendelt oder so ...

 

Bei der Audio-/Video"qualität" allein wäre IMHO immer so nah wie möglich am Original optimal. Und das kann man auch programmieren.

Pseudocode> Source.getProperties() >>> Target.setProperties(). Wo die drei Pfeile stehen: Berechnung unter Berücksichtigung der Möglichkeiten des Ziels (Codec/Browser/Plugins/App/Screensize) und der maximalen Bandbreite.

 

Ich habe immer noch die Frage: Was liefert der Recording Service denn, und in welchem Format?

Edited October 15, 2015 by dkdvb

[MarkusK]

@Griga

Mache ich.

 

Die zukünftige iOS Streamconfig Seite sieht übrigens so aus (siehe Bild). Wahnsinnig kompliziert und alles fest in Stein gemeißelt, damit dann das Geschrei losgeht, wenn es bei vielen nicht läuft (Ironie aus). Das Schlimme daran ist, dass die 1x gewählten Werte gespeichert werden und man nicht jedes Mal neue Bitraten usw. auswählen muss (Ironie).

Edited October 15, 2015 by MarkusK

[dkdvb]

Genau Markus, jetzt nur noch die Knöppe alle weglassen und den Computer mal machen lassen zur Laufzeit. ;-)

 

Ich hab Euch ein gutes Grunddesign geliefert, bitteschön. Dann macht mal, ihr Cracks.

Danke für die konstruktiven Töne.

Knopf aus.

[nuts]

Langsam nervst du.

Geliefert hast du hier gar nix.

Nur undurchführbare Wünsche abgeliefert, die nebenbei deutlich zeigen, dass du dich mit der Materie noch kein bisschen beschäftigt hast.

[dkdvb]

nuts, ich rede von Bandbreite und du unterscheidest internes und externes WLAN ... Halt dich besser zurück. Ich bin wirklich raus, jetzt. Also Danke und tschüss.