News-Kommentare Forum



FFmpeg direkt im Browser nutzen - FFMPEG.WASM



Kommentare / Diskussionen zu aktuellen Newsmeldungen auf slashCAM
Antworten
slashCAM
Administrator
Administrator
Beiträge: 11262

FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von slashCAM » Do 01 Dez, 2022 10:40


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 ...
Bild
Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
FFmpeg direkt im Browser nutzen - FFMPEG.WASM




Frank Glencairn
Beiträge: 17522

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von Frank Glencairn » Fr 02 Dez, 2022 09:10

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
Beiträge: 971

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von vaio » Fr 02 Dez, 2022 09:26

Frank Glencairn hat geschrieben:
Fr 02 Dez, 2022 09:10
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?
Zurück in die Zukunft




Frank Glencairn
Beiträge: 17522

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von Frank Glencairn » Fr 02 Dez, 2022 11:10

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




Darth Schneider
Beiträge: 13748

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von Darth Schneider » Fr 02 Dez, 2022 11:24

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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 11:39

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
Beiträge: 1405

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von prime » Fr 02 Dez, 2022 11:59

cantsin hat geschrieben:
Fr 02 Dez, 2022 11:39
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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 12:03

cantsin hat geschrieben:
Fr 02 Dez, 2022 11:39
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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 12:13

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 12:03
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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 12:24

prime hat geschrieben:
Fr 02 Dez, 2022 11:59
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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 14:04

cantsin hat geschrieben:
Fr 02 Dez, 2022 12:13
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 12:03
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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 16:21

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 14:04
cantsin hat geschrieben:
Fr 02 Dez, 2022 12:13


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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 16:37

cantsin hat geschrieben:
Fr 02 Dez, 2022 16:21
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 14:04

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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 17:06

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 16:37
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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 17:24

cantsin hat geschrieben:
Fr 02 Dez, 2022 17:06
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 16:37
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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 17:59

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 17:24
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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 19:57

cantsin hat geschrieben:
Fr 02 Dez, 2022 17:59
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 17:24
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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 22:15

dienstag_01 hat geschrieben: 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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 22:33

cantsin hat geschrieben:
Fr 02 Dez, 2022 22:15
dienstag_01 hat geschrieben: 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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 22:42

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:33
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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 22:50

cantsin hat geschrieben:
Fr 02 Dez, 2022 22:42
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:33
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
Beiträge: 3432

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von Bluboy » Fr 02 Dez, 2022 23:23

Win XP oder Server 2003 ;-(




cantsin
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Fr 02 Dez, 2022 23:25

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:50
cantsin hat geschrieben:
Fr 02 Dez, 2022 22:42


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
Beiträge: 1842

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von TheBubble » Fr 02 Dez, 2022 23:36

dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:33
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.
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:33
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
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Fr 02 Dez, 2022 23:59

TheBubble hat geschrieben:
Fr 02 Dez, 2022 23:36
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:33
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.
TheBubble hat geschrieben:
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.
Zuletzt geändert von dienstag_01 am Sa 03 Dez, 2022 00:09, insgesamt 1-mal geändert.




dienstag_01
Beiträge: 12170

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von dienstag_01 » Sa 03 Dez, 2022 00:08

cantsin hat geschrieben:
Fr 02 Dez, 2022 23:25
dienstag_01 hat geschrieben:
Fr 02 Dez, 2022 22:50

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
Beiträge: 971

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von vaio » Sa 03 Dez, 2022 09:52

Frank Glencairn hat geschrieben:
Fr 02 Dez, 2022 11:10
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.
Zurück in die Zukunft




vaio
Beiträge: 971

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von vaio » Sa 03 Dez, 2022 09:52

cantsin hat geschrieben:
Fr 02 Dez, 2022 11:39
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.
Zurück in die Zukunft




Frank Glencairn
Beiträge: 17522

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von Frank Glencairn » Sa 03 Dez, 2022 10:25

vaio hat geschrieben:
Sa 03 Dez, 2022 09:52

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




cantsin
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Sa 03 Dez, 2022 11:57

Frank Glencairn hat geschrieben:
Sa 03 Dez, 2022 10:25
vaio hat geschrieben:
Sa 03 Dez, 2022 09:52

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
Beiträge: 17522

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von Frank Glencairn » Sa 03 Dez, 2022 12:22

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
Beiträge: 12025

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von cantsin » Sa 03 Dez, 2022 13:08

Frank Glencairn hat geschrieben:
Sa 03 Dez, 2022 12:22
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
Beiträge: 971

Re: FFmpeg direkt im Browser nutzen - FFMPEG.WASM

Beitrag von vaio » Sa 03 Dez, 2022 13:41

Frank Glencairn hat geschrieben:
Sa 03 Dez, 2022 10:25
vaio hat geschrieben:
Sa 03 Dez, 2022 09:52

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).
Zurück in die Zukunft




Social Media

       
 Aktuelle Beiträge [alle Foren]
 
» Frage zum workflow CineMatch + Adobe Premiere
von dienstag_01 - Fr 14:48
» Nach dem Trailer zu urteilen, könnte der doch was werden
von Darth Schneider - Fr 14:40
» Spaß mit NVIDIAs neuem Blickkontakt-Effekt: Robert De Niro schaut Dir in die Augen
von Darth Schneider - Fr 13:57
» Jetzt auch für Resolve (Mac): Automatische Transkription von Simon Says
von dienstag_01 - Fr 13:41
» BRAW Toolbox - Blackmagic RAW Import in FCPX ab Montag verfügbar
von Darth Schneider - Fr 13:35
» BRAW Toolbox für FCPX
von R S K - Fr 12:36
» MacBook Pro 16“ M2 Max im Performance-Test mit ARRI, Canon, Sony, Panasonic, Blackmagic …
von slashCAM - Fr 12:21
» Okay, ich denke das mit der AI ist jetzt offiziell durch
von Funless - Fr 10:45
» Sony a7s iii AF pumpt
von Pianist - Fr 10:31
» Videoleuchte mit DMX Steuerung – Rollei Lumen 150
von Darth Schneider - Fr 10:08
» Neue Apple Mac mini und MacBook Pro Modelle mit M2, M2 Pro und M2 Max
von Frank Glencairn - Fr 9:00
» Nosferatu — Robert Eggers
von Map die Karte - Fr 6:06
» Visuelles Dubbing per KI macht jeden Schauspieler zum Mehrfach-Muttersprachler
von Frank Glencairn - Do 23:37
» Mobiles Live-Streaming?
von DAF - Do 22:59
» VEGAS 20 Update 2 bringt zahlreiche Neuerungen plus Rabattaktion
von dokta_ALK - Do 22:14
» Stockphoto-Portal Shutterstock integriert KI-Bilder und gibt eine Antwort auf die Gretchenfrage
von tom - Do 18:41
» Welchsel auf L-Mount: EF-Linsen & Adapter Sigma MC21 vs Viltrox vs Commlite AdapterCM EF L?
von Darth Schneider - Do 18:34
» Canon entwickelt 4K-Bildsensor mit 148 dB Dynamik (24 Blendenstufen) - aber nicht für Filmer
von slashCAM - Do 16:15
» importing/converting .mov in Premiere Pro 2021 FAILED ! Only Audio visible
von Jott - Do 15:42
» Panasonic GH6 und Atomos Shogun Connect in der (Cloud)Praxis: Proxy-Upload mit LTE-Handy vom Set?
von Darth Schneider - Do 15:37
» Neuer KI-Effekt NVIDIA Eye Contact: Bye bye Teleprompter?
von Alex - Do 15:01
» Großer Vergleichstest: Upscaling per KI - welches Tool ist am besten (und kostenlos)?
von dienstag_01 - Do 12:32
» Sennheiser MKH 8060 im ersten Test: Die neue slashCAM Audio-Referenz? Inkl. MKH 416 Vergleich
von Darth Schneider - Do 11:57
» Magic Nodes: Endlich Node-Compositing in After Effects
von -paleface- - Do 11:50
» Workflow Interviews
von funkytown - Do 11:47
» Was schaust Du gerade?
von Darth Schneider - Do 10:49
» Portable Samsung T7 Shield NVMe-SSD jetzt auch mit 4 TB
von slashCAM - Do 10:30
» Medienstudierende für internationales Stiftungsprojekt gesucht.
von Darth Schneider - Do 10:16
» Topaz Video Enhance AI 3.0: Neue KI-Funktionen und großer Preisrabatt
von medienonkel - Do 7:54
» Musik-Video - Timeline Organisation / Vorgehensweise in Premiere
von Darth Schneider - Do 4:21
» Mikrofon mit XLR (z.B. Rode Reporter) an Klinkeneingang mit "MIC-Power"?
von Blackbox - Mi 21:37
» Musikvideo Was davon ist echt?
von Heinrich123 - Mi 19:17
» Da gab es doch diesen Film...?
von klusterdegenerierung - Mi 18:33
» DER GIMBAL THREAD
von Darth Schneider - Mi 16:24
» Einer der berühmtesten Soundeffekte der Filmgeschichte: Wilhelm Scream
von Darth Schneider - Mi 15:26
 
neuester Artikel
 
Test: MacBook Pro M2 Max

Mit dem neuen M2 Max Prozessor stell Apple seinen bislang leistungsstärksten Notebook-Prozessor vor. Mit jetzt 12 CPU- und 38 GPU-Kernen tritt Apples aktuellstes Unified Memory-Design an, nochmal mehr Performance für die Bereiche Videoschnitt, Compositing und Farbkorrektur zur Verfügung zu stellen. Wie dieser Performance-Zuwachs in der Schnitt-Praxis aussieht, klärt unser erster Test des neuen MacBook Pro mit M2 Max Prozessor mit diversem 10-16 Bit Videomaterial weiterlesen>>

Test: Sennheiser MKH 8060

Die 8000er Serie stellt die aktuellste Version von Sennheisers weit etablierter, professioneller MKH-Serie dar. Innerhalb des 8000er Mikrofon-Portfolios ordnet Sennheiser dem (aktuell kaum verfügbaren) MKH 8060 Richtrohrmikrofon die Anwendungsbereiche Spiel- und Dokumentarfilm, Outdoor- sowie Studioaufnahmen zu. Damit darf es durchaus auch als moderne Variante des Sennheiser MKH 416 gelten, das nach wie vor das Richtrohr-Referenzmikrofon bei slashCAM darstellt - Zeit für eine neue Referenz? weiterlesen>>