Newsmeldung von 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
Antwort von 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?
Antwort von vaio:
"Frank Glencairn" hat geschrieben:
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?
Antwort von Frank Glencairn:
Das beantwortet meine Frage nicht, eine Standalone Version wäre ja ebenfalls lokal und ohne Internet.
Antwort von 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
Antwort von 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.
Antwort von prime:
cantsin hat geschrieben:
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.
Antwort von dienstag_01:
cantsin hat geschrieben:
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 ;)
 |
Antwort von cantsin:
dienstag_01 hat geschrieben:
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.
Antwort von cantsin:
prime hat geschrieben:
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.
Antwort von dienstag_01:
cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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 ;)
Antwort von cantsin:
dienstag_01 hat geschrieben:
cantsin hat geschrieben:
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:
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.
Antwort von dienstag_01:
cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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:
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 ;)
|
Antwort von cantsin:
dienstag_01 hat geschrieben:
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 wird das Video decodiert. Dabei streamt YT je nach dessen Endgerät und Internetbandreite einen der 25 Streams .
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 wird das Video decodiert...
Antwort von dienstag_01:
cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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 wird das Video decodiert. Dabei streamt YT je nach dessen Endgerät und Internetbandreite einen der 25 Streams .
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 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.
|
Antwort von cantsin:
dienstag_01 hat geschrieben:
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.)
Antwort von dienstag_01:
cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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.
|
Antwort von 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.
Antwort von dienstag_01:
cantsin 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?
Antwort von cantsin:
dienstag_01 hat geschrieben:
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.
Antwort von dienstag_01:
cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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.
Antwort von Bluboy:
Win XP oder Server 2003 ;-(
Antwort von cantsin:
dienstag_01 hat geschrieben:
cantsin hat geschrieben:
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.
Antwort von TheBubble:
dienstag_01 hat geschrieben:
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:
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.
Antwort von dienstag_01:
TheBubble hat geschrieben:
dienstag_01 hat geschrieben:
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.
|
Antwort von dienstag_01:
cantsin hat geschrieben:
dienstag_01 hat geschrieben:
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 ;)
Antwort von vaio:
"Frank Glencairn" hat geschrieben:
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.
Antwort von vaio:
cantsin hat geschrieben:
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.
Antwort von Frank Glencairn:
vaio hat geschrieben:
Ich denke, dass du die Zusammenhänge nicht verstehst.
Dann erleuchte mich.
Antwort von cantsin:
"Frank Glencairn" hat geschrieben:
vaio hat geschrieben:
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.)
Antwort von 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.
Antwort von cantsin:
"Frank Glencairn" hat geschrieben:
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.
Antwort von vaio:
"Frank Glencairn" hat geschrieben:
vaio hat geschrieben:
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).
