RS Webinterface Streaming

[epsy]

cool, besten Dank. Bin allerdings wenige Tage im Urlaub...

mal schauen was in den nächsten Tagen hier noch passiert.

[Griga]

Jetzt weiß ich, wie ich das 400 kbit Preset nenne

 

http://dict.leo.org/ende/index_de.html#/search=poor&searchLoc=0&resultOrder=basic&multiwordShowSingle=on

[RobertSmith]

Zu webm:
Ich hatte mich gewundert, wieso der libvpx-encoder nur einen Prozessorkern verwendet und bin auf diesen Hinweis gestoßen:
Der Encoder übernimmt die "-threads x"-Vorgabe nur, wenn sie direkt hinter "-vcodec libvpx" steht.

 

Ganz am Anfang ("ffmpeg -threads x"), so wie es aktuell in der ffmpegprefs.ini steht, wird es einfach ignoriert!

[Griga]

Ich hatte mich gewundert, wieso der libvpx-encoder nur einen Prozessorkern verwendet

 

Das kann ich nicht bestätigen. Ich habe in letzter Zeit sehr viele Tests durchgeführt und dabei auch die CPU-Last im Auge gehabt. Die Auslastung meiner beiden Kerne war bei WebM mit VP8 und VP9 immer gleichmäßig. Fragt sich, wo der Unterschied liegt. Meine FFmpeg-Version ist zur Zeit 2.8.0 64 Bit vom 11.10.

 

Ogg mit Theora zeigt eine deutlich ungleichmäßige Auslastung. Aber dagegen hilft der obige Hinweis nicht.

[Griga]

Im Anhang eine vorläufige Fassung der ffmpegprefs.ini für das nächste RS Release. Anmerkungen dazu:

 

- Die Flash und TS-Presets sollten auch im aktuellen Release verwendbar sein. Die Webm- und Ogg-Presets enthalten Platzhalter, die erst das neue Release bedienen wird. Dazu gehören -deadline {quality} (kann realtime oder good sein) und -cpu-used {cpu-used} bei WebM, sowie {quality} bei Ogg (wird durch -q plus Wert von 1 bis 10 ersetzt, schaltet in VBR Modus um). Wer hier experimentieren will, muss die Platzhalter selbst bestücken.

 

- Die Ogg Presets dienen nur experimentellen Zwecken und werden wahrscheinlich in der Release-Version rausfliegen, da der Theora Codec deutlich gegen VP8 abfällt. Der einzige für mich sichtbare Vorteil von Ogg ist, dass man bei Live Streams in Firefox zurückspringen kann, so dass man ansatzweise Timeshift hat.

 

- Anregungen / Fixes werden noch angenommen, aber das für alle Streaming-Arten einheitliche Abstufungs- und Benennungs-Schema steht und wird sich nicht mehr groß ändern. Überlegt habe ich, noch ein 960 x 540-Preset für herunterskaliertes HD aufzunehmen. IMO müsste es bei 2400 kbit liegen, um von Wert zu sein. Andererseits möchte ich die Anzahl Presets nicht unnötig aufblähen. Meinungen dazu?

 

- Es kann bis zum Release Änderungen geben, also noch nicht fest darauf bauen, dass jetzt alles so bleibt wie es ist. Diese Fassung dient erst mal App-Entwicklern und Anwendern als Orientierung und Diskussionsgrundlage.

ffmpegprefs.ini

[VinoRosso]

Also bitte die alte API nicht zerstören, ich denke nicht, dass ich zeitlich in der Lage bin noch irgendwas an der Android App zu ändern.

[Nanohcv]

Zumindest deine hart verlinkten Presets musst du ändern. Besser die App liest die über die Api ein

[Griga]

Also bitte die alte API nicht zerstören

 

Was genau meinst du mit "die alte API"?

 

Im API wird sich nichts wesentlich ändern. Dafür jedoch die ffmpegprefs.ini drastisch. Und die "alte Streaming-Methode" über den VLC als Transkodierer wird mit Sicherheit dem Rotstift zum Opfer fallen.

 

Ich weiß nicht, was die Android App macht - kann ich das irgendwo nachlesen?. In Zukunft wird es jedenfalls möglich sein, via Web Interface oder Eingabe einer URL und HTML 5 / WebM einen Stream in Chrome oder Firefox unter Android ohne zusätzlichen Player wiederzugeben (bereits erfolgreich getestet). Trifft sich das / beißt sich das irgendwie?

[koekjuli]

Fragen an die Allgemeinheit: Wer verwendet noch Flash-Streaming mit dem Recording Service? Oder etwas spezieller: Wer verwendet es über das Web Interface? Und wer braucht tatsächlich die 10 Qualitäts / Bitraten / Auflösungs-Abstufungen in der ffmpegprefs.ini?

 

- Müssen es wirklich standardmäßig 10 Flash Presets sein? IMO würden (wenn überhaupt) 4 reichen, z.B. 4000 / 2000 / 1000 / 500 kbit/s. Das sind die Abstufungen, die ich für WebM eingerichtet habe. Die Folge wäre allerdings, dass Nanohcv in seiner Windows Phone App die Presets zukünftig über ihren Namen referenzieren muss, nicht mehr wie bisher über den Index, denn wenn ich 6 Presets rauswerfe, verschieben sich die Nummern,

 

- Muss Flash noch im Web Interface via Flowplayer angeboten werden, oder können wir das komplett eliminieren und nur noch auf WebM setzen

 

Hallo Griga,

 

zu deiner ersten Frage:

Ich verwende den Recording-Service hauptsächlich zum Verteilen der EPG-Informationen an meine Clients, sowie zum Aufnehmen von TV-Programmen und als RTSP-Server.

Das Web-Interface selber verwende ich eigentlich nur noch, um mal in den Status zu schauen, was sich gerade tut.

Live-Streaming mache ich ausschließlich über die Android-App, wo man bekanntlich die Presets fest einstellen kann und sie nicht jedes Mal neu einstellen muss.

Meiner Meinung braucht man keine 10 Qualitäts-Abstufungen, um gleich zu deiner zweiten Frage zu kommen.

Ich stelle mir das spontan in etwa so vor:

 

//hat sich schon alles geklärt, wie ich den letzten Postings entnehmen konnte...

- 500 kbit/s (via Mobilfunk)

- 1000 kbit/s (via LTE)

- 2000 kbit/s (via WLAN)

- 4000 kbit/s (via LAN)

 

Zur Windows-Phone App: Kann Nanohcv das mit den Namen nicht einfach ausbessern und die App in einer geupdateten Version zur Verfügung stellen?

 

Zu deiner dritten Frage:

Meiner Meinung nach kann Flash komplett rausgeschmissen werden, WebM wird von sehr vielen Browsern unterstützt und ist zukunftsorientiert.

Da müssen sich die User halt für einen anderen Browser entscheiden. Übertrieben gesagt haben die alten IE6-User dann einfach Pech gehabt.

 

Gruß

Julian

 

 

 

 

EDIT: Was mich an den Presets am meisten irritiert, ist die FFmpeg-Voreinstellung. Für den Endverbraucher könnte das doch auch auf 3-4 Presets reduziert werden, wie beispielsweise:

- Ultrafast (schwache CPU)

- Faster (mittelmäßige CPU)

- medium (schnelle CPU)

- veryslow (ultraschnelle CPU)

Edited October 24, 2015 by koekjuli

[Griga]

Was mich an den Presets am meisten irritiert, ist die FFmpeg-Voreinstellung. Für den Endverbraucher könnte das doch auch auf 3-4 Presets reduziert werden,

 

Genauer gesagt handelt es sich um Vorgaben für den x264 Encoder (also eigentlich nur für H.264 Video Output). Aber da es die Einstellung im UI nun mal gibt, wird sie das nächste RS Release auf ähnliche Einstellungen der WebM Encoder (VP8 / VP9) abbilden.

 

Reduzierte Wahlmöglichkeiten wären übersichtlicher, würden aber Anwender ärgern, die eine optimale Balance zwischen CPU-Last und Video-Qualität gefunden haben, die sie dann nicht mehr einstellen können

[Griga]

Hier informativ als Anhang die Presets (ffmpegprefs.ini, iphoneprefs.ini) so wie sie wahrscheinlich das nächste RS Release als neuer Default mitbringen wird. Man beachte das einheitliche Benennungs- und Bitraten-Abstufungsschema für alle Arten des transkodierten Streamings:

 

Presets.zip

 

Inzwischen ist es uns auch gelungen, Safari unter OS-X und iOS zu knacken. Das heißt, es wird möglich sein, vom RS erzeugte HLS-Streams direkt im Browser wiederzugeben, entweder im Web Interface oder durch Eingabe einer URL. Flash wird in Safari unter OS-X nur noch optional zur Verfügung stehen. Man kann in den RS Optionen wählen, ob man Flash oder HLS verwenden will. Beides geht nicht.

 

Bei der Stream-Konfiguration im Web Interface gibt es größere Änderungen. Einserseits sind einige Optionen verschwunden, andererseits steht eine Experten-Ansicht mit weitgehenden Eingriffsmöglichkeiten zur Verfügung:

 

 

Neu ist hier auch ein Button, mit dem man eine M3U-Senderliste für transkodierte Sender downloaden kann. Es werden dabei die eingestellten Parameter verwendet.

[Griga]

P.S. Sorry, im obigen Anhang gab es einen kleinen Fehler: Das Audio Preset in der iphoneprefs.ini war noch nicht als "HLS" gekennzeichnet. Ist jetzt korrigiert.

[Nanohcv]

Sieht wirklich gut aus. Bin sehr gespannt auf die nächste RS Version.

 

Werden die TS-Profile im Webinterface ausgeblendet? Die TS-Streams werden ja sicherlich nicht im Browser laufen.

[Griga]

Werden die TS-Profile im Webinterface ausgeblendet?

 

Wollte ich eigentlich, aber dann ist mir eingefallen, dass damit auch die Möglichkeit entfallen würde, eine Senderliste mit transkodiertem TS zu downloaden. Also werden die TS Presets in der Liste erscheinen. Der Browser wird schon bekanntgeben, was er davon hält (nicht unterstützter Mime Type oder so).

[Nanohcv]

Naja man könnte ja nur den Button "In Browser wiedergeben" deaktivieren. Aber hast recht. Man muss es ja nicht übertreiben mit Benutzerfreundlichkeit.

[Griga]

Das passiert in Firefox:

 

Ich finde das ausreichend benutzerfreundlich. Wenn man den Button deaktiviert, stellt es Anwender vor ein Rätsel, weil sie nicht erfahren, warum.

[dkdvb]

Entschuldigt bitte die erneute Störung ... Beleidigen lassen muss ich mich wohl nicht. Der Ton war scharf, aber gerecht ...

 

Und ihr möchtet müsst halt wurschteln statt das Design der Software zu ändern ... Baut doch wenigstens eine (oldschool 90er-Jahre ;-) Browserweiche ein, damit ich wir den iOS-Ordner nicht manuell auswählen muss müssen, oder sagt ja zu der Idee ... Vielleicht bekommt ihr dann eine gratis ;-)

 

Versteht mich hier bitte nicht falsch, es ist nicht so böse gemeint, wie es sich anhört. Mir ist klar, dass ihr Code aus unterschiedlichen Quellen habt und anpasst weiterentwickelt, so gut es geht. Manchmal wäre es aber einfacher, den großen Wurf zu machen, als zu wurschteln.

 

 

Griga:

 

Markus' iOS App versucht das Problem zu lösen, indem sie nach dem Start des HLS Streams eine Zeit wartet, und der Player kriegt die URL erst zu sehen, wenn (hoffentlich) bereits Segmente abrufbereit sind.

 

Und man kann eine Website per JavaScript nicht dazu bringen, einen beliebigen Timer auszuführen? Das UI ist doch eine Website in Safari. Oder man kann Webseiten umleiten / einen Reload machen, ach was sag ich ...

 

Ebenfalls hatte ich geschrieben, man könnte sofort einen Teststream senden. Das würde Zeit schaffen um einen 24/7 Stream zu simulieren.

 

Irgendwer hat gesagt, einige Programmierer hier verstünden nichts von Webprogrammierung ... Scheint zu stimmen. Glaubt mir, man Man spricht nicht umsonst von Webanwendungen.

 

Andererseits ist auch nicht wahr, dass man um einen Client zufrieden zu stellen, wirklich das machen muss, was der Client gern hätte. Der Client muss nur glauben, es wäre alles, wie er gern hätte. (s.o.)

 

Weitere Quotes spare ich mir. Selbstverständlich kann ich nicht alles aus den Stehgreif programmieren, was ich vorgeschlagen habe.

 

Wenn ihr mich einmal gefragt hättet, ob ich mitmache, oder ihr einfach mal Fragen beantwortet hättet, oder man sich hier allgemein willkommen fühlen würde, wäre das ernsthafte und codemäßige Helfen kein Problem.

 

Ich möchte allerdings nicht mehr helfen. Profiliert euch so gut ihr könnt ... Ich mag was ihr programmiert habt, aber bewundern tu ich euch nicht.

 

Manchmal würde einfach reichen zu sagen: Ja, gute Idee! Welche Infos brauchst du, um das umzusetzen?

 

Ich erwarte, dass hier einer die Eier hat, sich zu entschuldigen, wie ich es zwischendurch immer wieder getan habe.

Edited November 12, 2015 by dkdvb

[epsy]

"...oder man sich hier allgemein willkommen fühlen würde..."

Nunja, wie man in den Wald hineinruft/-poltert...

 

Der Ton der Admins ist nicht selten etwas überheblich, dass empfinde ich auch so! Dein Ton ist aber auch kein Deut besser - schlimmer würde ich sogar behaupten!!!

 

Ich würde es dennoch begrüßen, wenn die Entwickler und Du eine Möglichkeit einer Zusammenarbeit hinbekämen. Ich finde einige Deiner Idee sollten tatsächlich umgesetzt werden!

 

In meiner Heimat würde man sagen: setzt euch erst einmal an einen Tisch und trinkt ein Bier zusammen

[Nanohcv]

Ich würde es dennoch begrüßen, wenn die Entwickler und Du eine Möglichkeit einer Zusammenarbeit hinbekämen. Ich finde einige Deiner Idee sollten tatsächlich umgesetzt werden!

 

Das wird wohl nicht passieren.

Ich glaube kaum, dass sich Griga oder Christian dieses allgemeine BlaBla antun werden bzw. überhaupt die Zeit dazu haben seine Vorschläge zu studieren. Ich hab in dkdvb's Posts nicht einen konkreten Wunsch oder Vorschlag gesehen. Sondern nur so ein wischiwaschi Zeugs wie lasst den Rechner doch rechnen und so ein Mist.

 

Sorry wenn das jetzt hart klingt, aber dieses Gebrabbel hilft niemanden.

[nuts]

Kann auch keinen Vorschlag oder Wunsch erkennen.

Auf die Gegenargumente auf das Gebrabbel wurde ja dann von dkdvb auch nicht eingegangen.

Von daher sehe ich da keinen Handlungsbedarf.

[epsy]

Wie im Kindergarten "mit dem spiel ich nicht mehr" - ALLE!

[nuts]

Du kannst ja das Gebrabbel auswerten und in eine für die Entwickler sinnvolle Form bringen.

Mach ich auch so wenn mir ein Thema wichtig erscheint und ich mir davon Verbesserungen erhoffe.

 

Auf dem Niveau von dkdvb hab ich dazu aber keine Lust und sehe auch kein Potential, was du ja anders zusehen scheinst.

Die Chancen auf Umsetzung steigen massiv wenn die Vorschläge vernünftig vorgetragen werden.

Edited November 13, 2015 by nuts

[epsy]

Habe ein bisschen Experimentiert - Streaming auf iPhone

Streamen von HD-Kanälen (1920 x 1080i)

 

HLS HD 3600 kbit mit ffmeg superfast oder ultrafast (Ausgabe: 1280 x 720p)

CPU-Auslastung ca. 70%

lief über 3 Stunden ohne Probleme!

 

HLS Mid 1200 kbit mit ffmpeg faster (Ausgabe: 960 x 540p) Hinweis: Habe die Auflösung angepasst!

CPU-Auslastung ca. 60%

bricht regelmäßig nach wenigen Minuten ab und der Recording-Service hängt. Kein Zugriff mehr möglich. Neustart des PC erforderlich.

 

Was kann das sein? hier ein Auszug der svcdebug.log

 

 

16.11.15 10:17:12.517 FFMPEG frame=13136 fps= 25 q=27.0 size= 61472kB time=00:08:46.53 bitrate= 956.4kbits/s
16.11.15 10:17:13.022 FFMPEG frame=13152 fps= 25 q=27.0 size= 61505kB time=00:08:46.89 bitrate= 956.3kbits/s
16.11.15 10:17:13.631 FFMPEG frame=13164 fps= 25 q=27.0 size= 61511kB time=00:08:47.57 bitrate= 955.1kbits/s
16.11.15 10:17:14.141 FFMPEG frame=13180 fps= 25 q=27.0 size= 61521kB time=00:08:48.02 bitrate= 954.5kbits/s
16.11.15 10:18:14.102 TRecordingEngine ReleaseReference webserver: 1
16.11.15 10:21:54.561 TRecordingEngine AddReference webserver: 2
16.11.15 10:34:19.461 Start App ------------------------------------------------------------
16.11.15 10:34:19.461 DVBViewer Recording Service 1.31.0.0 (beta)
16.11.15 10:34:19.461 TRecordingEngine Execute Start
16.11.15 10:34:19.471 TRecordingEngine StartService start timer

 

ffmpeg ist aktuell!

[Griga]

Gibt es ein wiederkehrendes Muster, z.B. immer den Eintrag "AddReference webserver: 2" vor dem Festhänger?

 

Ein bekanntes (und intern bereits gefixtes) Problem ist, dass der RS festhängt, wenn eine höher priorisierte Instanz wie z.B. eine Timeraufnahme dem Live Streamserver das DVB-Gerät wegnimmt.

[epsy]

Nun ist er einfach so abgeschmiert:

 

HLS Mid 1200 kbit mit FFmpeg faster (Ausgabe: 960 x 540p)

 

 

6.11.15 14:31:09.946 FFMPEG frame= 6021 fps= 25 q=30.0 size= 35267kB time=00:04:02.03 bitrate=1193.6kbits/s
16.11.15 14:31:10.462 FFMPEG frame= 6032 fps= 25 q=33.0 size= 35345kB time=00:04:02.52 bitrate=1193.9kbits/s
16.11.15 14:31:10.962 FFMPEG frame= 6044 fps= 25 q=33.0 size= 35422kB time=00:04:02.97 bitrate=1194.3kbits/s
16.11.15 14:31:11.492 FFMPEG frame= 6058 fps= 25 q=34.0 size= 35516kB time=00:04:03.48 bitrate=1194.9kbits/s
16.11.15 14:31:11.970 FFMPEG frame= 6072 fps= 25 q=34.0 size= 35604kB time=00:04:04.12 bitrate=1194.7kbits/s
16.11.15 14:31:12.061 TPipeServerReadThread Split 5007
16.11.15 14:31:12.495 FFMPEG frame= 6085 fps= 25 q=35.0 size= 35673kB time=00:04:04.59 bitrate=1194.7kbits/s
16.11.15 14:31:13.018 FFMPEG frame= 6101 fps= 25 q=34.0 size= 35763kB time=00:04:05.08 bitrate=1195.4kbits/s
16.11.15 14:31:26.833 TRecordingEngine ReleaseReference TStreamClient: 1
16.11.15 14:31:29.221 Release USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:31:29.221 Destroy USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:31:29.800 Destroyed USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:31:29.800 hamDeleted USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:31:31.939 TDataReaderMedia Execute Start
16.11.15 14:31:31.939 TDataReaderMedia PhotoClean 0
16.11.15 14:31:31.939 TDataReaderMedia AudioClean 0
16.11.15 14:31:31.954 TBDATTDiSEqC Opendevice TT Device: 3
16.11.15 14:31:31.954 TDataReaderMedia VideoClean 15
16.11.15 14:31:32.089 TBDATTDiSEqC Opendevice bvTTDiSEqC
16.11.15 14:31:32.089 TEPGUpdater AllocateHardware USB 2.0 BDA DVB-S Tuner (1)
16.11.15 14:31:32.089 TBDATTDiSEqC SetTuner TType: 1, Freq: 10744, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 3, FEC: 4, APID: 402, VPID: 401, PMT: 400, SID: 28724, TID: 1051, NID: 1, SatMod: 1, DiseqCVal: 0, Flags: 24
16.11.15 14:31:32.424 TDataReaderMedia Execute read files ready 483
16.11.15 14:31:32.452 TDataReaderMedia Execute 515
16.11.15 14:31:33.967 TDataReaderMedia Destroy
16.11.15 14:31:33.967 TRecordingEngine wm_Ready FDatareaderMedia Free
16.11.15 14:32:04.383 TEPGUpdater AllocateHardware USB 2.0 BDA DVB-S Tuner (1)
16.11.15 14:32:04.383 TEPGUpdater Release USB 2.0 BDA DVB-S Tuner (1)
16.11.15 14:32:04.383 TBDATTDiSEqC SetTuner TType: 1, Freq: 11598, Symrate: 22000, LOF: 9750, Tone: 0, Pl

 

Immerhin: Der Recordingservice war danach ansprechbar und der Stream konnte erneut gestartet werden.

 

 

HLS Mid 1200 kbit mit FFmpeg faster (Ausgabe: 960 x 540p)

So, nun der zweite Stream. 4 Minuten später:

 

16.11.15 14:37:58.303 TEPGUpdater hamDeleted USB 2.0 BDA DVB-S Tuner (1)
16.11.15 14:37:58.472 FFMPEG frame= 5540 fps= 25 q=27.0 size= 31361kB time=00:03:41.87 bitrate=1157.9kbits/s
16.11.15 14:37:58.995 FFMPEG frame= 5553 fps= 25 q=27.0 size= 31427kB time=00:03:42.38 bitrate=1157.7kbits/s
16.11.15 14:37:59.518 FFMPEG frame= 5568 fps= 25 q=29.0 size= 31515kB time=00:03:42.87 bitrate=1158.4kbits/s
16.11.15 14:38:00.028 FFMPEG frame= 5584 fps= 25 q=27.0 size= 31595kB time=00:03:43.54 bitrate=1157.8kbits/s
16.11.15 14:38:00.385 TPipeServerReadThread Split 5007
16.11.15 14:38:00.546 FFMPEG frame= 5600 fps= 25 q=28.0 size= 31730kB time=00:03:43.98 bitrate=1160.5kbits/s
16.11.15 14:38:01.055 FFMPEG frame= 5615 fps= 25 q=29.0 size= 31823kB time=00:03:44.60 bitrate=1160.7kbits/s
16.11.15 14:38:01.576 FFMPEG frame= 5625 fps= 25 q=27.0 size= 31867kB time=00:03:45.07 bitrate=1159.9kbits/s
16.11.15 14:38:02.937 TEPGUpdater Release USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:38:17.460 TRecordingEngine ReleaseReference TStreamClient: 1
16.11.15 14:38:19.753 Release USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:38:19.753 Destroy USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:38:20.332 Destroyed USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:38:20.332 hamDeleted USB 2.0 BDA DVB-S Tuner (2)

Recordingservice weiterhin stabil...

 

 

HLS Mid 1200 kbit mit FFmpeg superfast (Ausgabe: 960 x 540p)

 

16.11.15 14:45:59.420 FFMPEG frame= 8812 fps= 25 q=25.0 size= 52183kB time=00:05:53.20 bitrate=1210.3kbits/s
16.11.15 14:45:59.932 FFMPEG frame= 8829 fps= 25 q=26.0 size= 52299kB time=00:05:53.76 bitrate=1211.1kbits/s
16.11.15 14:46:13.190 TRecordingEngine ReleaseReference TStreamClient: 1
16.11.15 14:46:16.693 Release USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:46:16.693 Destroy USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:46:17.272 Destroyed USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:46:17.272 hamDeleted USB 2.0 BDA DVB-S Tuner (2)

Recordingservice läuft...

 

 

HLS HD 3600 kbit mit ffmeg superfast (Ausgabe: 1280 x 720p)

gestern im internen Netzwerk lief das ganze gestern 3 Stunden durch.

Nun sitze ich im Büro und mit selbiger Einstellung schmiert der Stream nach weniger als 4 Minuten ab

 

 

16.11.15 14:49:59.038 FFMPEG frame= 3659 fps= 25 q=23.0 size= 60422kB time=00:02:27.32 bitrate=3359.9kbits/s
16.11.15 14:49:59.535 FFMPEG frame= 3670 fps= 25 q=23.0 size= 60628kB time=00:02:27.76 bitrate=3361.3kbits/s
16.11.15 14:50:00.035 FFMPEG frame= 3685 fps= 25 q=23.0 size= 60927kB time=00:02:28.36 bitrate=3364.2kbits/s
16.11.15 14:50:00.572 FFMPEG frame= 3698 fps= 25 q=23.0 size= 61191kB time=00:02:28.88 bitrate=3367.0kbits/s
16.11.15 14:50:01.091 FFMPEG frame= 3712 fps= 25 q=22.0 size= 61453kB time=00:02:29.44 bitrate=3368.7kbits/s
16.11.15 14:50:01.464 TPipeServerReadThread Split 5117
16.11.15 14:50:01.618 FFMPEG frame= 3723 fps= 25 q=23.0 size= 61701kB time=00:02:29.88 bitrate=3372.4kbits/s
16.11.15 14:50:13.553 TRecordingEngine ReleaseReference TStreamClient: 1
16.11.15 14:50:16.170 Release USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:50:16.170 Destroy USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:50:16.749 Destroyed USB 2.0 BDA DVB-S Tuner (2)
16.11.15 14:50:16.749 hamDeleted USB 2.0 BDA DVB-S Tuner (2)

 

ich teste heute Abend mal im internen Netzwerk...

 

SD Inhalte schmieren nun auch ab... Was ist da los?

[epsy]

Ursache scheint die VPN-Verbindung zwischen Büro und Heim zu sein. Testweise mal deaktiviert, liefen alle Videos (nahezu) anstandlos!

Bin sehr gespannt auf die neu Version.

[Griga]

Schön dass sich das geklärt hat.

 

Heute habe ich mich mit DVB-Untertiteln in transkodierten Streams beschäftigt - siehe dazu auch hier.

 

 

Das nächste Release wird Untertitel mittels URL-Parameter (also auch in den Experten-Einstellungen) unterstützen. Es funktioniert mit sämtlichen Stream-Arten (also WebM, Flash, TS, HLS). Ein ungelöstes Problem ist dabei, dass FFmpeg abbricht und gar nichts macht, wenn man den Parameter angibt, der Sender aber keinen Untertitel-Stream bietet. Irgendwie müsste man FFmpeg dazu bringen, den fehlenden Stream zu ignorieren oder den Overlay Filter nur bedingt anzuwenden. Falls jemand etwas dazu einfällt, bitte posten.

[Griga]

P.S. Was noch zu erwähnen wäre: Der obige Screenshot zeigt Chrome. Ich bin nicht unbedingt ein Google-Fan, muss aber zugeben, dass dem Browser bei der Wiedergabe von TV und Video der Spitzenplatz gebührt, gefolgt von Firefox. Die Unterstützung für verschiedene Formate ist einfach am besten, was sich unter Android fortsetzt - da kann Chrome sogar HLS, und das IMO sogar besser als Safari (HLS ist ein Apple-Format).

 

Die in der Adresszeile des Screenshots sichtbare URL (tv.html) wird es im nächsten RS Release ermöglichen, TV- und Radio-Streams unabhängig vom Web Interface abzurufen, so dass man sich im Browser eine TV-Favoritenliste anlegen kann.