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.