Optymalizacja wideo pod kątem rozmiaru i jakości

W ciągu ostatnich kilku lat coraz więcej projektów wykorzystuje wideo jako integralną część aplikacji. To świetny kierunek, ponieważ filmy są bardziej angażujące niż zdjęcia (filmy mogą podwoić współczynnik konwersji i wydłużyć czas spędzany w witrynie) i jako takie mogą naprawdę przyciągnąć klientów do poznania szczegółów dotyczących produktów i usług. Jednak wszystko idzie na boki, gdy pojawiają się problemy związane z odtwarzaniem wideo.

Problemy z odtwarzaniem wideo są bezpośrednio związane z rozmiarem i szybkością transmisji wideo. Pobieranie filmu o dużych wymiarach lub dużej szybkości transmisji bitów będzie trwało dłużej, a płynne odtwarzanie będzie wymagać sieci o większej prędkości. Prowadzi to do dłuższych czasów uruchamiania, a jeśli sieć nie może dostarczyć wideo wystarczająco szybko, wideo zatrzyma się podczas odtwarzania wideo.

Jest jednak rozwiązanie! Przeprowadzając podstawowe optymalizacje naszych filmów przed dodaniem ich do naszych witryn, możemy na dobre zapobiec występowaniu tych problemów — cóż, większości z nich. Wszystko, co naprawdę musimy zrobić, to zmniejszyć plik — w taki czy inny sposób. A więc teraz trik polega na tym: jak zmniejszyć plik bez obniżania jakości?

W tym artykule omówimy narzędzia i niektóre kroki, które możesz podjąć, aby zoptymalizować swoje filmy do odtwarzania — wszystko po to, aby uniknąć przestojów i zaimponować cennym klientom!

Dane ze świata rzeczywistego

Często zdarza się, że można znaleźć witryny z bardzo dużymi filmami — na przykład używane jako filmy w tle bohaterów. W moich badaniach przyjrzałem się witrynom znalezionym w mobilnym archiwum HTTPArchive z grudnia 2020 r. i nie było trudno zauważyć dużą liczbę witryn ładujących domyślnie ogromne pliki wideo, zarówno na urządzeniach mobilnych, jak i na komputerach stacjonarnych.

Oczywiście wątpliwe jest, czy uda Ci się osiągnąć te same oszczędności, które pokażę tutaj, ale otrzymasz kilka przydatnych wskazówek i wskazówek, o których należy pamiętać podczas pracy z filmami. W rzeczywistości bardzo łatwo jest przypadkowo umieścić bardzo duże filmy na swojej stronie, jeśli nie jesteś ostrożny, co powoduje, że są one prawie bezużyteczne dla większości klientów.

Historia łaty dyni

Wyobraź sobie, że jest połowa października i szukasz grządki z dynią i kukurydzianego labiryntu, aby spędzić weekendowe popołudnie z rodziną. W zaciszu swojego komputera stacjonarnego przeszukujesz sieć w poszukiwaniu najbliższej lokalizacji i znajdujesz idealną. Strona wygląda uroczo, z pięknym dronem wideo 4K z polami grającymi na górze strony. Wybierasz adres URL i wysyłasz go sobie i swoim bliskim, abyście razem mogli dalej odkrywać tę opcję w podróży.

Ale kiedy otworzysz stronę w telefonie, zauważysz usterkę: film desperacko próbuje odtworzyć na telefonie, ale niestety mu się to nie udaje. Film ciągle się zacina i uruchamia ponownie , będąc znacznie bardziej uciążliwym i denerwującym niż na komputerze. W końcu idziesz dalej, dodajesz zakładkę do adresu URL i kontynuujesz codzienną rutynę.

Po zabawnym, błotnistym dniu (no cóż, niedawno mieszkałem w Seattle i Wielkiej Brytanii, więc plamy z dyni są zabłocone), wracasz do komputera: może jeszcze raz myślisz o tym filmie i zastanawiasz się, dlaczego nie było odtwarzane dobrze w telefonie. Cóż, zdiagnozujmy, co się dzieje.

Możesz zacząć od otwarcia DevTools w przeglądarce. Po załadowaniu strony możemy przejść do zakładki Sieć i filtrować według „mediów”, aby zobaczyć wszystkie pliki wideo:

Widzimy, że pobierany jest plik MP4. Plik nie przechodzi przez sieć jako samodzielny plik; usługa przesyłania strumieniowego musi raczej dzielić plik na kilka segmentów , więc możesz zobaczyć kilka żądań 206 (częściowej zawartości) dla tego samego pliku.

Patrząc na nagłówki odpowiedzi dla tego pliku, możemy zauważyć kilka szczegółów:

 accept-ranges: bytes access-control-allow-headers: x-test-header, Origin, X-Requested-With, Content-Type, Accept access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS Content-Length: 87690242 Content-Range: bytes 70025216-157715457/157715458 content-type: video/mp4 date: Fri, 22 Jan 2021 15:27:26 GMT last-modified: Mon, 24 Jun 2019 05:13:04 GMT server: Apache

Niektóre z tych liczb są nieco przerażające, ponieważ są nieco duże. W rzeczywistości są one często tak duże, że przyzwyczaiłem się dodawać przecinki, dzięki czemu mogę zorientować się, jak duże są te pliki. W tym przypadku częściowe pobieranie zajmuje 87 MB, a cały plik ma 157 715 457 bajtów. Tak, zgadza się, ten film ma 157 MB i (próbowałem) załadować się na mój telefon dzisiaj! Nic dziwnego, że się nie udało.

Więc co słychać w tym filmie?

Zanurzmy się trochę głębiej. Najwyraźniej wideo jest zbyt duże, aby odtwarzać płynnie na telefonie komórkowym z mniejszą pamięcią i wolniejszą siecią. Ale czego potrzebujemy, aby to naprawić? Aby dowiedzieć się, na czym dokładnie polega problem, możemy użyć FFMPEG, który jest open source i darmowy, i okazuje się być jednym z najbardziej niezawodnych narzędzi do optymalizacji filmów . Moglibyśmy bez końca poprawiać konfigurację w FFMPEG, ale porozmawiajmy o kilku ważnych w tym artykule.

Zacznijmy więc od narzędzia diagnostycznego o nazwie FFprobe. FFprobe zbiera informacje ze strumieni multimedialnych i dostarcza szczegółowe informacje o tym, jak wideo jest zakodowane i jak będzie odtwarzane. Jest to część pakietu FFMPEG i właściwie jest całkiem łatwy w użyciu.

Co więcej: jeśli Twój film jest już online, istnieje internetowa wersja ffprobe, do której możemy od razu przejść. Wpiszmy więc po prostu adres URL w formularzu i uzyskajmy w zamian szczegółowe informacje o filmie (np. wymiary wideo, przepływność i sporo metadanych).

Kiedy dodam adres URL MP4 z farmy dyni, od razu widzimy jeden z problemów. Odpowiedź show_format z ffprobe zwraca podsumowanie: najwyraźniej są 2 strumienie i ma długość 62 s (co brzmi na tyle normalnie, że nie wzbudza żadnych podejrzeń). Ale kiedy dojdziemy do rozmiaru i szybkości transmisji bitów , od razu widzimy, gdzie wideo zawodzi.

Jak wspomniano powyżej, dobrym pomysłem może być przyzwyczajenie się do dodawania przecinków do tych dużych liczb. Jak się okazuje, rzeczywiście materiał z drona przelatującego nad polem ma 157 MB i ma szybkość transmisji 20 MB na sekundę! Oznacza to, że aby wideo było odtwarzane płynnie, sieć musi być w stanie przesyłać strumieniowo wideo z szybkością większą niż 20 MBPS, co jest dokładnie powodem zwłoki w telefonie.

Jaki jest idealny bitrate odtwarzania?

Aby uniknąć przestoju, musimy przesyłać wideo z odpowiednią szybkością . Właśnie tam bitrate staje się ważny. Bitrate to szybkość odtwarzania wideo. Aby przeglądarka mogła płynnie odtwarzać wideo, wideo musi być pobierane szybciej niż odtwarzane — co oznacza, że ​​wideo będzie odtwarzane płynnie tylko wtedy, gdy prędkość sieci przekroczy 20 MB/s. Kiedy myślę o prędkościach sieci, zwykle polegam na profilach ruchu WebPageTest:

Jak możemy powiedzieć z powyższego przeglądu, wideo może dobrze odtwarzać się na „Połączeniu natywnym” i na ultraszybkim kablu optycznym połączenia FIOS (20 MBPS to dokładnie wymagana prędkość, więc miejmy nadzieję, że nie trzeba nic więcej pobierać w tło). Jednak wszystkie inne połączenia mają prędkość pobierania, która jest znacznie niższa niż 20 MBPS . Jeśli wideo ładuje się z tymi prędkościami, odtwarzacz spróbuje wykorzystać wideo szybciej, niż można je pobrać, a wideo zostanie trwale zatrzymane.

Szybkość transmisji Twojego filmu określa minimalną prędkość sieci, z której mogą korzystać Twoi klienci. Ogólnie rzecz biorąc, szybkość transmisji wideo powinna wynosić około 80% przepustowości dostępnej w sieci. Tak więc wideo 20 MBPS naprawdę potrzebuje przepustowości sieci 24 MBPS, aby płynnie odtwarzać wideo. Wszyscy korzystający z wolniejszego połączenia będą mieli dość słabe wrażenia i prawdopodobnie w ogóle nie będą mogli oglądać wideo. Mówiąc dokładniej, oznacza to, że abyśmy mogli grać płynnie i jedwabiście w 4G, bitrate musi pozostać poniżej 7,2 MBPS .

Czy możemy obniżyć szybkość transmisji tego filmu wideo?

TAk! Przyjrzyjmy się niektórym konfiguracjom, których możemy użyć do zmniejszenia szybkości transmisji tego filmu. Ale najpierw spójrzmy na dane, które otrzymujemy z FFprobe. Jedną rzeczą, która jest całkiem zauważalna, jest wartość r_frame_rate , która jest liczbą klatek na sekundę w filmie. Jego wartość to 60000/1001. Oznacza to, że szybkość odtwarzania wideo wynosi 60 klatek na sekundę. Jednak typowe liczby klatek na sekundę w sieci to 25–30, więc pierwszą rzeczą, jaką możemy zrobić, jest ponowne zakodowanie wideo z niższą szybkością transmisji .

Inną rzeczą, o której należy pamiętać, jest współczynnik stałej stopy . W FFMPEG głównym testem porównawczym jakości/rozmiaru jest kompresja współczynnika stałej szybkości (CRF), z wartościami od 0 (brak kompresji) do 50 (wysoka kompresja). Domyślna wartość CRF w FFMPEG to 23 (jeśli pominiesz parametr CRF, Twój film będzie miał tę wartość). Z mojego osobistego doświadczenia wynika, że ​​wartości od 23 do 28 nadal tworzą wysokiej jakości filmy , dobrze wyglądające w sieci i znacznie zmniejszone w rozmiarze pliku.

Zacznijmy więc od 30 klatek na sekundę i CRF 23 . Polecenie Terminal będzie wyglądać tak:

 ffmpeg -i input.mp4 -vcodec h264 -acodec aac -crf 23 -strict -2 :v fps=fps=30 output.mp4

Voila! Daje to film o wielkości 81,5 MB — już 48% poprawa. Ale wideo jest nadal bardzo duże, z szybkością transmisji 10 MBPS. Jeśli ustawimy CRF na 28, plik spadnie do 35,4 MB, przy przepływności 4,5 MB/s, co jest znacznie bardziej prawdopodobne przy połączeniu 4G.

To pięciokrotna poprawa w stosunku do oryginalnego filmu . Aby ten film był jeszcze bardziej dostępny, możemy zmienić jego rozmiar, aby był mniejszy. To coś, co omówimy w sekcji strumieniowania poniżej.

Historia głodu pizzy

Wyobraź sobie, że jesteś w Los Angeles, być może odwiedzasz go z zagranicy i wędrujesz przez telefon, i oczywiście myślisz o zjedzeniu kawałka pizzy. Znajdujesz w telefonie niezwykłą pizzerię i decydujesz się tam udać. Być może zauważyłeś na stronie kilka filmów i obrazów bohaterów, ale tak naprawdę każda pizzeria wygląda tak samo, więc nie zawracałeś sobie głowy oglądaniem filmu. Idziesz i łapiesz kawałek lub dwa przed powrotem do hotelu.

Tej nocy dostajesz SMS-a od swojego operatora, że ​​wykorzystałeś o wiele więcej danych, niż sobie wyobrażałeś (i zdecydowanie więcej niż pierwotnie planowałeś!). Kilka taksówek i strona z pizzą — jak droga była znowu strona z pizzą?

Wstawiasz witrynę z pizzą do WebPageTest i sprawdzasz ją na połączeniu mobilnym:

44 MB wideo . Skąd to pochodzi? Nawet poza tym, gdy bardziej szczegółowo przyjrzymy się źródłu i wodospadowi, zobaczymy, że w rzeczywistości są dwa filmy! Na szczęście (lub niestety?) żadnego z nich nie udało się pobrać w całości:

Rodzi to kilka obaw i kilka pytań.

Po pierwsze, dlaczego pobrano tak dużo filmów, skoro nie były one odtwarzane automatycznie? Nie udało nam się jeszcze w nic kliknąć, ale zużyliśmy już prawie 40 MB danych. Odpowiedź, jak zawsze, leży w źródle. Cóż, to znaczy „zobacz źródło”.

 <video class="video-js vjs-big-play-centered" controls preload="auto" width="1050" height="591" poster="assets/home_poster.jpg" data-setup='{"fluid": true}'>
  <source src="assets/home_1.mp4" type='video/mp4'> <source src="assets/home.webm" type='video/webm'>
  <p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="https://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p> </video>

Poza nietoperzem widzimy co najmniej dwa problemy:

• wstępne ładowanie = „auto”
  Kiedy ustawiamy preload="auto" , zastępujemy domyślne ustawienie przeglądarki, wymuszając pobieranie wideo — niezależnie od tego, czy klient nacisnął przycisk „Odtwórz”. Domyślnym atrybutem preload ładowania jest metadata i spowodowałoby pobranie kilku 100 KB. Trzeba przyznać, że jest to znacznie lepszy wynik dla odwiedzających witrynę, którzy nigdy nie obejrzą tego filmu.
• Zamówienie wideo
  Jeśli masz wiele wersji wideo (w tym przypadku: filmy zakodowane w formacie h264 .mp4 i VP8 .webm), przeglądarka wybierze pierwszy film , który potrafi odtworzyć. Teraz każda nowoczesna przeglądarka obsługuje mp4, podczas gdy większość nowoczesnych przeglądarek obsługuje również webm (95,4% globalne wsparcie, według CanIUse).

Jedną ze sztuczek, którą lubię używać, jest wstawienie odpowiedniej linii źródła wideo za pomocą JavaScript. W ten sposób, jeśli zdecydujesz się nie wyświetlać wideo na niektórych ekranach, wystarczy pusty tag <video> — i nie będzie można pobrać żadnego wideo.

window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }
window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }

Jeśli teraz uruchomimy sondę ff na tych dwóch filmach, odkryjemy znaczące różnice w rozmiarach:

Webm jest o 90% mniejszy, a mimo to ma 0 wyświetleń , ponieważ każda przeglądarka obsługuje mp4. Te dwa filmy mają długość 640 × 360 i 140 s. Uruchomienie polecenia ffmpeg z góry na mp4 daje film o wielkości 12,4 MB, więc jest prawdopodobne, że programiści zastosowali podobny proces, aby skompresować i zakodować również wariant .webm. Być może posiadanie preload="auto" dla 12,5 MB nie byłoby jednak takie złe.

Drugi film (nagranie z drona wewnątrz restauracji) jest nagrany w rozdzielczości Full HD (1080p), ale podobnie zostaje skompresowany ze 140 MB do 35 MB. Tak więc 120s z FFMPEG może zmniejszyć wagę wideo na tej stronie ze 160 MB do 57 MB. Odwrócenie kolejności webm/mp4 pozwoliłoby zaoszczędzić dodatkowe kilka MB dla 95% przeglądarek obsługujących ten format.

A co, gdybyśmy chcieli zrobić jeszcze lepiej, być może sprawić, by filmy reagowały na ekrany o różnych rozmiarach? Cóż, zdobądźmy jeszcze mniejsze filmy — z responsywnymi filmami!

Tag <video> nie obsługuje zapytań o media w celu wyświetlania różnych plików wideo na różnych ekranach, dlatego potrzebujemy innego sposobu dostarczania filmów o rozmiarze dostosowanym do ekranu urządzenia. Najłatwiej to osiągnąć za pomocą strumieniowego przesyłania wideo . Spowoduje to dodanie niektórych wymaganych zasobów JavaScript i innych zasobów odtwarzacza wideo, ale oszczędności wideo z pewnością zrekompensują te dodatkowe dane.

Możemy tworzyć strumienie wideo za pomocą FFMPEG (w przeszłości używałem takich skryptów basha), ale wymaga to od nas znajomości wszystkich rozmiarów i ustawień, których chcielibyśmy użyć (a jak wspomniano wcześniej, FFMPEG ma wiele ustawień! ).

Aby ułatwić strumieniowe przesyłanie wideo, istnieją interfejsy API (np. api.video i Mux), w których przesyłasz swoje wideo, a narzędzia tworzą strumienie wideo i hostują je dla Ciebie. Aby uzyskać pełne ujawnienie, pracuję nad pierwszym, więc aby uprościć proces przetwarzania wideo, użyję api.video do transkodowania i hostowania moich filmów. Dzięki API przesyłania mogę przesłać dowolny film, a narzędzie utworzy wersję strumieniową w wielu różnych wymiarach i szybkości transmisji bitów (obecnie 240p, 360p, 480p, 720p, 1080p i 4K).

Szybkość transmisji bitów dla mniejszych filmów jest znacznie zmniejszona, ponieważ zmniejszają się wymiary wideo. Oznacza to, że wideo będzie wymagało mniejszej przepustowości sieci na mniejszych ekranach i będzie odtwarzane w wolniejszych sieciach.

Dla zwięzłości przetestujemy tylko wideo z łatką dyni. Podobne wyniki otrzymałem z filmem z drona (drugi film o pizzy ma tylko 360p, więc nie ma większego znaczenia przy mniejszych rozmiarach).

Uwaga : Przypomnij sobie, że ten film jest obecnie wideo w formacie 1080p mp4 przy 60 klatkach na sekundę i waży 157 MB dla wszystkich odwiedzających.

Po niektórych optymalizacjach (CRF 28 i zmniejszeniu liczby klatek na sekundę do 30 klatek na sekundę) wideo zostało zmniejszone do 35,7 MB . Korzystając z DevTools, możemy emulować urządzenia, aby zobaczyć, ile danych jest używanych do odtwarzania wideo strumieniowego wideo na ekranach o różnych rozmiarach.

Poniższa tabela pokazuje łączną ilość wykorzystanego ruchu. W przypadku wideo HLS dostępny jest odtwarzacz JavaScript, CSS, czcionki itp., które dodają około 1 MB dodatkowego narzutu. Jest to uwzględnione w poniższych sumach:

W rozdzielczości 1080p do strumienia pobieranych jest około 4 MB dodatkowych zasobów, ale dla każdego innego rozmiaru istnieje znaczna oszczędność danych bez utraty jakości wideo. Rozmiar wideo nie tylko będzie odpowiedni dla urządzeń , ale jest znacznie mniej prawdopodobne, że przestanie działać, ponieważ szybkość transmisji jest zmniejszona w przypadku urządzeń, które najprawdopodobniej będą korzystały z wolniejszych połączeń mobilnych.

Strumieniowe przesyłanie wideo dba o liczbę klatek na sekundę, rozmiar wideo i jakość — zapewniając szybkie odtwarzanie na dowolnym ekranie i o dowolnej prędkości w sieci.

“

Kolejna zaleta przesyłania strumieniowego wideo: jeśli sieć działa wolno (lub nagle staje się wolniejsza), odtwarzacz może dostosować wyświetlane wideo i odtwarzać wersję wideo o niższej jakości — zapewniając odtwarzanie na urządzeniu — nawet w złych warunkach sieciowych. (Możesz przetestować różne filmy za pomocą StreamOrNot, małego projektu open source, który wypuściłem jakiś czas temu.

Czy to nie jest trochę za dużo? Czy nie moglibyśmy zrobić tego samego (tylko znacznie szybciej) z YouTube lub Vimeo? Z pewnością moglibyśmy, ale wtedy nie bylibyśmy w stanie całkowicie usunąć brandingu ani reklam z filmu, nie wspominając o narzutach związanych ze skryptami załadowanymi do elementu iframe odtwarzacza wideo. Ponadto czasami możesz chcieć użyć wideo jako tła wideo na stronie produktu i w ogóle uniknąć wszelkiego rodzaju zewnętrznego brandingu.

Wniosek

Nie umieszczamy obrazów z naszej kamery bezpośrednio w sieci, ale kompresujemy je i zmieniamy ich rozmiar, aby zrównoważyć jakość i wydajność sieci. To samo należy zrobić dla plików wideo. Mniejsze filmy zaczynają odtwarzać się szybciej i rzadziej się zatrzymują, poprawiając komfort korzystania z witryny.

W tym artykule omówiliśmy kilka prostych kroków, aby zoptymalizować nasze filmy, np. poprzez obniżenie jakości i liczby klatek na sekundę. Przyjrzeliśmy się również, w jaki sposób strumieniowe przesyłanie wideo może umożliwić nam tworzenie bardziej responsywnych materiałów wideo w Internecie — automatycznie wyświetlając filmy, które są odpowiednio dopasowane do ekranu urządzenia.

Dziękujemy za przeczytanie, a jeśli chcesz dowiedzieć się więcej, możesz przeczytać więcej o najlepszych praktykach wideo tutaj, w Smashing Magazine i na moim blogu:

• Odtwarzanie wideo w Internecie: aktualny stan wideo (część 1)
• Odtwarzanie wideo w Internecie: najlepsze praktyki dostarczania wideo (część 2)
• Ukrywanie filmów wideo w sieci mobilnej