FFmpeg direkt im Browser nutzen - FFMPEG.WASM

[slashCAM]

FFmpeg stellt zahlreiche Codecs und Werkzeuge zum Verarbeiten von Audio und Video zur Verfügung, die wiederum sowohl selbständig "Standalone" als auch als Funktionen von ...

Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
FFmpeg direkt im Browser nutzen - FFMPEG.WASM

[Frank Glencairn]

Denn durch die Transcompilation des Codes wird FFmpeg im Browser sicherlich langsamer laufen als als native Applikation.
Dennoch: Wer beispielsweise Transcoding Anwendungen im Browser anbieten will, muss die Videoclips nun nicht mehr über das Netz an einen Server schicken, sondern kann dies lokal, sogar ganz ohne Internet bewerkstelligen.

Und welchen Vorteil hätte ich dann davon, das Transcoding umständlich und langsam im Browser zu machen statt in der performanten stand alone?

[vaio]

Denn durch die Transcompilation des Codes wird FFmpeg im Browser sicherlich langsamer laufen als als native Applikation.
Dennoch: Wer beispielsweise Transcoding Anwendungen im Browser anbieten will, muss die Videoclips nun nicht mehr über das Netz an einen Server schicken, sondern kann dies lokal, sogar ganz ohne Internet bewerkstelligen.

Und welchen Vorteil hätte ich dann davon, das Transcoding umständlich und langsam im Browser zu machen statt in der performanten stand alone?

[Frank Glencairn]

Das beantwortet meine Frage nicht, eine Standalone Version wäre ja ebenfalls lokal und ohne Internet.

[Darth Schneider]

Es geht doch wahrscheinlich nur darum das wenn man das Rendering gleich im Browser macht, verdient der FFmpeg Erfinder womöglich um Welten mehr Geld….;)
Oder sieht ihr das anders ?
Gruss Boris

[cantsin]

ffmpeg ist Open Source-Software.

Den Vorteil so einer Lösung sehe ich darin, dass Webdienste das Transcoding auf den Browser/Client verlagern können.

Bei YouTube & Co. läuft ebenfalls ffmpeg auf den Serverfarmen, um hochgeladene Videos in die tatsächlichen Streamingformate zu transcodieren. Die nötige Rechenleistung macht einen erheblichen Teil der Betriebskosten dieser Plattformen aus.

Dienste wie YouTube und Vimeo könnten mit dieser Lösung das Transcoding optional beim Nutzer machen lassen, dabei aber (im Gegensatz zu einem als Desktop-Software beim User installierten ffmpeg/Handbrake/Shutter Encoder) über den Browser alle Encoding-Parameter kontrollieren bzw. steuern. Im Gegenzug könnten die Plattformen ihren Nutzern Vorteile einräumen wie z.B. schnelleres Bereitstellen des Videos oder reduzierte Abogebühren.

Für kleine Websites/-dienste (wie z.B. selbstgehostete WordPress-Sites) öffnet diese Lösung wahrscheinlich sogar den einzigen vernünftigen Weg, Nutzern Videouploads zu erlauben.

[prime]

Dienste wie YouTube und Vimeo könnten mit dieser Lösung das Transcoding optional beim Nutzer machen lassen, dabei aber (im Gegensatz zu einem als Desktop-Software beim User installierten ffmpeg/Handbrake/Shutter Encoder) über den Browser alle Encoding-Parameter kontrollieren bzw. steuern.

Ich kenne mich mit WebAssembly nicht aus aber zumindest bei normalen JS/HTML kann man Serverseitig niemals den Userinput oder hochgeladenen Dateien "vertrauen" (siehe SQL Injection). Also inwieweit kann der User WebAssembly Objekte manipulieren und z.B. doch eine höhere Bitrate einstellen odere andere Dinge dem Server unterjubeln. Auch wenn man Serverseitig eine Validierung vornimmt, wenn man am Transcoding spart, liefert man mehr oder weniger Nutzergenerierte Dateien aus.

Es ist auf jeden Fall interessant und gleichzeitig absurd. Ich habs mal ausprobiert, mit H264/mp4 Ausgangsmaterial funktioniert es aber ProRes will er nicht. Die Browserversion ist in meinen Test ca: ca. 4-5x langsamer als die native Version.

Der einzige "Vorteil" ist das ffmpeg hiermit sehr leicht "verfügbar" gemacht werden kann. Also quasi für Leute die schon damit überfordert sind ShutterEncoder/Handbrake etc. runterzuladen, installieren und dann auch noch das Transcoding zu machen.

[dienstag_01]

ffmpeg ist Open Source-Software.

Den Vorteil so einer Lösung sehe ich darin, dass Webdienste das Transcoding auf den Browser/Client verlagern können.

Bei YouTube & Co. läuft ebenfalls ffmpeg auf den Serverfarmen, um hochgeladene Videos in die tatsächlichen Streamingformate zu transcodieren. Die nötige Rechenleistung macht einen erheblichen Teil der Betriebskosten dieser Plattformen aus.

Dienste wie YouTube und Vimeo könnten mit dieser Lösung das Transcoding optional beim Nutzer machen lassen, dabei aber (im Gegensatz zu einem als Desktop-Software beim User installierten ffmpeg/Handbrake/Shutter Encoder) über den Browser alle Encoding-Parameter kontrollieren bzw. steuern. Im Gegenzug könnten die Plattformen ihren Nutzern Vorteile einräumen wie z.B. schnelleres Bereitstellen des Videos oder reduzierte Abogebühren.

Für kleine Websites/-dienste (wie z.B. selbstgehostete WordPress-Sites) öffnet diese Lösung wahrscheinlich sogar den einzigen vernünftigen Weg, Nutzern Videouploads zu erlauben.

Weil es jetzt möglich ist, encodieren wir jetzt alle Videos im Browser.
Videos einfach anzeigen war gestern ;)

[cantsin]

Weil es jetzt möglich ist, encodieren wir jetzt alle Videos im Browser.
Videos einfach anzeigen war gestern ;)

Vor 17 Jahren (als YouTube anfing) hätten Foristen geschrieben: Weil es jetzt möglich ist, spielen wir alle Videos im Browser ab. Einfach mal den Quicktime-Player anwerfen war gestern...

Und noch davor: Weil es jetzt möglich ist, machen wir Textverarbeitung im Browser. Texte einfach anzeigen war gestern.

[cantsin]

Ich kenne mich mit WebAssembly nicht aus aber zumindest bei normalen JS/HTML kann man Serverseitig niemals den Userinput oder hochgeladenen Dateien "vertrauen" (siehe SQL Injection).

Direkte code injection ist wohl nicht möglich - und daher dürften Video-Uploads in ein browserseitiges ffmpeg unproblematisch sein -, aber es gibt durchaus andere Sicherheitsbedenken: https://www.fastly.com/blog/hijacking-c ... ebassembly

Ansonsten hast Du das code injection-Problem potentiell bei jeder Website, die Video-Uploads anbietet - wenn da der UI-Code und Server-Code der Webapplikation unsicher geschrieben ist und übermittelte Strings nicht prüft, oder falls es Sicherheitslücken in ffmpeg geben sollte. Das ist völlig unabhängig davon, ob ffmpeg auf dem Client oder Server läuft. Man könnte sogar argumentieren, dass die Client-seitige Lösung Risiken vermindert, weil man mit ihr besser sicherstellen kann, dass wirklich nur Videodaten auf den Server hochgeladen werden.

[dienstag_01]

Weil es jetzt möglich ist, encodieren wir jetzt alle Videos im Browser.
Videos einfach anzeigen war gestern ;)

Vor 17 Jahren (als YouTube anfing) hätten Foristen geschrieben: Weil es jetzt möglich ist, spielen wir alle Videos im Browser ab. Einfach mal den Quicktime-Player anwerfen war gestern...

Und noch davor: Weil es jetzt möglich ist, machen wir Textverarbeitung im Browser. Texte einfach anzeigen war gestern.

Du verwechselst zwar einiges, wahrscheinlich ist dir auch nicht bewusst, dass vor dem Encoding das Decoding liegt, aber egal, 17 Jahre warten bist zum Durchbruch dieser genialen Idee des Client-Enccodings bei Youtube Videos ist weltgeschichtlich nichts. Bin schon ganz hibbelig ;)

[cantsin]

Vor 17 Jahren (als YouTube anfing) hätten Foristen geschrieben: Weil es jetzt möglich ist, spielen wir alle Videos im Browser ab. Einfach mal den Quicktime-Player anwerfen war gestern...

Und noch davor: Weil es jetzt möglich ist, machen wir Textverarbeitung im Browser. Texte einfach anzeigen war gestern.

Du verwechselst zwar einiges, wahrscheinlich ist dir auch nicht bewusst, dass vor dem Encoding das Decoding liegt, aber egal, 17 Jahre warten bist zum Durchbruch dieser genialen Idee des Client-Enccodings bei Youtube Videos ist weltgeschichtlich nichts. Bin schon ganz hibbelig ;)

Dass vor dem Encoding das Decoding liegt, war mir zufälligerweise bekannt, steckt ja bereits im Wort "Codec".

Sag mal, da Du hier nicht ansatzweise argumentierst oder Deine Behauptungen belegst (und stattdessen Leersätze wie "Du verwechselt zwar einiges" absonderst), kann es sein, dass Du derjenige bist, der diese Technik nicht begriffen hat?

Also nochmal langsam:

Heutiger/klassischer Online-Video-Upload-Workflow:
(a) Nutzer rendert eine Upload-Videodatei für YouTube, Vimeo, Facebook & Co., im besten Fall nach den Formatvorgaben der jeweiligen Plattform, und lädt die auf die Plattform hoch.
(b) Auf der Serverfarm der Plattform wird das hochgeladene Video in mehrere Stream-Endformate transcodiert. Bei einem typischen YouTube-Video sind das Streams in verschiedenen Auflösungen (360p/480p/720p/1080p/1440p/UHD) sowie in verschiedenen Codecs (h264, VP9, AV1) und Containern (mp4, webm).
(c) Praktisch alle Plattformen verwenden das vom User hochgeladene Originalvideo nur als ihr eigenes Transcoding-Master und bieten es nicht als Stream an. (Ausnahme: Vimeo, über die "Download"-Funktion). Was tatsächlich gestreamt wird, ist immer eine qualitativ schlechtere Version des hochgeladenen Videos mit i.d.R. niedrigeren Bitraten.

Was YouTube für ein einziges Video alles an Streaming-Formaten (bzw. Kombinationen von Auflösungen und Codecs) anbietet, kann man sich sehr schön mit Tools wie yt-dlp (mit dem Schalter "-F") anzeigen lassen. Hier z.B. Slashcams Testvideo der Fuji X-H2:

Code: Alles auswählen

599 m4a   audio only      2 |    1.17MiB   31k https | audio only        mp4a.40.5   31k 22k ultralow, m4a_dash
600 webm  audio only      2 |    1.25MiB   33k https | audio only        opus        33k 48k ultralow, webm_dash
139 m4a   audio only      2 |    1.85MiB   49k https | audio only        mp4a.40.5   49k 22k low, m4a_dash
249 webm  audio only      2 |    1.84MiB   49k https | audio only        opus        49k 48k low, webm_dash
250 webm  audio only      2 |    2.44MiB   64k https | audio only        opus        64k 48k low, webm_dash
140 m4a   audio only      2 |    4.90MiB  129k https | audio only        mp4a.40.2  129k 44k medium, m4a_dash
251 webm  audio only      2 |    4.85MiB  128k https | audio only        opus       128k 48k medium, webm_dash
17  3gp   176x144      6  1 |    2.65MiB   70k https | mp4v.20.3     70k mp4a.40.2    0k 22k 144p
597 mp4   256x108     13    |  896.96KiB   23k https | avc1.4d400b   23k video only          144p, mp4_dash
598 webm  256x108     13    |  750.45KiB   19k https | vp9           19k video only          144p, webm_dash
160 mp4   256x108     25    |    1.94MiB   51k https | avc1.4d400b   51k video only          144p, mp4_dash
278 webm  256x108     25    |    1.94MiB   51k https | vp9           51k video only          144p, webm_dash
133 mp4   426x182     25    |    4.28MiB  113k https | avc1.4d400d  113k video only          240p, mp4_dash
242 webm  426x182     25    |    2.70MiB   71k https | vp9           71k video only          240p, webm_dash
134 mp4   640x272     25    |    7.66MiB  202k https | avc1.4d4015  202k video only          360p, mp4_dash
18  mp4   640x272     25  2 |   11.25MiB  297k https | avc1.42001E  297k mp4a.40.2    0k 44k 360p
243 webm  640x272     25    |    4.22MiB  111k https | vp9          111k video only          360p, webm_dash
135 mp4   854x364     25    |   13.97MiB  369k https | avc1.4d401e  369k video only          480p, mp4_dash
244 webm  854x364     25    |    6.90MiB  182k https | vp9          182k video only          480p, webm_dash
22  mp4   1280x544    25  2 | ~ 31.86MiB  821k https | avc1.64001F  821k mp4a.40.2    0k 44k 720p
136 mp4   1280x544    25    |   26.20MiB  692k https | avc1.64001f  692k video only          720p, mp4_dash
247 webm  1280x544    25    |   11.63MiB  307k https | vp9          307k video only          720p, webm_dash
137 mp4   1920x818    25    |   55.10MiB 1456k https | avc1.640028 1456k video only          1080p, mp4_dash
248 webm  1920x818    25    |   23.70MiB  626k https | vp9          626k video only          1080p, webm_dash
271 webm  2560x1090   25    |   65.39MiB 1727k https | vp9         1727k video only          1440p, webm_dash
313 webm  3840x1634   25    |  218.13MiB 5763k https | vp9         5763k video only          2160p, webm_dash

Das ganze ist für Google - bei z.Zt. 3,7 Millionen Video-Uploads pro Tag - so aufwändig und teuer, dass sie für ihre YouTube-Serverfarmen gerade einen eigenen Video-Transcoderchip entwickeln.

Und sicher wird das Server-seitige Transcoding der Mainstream-Standard bleiben. Wenn jedoch auch Browser-/clientseitig Video-Transcoding möglich ist (wie jetzt mit dieser ffmpeg-Web Assembly-Lösung, auch wenn die vielleicht nur ein vorläufiger experimenteller Ansatz bleiben sollte), können Plattformen wie Google/YouTube, Vimeo oder eben auch kleine WordPress-Sites das Transcoding in die tatsächlichen Stream-Formate an den Nutzer auslagern, es zugleich aber über ihre Webinterfaces erledigen & steuern, so dass sich für den Nutzer am bisherigen Upload-Workflow nichts ändert außer der zusätzlich nötigen Rechenzeit.

Zumindest können Google & Co. so handfest Rechenleistung und damit Geld sparen. Für Betreiber von kleinen Websites (wie WordPress-Blogs) ist das sogar die einzige realistische Möglichkeit, nutzerseitige Video-Uploads (z.B. als Teil von Blogpostings) zu erlauben, weil anderenfalls das nötige Stream-Transcoding den WordPress-Server in die Knie zwingen würde.

[dienstag_01]

Du verwechselst zwar einiges, wahrscheinlich ist dir auch nicht bewusst, dass vor dem Encoding das Decoding liegt, aber egal, 17 Jahre warten bist zum Durchbruch dieser genialen Idee des Client-Enccodings bei Youtube Videos ist weltgeschichtlich nichts. Bin schon ganz hibbelig ;)

Dass vor dem Encoding das Decoding liegt, war mir zufälligerweise bekannt, steckt ja bereits im Wort "Codec".

Sag mal, da Du hier nicht ansatzweise argumentierst oder Deine Behauptungen belegst (und stattdessen Leersätze wie "Du verwechselt zwar einiges" absonderst), kann es sein, dass Du derjenige bist, der diese Technik nicht begriffen hat?

Also nochmal langsam:

Heutiger/klassischer Online-Video-Upload-Workflow:
(a) Nutzer rendert eine Upload-Videodatei für YouTube, Vimeo, Facebook & Co., im besten Fall nach den Formatvorgaben der jeweiligen Plattform, und lädt die auf die Plattform hoch.
(b) Auf der Serverfarm der Plattform wird das hochgeladene Video in mehrere Stream-Endformate transcodiert. Bei einem typischen YouTube-Video sind das Streams in verschiedenen Auflösungen (360p/480p/720p/1080p/1440p/UHD) sowie in verschiedenen Codecs (h264, VP9, AV1) und Containern (mp4, webm).
(c) Praktisch alle Plattformen verwenden das vom User hochgeladene Originalvideo nur als ihr eigenes Transcoding-Master und bieten es nicht als Stream an. (Ausnahme: Vimeo, über die "Download"-Funktion). Was tatsächlich gestreamt wird, ist immer eine qualitativ schlechtere Version des hochgeladenen Videos mit i.d.R. niedrigeren Bitraten.

Was YouTube für ein einziges Video alles an Streaming-Formaten (bzw. Kombinationen von Auflösungen und Codecs) anbietet, kann man sich sehr schön mit Tools wie yt-dlp (mit dem Schalte "-F") anzeigen lassen. Hier z.B. Slashcams Testvideo der Fuji X-H2:

Code: Alles auswählen

599 m4a   audio only      2 |    1.17MiB   31k https | audio only        mp4a.40.5   31k 22k ultralow, m4a_dash
600 webm  audio only      2 |    1.25MiB   33k https | audio only        opus        33k 48k ultralow, webm_dash
139 m4a   audio only      2 |    1.85MiB   49k https | audio only        mp4a.40.5   49k 22k low, m4a_dash
249 webm  audio only      2 |    1.84MiB   49k https | audio only        opus        49k 48k low, webm_dash
250 webm  audio only      2 |    2.44MiB   64k https | audio only        opus        64k 48k low, webm_dash
140 m4a   audio only      2 |    4.90MiB  129k https | audio only        mp4a.40.2  129k 44k medium, m4a_dash
251 webm  audio only      2 |    4.85MiB  128k https | audio only        opus       128k 48k medium, webm_dash
17  3gp   176x144      6  1 |    2.65MiB   70k https | mp4v.20.3     70k mp4a.40.2    0k 22k 144p
597 mp4   256x108     13    |  896.96KiB   23k https | avc1.4d400b   23k video only          144p, mp4_dash
598 webm  256x108     13    |  750.45KiB   19k https | vp9           19k video only          144p, webm_dash
160 mp4   256x108     25    |    1.94MiB   51k https | avc1.4d400b   51k video only          144p, mp4_dash
278 webm  256x108     25    |    1.94MiB   51k https | vp9           51k video only          144p, webm_dash
133 mp4   426x182     25    |    4.28MiB  113k https | avc1.4d400d  113k video only          240p, mp4_dash
242 webm  426x182     25    |    2.70MiB   71k https | vp9           71k video only          240p, webm_dash
134 mp4   640x272     25    |    7.66MiB  202k https | avc1.4d4015  202k video only          360p, mp4_dash
18  mp4   640x272     25  2 |   11.25MiB  297k https | avc1.42001E  297k mp4a.40.2    0k 44k 360p
243 webm  640x272     25    |    4.22MiB  111k https | vp9          111k video only          360p, webm_dash
135 mp4   854x364     25    |   13.97MiB  369k https | avc1.4d401e  369k video only          480p, mp4_dash
244 webm  854x364     25    |    6.90MiB  182k https | vp9          182k video only          480p, webm_dash
22  mp4   1280x544    25  2 | ~ 31.86MiB  821k https | avc1.64001F  821k mp4a.40.2    0k 44k 720p
136 mp4   1280x544    25    |   26.20MiB  692k https | avc1.64001f  692k video only          720p, mp4_dash
247 webm  1280x544    25    |   11.63MiB  307k https | vp9          307k video only          720p, webm_dash
137 mp4   1920x818    25    |   55.10MiB 1456k https | avc1.640028 1456k video only          1080p, mp4_dash
248 webm  1920x818    25    |   23.70MiB  626k https | vp9          626k video only          1080p, webm_dash
271 webm  2560x1090   25    |   65.39MiB 1727k https | vp9         1727k video only          1440p, webm_dash
313 webm  3840x1634   25    |  218.13MiB 5763k https | vp9         5763k video only          2160p, webm_dash

Das ganze ist für Google - bei z.Zt. 3,7 Millionen Video-Uploads pro Tag - so aufwändig und teuer, dass sie für ihre YouTube-Serverfarmen gerade einen eigenen Video-Transcoderchip entwickeln.

Und sicher wird das Server-seitige Transcoding der Mainstream-Standard bleiben. Wenn jedoch auch Browser-/clientseitig Video-Transcoding möglich ist (wie jetzt mit dieser ffmpeg-Web Assembly-Lösung, auch wenn die vielleicht nur ein vorläufiger experimenteller Ansatz bleiben sollte), können Plattformen wie Google/YouTube, Vimeo oder eben auch kleine WordPress-Sites das Transcoding in die tatsächlichen Stream-Formate an den Nutzer auslagern, es zugleich aber über ihre Webinterfaces erledigen & steuern, so dass sich für den Nutzer am bisherigen Upload-Workflow nichts ändert außer der zusätzlich nötigen Rechenzeit.

Zumindest können Google & Co. so handfest Rechenleistung und damit Geld sparen. Für Betreiber von kleinen Websites (wie WordPress-Blogs) ist das sogar die einzige realistische Möglichkeit, nutzerseitige Video-Uploads (z.B. als Teil von Blogpostings) zu erlauben, weil anderenfalls das nötige Stream-Transcoding den WordPress-Server in die Knie zwingen würde.

Ich sehe gerade, nein, du verwechselst nichts, du möchtest bewusst diesen Umweg gehen.
Derzeit sieht es so aus: YT stellt ein Video bereit, beim User wird es decodiert und abgespielt.
Dein Weg ist: YT stellt ein Video bereit, beim User wird es decodiert, danach in ein neues Format encodiert um es danach wieder zu decodieren und abzuspielen.
Vielleicht findest du Verbündetet für diesen Weg ;)

[cantsin]

Ich sehe gerade, nein, du verwechselst nichts, du möchtest bewusst diesen Umweg gehen.
Derzeit sieht es so aus: YT stellt ein Video bereit, beim User wird es decodiert und abgespielt.
Dein Weg ist: YT stellt ein Video bereit, beim User wird es decodiert, danach in ein neues Format encodiert um es danach wieder zu decodieren und abzuspielen.
Vielleicht findest du Verbündetet für diesen Weg ;)

Nein, Du kapierst es wirklich nicht.

Sowieso stellt erstmal nicht YT ein Video bereit, sondern der Nutzer, der es auf die Plattform hochlädt.

Noch langsamer, und in Deinen Worten:

Derzeit sieht es so aus:
- User 1 rendert eine Videodatei, lädt sie auf YT hoch
- YT transcodiert auf seinem Server die hochgeladene Datei in 25 neue Stream-Dateien (in verschiedenen Auflösungen und Codecs), mit der Rechenleistung des Servers
- YT stellt dieses Video in diesen 25 alternativen Streams bereit.
- Bei User 2 [und 3 und 4 etc.] wird das Video decodiert. Dabei streamt YT je nach dessen Endgerät und Internetbandreite einen der 25 Streams [oder wechselt auch dynamisch zwischen diesen Streams, Stichwort "adaptive Streaming"].

Alternatives Szenario, mit Browser-/Client-seitigem Transcoder:

- User 1 rendert eine Videodatei, klickt den "Upload"-Knopf von YT
- YT lädt diese Datei nicht auf seinen Server hoch, sondern jagt sie durch den Browser-seitigen Transcoder von User 1 und erzeugt alle nötigen Stream-Endformate. Die dafür nötige Rechenzeit fällt auf dem PC von User 1 an.
- Der YT-Server zieht sich die im Browser transcodierten Streams und bietet sie direkt an.
- Bei User 2 [3,4] wird das Video decodiert...

[dienstag_01]

Ich sehe gerade, nein, du verwechselst nichts, du möchtest bewusst diesen Umweg gehen.
Derzeit sieht es so aus: YT stellt ein Video bereit, beim User wird es decodiert und abgespielt.
Dein Weg ist: YT stellt ein Video bereit, beim User wird es decodiert, danach in ein neues Format encodiert um es danach wieder zu decodieren und abzuspielen.
Vielleicht findest du Verbündetet für diesen Weg ;)

Nein, Du kapierst es wirklich nicht.

Sowieso stellt erstmal nicht YT ein Video bereit, sondern der Nutzer, der es auf die Plattform hochlädt.

Noch langsamer, und in Deinen Worten:

Derzeit sieht es so aus:
- User 1 rendert eine Videodatei, lädt sie auf YT hoch
- YT transcodiert auf seinem Server die hochgeladene Datei in 25 neue Stream-Dateien (in verschiedenen Auflösungen und Codecs), mit der Rechenleistung des Servers
- YT stellt dieses Video in diesen 25 alternativen Streams bereit.
- Bei User 2 [und 3 und 4 etc.] wird das Video decodiert. Dabei streamt YT je nach dessen Endgerät und Internetbandreite einen der 25 Streams [oder wechselt auch dynamisch zwischen diesen Streams, Stichwort "adaptive Streaming"].

Alternatives Szenario, mit Browser-/Client-seitigem Transcoder:

- User 1 rendert eine Videodatei, klickt den "Upload"-Knopf von YT
- YT lädt diese Datei nicht auf seinen Server hoch, sondern jagt sie durch den Browser-seitigen Transcoder von User 1 und erzeugt alle nötigen Stream-Endformate. Die dafür nötige Rechenzeit fällt auf dem PC von User 1 an.
- Der YT-Server zieht sich die im Browser transcodierten Streams und bietet sie direkt an.
- Bei User 2 [3,4] wird das Video decodiert...

Ah, du meinst vor dem Upload, das hatte ich wirklich nicht verstanden.
Könnte man machen, allerdings spricht es nicht gerade dafür, dass bisher noch nicht einmal ein Versuch in diese Richtung unternommen wurde. Und der wäre ja auch ohne Browser - was es sicherlich vom Handling her vereinfacht - möglich gewesen.
Aber ok, vielleicht sieht da irgendwer Potential.

[cantsin]

Könnte man machen, allerdings spricht es nicht gerade dafür, dass bisher noch nicht einmal ein Versuch in diese Richtung unternommen wurde. Und der wäre ja auch ohne Browser - was es sicherlich vom Handling her vereinfacht - möglich gewesen.

Ja, aber in diesem letzteren Fall müsste sich die Plattform/der Server darauf verlassen, dass der User wirklich 100% die gewünschten Encoding-Parameter verwendet (die ja sehr speziell sein können und mit allen möglichen esoterischen Flags und Optimierungen, wie sie ffmpeg in Hülle und Fülle anbietet), ohne dass man das Plattform-/Server-seitig gut kontrollieren könnte. Bei browserseitigem Transcoder könnte die Plattform das Transcoding komplett steuern und sichergehen, dass die richtigen Parameter gesetzt sind.

Und wie gesagt, sehe ich mögliche Einsatzszenarien vor allem auf kleinen Servern wie z.B. WordPress-Installationen. Heute ist es für die einerseits zu riskant, das Stream-Transcoding vollständig dem Nutzer und seiner externen Software bzw. Encoding-Kompetenz zu überlassen, und andererseits zu rechenaufwändig, um es auf dem Server zu erledigen. Was konkret zur Folge hat, dass solche Server heute zwar Standbild-, aber keine Video-Uploads erlauben. Für die könnten browserseitige Transcoder eine wirkliche Lösung sein, auch weil sie die nötigen Mittel bieten, um durch dann Server-seitig gesetzte Parameter Upload-Videos in Laufzeit, Dateigröße, Auflösung etc. zu beschränken.


(Aber sowieso hat ein Browser-seitiger Transcoder ja nur vor Uploads Sinn. Daher war ich davon ausgegangen, dass das eine selbstverständliche Annahme ist.)

[dienstag_01]

Könnte man machen, allerdings spricht es nicht gerade dafür, dass bisher noch nicht einmal ein Versuch in diese Richtung unternommen wurde. Und der wäre ja auch ohne Browser - was es sicherlich vom Handling her vereinfacht - möglich gewesen.

Ja, aber in diesem letzteren Fall müsste sich die Plattform/der Server darauf verlassen, dass der User wirklich 100% die gewünschten Encoding-Parameter verwendet (die ja sehr speziell sein können und mit allen möglichen esoterischen Flags und Optimierungen, wie sie ffmpeg in Hülle und Fülle anbietet), ohne dass man das Plattform-/Server-seitig gut kontrollieren könnte. Bei browserseitigem Transcoder könnte die Plattform das Transcoding komplett steuern und sichergehen, dass die richtigen Parameter gesetzt sind.

Und wie gesagt, sehe ich mögliche Einsatzszenarien vor allem auf kleinen Servern wie z.B. WordPress-Installationen. Heute ist es für die einerseits zu riskant, das Stream-Transcoding vollständig dem Nutzer und seiner externen Software bzw. Encoding-Kompetenz zu überlassen, und andererseits zu rechenaufwändig, um es auf dem Server zu erledigen. Was konkret zur Folge hat, dass solche Server heute zwar Standbild-, aber keine Video-Uploads erlauben. Für die könnten browserseitige Transcoder eine wirkliche Lösung sein, auch weil sie die nötigen Mittel bieten, um durch dann Server-seitig gesetzte Parameter Upload-Videos in Laufzeit, Dateigröße, Auflösung etc. zu beschränken.


(Aber sowieso hat ein Browser-seitiger Transcoder ja nur vor Uploads Sinn. Daher war ich davon ausgegangen, dass das eine selbstverständliche Annahme ist.)

Es würde mich freuen, wenn damit irgendjemandes Probleme gelöst würden. Allerdings glaube ich, dass du den Aufwand für das Encoding in der Gesamtkette zu hoch einschätzt.
Wir werden ja sehen.

[cantsin]

Allerdings glaube ich, dass du den Aufwand für das Encoding in der Gesamtkette zu hoch einschätzt.

Glaube ich nicht:
https://arstechnica.com/gadgets/2021/04 ... ing-chips/
(Abschnitt "YouTube’s unfathomably large transcoding problem").

Und eben nicht nur für die großen Anbieter. Wenn ich ffmpeg-Jobs auf meinem eigenen Webserver laufen lassen würde, ginge der in die Knie. Mein Desktop-Ryzen ist ja schon auf fast voller CPU-Last aller zwölf Kerne beim Transcodieren von DNxHR nach 24Mbit/s-h264 und kommt dabei in hoher Qualitätsstufe auf 12fps.

[dienstag_01]

Allerdings glaube ich, dass du den Aufwand für das Encoding in der Gesamtkette zu hoch einschätzt.

Glaube ich nicht:
https://arstechnica.com/gadgets/2021/04 ... ing-chips/
(Abschnitt "YouTube’s unfathomably large transcoding problem").

Und eben nicht nur für die großen Anbieter. Wenn ich ffmpeg-Jobs auf meinem eigenen Webserver laufen lassen würde, ginge der in die Knie. Mein Desktop-Ryzen ist ja schon auf fast voller CPU-Last aller zwölf Kerne beim Transcodieren von DNxHR nach 24Mbit/s-h264 und kommt dabei in hoher Qualitätsstufe auf 12fps.

Niemand ist gezwungen, das Transcoding auf seinem Webserver zu machen, man kann sich auch jetzt schon das File mit genauen Spezifikationen anliefern lassen. Auch mehrere Files für ein Video.
Adobe z.B. bietet doch auch adaptives Streaming an, wie machen die das?

[cantsin]

Adobe z.B. bietet doch auch adaptives Streaming an, wie machen die das?

Laut deren Website auf der Basis von... ...Flash!
https://business.adobe.com/products/pri ... aming.html
https://helpx.adobe.com/adobe-media-ser ... -file.html

Wenn Du dann aber den Link auf "Flash Media Live Encoder" klickst, landest auf einem 404.

Scheint wohl ein totes Produkt zu sein.

[dienstag_01]

Adobe z.B. bietet doch auch adaptives Streaming an, wie machen die das?

Laut deren Website auf der Basis von... ...Flash!
https://business.adobe.com/products/pri ... aming.html
https://helpx.adobe.com/adobe-media-ser ... -file.html

Wenn Du dann aber den Link auf "Flash Media Live Encoder" klickst, landest auf einem 404.

Scheint wohl ein totes Produkt zu sein.

Von der Flash-Zeit kenne ich das auch noch. Verlangte aber einen Adobe-Server.
Keine Ahnung, welche Anforderungen adaptives Streaming an den Server stellt.

[Bluboy]

Win XP oder Server 2003 ;-(

[cantsin]

Laut deren Website auf der Basis von... ...Flash!
https://business.adobe.com/products/pri ... aming.html
https://helpx.adobe.com/adobe-media-ser ... -file.html

Wenn Du dann aber den Link auf "Flash Media Live Encoder" klickst, landest auf einem 404.

Scheint wohl ein totes Produkt zu sein.

Von der Flash-Zeit kenne ich das auch noch. Verlangte aber einen Adobe-Server.
Keine Ahnung, welche Anforderungen adaptives Streaming an den Server stellt.

Na, lustigerweise scheint sich dann doch mit dem im Browser laufenden Transcoder die letzte Lücke zu schließen, die Flash hinterlassen hat. Was Adobe damals machte (nämlich alle Streams im finalen Serverformat clientseitig berechnen zu lassen), geht dann heute als Webapplikation.

[TheBubble]

Niemand ist gezwungen, das Transcoding auf seinem Webserver zu machen, man kann sich auch jetzt schon das File mit genauen Spezifikationen anliefern lassen. Auch mehrere Files für ein Video.

Kann man. Wenn man das jedoch jeden erlaubt, haben die User womöglich ein Sicherheitsproblem.

Ein bösartiger Benutzer könnte nämlich eine speziell vorbereitete Datei hochladen, die so gestaltet ist, dass ein bestimmter Decoder sie nicht richtig verarbeitet und man mit ihr den Webbrowser zur Ausführung beliebigen Codes bringt. Darüber könnte dann z.B. Malware aller Art installiert werden.

Natürlich könnte der bösartige Benutzer diese Datei auch auf einem beliebigen anderen Webserver platzieren, aber von dort wird es schwieriger viele Opfer zu erreichen.

Und falls solche manipulierten Dateien von Videoplattformen mit hoher Reputation verbreitet werden, dann ist diese schwer beschädigt. Nutzer werden Sorge haben die Plattform noch zu nutzen oder viele Teilnetze werden diese aus Sicherheitsgründen sperren.

Adobe z.B. bietet doch auch adaptives Streaming an, wie machen die das?

Ohne zu wissen, was Adobe macht, bedeutet adaptives Streaming in der Regel folgendes: Der Streaming-Server liefert die Daten grob mit der Wiedergabedatenrate. Sobald die Datenrate einbricht, reduziert er diese, wenn sie sich erholt, dann erhöht er diese.

Dies macht er, indem er in Echtzeit aus mehreren (ggf. vorab erzeugten oder von Encodern live zugespielten) Streams einen neuen mehr oder weniger individuellen Stream zusammenbaut, der die Zieldatenrate einhält. Im Prinzip packt er also nur die zur Datenrate passenden Pakete in einen neuen Container-Stream.

[dienstag_01]

Niemand ist gezwungen, das Transcoding auf seinem Webserver zu machen, man kann sich auch jetzt schon das File mit genauen Spezifikationen anliefern lassen. Auch mehrere Files für ein Video.

Kann man. Wenn man das jedoch jeden erlaubt, haben die User womöglich ein Sicherheitsproblem.

Ein bösartiger Benutzer könnte nämlich eine speziell vorbereitete Datei hochladen, die so gestaltet ist, dass ein bestimmter Decoder sie nicht richtig verarbeitet und man mit ihr den Webbrowser zur Ausführung beliebigen Codes bringt. Darüber könnte dann z.B. Malware aller Art installiert werden.

Natürlich könnte der bösartige Benutzer diese Datei auch auf einem beliebigen anderen Webserver platzieren, aber von dort wird es schwieriger viele Opfer zu erreichen.

Und falls solche manipulierten Dateien von Videoplattformen mit hoher Reputation verbreitet werden, dann ist diese schwer beschädigt. Nutzer werden Sorge haben die Plattform noch zu nutzen oder viele Teilnetze werden diese aus Sicherheitsgründen sperren.

Das spricht ja dann eher dafür, dass der Streamingdienst selbst decodiert, denn beim User im Browser sind ja auch Sicherheitsprobleme nicht auszuschließen.

Ohne zu wissen, was Adobe macht, bedeutet adaptives Streaming in der Regel folgendes: Der Streaming-Server liefert die Daten grob mit der Wiedergabedatenrate. Sobald die Datenrate einbricht, reduziert er diese, wenn sie sich erholt, dann erhöht er diese.

Dies macht er, indem er in Echtzeit aus mehreren (ggf. vorab erzeugten oder von Encodern live zugespielten) Streams einen neuen mehr oder weniger individuellen Stream zusammenbaut, der die Zieldatenrate einhält. Im Prinzip packt er also nur die zur Datenrate passenden Pakete in einen neuen Container-Stream.

Was adaptives Streaming ist, weiß ich. Ich konnte es aber selber noch nicht einsetzen, weil mir die nötigen Server dafür gefehlt haben (hat niemand einfach so bereitgestellt, meine ich). Tools zum Transkodieren gibt es.

[dienstag_01]

Von der Flash-Zeit kenne ich das auch noch. Verlangte aber einen Adobe-Server.
Keine Ahnung, welche Anforderungen adaptives Streaming an den Server stellt.

Na, lustigerweise scheint sich dann doch mit dem im Browser laufenden Transcoder die letzte Lücke zu schließen, die Flash hinterlassen hat. Was Adobe damals machte (nämlich alle Streams im finalen Serverformat clientseitig berechnen zu lassen), geht dann heute als Webapplikation.

Das kannst du natürlich die ganzen Jahre immer noch genau so. Da hat sich die Situation seit dem Wegfall von Flash verbessert und nicht verschlechtert. Will nur anscheinend niemand ;)

[vaio]

Das beantwortet meine Frage nicht, eine Standalone Version wäre ja ebenfalls lokal und ohne Internet.

Ich denke, dass du die Zusammenhänge nicht verstehst.

[vaio]

ffmpeg ist Open Source-Software.

Den Vorteil so einer Lösung sehe ich darin, dass Webdienste das Transcoding auf den Browser/Client verlagern können.

Genauso sehe ich das auch.

[Frank Glencairn]

Ich denke, dass du die Zusammenhänge nicht verstehst.

Dann erleuchte mich.

[cantsin]

Ich denke, dass du die Zusammenhänge nicht verstehst.

Dann erleuchte mich.

Mit dieser web assembly-Lösung kann jede Website/jeder Webdienst seinen maßgeschneiderten Transcoder anbieten und direkt im Browser des Nutzers laufen lassen - und zwar vor dem Upload der Videodatei, als Zwischenschritt zwischen der userseitigen Auswahl der Datei und dem tatsächlichen Upload.

Angenommen, ich betreibe einen kleinen Blogserver - oder ein Forum wie Slashcam - und will meinen Nutzern erlauben, maximal 30sekündige Videos in 480p und h264 mit 2 MBit/s in ihren Postings einzubauen. Dann könnte ich das zwar als Formatvorgabe definieren und erwarten, dass die Leute mit Media Encoder, Handbrake etc. gemäß dieser Vorgabe encodieren und uploaden. Problem: Ich müsste nach dem Upload mit Streamanalyse-Software auf dem Server testen, ob die Videos regelkonform sind, müsste bei Fehlern eine Fehlermeldung ausgeben und den User zum neuen Encoding zwingen (woran viele wahrscheinlich scheitern würden), und ich würde mir ein enormes Sicherheitsrisiko aufhalsen, weil Leute in die hochgeladene Videodatei Malwarecode packen und versuchen könnten, die mit einer Code-/Script-Injection-Attacke des Webinterfaces aus der vermeintlichen Videodatei zu extrahieren und auszuführen, oder darauf bauen, dass die Datei ungecheckt auf der Website eingebettet wird.

Stattdessen könnte ich dadurch, dass ich den Transcoder im Browser des Nutzers laufen lasse, den Nutzer eine Videodatei auswählen lassen und sie dann exakt nach meinen o.g
Formatvorgaben (incl. Abschneiden nach 30 Sekunden) umwandeln, wobei die Umwandlung trotzdem auf dem Rechner des Nutzers läuft und meinen Blog-/Forenserver nicht belastet, und mir dann die maßgeschneiderte Videodatei ziehen und auf dem Server anbieten. Ich könnte so praktisch jedes Risiko ausschließen, dass die Leute technischen Müll uploaden, wenn ich so eine Video-Postingfunktion einbauen würde.

Das bedeutet auch, dass wenn ich als Websitebetreiber neuere/effizientere Codecs wie AV1 für eingebettete Videos verwenden will, bei denen viele angebotene Encoder noch experimentell sind, ich mich nicht darauf verlassen muss, dass der User einen guten Encoder einsetzt, sondern ich kann meinen bevorzugten und bewährten Encoder auf diese Weise immer verwenden/automatisch vorschreiben, ohne meinen Server damit belasten zu müssen. (Das gleiche gilt ja faktisch auch für h264, für das es ja alle möglichen Schrott-Encoder gibt. Mit dieser Lösung könnte ich sicherstellen, dass immer der x264-Encoder mit meinen als Websitebetreiber gewünschten Optimierungsparametern verwendet wird.)

(Ich finde es ja wirklich erstaunlich, dass soviele gestandene Mitforisten hier Probleme haben, das Konzept zu verstehen.)

[Frank Glencairn]

Selbstverständlich hab ich das Konzept verstanden - aber du offensichtlich meine Frage nicht.

"Wer beispielsweise Transcoding Anwendungen im Browser anbieten will, muss die Videoclips nun nicht mehr über das Netz an einen Server schicken, sondern kann dies lokal, sogar ganz ohne Internet bewerkstelligen."

Und welchen Vorteil hätte ich dann davon, das Transcoding umständlich und langsam im Browser zu machen statt in der performanten stand alone?

Die Frage war also nicht was irgend ein Plattformbetreiber davon hat meinen Rechner die Arbeit machen zu lassen - was er davon hat ist ja offensichtlich - sondern was ich davon habe, einen Clip umständliche und langsam im Brower, statt einfach und schnell in einer Standalone Version zu komprimieren.

Hier ging's also um Standalone vs Browser Encoding, und nicht was mit der Datei danach passiert.

[cantsin]

Hier ging's also um Standalone vs Browser Encoding, und nicht was mit der Datei danach passiert.

Ah, my bad. Naja, auch das mag seine Anwendungsfälle haben, z.B. als Notnagel, wenn man auf einem Chromebook transcodieren will oder auf einem abgeriegelten (Büro-/Firmen-/Hotel-) Rechner, auf dem man keine Berechtigung hat, eigene Software zu installieren.

[vaio]

Ich denke, dass du die Zusammenhänge nicht verstehst.

Dann erleuchte mich.

Es ist doch ganz einfach. Wenn du für dich kein Szenario mit Vorteilen erkennst, vergiss es. Dann ist das nichts für dich.

Für mich übrigens auch nicht, dennoch kann ich mir für einige Anwendungsbereiche schon Vorteile vorstellen (z.B. in Unternehmen /-Netzwerke).