nuts Posted October 15, 2015 Share Posted October 15, 2015 Ja weil das ein Unterschied ist ... und Tschüss! Link to comment
epsy Posted October 15, 2015 Share Posted October 15, 2015 Ich finde den Ton von dkdvb auch sehr provozierend, allerdings hat er in vielen Dingen recht!! UND: Niemals provozieren lassen Und das mit der Automatik ist hier beschrieben: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple_ref/doc/uid/TP40008332-CH102-SW1 Zitat:" Stream Alternates A master index file may reference alternate streams of content. References can be used to support delivery of multiple streams of the same content with varying quality levels for different bandwidths or devices. HTTP Live Streaming supports switching between streams dynamically if the available bandwidth changes. The client software uses heuristics to determine appropriate times to switch between the alternates. Currently, these heuristics are based on recent trends in measured network throughput. The master index file points to alternate streams of media by including a specially tagged list of other index files, as illustrated in Figure 2-1 oth the master index file and the alternate index files are in .M3U8 playlist format. The master index file is downloaded only once, but for live broadcasts the alternate index files are reloaded periodically. The first alternate listed in the master index file is the first stream used—after that, the client chooses among the alternates by available bandwidth. Note that the client may choose to change to an alternate stream at any time, such as when a mobile device enters or leaves a WiFi hotspot. All alternates should use identical audio to allow smooth transitions among streams. You can create a set of stream alternates by using the variantplaylistcreator tool and specifying the -generate-variant-playlist option for either the mediafilesegmenter tool or the mediastreamsegmenter tool (see Download the Tools for details)." Problem: Man müsste bei einer Automatik IMMER das zu streamende (schreibt man das so) Element/Video (z.B.) drei mal encodieren (Niedrig, Mittel, Hoch)! Kostet entsprechend CPU! Einem i7 (i5) macht das möglicherweise wenig aus, der ein oder andere User nutzt aber einen ATOM oder ausrangierten älteren Rechner, der zumindist bisher Videos in Baseline und Preset Ultrafast EINEN Stream einwandfrei encodieren konnte. Hier wird es schon wieder schwierig dieses Problem für ALLE zu lösen. Dann beschweren sich Leute, dass die Automatik nicht einwandfrei funktionieren würde... Angenommen ein Video in 1920x1080i mit 50 (Halb-)Bildern / s: Dies in drei Auflösungen zu codieren: (1280x720p [25], 720x400p [25], 480x272p [15]) + entsprechend 3x Audio (z.B.: 5.1 [160kBit/s), Stereo [128kBit/s], Mono 48kBit/s mit 32kHz Sampling]), dürfte viele Rechner vollkommen auslasten! Nicht unbedingt in Baseline und Ultrafast, aber hier ist die Bildqualität auch entsprechend SEHR bescheiden! Eine solche Automatik ist doch sehr von der jeweiligen CPU abhängig... Ob das Sinn macht oder für viele Nutzer für Frust sorgt.... Sollen die Entwickler entscheiden Link to comment
Griga Posted October 16, 2015 Share Posted October 16, 2015 Eine solche Automatik ist doch sehr von der jeweiligen CPU abhängig... Ob das Sinn macht oder für viele Nutzer für Frust sorgt.... Sollen die Entwickler entscheiden. Haben sie schon entschieden: Machen sie nicht. Es gibt nämlich ein grundsätzliches Problem mit dem RS als HLS Server. Normalerweise ist es so, dass HLS-Server Streams 24/7 bereitstellen, d.h. wenn ein Client sich einklinkt, wird er sofort bedient. Die HLS-Spezifikationen setzen voraus, dass es so ist! Der RS liefert jedoch zwangsläufig "on demand", nämlich wenn ein Client einen Sender haben will - wie soll er 100 Sender einer Senderliste in jeweils 3 Qualitätstufen = 300 transodierte Streams permanent verfügbar halten? Selbst wenn eine entsprechende Serverfarm vorhanden wäre - die Stromrechnung möchte ich nicht bezahlen Also: Ein Client fordert einen Sender an, und dann geht es los: Zunächst muss die DVB-Karte aus dem Quark kommen - je nach Fabrikat dauert das mehr oder weniger lange. Dann muss FFmpeg aus dem Quark kommen, eine Weile den Input analysieren, die Encoder konfigurieren usw.. Dann muss sich eine Mindestanzahl von Segmenten angesammelt haben, bis der RS anfängt zu liefern. Das dauert insgesamt erst mal 10 bis 20 Sekunden. Bis dahin hat der Client eventuell schon aufgegeben. Zum Beispiel Safari unter OS-X, wenn man eine master.m3u8 URL eingibt, die unsere aktuelle (interne) RS-Version bedienen soll. Bislang haben wir das nicht zum Laufen gekriegt. Am Wochenende werde ich es noch mal probieren - da kommt eine Bekannte mit einem MacBook vorbei - aber viel Hoffnungen mache ich mir nicht. 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. Zukünftige RS-Versionen werden es erlauben, über das API permanente HLS-Streams zu konfigurieren, zu starten und zu stoppen. Sie laufen unabhängig von Anforderungen durch Clients. Aber bei denen kann der Client natürlich nicht den Sender umschalten. Fazit: Senderumschaltungen sind bei HLS nicht vorgesehen. Das beißt sich vorne und hinten. Diese Streaming-Art und der Daseinszweck des RS passen einfach nicht zusammen. Man kann etwas um das Problem herumarbeiten, aber grundsätzlich lässt sich der Widerspruch nicht auflösen. Ich finde den Ton von dkdvb auch sehr provozierend, allerdings hat er in vielen Dingen recht!! Problemchen wie das oben beschriebene haben Besserwisser mit ihren tollen Ideen, wie das alles sein sollte, nie auf der Rechnung, weil sie nie selbst probiert haben, es in die Praxis umzusetzen. Eunuchen sozusagen: Sie wissen wie es geht, aber können selbst nicht... Link to comment
nuts Posted October 16, 2015 Share Posted October 16, 2015 Vielleicht noch als Ergänzung: Selbst wenn man für den gewünschten Sender 3 Stufen bereithält, was ich mit ffmpeg und Software transcodieren für völligen Unsinn halte (was ist bei mehr als einem Client?), kriegt man dann keine stufenlose adaptive Anpassung hin. Es liegen ja nur die 3 Stufe vor und die muss man zu Beginn spezifizieren. Link to comment
MarkusK Posted October 16, 2015 Share Posted October 16, 2015 Dazu käme dann noch der max. Upload der jeweiligen Internetverbindung des Users zzgl. der möglichen Downloadrate vom Client bzw. des mobilen Geräts (bei externer Nutzung)... Link to comment
Griga Posted October 16, 2015 Share Posted October 16, 2015 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? Ich habe gerade Flash mit H.264/MP3 und WebM mit VP8/Vorbis als Codec in zwei Varianten verglichen. Flash lief im VLC, WebM im DVBViewer GE mit dem LAV Sourcefilter. Beide Fenster nebeneinander, beide mit arte SD, beide Encoder in mitllerer Qualitätsstufe aktiv. Ein Test mit 720x404 bei ca. 1000 kbit/s Gesamtbitrate, davon 96 kbit/s Audio, ein weiterer mit 470x270 bei ca. 500 kbit/s, Audio 64 kbit/s. Für zweimal transkodiertes HD reicht mein etwas altersschwacher DualCore leider nicht. Fazit: Das tut sich nicht viel. Bei der Bildqualität vielleicht manchmal leichte Vorteile für H.264, aber nie so, dass man sagen könnte: Jetzt macht der eine Encoder massiv Blockartefakte und der andere nicht. Oder bei einem ist das Bild deutlich schärfer als beim anderen. Bei 64 kbit/s Audio ist der WebM Vorbis Codec dem altehrwürdigen MP3 deutlich überlegen. Allerdings könnte man bei Flash auch AAC mit einpacken. Von der praktischen Seite her gibt es jedoch deutliche Unterschiede: - Flash braucht zwingend die permanenten Sicherheitslücken und Updates von Adobe (siehe aktuell hier), dazu muss man mit HTML/Javascript einen Flash-Player von dritter Hand im Browser herbeizitieren. - WebM läuft dagegen nativ in Firefox und Chrome (auch unter Android), mit leichten Abstrichen auch im Internet Explorer. Der IE braucht für WebM ein Add-On von Google, im IE9 funktioniert es hier kaum, im IE11 recht gut, allerdings habe ich AutoPlay bislang nicht zum Laufen gekriegt, d.h. man muss nach einem Senderwechsel auf Play klicken. In FireFox und Chrome reicht die Eingabe eine URL der Machart http://[iP]:[Port]/flashstream/stream.webm?[Parameter], um den vom RS gelieferten WebM-Content wiederzugeben. Der IE möchte die URL gerne in einer HTML 5-Seite mit Video-Tag eingebettet haben. Das ist aber kein Problem, sowas wie http://[iP]:[Port]/webm.html?[Parameter] kann der RS ohne größeren Aufwand bedienen - mehr als 20 Zeilen HTML braucht es nicht. Außerdem ermöglich es die HTML-Seite, das Erscheinungsbild des browser-eigenen Players etwas netter zu gestalten (auch in Firefox und Chrome), zum Beispiel mit Senderlogos über das Poster-Attribut des Video-Tags. Die Wiedergabe eines vom RS als WebM gestreamten Radiosenders in Chrome sieht dann so aus: IMO liegen die praktsichen Vorteile eindeutig bei WebM. Die Frage ist nun: Wie soll das in zukünftigen Recording Service Releases aussehen? Damit keine Missverständnisse aufkommen: Technisch wird Flash auf jeden Fall weiter unterstützt, d.h. wer mit Flash-Presets in der ffmpegprefs.ini operieren will, kann das auch weiterhin tun. Aaaaber: - 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? Feedback zu diesen Fragen ist erwünscht! Link to comment
Nanohcv Posted October 17, 2015 Share Posted October 17, 2015 Also ich brauche nicht so viele Presets. Ich würde deine Presets aber mehr an den üblichen Upload-Geschwindigkeiten orientieren. Z.B. hat DSL 16000 i.d.R: 1Mbit Upload, da würde es bei deinen Presets vermutlich nur mit den 500kbit/s Preset flüssig funktionieren. Folglich würde ich für die Bitraten immer ein Wert wählen, der knapp unterhalb der üblichen Upload-Geschwindigkeit liegt. Bezügliche Flash und Flowplayer: Ich nutze das Webinterface Streaming schon ab und zu. Wenn WebM mit VP8 gut funktioniert, kann ich auf Flash gut und gerne verzichten. Als Browser nutze ich Firefox. In meinem Bekanntenkreis nutzen eigentlich alle Firefox oder Chrome. Ich denke das trifft auch auf die Mehrheit der Recording Service Nutzer zu und sollte somit bei den meißten funktionieren. Frage ist halt, was man mit den OSX / Safari Nutzern macht. VinoRosso mit seiner Android App muss auch aufpassen. Da werden die Streaming Profile nicht ausgelesen sondern sind in der App fest verdrahtet. Ich empfehle ihm sowieso statt den Flash Presets auf h264 ts Presets umzustellen. Dann funktioniert nämlich auch das Hardwaredecoding. Link to comment
driver140771 Posted October 17, 2015 Share Posted October 17, 2015 Also ich brauche nicht so viele Presets. Trifft für mich auch zu. Frage ist halt, was man mit den OSX / Safari Nutzern macht. Ich nutze auch unter OSX den Firefox, der ja auch bald für iOs kommen soll. Link to comment
Griga Posted October 17, 2015 Share Posted October 17, 2015 Ich würde deine Presets aber mehr an den üblichen Upload-Geschwindigkeiten orientieren. Und die wären außer 1 MBit? An Zugriffe über das Internet habe ich noch gar nicht gedacht. Ob WebM unter den Bedingungen als Streaming-Format gut geeignet ist, bleibt noch auszuprobieren. Frage ist halt, was man mit den OSX / Safari Nutzern macht. Eigentlich müssten die mit HLS bedient werden. Aber wie gesagt waren bisherige Tests in der Hinsicht nicht sehr erfolgreich (siehe hier). Bei WebM-Tests mit dem IE 11 hat sich noch ein unschönes Problem gezeigt. Wenn man in einem Browser-Tab einen Sender laufen hat, und ruft im gleichen Tab einen anderen Sender auf, lässt der IE die vorherige Verbindung eine Weile stehen, nach dem Motto, vielleicht brauchen wir die gleich noch mal... was im RS zur Folge hat, dass der dazugehörige Konverter weiterläuft und die Hardware besetzt bleibt. Kurz gesagt geht bei den hiesigen zwei DVB-S-Karten im Server-PC ab der zweiten Senderumschaltung im IE 11 nichts mehr, weil kein DVB-Gerät mehr frei ist . Zwischen zwei Sendern hin und herschalten geht dann allerdings *sehr* schnell, weil der IE auf bereits bestehende Verbindungen zurückgreifen kann. Das Problem besteht übrigens auch bei anderen Streaming-Arten wie dem TS für das Windows Phone, wenn der Client sich so verhält. Im Grunde bleibt da nur, die Anzahl gleichzeitig gelieferter Sender pro Client IP und User Agent serverseitig auf 1 zu beschränken. D.h. wenn eine Client Request mit einer Client IP / User Agent-Kombination eintrifft, der bereits eine Konverter-Instanz zugewiesen ist, wird diese erbarmungslos abgeräumt. Das verhindert natürlich auch zwei Sender in zwei Fenstern oder Tabs des selben Browsers. Link to comment
spachti Posted October 17, 2015 Share Posted October 17, 2015 (edited) Sorry, Thema falsch verstanden. Edited October 17, 2015 by spachti Link to comment
Nanohcv Posted October 18, 2015 Share Posted October 18, 2015 Und die wären außer 1 MBit? Bei DSL 6000 -> 576kbit/s Bei DSL 16000 -> 1024kbit/s oder 2400kbit/s Bei VDSL 25000 -> 5Mbit/s Bei VDSL 50000 -> 10Mbit/s Bei KabelDeutschland 25 -> 1 Mbit Bei KabelDeutschland 50 -> 2 Mbit Bei KabelDeutschland 100 -> 6 Mbit Bei KabelDeutschland 200 -> 12 Mbit Bei Unitymedia 10 -> 1Mbit Bei Unitymedia 60 -> 3Mbit Bei Unitymedia 120 -> 6Mbit Also würde ich ein Preset mit 400 kbit/S (wenn man das noch ansehen kann), eins mit 800 kbit/s, eins mit 1800kbit/s und eins mit 3 oder 4 Mbit erstellen. Bei WebM-Tests mit dem IE 11 hat sich noch ein unschönes Problem gezeigt. Wenn man in einem Browser-Tab einen Sender laufen hat, und ruft im gleichen Tab einen anderen Sender auf, lässt der IE die vorherige Verbindung eine Weile stehen, nach dem Motto, vielleicht brauchen wir die gleich noch mal... was im RS zur Folge hat, dass der dazugehörige Konverter weiterläuft und die Hardware besetzt bleibt. Kurz gesagt geht bei den hiesigen zwei DVB-S-Karten im Server-PC ab der zweiten Senderumschaltung im IE 11 nichts mehr, weil kein DVB-Gerät mehr frei ist . Zwischen zwei Sendern hin und herschalten geht dann allerdings *sehr* schnell, weil der IE auf bereits bestehende Verbindungen zurückgreifen kann. Das Problem besteht übrigens auch bei anderen Streaming-Arrten wie dem TS für das Windows Phone, wenn der Client sich so verhält. Das ist ja wirklich unschön Die Windows Phone App verhält sich aber nicht so, sonst würde ja umschalten nicht gehen. Link to comment
RobertSmith Posted October 18, 2015 Share Posted October 18, 2015 (edited) Ich verwende das Webinterface nur um zu sehen, was gerade läuft. Den Flashplayer verwende ich nicht, sondern starte die Wiedergabe über Playlisten (je nach Bitrate "1000k.m3u" / "2400k.m3u" / "5000k.m3u"). Statt den Standardpresets verwende ich eigene. Dies soll bitte auch in Zukunft möglich bleiben. Könnte man nicht den Benutzer nach seiner Internetverbindung fragen? Anhand einer Tarif-Auswahlliste während der Installation. (Mit einem Verweis auf speedtest.net, falls die Angabe nicht bekannt ist.) Dann kann man eine Vorgabe passend zum Upload anlegen. Edited October 18, 2015 by RobertSmith Link to comment
Griga Posted October 18, 2015 Share Posted October 18, 2015 Also würde ich ein Preset mit 400 kbit/S (wenn man das noch ansehen kann), eins mit 800 kbit/s, eins mit 1800kbit/s und eins mit 3 oder 4 Mbit erstellen. Also praktisch etwas niedriger, als ich es ins Auge gefasst hatte. Wäre wohl machbar. Wie es sich mit WebM in dieser Hinsicht verhält, muss jemand nach dem nächsten RS Release gründlich testen. VP8 ist ein ausgeprägter VBR Codec. Wenn man ihn zu sehr auf eine konstante Bitrate festnagelt, verliert er an Qualität. Ich habe gestaunt, mit wie geringer (im VLC angezeigter) Bitrate er 720 x 404 bewältigt. Die Zielbitrate war 1000 kbit/s, aber oft turnte er bei 300 bis 500 herum. Mitunter aber auch bei 1500 Mit dem MacBook Pro einer Besucherin konnte ich heute leider nur kurz den Status Quo feststellen - mehr Zeit war nicht und außerdem ein lebhaftes Kleinkind dabei. Es sieht so aus, dass Safari unter OS-X bestens mit dem vom RS gelieferten HLS klarkommt - aber nur, wenn der Stream bereits vorher gestartet wird, so dass es keine Wartezeiten mehr gibt. Wird er erst "on demand" bzw. durch Anforderung von Safari gestartet, läuft das Bild genau eine Media-Playliste lang. Dann ist Feierabend, es geht nicht mehr weiter. Es liegt also nicht an der HLS-Implementation im RS, sondern ist prinzipbedingt. Das ist ja wirklich unschön Nun, es ist sicher gut gemeint vom IE. Er weiß ja nicht, dass er durch sein Verhalten am anderen Ende der Leitung die Bude heizt und DVB-Hardware blockiert. Normalerweise werden bereits fertig kodierte Dateien über das HTML 5 Video-Tag eingebunden und keine Live Streams mit on-the fly Transkodierung. Wie auch immer - ich habe dem jetzt einen Riegel vorgeschoben. Der betrifft allerdings alle Clients! Im Grunde ist es auch sinnvoll, den Empfängern trankodierter Streams ein sparsames Verhalten zu verordnen. Bevor jemand auf die Idee kommt, den Server durch 6 Browserfenster mit 6 HD-Sendern gleichzeitig abrauchen zu lassen.... es gibt so Leute Falls eine App sowas wie Bild in Bild inszenieren will, hat sie damit aber ein gewisses Problem. Es müssen zwei verschiedene User Agents sein, sonst würgt ein Stream den anderen ab. Abhilfe könnte ich durch einen (nur verantwortungsbewussten Insidern bekannten) zusätzlichen URL-Parameter schaffen, eine Art ID, die standardmäßig = 0 ist. Zwei oder mehr Streams für den selben Client werden akzeptiert, wenn ihre ID unterschiedlich ist. Könnte man nicht den Benutzer nach seiner Internetverbindung fragen? Anhand einer Tarif-Auswahlliste während der Installation. Einspruch, Euer Ehren! Damit gäbe es wieder etwas, das ständig gepflegt und aktuell gehalten werden muss. Dafür haben wir nicht die Ressourcen. Oder machst du das die nächsten Jahre? Link to comment
Nanohcv Posted October 18, 2015 Share Posted October 18, 2015 Wie auch immer - ich habe dem jetzt einen Riegel vorgeschoben. Der betrifft allerdings alle Clients! Im Grunde ist es auch sinnvoll, den Empfängern trankodierter Streams ein sparsames Verhalten zu verordnen. Bevor jemand auf die Idee kommt, den Server durch 6 Browserfenster mit 6 HD-Sendern gleichzeitig abrauchen zu lassen.... es gibt so Leute Kann ich gut mit leben. Mein Server schafft eh nur ein transkodierten Stream Link to comment
epsy Posted October 19, 2015 Share Posted October 19, 2015 Habe WebM noch einmal getestet (VLC-Abruf). Die Qualität ist ein wenig schlechter als h.264, allerdings besser als erwartet. Immer berücksichtigt, dass man auch unterwegs mit wenig Bitrate Videoinhalte übertragen möchte! Daher auch hier ein Profil mit ca. 600 kBit/s Gesamtbitrate (Video + Audio)! Habe hierzu folgende Einstellung verwendet: [600 kbit - Audio 96]Cmd=-re -threads {threads} {offset} {realtime} -i "{infile}" -threads {threads} -f flv -vcodec libx264 -crf 23 -maxrate 500k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 96k -ac 2 -y "{outfile}"maxWidth=640maxHeight=480MimeType=video/x-flvExt=.flvBitrate=600 [600 kbit - Audio 96 - WebM]Cmd=-re -threads {threads} {offset} {realtime} -i "{infile}" -threads {threads} -f webm -vcodec libvpx -crf 23 -b:v 500k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -acodec libvorbis -ab 96k -ar 44100 -ac 2 -y "{outfile}"maxWidth=640maxHeight=480MimeType=video/webmExt=.ffmBitrate=600 Aufruf VLC mit: WebM: http://MEINE-DYNDNS-ADRESSE:8089/flashstream/stream.flv?Preset=1&ffPreset=fast&chid=3 h.264: http://MEINE-DYNDNS-ADRESSE:8089/flashstream/stream.flv?Preset=0&ffPreset=fast&chid=3 Ich würde eine Lösung ohne Flash-Player begrüßen. Auf meinem Bürorechner daher auch schon nicht mehr installiert! Da ist mir ein Video mit etwas mehr Blockartefakten lieber. Link to comment
Griga Posted October 19, 2015 Share Posted October 19, 2015 Ersetze mal probeweise libvpx durch libvpx-vp9. Wie sieht es damit aus? Ich experimentiere gerade mit dem neuen Codec VP9, da Edge unter Windows 10 offenbar keinen anderen unterstützt. Hier geht es nur mit -quality realtime, sonst ist die Server-CPU sofort am Anschlag In Firefox und Chrome geht die VP9-Wiedergabe, aber der IE11 will dann kein Video mehr abspielen. Man hört nur den Ton. Link to comment
Griga Posted October 19, 2015 Share Posted October 19, 2015 Hier gibt es einen Vergleich zwischen H.264 und VP8 mit Bildmaterial. Link to comment
epsy Posted October 19, 2015 Share Posted October 19, 2015 libvpx-vp9 hatte ich bereits ausprobiert. Nutzt von meinen 4 Kernen nur einen, welcher völlig ausgelastet ist und mit 2,5 Bilder/s nicht sonderlich effizient Mit "-quality realtime" leider keine wirkliche Besserung. Ist mein i3 zu schwach? Link to comment
Griga Posted October 19, 2015 Share Posted October 19, 2015 (edited) Mit "-quality realtime" leider keine wirkliche Besserung. Ist mein i3 zu schwach? Der Codec ist irgendwie sonderbar. Entweder ist er noch eine ziemliche Baustelle, oder er tickt bei der Interpretation der Parameter ganz anders als der VP8. Die einzige akzeptable CPU-Auslastung habe ich bislang mit -quality realtime -cpu-used 3 7 erhalten. Eine Erhöhung des Wertes für cpu-used, der beim VP8 laut Dokumentation und auch tatsächlich zu einer niedrigeren CPU-Auslastung führt, lässt sie beim VP9 sofort an die Decke gehen Edited October 19, 2015 by Griga Korrektur -cpu-used 7 statt 3 Link to comment
Griga Posted October 19, 2015 Share Posted October 19, 2015 Naja: https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. Higher –cpu-used=X parameters make the quality gains melt away. Wenn die cpu-used x Parameter denn mal wie erwartet funktionieren würden. Ich glaube, den Frischling lässt man für Live-Streaming besser außen vor. Link to comment
Griga Posted October 19, 2015 Share Posted October 19, 2015 Ich habe es mit VP9 systematisch durchprobiert: Der gültige Wertebereich für -quality realtime -cpu-used x geht bis x = 8 (geringste CPU-Last). Überschreitet man ihn, greift irgendein tödlicher Default. Wenn ich den Wert senke (wobei sich die CPU-Last erhöht), läuft es bis etwa 5. Bei 4 wird es schon kritsch (Firefox will nicht mehr, Chrome noch gerade so eben). Bei 3 ist meine CPU hoffnungslos überfordert. Ich hatte mich vorhin vertan. Der erfolgreiche Wert war 7, nicht 4. Link to comment
Griga Posted October 20, 2015 Share Posted October 20, 2015 Ich habe mir noch mal verschiedene Ansichten in diesem Thema zu Gemüte geführt und möchte jetzt die folgenden beiden Anregungen aufgreifen: Die FFmpeg Entwicklern empfehlen den qualitätsbasierten Modus mit Bitratebeschränkung für Streaming. In meinen Tests sind die Ergebnisse damit besser. Ich habe es mir angeschaut, und es sieht soweit ok aus. In welcher Hinsicht waren die Ergebnisse besser?Bei Streaming mit begrenzter Bandbreite ist es vermutlich eher angebracht, eine obere Grenze statt einem Mittelwert als Zielbitrate zu definieren. Der unbekannte Faktor ist dabei allerdings der Overhead durch den Container. Beim TS für das Windows Phone setzt FFmpeg zum Beispiel alle 0,07 Sekunden PAT und PMT in den Stream (jeweils ein Paket á 188 Bytes, das zum größten Teil mit Stuffing gefüllt ist). Das addiert sich zu ca. 40 kbps! Dem habe ich jetzt mit -pat_period 0.2 entgegengewirkt. Eine Zykluszeit von 0,2 Sekunden ist IMO ausreichend und senkt die PAT/PMT-Rate unter 15 kbps. Allerdings kommen noch als Verpackungsmaterial TS- und PES-Header im Video/Audio-Stream oben drauf... keine Ahnung, wie sich das bei Flash und WebM verhält. Da kann ich es leider auch nicht so schön wie bei einem TS mit TransEdit messen. Also ich brauche nicht so viele Presets. Ich würde deine Presets aber mehr an den üblichen Upload-Geschwindigkeiten orientieren. Ist sicher sinnvoll, aber tut der Bildqualität nicht so gut. Die von mir urspünglich ins Auge gefassten vier Presets hatte ich mit einigen Versuchen hinsichtlich Bitrate und Auflöung gut ausbalanciert. Bei Berücksichtigung gängiger Upload-Raten müssen bei dreien die Bitraten herabgesetzt werden:HD 4000 kbit max. 1280 x 720High 2000 kbit max. 720 x 576 ---> 1800 kbitMid 1000 kbit max. 640 x 360 ---> 800 kbitLow 500 kbit max. 480 x 270 ---> 400 kbitAb dem Mid-Preset abwärts sieht man es der Bildqualität deutlich an. Entweder man nimmt es in Kauf, oder man muss mit der Auflösung runtergehen (Mid: 512 x 288, Low 360 x 180). Erhängen oder Erschießen?Unabhängig davon möchte ich in einer neuen Standard-ffmpegprefs.ini jeweils vier einheitliche Presets mit einheitlicher Benennung für alle drei relevanten Streaming-Arten gemäß dem Schema [Typ Qualität] einführen. Typ ist Flash, WP oder WebM, Qualität ist HD, High, Mid oder Low. Macht insgesamt 3 x 4 = 12 Presets. Dazu für jede Streaming-Art genau ein reines Audio-Preset (für Radio) mit 128 kbit gemäß dem Schema [Typ Audio]. Damit wären es 15 Presets. Beispiele: [Flash HD 4000 kbit] [Flash Audio 128 kbit] [WP High 1800 kbit] [WebM Mid 800 kbit] Die Frage ist, ob die Bitrate im Titel erscheinen soll. Einerseits hat sie einen informativen Wert, andererseits muss man dann konsequenterweise den Preset-Titel ändern, wenn man die Bitrate anpasst, und danach führen Referenzen über den Namen ins Leere. Vielleicht wäre es besser, wenn die Zielbitrate in der INI einen separaten Eintrag hätte. Link to comment
Nanohcv Posted October 20, 2015 Share Posted October 20, 2015 Ich würde die Bitrate im Titel belassen. Sonst muss man immer erst in die ffmpegprefs.ini schauen ob das Preset zu seiner Uploadrate passt. Vielleicht die Windows Phone Presets in H264 TS Presets umbenennen oder nur in H264. Dann müssen meine User das zwar ändern aber das sollte ja nicht das Problem sein. Es klingt einfach konsequenter wenn im Titel der Codec steht. Außerdem sollte VinoRosso in seine Android App auch die H264 (bzw. WP) Profile nutzen. Im Gegensatz zu den zu den Flash Profilen (die er jetzt verwendet) funktioniert dann auch die Hardwarebeschleunigung bei der Wiedergabe. Link to comment
epsy Posted October 20, 2015 Share Posted October 20, 2015 Ich habe festgestellt, dass ein Stream mit hoher Bitrate nicht sehr stabil funktioniert. Folgendes Preset wurde gestern nach 45 Minuten beendet: [1800 kbit - Audio 128k]Cmd=-re -threads {threads} {offset} {realtime} -i "{infile}" -threads {threads} -f flv -vcodec libx264 -crf 20 -maxrate 1600k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 128k -ac 2 -y "{outfile}"maxWidth=1280maxHeight=720MimeType=video/x-flvExt=.flvBitrate=1800 Ich finde übrigens die Qualität mit einem definierten FFmpeg Voreinstellung "fast" absolut ausreichend! Höhere Bitraten würden von mir nicht genutzt, zumal Einstellungen um die 4000 kBit bei mir abschmieren. Habt ihr das nicht? Folgende Einstellung habe ich testweise heute Nacht getestet. Lief über 17 Stunden und wurde durch mich beendet: [300 kbit - Audio 32]Cmd=-re -threads {threads} {offset} {realtime} -i "{infile}" -threads {threads} -f flv -vcodec libx264 -crf 24 -maxrate 250k -bufsize 4500k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 32k -ar 32000 -ac 1 -y "{outfile}"maxWidth=360maxHeight=288MimeType=video/x-flvExt=.flvBitrate=300 "RobertSmith, on 14 Oct 2015 - 21:47, said: Die FFmpeg Entwicklern empfehlen den qualitätsbasierten Modus mit Bitratebeschränkung für Streaming. In meinen Tests sind die Ergebnisse damit besser" Ich verwende, wie man auch in den presets sieht, schon seit Jahren crf und maxrate. Ich wäre für folgende Presets: High = 2000 kBit (1280 x 720) Mid = 1.200 kBit (960 x 576) Low = 600 kBit (640 x 384) Ultralow = 300 kBit (360 x 288) Aber für mich viel wichtiger wäre zu erfahren, ob bei euch Presets mit hoher Bitrate stabil laufen... Link to comment
Griga Posted October 20, 2015 Share Posted October 20, 2015 Aber für mich viel wichtiger wäre zu erfahren, ob bei euch Presets mit hoher Bitrate stabil laufen... Bislang keine Probleme. Allerdings habe ich es noch nie so lange laufen lassen. Solche Informationen sind jedoch für dich ohne Wert (und damit auch deine Fragestellung sinnlos), weil es vermutlich davon abhängt, welche ffmpeg-Version im Spiel ist. Wenn du mal hier schaust....ich würde die letzte stabile Version (mit Versionsnummer im Dateinamen) probieren. Hier findest du die 64-Bit-Versionen Ich verwende zur Zeit die 2.8 64 Bit. Zu beachten: Bei neueren Versionen (etwa seit November 2014) hat sich ein wichtiger Default geändert. Die Zeit, die ffmpeg den Input analysiert, ist jetzt 5 Sekunden statt 1 Sekunde. Entprechend länger dauert es, bis der Stream startet. Um das rückgängig zu machen, muss man -analyzeduration 1M an den Anfang des Kommandozeile setzen. 1M = 1 Mega-Mikrosekunde = 1 Sekunde. Link to comment
epsy Posted October 20, 2015 Share Posted October 20, 2015 (edited) Nö, VLC beendet den Stream nach weniger 10 Sekunden und via Flowplayer keine 2 Minuten bevor das Bild steht - bei 4000 kBit. Seltsamerweise läuft intern der Stream weiter laut svcdebug.log Getestet mit der aktuellen Version von FFmpeg! Hatte zuvor aber eine Version aus September 2015 installiert. Also auch nicht wirklich alt! Danke für den Hinweis mit -analyzeduration 1M Kannte ich noch nicht. Hab es im internen LAN noch nicht getestet. Streame also via Heim-PC zum Büro via DSL Keine Angst, genügend Bandbreite ist in beiden Fällen vorhanden! [4000 kbit - Audio 128k]Cmd=-threads {threads} {offset} {realtime} -analyzeduration 1M -i "{infile}" -f flv -vcodec libx264 -crf 17 -maxrate 3800k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 128k -ac 2 -y "{outfile}"maxWidth=1280maxHeight=720MimeType=video/x-flvExt=.flvBitrate=4000 Edited October 20, 2015 by epsy Link to comment
epsy Posted October 20, 2015 Share Posted October 20, 2015 test im internen LAN: Stream bricht auch nach wenigen Sekunden ab (VLC). Via Flowplayer abbruch nach ca. 1 Minute Link to comment
RobertSmith Posted October 20, 2015 Share Posted October 20, 2015 (edited) Ich habe festgestellt, dass ein Stream mit hoher Bitrate nicht sehr stabil funktioniert. [...] Aber für mich viel wichtiger wäre zu erfahren, ob bei euch Presets mit hoher Bitrate stabil laufen... Ich habe die gleichen Probleme, ab 4.000 kbit/s bleibt der Stream nach wenigen Minuten hängen. Sowohl am PC als auch am Smartphone (Android, BSPlayer). FFmpeg wird dabei nicht beendet. Woran könnte es liegen? Verschiedene buffer-Größen habe ich schon erfolglos getestet, auch eine konstante Bitrate (b=minrate=maxrate) löst das Problem nicht. edit: im mpegts-container statt flv, bleibt der Stream nur gelegentlich kurz hängen, läuft aber weiter. Edited October 20, 2015 by RobertSmith Link to comment
RobertSmith Posted October 20, 2015 Share Posted October 20, 2015 Die CPU war nur überfordert (trotz lediglich 65% Auslastung). Ein schnelleres x264 Preset läuft flüssig durch. Link to comment
Griga Posted October 21, 2015 Share Posted October 21, 2015 (edited) Sowas ähnliches kenne ich auch. Meistens teste ich hier mit Server und Client auf dem selben PC. Wenn die Gesamt-CPU-Last bei meinem alten Core Duo (E7500 @2,94 GHz) über 80% steigt, wird es kritisch. Dann stockt die Wiedergabe oder bleibt ganz stehen, je nach Client/Player. Anzunehmen ist, dass die Datenrate in dem Fall zumindest zeitweise unter Echtzeit fällt, so dass es bei Live TV im Server zu Buffer Overflows kommt (Push-Modus, der Sender wartet ja nicht) und im Player zu Buffer Underruns. Zur Frage, welche Presets mit welcher Balance zwischen Auflösung und Bitrate das Angebot umfassen sollte: So macht es das WDR Fernsehen beim HLS Streaming (Master Playliste gekürzt): #EXTM3U#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=184000,RESOLUTION=320x180,CODECS="avc1.66.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=320000,RESOLUTION=480x270,CODECS="avc1.66.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=608000,RESOLUTION=512x288,CODECS="avc1.66.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1216000,RESOLUTION=640x360,CODECS="avc1.77.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1992000,RESOLUTION=960x540,CODECS="avc1.77.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2691000,RESOLUTION=960x540,CODECS="avc1.77.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3776000,RESOLUTION=1280x720,CODECS="avc1.77.30, mp4a.40.2"#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=56000,CODECS="mp4a.40.2" Die Bandbreite wird in Bit/s angegeben, also für kbit drei Nullen streichen. avc1.66.30 entspricht H.264 Baseline, avc1.77.30 ist H.264 Main Profile, mp4a.40.2 ist AAC. Der Kram wird über Akamai ausgeliefert, so dass wohl kaum Begrenzungen der Upload-Rate zu berücksichtigen sind. Eher die Gesamtdatenrate für alle Zuschauer in Spitzenzeiten. Ich denke, wenn man sowohl gängige Upload-Raten berücksichtigen als auch Standard-Auflösungen mit erträglicher Bildqualität liefern will, muss es ein Preset mehr sein, also z.B. in den Abstufungen 400 / 800 / 1200 / 1800 / 4000 kbit. Das niedrigste nennen wir dann Trash. P.S. Und das höchste Crash Edited October 21, 2015 by Griga Link to comment
epsy Posted October 21, 2015 Share Posted October 21, 2015 [400 kbit - Audio 32] Cmd=-threads {threads} {offset} {realtime} -i "{infile}" -analyzeduration 1M -f flv -vcodec libx264 -crf 24 -maxrate 350k -bufsize 4500k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 32k -ar 32000 -ac 1 -y "{outfile}" maxWidth=480 maxHeight=272 MimeType=video/x-flv Ext=.flv Bitrate=400 Nunja, als trash würde ich es nicht bezeichnen, vorausgesetzt als FFmpeg Voreinstellung wird NICHT "ultrafast" oder "superfast" gewählt. Habe es mal testweise mit VLC auf dem iPhone 6 getestet und würde die Qualität in Schulnote bemaßt als 3 einstufen. Und wenn man es mit dem Browser auf dem PC sich anschauet, ist es auch noch mehr als akzeptabel! Aufgrund der geringen Auflösung hält sich die CPU-Last auch in Grenzen. HD-Kanäle zu streamen macht keinen sinn. Erhöht meine CPU-Last auf das Doppelte (im Schnitt ca. 25%) bei FFmpeg Voreinstellung "faster" @RobertSmith habe das 4.000er Profil mal mit Ultrafast getestet. VLC schmiert nach wie vor ab, im Browser scheint es allerdings zu laufen. Link to comment
Griga Posted October 21, 2015 Share Posted October 21, 2015 Das Problem bei hoher CPU Last dürfte auch sein, dass es zu Diskontinuitäten im Datenstrom kommen kann, wo effektiv Teile fehlen. Der Stream entpricht dann nicht mehr den Spezifikationen. Encoder und Decoder müssen mit Ausnahme/Fehlerbedingungen zurechtkommen. Eine Rolle spielt dabei auch die Neigung des DVB-Gerätes bzw. seines Treibers zu Aussetzern. Manche lassen bei hoher Last leicht Daten fallen, andere weniger leicht. Nunja, als trash würde ich es nicht bezeichnen, Es ist reine Poesie: [Flash Trash 400 kbit][Flash Crash 4000 kbit]Na gut, aber welche Bezeichnung dann? Muss kurz und einprägsam sein: ???, Low, Mid, High, HD. Ich versuche gerade, es folgendermaßen auszuarbeiten: 400 kbit 480 x 270 800 kbit 512 x 288 1200 kbit 640 x 360 1800 kbit 720 x 576 3600 kbit 1280 x 720 Link to comment
epsy Posted October 21, 2015 Share Posted October 21, 2015 (edited) Low - 400 kbit 480 x 270 Mid - 800 kbit 640 x 360 High SD - 1200 kbit 720 x 400 High+ HD - 1800 kbit 960 x 540 Ultra+ HD - 3600 kbit 1280 x 720 Auflösungwünsche von mir Bei 1800 kBit kann man meiner Meinung ganz gut mit 960 x 540 streamen Und 1200 kBit für SD-Inhalte in 720 x 400 sind meiner Meinung nach völlig ausreichend! [ultra+ HD - 3600 kbit]Cmd=-threads {threads} {offset} {realtime} -analyzeduration 1M -i "{infile}" -f flv -vcodec libx264 -crf 18 -maxrate 3300k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 128k -ac 2 -y "{outfile}"maxWidth=1280maxHeight=720MimeType=video/x-flvExt=.flvBitrate=3600 [High+ HD - 1800 kbit]Cmd=-threads {threads} {offset} {realtime} -analyzeduration 1M -i "{infile}" -f flv -vcodec libx264 -crf 20 -maxrate 1600k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 128k -ac 2 -y "{outfile}"maxWidth=960maxHeight=540MimeType=video/x-flvExt=.flvBitrate=1800 [High SD - 1200 kbit]Cmd=-threads {threads} {offset} {realtime} -analyzeduration 1M -i "{infile}" -f flv -vcodec libx264 -crf 21 -maxrate 1000k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 128k -ac 2 -y "{outfile}"maxWidth=720maxHeight=400MimeType=video/x-flvExt=.flvBitrate=1800 [Mid - 800 kbit]Cmd=-threads {threads} {offset} {realtime} -analyzeduration 1M -i "{infile}" -f flv -vcodec libx264 -crf 21 -maxrate 680k -bufsize 9000k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 96k -ac 2 -y "{outfile}"maxWidth=640maxHeight=360MimeType=video/x-flvExt=.flvBitrate=800 [Low - 400 kbit]Cmd=-threads {threads} {offset} {realtime} -i "{infile}" -analyzeduration 1M -f flv -vcodec libx264 -crf 24 -maxrate 350k -bufsize 4500k {framerate} -map 0:0 -map 0:1 -vf "yadif=0:-1:1, scale={scalex}:{scaley}" -preset {vpreset} -tune film -profile:v high -level 3.1 -acodec libvo_aacenc -b:a 32k -ar 32000 -ac 1 -y "{outfile}"maxWidth=480maxHeight=272MimeType=video/x-flvExt=.flvBitrate=400 so in etwa?? kannst ja mal testen. Ich meine es passt Edited October 21, 2015 by epsy Link to comment
Griga Posted October 21, 2015 Share Posted October 21, 2015 [400 kbit - Audio 32] @Epsy: Du hast den Bitraten-Overhead durch das Container-Format nicht ausreichend berücksichtigt. Die Rechnung "Maximale Video-Bitrate + Audio Bitrate = Maximale Ziel-Bitrate" geht deshalb nicht auf. Wenn z.B. TS Output tatsächlich auf maximal 400 kbit kommen soll, musst du mit der Video-Bitrate auf ca. 300 kbit runter. Und dann stimmt auch Trash Am besten lässt sich das (leider nur bei TS) mit dem TransEdit 4.1 Analyzer messen, der die Gesamtbitrate mitsamt Container anzeigt und die Möglichkeit bietet, verschiedene Arten der Mittelwertbildung auszuwählen, von momentane Bitrate (Mittelwert der letzten Sekunde) bis Mittelwert über die gesamte Zeit. Der Screenshot zeigt den Mittelwert über eine Minute bei -maxrate 300k und -ab 32k. Da siehst du, was an Overhead zusammenkommt. Bei PAT und PMT habe ich schon mit -pat_period 0.2 eingegriffen, sonst würden die zusammen 40 kbps beschlagnahmen. Link to comment
Griga Posted October 21, 2015 Share Posted October 21, 2015 (edited) High SD - 1200 kbit 720 x 400 400 ist schlecht. Ich erkläre mal kurz warum. In der Standardeinstellung (URL Parameter keepres=h) wird nur die horizontale Begrenzung der Auflösung berücksichtigt. Die vertikale Vorgabe wird ignoriert. Sie wird intern so berechnet, dass bei quadratischen Pixeln das Seitenverhältnis des Outputs dem des Inputs entspricht. Bei 720 horizontal und 16:9 sind das 720 / 16 x 9 = 404 vertikal (auf die nächste gerade Zahl abgerundet). SD mit 720 x 576 Input-Auflösung wird also vertikal runterskaliert. Bei 4:3 Input Aspect Ratio wären es dagegen 720 / 4 x 3 = 540! Dass du MaxHeight auf 400 gesetzt hast, interessiert niemand. BTW: Bei der Balance zwischen Bitrate und Auflösung ist zu berücksichtigen, dass letztere durch 4:3 höher wird! Bei 480 horizontal kommst du auf 480 / 4 * 3 = 360 statt 288. Also noch mehr Trash Bei keepres=v wird dagegen die vertikale Begrenzung berücksichtigt und die horizontale ignoriert. Die Folgen kannst du dir bei MaxHeigth = 400 selbst ausrechnen... deshalb sollte MaxWidth x MaxHeigth = 720 x 576 sein, einfach um zu vermeiden, das FFmpeg bei dieser Einstellung und SD TV Input unnötig vertikal skaliert. Die resultierende Auflösung mit keepres=v ist dann übrigens 1024 x 576, d.h. SD wird vertikal horizontal hochskaliert. Interessant ist die Einstellung keepres=hv. Damit wird sowohl die horizontale als auch die vertikale Begrenzung berücksichtigt. Mit MaxHeigth = 576 ist bei SD TV dann 720 x 576 sowohl die Input als auch die Output-Auflösung. FFmpeg braucht überhaupt nicht mehr skalieren. Allerdings erhälst du so einen anamorphen Output mit nicht-quadratischen Pixeln. Mit anderen Worten: Dann muss der Client/Player auf das richtige Seitenverhältnis skalieren (falls er das kann), sonst gibt es Eierköpfe. Alles klar? Eine Wissenschaft für sich... Edited October 21, 2015 by Griga Korrektur Link to comment
RobertSmith Posted October 21, 2015 Share Posted October 21, 2015 -maxrate 350k -bufsize 4500kDie Puffergröße gibt an, für welche Intervalle (bufsize/maxrate) die maximale Bitrate eingehalten werden soll. In deinem Beispiel muss die durchschnittliche Bitrate für jeden 13 Sekunden Abschnitt unter 350k liegen. Z.b. 10 Sekunden 150 kbit/s + 3 Sekunden 1.000 kbit/s = 350 kbit/s. Für Streaming ist das nicht geeignet. Der Puffer von ffmpeg sollte dem Puffer des Players entsprechen, 1-2 Sekunden. Link to comment
Griga Posted October 21, 2015 Share Posted October 21, 2015 Danke für die Erläuterung Das war mir auch noch nicht ganz klar. Link to comment
epsy Posted October 21, 2015 Share Posted October 21, 2015 Ich bin ein wenig überrascht von den ganzen Weisheiten... Warum wurden diese dann nicht viel früher mal diskutiert bzw. umgesetzt Schön das darüber mal gesprochen wurde/wird Dann dürft ich Euch doch freundlich darum bitten, Presetsempfehlungen auf Basis Euerer Weisheiten zu veröffentlichen Ich würde mir diese gerne mir mal ansehen Link to comment
Griga Posted October 21, 2015 Share Posted October 21, 2015 Ich werde hier demnächst die vorläufigen Presets für das nächste RS Release zwecks Beurteilung eurerseits bereitstellen. Sind aber noch nicht ganz fertig... Link to comment
RobertSmith Posted October 21, 2015 Share Posted October 21, 2015 (edited) Dann dürft ich Euch doch freundlich darum bitten, Presetsempfehlungen auf Basis Euerer Weisheiten zu veröffentlichen Ich würde mir diese gerne mir mal ansehen Meine sind etwas umfangreicher, da ich aus alles Auflösungen und Bitraten das Optimium rausholen möchte. Dadurch habe ich 12 statt 4 Presets. In meinen Playlisten (1 je Bitrate) sind dann je nach Senderauflösung die Presets zugewiesen. ffmpegprefs.ini Edited October 21, 2015 by RobertSmith 1 Link to comment
Recommended Posts