Videoyu Boyut ve Kalite İçin Optimize Etme

Son birkaç yılda, giderek daha fazla proje, videoyu uygulamanın ayrılmaz bir parçası olarak kullanıyor. Videolar, fotoğraflardan daha ilgi çekici olduğundan (videolar dönüşüm oranını ikiye katlayabilir ve sitede geçirilen süreyi artırabilir) ve bu nedenle, müşterileri ürün ve hizmetlerle ilgili ayrıntıları keşfetmeye gerçekten çekebileceğinden, bu harika bir yön. Ancak, video oynatmayla ilgili sorunlar olduğunda her şey ters gider.

Video oynatma sorunları , doğrudan videonun boyutu ve bit hızı ile ilgilidir. Büyük boyutlu veya yüksek bit hızına sahip bir videonun indirilmesi daha uzun sürer ve sorunsuz bir şekilde oynatılması için daha yüksek hızlı bir ağ gerekir. Bu, daha uzun başlatma sürelerine yol açar ve ağ videoyu yeterince hızlı sağlayamazsa, video oynatma sırasında video durur.

Yine de bir çözüm var! Videolarımızı web sitelerimize eklemeden önce temel optimizasyonlarını çalıştırarak, bu sorunların oluşmasını kesin olarak önleyebiliriz - evet, çoğu. Tek yapmamız gereken dosyayı bir şekilde küçültmek. Şimdi işin püf noktası şu: kaliteyi düşürmeden dosyayı nasıl küçültebiliriz?

Bu makalede, videolarınızı oynatma için optimize etmek için atabileceğiniz araçlar ve bazı adımları gözden geçireceğiz - bunların tümü, duraklamalardan kaçınmak ve değerli müşterilerinizi etkilemek için!

Gerçek Dünya Verileri

Son derece büyük videolara sahip web siteleri bulmak nadir değildir - örneğin, kahraman arka plan videoları olarak kullanılır. Araştırmamda, Aralık 2020 mobil HTTPArchive'de bulunan siteleri araştırıyordum ve hem mobilde hem de masaüstünde varsayılan olarak büyük video dosyaları yükleyen çok sayıda siteyi tespit etmek zor olmadı.

Burada göstereceğim tasarrufların aynısını elde edip edemeyeceğiniz elbette şüpheli, ancak videolarla uğraşırken akılda tutulması gereken şeyler hakkında bazı faydalı ipuçları ve ipuçları alacaksınız. Aslında, dikkatli olmazsanız, yanlışlıkla çok büyük videoları web sitenize yerleştirmek çok kolaydır, bu da müşterilerinizin çoğu için neredeyse kullanılamaz hale gelmesine neden olur.

Kabak Yaması Hikayesi

Ekim ayının ortası olduğunu ve ailenizle bir hafta sonu öğleden sonra geçirmek için bir balkabağı yaması ve mısır labirenti aradığınızı hayal edin. Masaüstü makinenizin rahatlığında, web'de yakındaki bir yeri arar ve mükemmel olanı bulursunuz. Web sitesi, sayfanın üst kısmında oynayan alanların güzel bir drone 4K videosu ile güzel görünüyor. URL'yi seçip kendinize ve sevdiklerinize gönderirsiniz, böylece hareket halindeyken bu seçeneği birlikte keşfetmeye devam edebilirsiniz.

Ancak sayfayı telefonunuzda açtığınızda bir aksaklık fark ediyorsunuz: Video umutsuzca telefonunuzda oynatmaya çalışıyor ama maalesef bunu başaramıyor. Video, bilgisayarınızdakinden çok daha rahatsız edici ve rahatsız edici bir şekilde durup tekrar tekrar başlıyor . Sonunda devam edersiniz, URL'yi işaretlersiniz ve günlük rutininize devam edersiniz.

Çamurlu eğlenceli bir günün ardından (son zamanlarda Seattle ve Birleşik Krallık'ta yaşadım, bu nedenle balkabağı yamaları çamurlu), bilgisayarınıza geri döndünüz: belki o video hakkında bir kez daha düşünüyorsunuz ve neden oynatılmadığını merak ediyorsunuz. iyi telefonda. Peki, neler olduğunu teşhis edelim.

Tarayıcınızda DevTools'u açarak başlayabilirsiniz. Sayfa yüklendikten sonra Ağ sekmesine geçebilir ve tüm video dosyalarını görmek için “medya”ya göre filtreleyebiliriz:

Bir MP4 dosyasının indirildiğini görüyoruz. Dosya ağ üzerinden bağımsız bir dosya olarak gelmez; bunun yerine, akış hizmetinin dosyayı birkaç bölüme ayırması gerekir, bu nedenle aynı dosya için birkaç 206 (kısmi içerik) isteği görebilirsiniz.

Bu dosyanın yanıt başlıklarına baktığımızda bazı ayrıntıları görebiliriz:

 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

Şimdi, bu sayıların bazıları biraz büyük oldukları için biraz korkutucu. Aslında, genellikle o kadar büyüktürler ki, dosyaların gerçekte ne kadar büyük olduğuna dair bir fikir edinebilmek için kendimi virgül ekleme alışkanlığı edinmiş buldum. Bu durumda, kısmi indirme 87 MB'dir ve tüm dosya 157.715.457 bayttır. Evet, doğru, bu video 157MB ve bugün erken saatlerde telefonuma yüklenmeye (denedildi)! Başarılı olmamasına şaşmamalı.

Peki Bu Videoda Neler Var?

Hadi biraz daha derine dalalım. Görünüşe göre video, daha düşük belleğe ve daha yavaş bir ağa sahip bir cep telefonunda sorunsuz oynatılamayacak kadar büyük. Ama düzeltmek için neye ihtiyacımız var? Sorunun tam olarak ne olduğunu anlamak için açık kaynak kodlu ve ücretsiz olan ve videoları optimize etmek için en güvenilir araçlardan biri olduğunu kanıtlayan FFMPEG'i kullanabiliriz. FFMPEG'deki konfigürasyonu sonsuz bir şekilde değiştirebiliriz, ancak bu makalede sadece birkaç önemli olana değinelim.

Öyleyse, FFprobe adlı tanı aracıyla başlayalım. FFprobe, multimedya akışlarından bilgi toplar ve size videonun nasıl kodlandığı ve nasıl oynatılacağı hakkında ayrıntılar sağlar. FFMPEG paketinin bir parçasıdır ve aslında kullanımı oldukça kolaydır.

Daha da iyisi: Videonuz zaten çevrimiçiyse, hemen atlayabileceğimiz çevrimiçi bir ffprobe sürümü vardır. Öyleyse, forma URL'yi girelim ve karşılığında videoyla ilgili ayrıntıları alalım (örn. video boyutları, bit hızı ve oldukça fazla meta veri).

Kabak çiftliğinden MP4 URL'sini eklediğimde hemen sorunlardan birini görüyoruz. show_format yanıtı bir özet döndürür: görünüşe göre, 2 akış var ve 62s uzunluğunda (tüm bunlar herhangi bir şüphe uyandırmayacak kadar normal görünüyor). Ancak boyut ve bit hızına geldiğimizde hemen videonun nerede başarısız olduğunu görüyoruz.

Yukarıda bahsedildiği gibi, bu büyük sayılara virgül eklemeye alışmak iyi bir fikir olabilir. Görünüşe göre, sahada uçan drone görüntüleri gerçekten 157 MB ve saniyede 20 MB bit hızına sahip! Bu, videonun sorunsuz bir şekilde oynatılabilmesi için, ağın videoyu 20 MBPS'den daha hızlı bir hızda aktarabilmesi gerektiği anlamına gelir, bu yüzden telefonda tam olarak bu yüzden duraklıyordu.

İdeal oynatma bit hızı nedir?

Durmayı önlemek için videoyu uygun bir hızda yayınlamamız gerekiyor. Bit hızının önemli olduğu yer burasıdır. Bit hızı, videonun oynatma hızıdır. Tarayıcının videoyu sorunsuz oynatması için, videonun oynatıldığından daha hızlı indirilmesi gerekir - bu, videonun yalnızca ağ hızı 20 MBPS'nin üzerindeyse sorunsuz oynatılacağı anlamına gelir. Ağ hızlarını düşündüğümde, WebPageTest'in trafik profillerine güvenme eğilimindeyim:

Yukarıdaki genel bakıştan anlayabileceğimiz gibi, video “Yerel Bağlantı” da ve ultra hızlı optik kablo FIOS bağlantısında (20 MBPS tam olarak gereken hızdır, bu nedenle umarım başka hiçbir şeyin indirilmesi gerekmez) arka fon). Bununla birlikte, diğer tüm bağlantıların, 20 MBPS'den önemli ölçüde daha düşük bir aşağı bağlantı hızı vardır. Video bu hızlarda yükleniyorsa, oynatıcı videoyu indirilebileceğinden daha hızlı tüketmeye çalışacak ve video kalıcı olarak duracaktır.

Videonuzun bit hızı, müşterilerinizin kullanabileceği minimum ağ hızını belirler. Genel olarak, videonuzun bit hızı, ağdaki mevcut aktarım hızının yaklaşık %80'i olmalıdır . Bu nedenle, 20 MBPS'lik bir videonun, videoyu sorunsuz bir şekilde oynatmak için gerçekten 24 MBPS ağ çıkışına ihtiyacı vardır. Daha yavaş bir bağlantıya sahip olan herkes oldukça kötü bir deneyime sahip olacak ve muhtemelen videoyu hiç izleyemeyecek. Daha spesifik olarak, bu, 4G'de sorunsuz ve ipeksi oynamamız için bit hızının 7,2 MBPS'nin altında kalması gerektiği anlamına gelir.

Bu Videonun Bit Hızını Düşürebilir miyiz?

Evet! Bu videonun bit hızını azaltmak için kullanabileceğimiz bazı yapılandırmalara bakalım. Ama önce FFprobe'dan aldığımız verilere bakalım. Oldukça dikkat çekici olan bir şey, videodaki saniyedeki kare sayısı olan r_frame_rate değeridir. Değeri 60000/1001'dir. Bu, videonun kare hızının saniyede 60 kare olduğu anlamına gelir. Ancak, web'deki tipik kare hızları 25-30'dur, bu nedenle yapabileceğimiz ilk şey videoyu daha düşük bir bit hızıyla yeniden kodlamaktır .

Akılda tutulması gereken başka bir şey de Sabit Hız Faktörüdür . FFMPEG'de, temel kalite/boyut karşılaştırması, 0 (sıkıştırma yok) ile 50 (yüksek sıkıştırma) arasında değişen değerlerle Sabit Hız Faktörü (CRF) sıkıştırmasıdır. FFMPEG'de CRF için varsayılan değer 23 (CRF parametresini dışarıda bırakırsanız videonuz bu değerdedir). Kişisel deneyimime göre, 23-28 arasındaki değerler hala yüksek kaliteli videolar üretiyor , web'de iyi görünüyor ve dosya boyutu büyük ölçüde küçültülmüş.

Öyleyse 30 fps ve 23 bir CRF ile başlayalım. Terminal komutu şöyle görünecektir:

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

işte! Bu, 81,5 MB'lık bir videoyla sonuçlanır - zaten %48'lik bir gelişme. Ancak video, 10 MBPS bit hızıyla hala çok büyük. CRF'yi 28'e ayarlarsak, dosya 4G bağlantısında iyi oynama olasılığı çok daha yüksek olan 4,5 MBPS bit hızıyla 35.4 MB'a düşer.

Bu, orijinal videoya göre beş katlık bir iyileştirmedir . Bu videoyu daha da erişilebilir kılmak için videoyu küçültecek şekilde yeniden boyutlandırabiliriz. Bu, aşağıdaki akış bölümünde tartışacağımız bir şey.

Pizzaya Açlık Hikayesi

Los Angeles'ta olduğunuzu, belki yurtdışından ziyaret ettiğinizi ve telefonunuzda dolaştığınızı ve elbette bir dilim pizza almayı düşündüğünüzü hayal edin. Telefonunuzda dikkat çekici bir pizzacı buluyorsunuz ve oraya gitmeye karar veriyorsunuz. Sayfada birkaç video ve kahraman görseli fark etmiş olabilirsiniz, ancak aslında her pizzacının türü birbirine benziyor, bu yüzden videoyu izleme zahmetine girmediniz. Otelinize dönmeden önce bir veya iki dilim alın ve alın.

O gece, operatörünüzden, hayal ettiğinizden çok daha fazla veri kullandığınızı (ve kesinlikle başlangıçta planladığınızdan çok daha fazlasını) kullandığınızı belirten bir mesaj alırsınız. Birkaç taksi ve pizza sitesi - pizza sitesi yine ne kadar pahalıydı?

Pizza web sitesini WebPageTest'e açtınız ve bir mobil bağlantıda kontrol ettiniz:

44 MB video . Nereden geliyor? Hatta bunun da ötesinde, kaynağı ve şelaleyi biraz daha detaylı incelediğimizde aslında iki video olduğunu görebiliyoruz! Neyse ki (veya ne yazık ki?), hiçbiri tamamen indirilemedi:

Bu, birkaç endişeyi ve birkaç soruyu gündeme getiriyor.

İlk olarak, otomatik oynatılmadığı halde neden bu kadar çok video indirildi? Henüz hiçbir şeye tıklamayı başaramadık, ancak şimdiden neredeyse 40 MB veri kullandık. Cevap, her zaman olduğu gibi, kaynakta yatıyor. Eh, "kaynağı görüntüle", yani.

 <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>

Yarasa dışında, en az iki sorun görüyoruz:

• ön yükleme = “otomatik”
  preload="auto" ayarını yaptığımızda, müşteriniz “Oynat”a basmış olsun ya da olmasın, tarayıcının varsayılan ayarını geçersiz kılarak video indirmeyi zorunlu kılarız . Varsayılan preload özniteliği metadata ve birkaç 100 KB indirilmesiyle sonuçlanabilirdi. Kuşkusuz, bu videoyu asla izlemeyecek site ziyaretçileri için çok daha iyi bir sonuçtur.
• Video Sırası
  Videonun birden fazla sürümüne sahipseniz (bu durumda: h264 .mp4 ve VP8 .webm kodlu videolar), tarayıcı nasıl oynatılacağını bildiği ilk videoyu seçer. Artık her modern tarayıcı mp4'ü desteklerken, çoğu modern tarayıcı webm'yi de destekliyor (CanIUse'a göre %95,4 global destek).

Kullanmayı sevdiğim bir püf noktası, uygun video kaynak satırını Javascript ile eklemek. Bu şekilde, belirli ekranlarda video sunmamayı seçerseniz, yalnızca boş bir <video> etiketiniz olur ve hiçbir video indirilemez.

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",""); }; }

Şimdi bu iki video üzerinde bir ffprobe çalıştırırsak, boyutlarda önemli farklılıklar keşfedeceğiz:

Webm %90 daha küçüktür ve her tarayıcı mp4'ü desteklediğinden 0 görüntülemeye sahiptir . Bu iki video hem 640×360 hem de 140s uzunluğunda. Mp4 üzerinde yukarıdan ffmpeg komutunu çalıştırmak 12.4 MB'lık bir videoyla sonuçlanır, bu nedenle geliştiricilerin .webm varyantını sıkıştırmak ve kodlamak için benzer bir süreç izlemiş olmaları muhtemeldir. Belki de 12,5 MB için preload="auto" olması o kadar da kötü olmazdı.

İkinci video (restoran içindeki drone görüntüleri) Full HD (1080p) olarak çekildi, ancak benzer şekilde 140MB'den 35MB'ye sıkıştırıldı. Böylece, FFMPEG'li 120'ler, bu sayfadaki video ağırlığını 160 MB'den 57 MB'a düşürebilir . webm/mp4 sırasını çevirmek, bu formatı destekleyebilen tarayıcıların %95'i için birkaç MB ek tasarruf sağlayacaktır.

Ya daha iyisini yapmak istersek, belki de videoları çeşitli büyüklükteki ekranlara duyarlı hale getirmek istersek? Peki, duyarlı videolarla daha da küçük videolar çekelim!

<video> etiketi, farklı video dosyalarını farklı ekranlara sunmak için medya sorgularını desteklemediğinden, cihaz ekranı için boyutlandırılmış videolar sağlamak için farklı bir yola ihtiyacımız var. Bunu başarmanın en kolay yolu video akışı kullanmaktır. Bu, video oynatıcı için gerekli olacak bazı Javascript ve diğer varlıkları ekleyecektir, ancak video tasarrufları bu ekstra verileri kesinlikle telafi edecektir.

FFMPEG ile video akışları oluşturabiliriz (geçmişte buna benzer bash komut dosyaları kullandım), ancak bu, kullanmak istediğimiz tüm boyutları ve ayarları bilmemizi gerektirir (ve daha önce belirtildiği gibi, FFMPEG'de birçok ayar vardır! ).

Video akışını kolaylaştırmak için videonuzu yüklediğiniz API'ler (örn. api.video ve Mux) vardır ve araçlar video akışları oluşturur ve videonuzu sizin için barındırır. Tam açıklama için ilkinde çalışıyorum, bu nedenle video işleme hattımı basitleştirmek için videolarımı dönüştürmek ve barındırmak için api.video kullanacağım. Yükleme API'si ile herhangi bir videoyu yükleyebilirim ve araç birçok farklı boyutta ve bit hızında (şu anda 240p, 360p, 480p, 720p, 1080p ve 4K) bir akış sürümü oluşturacaktır.

Daha küçük videolar için bit hızları, videonun boyutları azaldıkça büyük ölçüde azalır. Bu , videonun daha küçük ekranlarda daha az ağ kapasitesi gerektireceği ve daha yavaş ağlarda oynatılacağı anlamına gelir.

Kısaca, sadece Kabak yama videosunu test edeceğiz. Drone videosu ile benzer sonuçlar aldım (diğer pizza videosu sadece 360p, bu yüzden daha küçük boyutlardan pek faydalanmıyor).

Not : Lütfen bu videonun şu anda 60 fps'de 1080p mp4 video olduğunu ve tüm ziyaretçiler için 157 MB ağırlığında olduğunu unutmayın.

Bazı optimizasyonlarla (CRF 28 ve kare hızının 30 fps'ye düşürülmesi) video 35.7 MB'a düşürüldü. DevTools'u kullanarak, farklı boyuttaki ekranlarda video akışının video oynatımı için ne kadar veri kullanıldığını görmek için cihazları taklit edebiliriz.

Aşağıdaki tablo, kullanılan toplam trafik miktarını göstermektedir. HLS videosunda, yaklaşık 1 MB ek yük ekleyen bir JavaScript oynatıcı, CSS, yazı tipleri vb. vardır. Bu, aşağıdaki toplamlara dahildir:

1080p'de, akış için indirilen yaklaşık 4 MB ek varlık vardır, ancak diğer tüm boyutlar için video kalitesinde kayıp olmadan önemli veri tasarrufu sağlanır. Video yalnızca cihazlar için uygun şekilde boyutlandırılmakla kalmaz, aynı zamanda daha yavaş mobil bağlantılarda olması muhtemel cihazlar için bit hızı düşürüldüğünden, durma olasılığı çok daha düşüktür.

Video akışı, kare hızı, video boyutu ve kalite sorunlarıyla ilgilenir - her boyutta ekranda ve her hızlı ağda hızlı oynatma sağlar.

“

Video akışının bir başka avantajı: ağ yavaşsa (veya aniden yavaşlarsa), oynatıcı gösterilen videoyu ayarlayabilir ve videonun daha düşük kaliteli bir sürümünü oynatabilir - cihazda oynatmayı sağlar - kötü ağ koşullarında bile. (Bir süre önce yayınladığım küçük bir açık kaynak projesi olan StreamOrNot ile farklı videoları test edebilirsiniz.

Şimdi, biraz fazla yük değil mi? Aynısını (çok daha hızlı) YouTube veya Vimeo ile yapamaz mıyız? Kesinlikle yapabilirdik, ancak o zaman video oynatıcı iframe'ine yüklenen komut dosyalarının ek yükünden bahsetmeden marka bilincini veya reklamı videodan tamamen kaldıramazdık. Ayrıca, bazen videoyu ürün sayfanızda arka plan videosu olarak kullanmak ve her türlü harici markalamadan kaçınmak isteyebilirsiniz.

Çözüm

Görüntüleri kameramızdan doğrudan web'e dağıtmıyoruz, ancak kalite ile web performansını dengelemek için bunları sıkıştırıyor ve yeniden boyutlandırıyoruz. Aynı şey video dosyaları için de yapılmalıdır. Daha küçük videolar daha hızlı oynamaya başlar ve daha az durur, bu da web sitesinin kullanıcı deneyimini iyileştirir.

Bu makalede, örneğin kaliteyi ve kare hızını düşürerek videolarımızı optimize etmek için birkaç basit adımdan geçtik. Ayrıca, video akışının, web için daha duyarlı bir video deneyimi oluşturmamıza nasıl izin verebileceğini de inceledik - cihazın ekranı için uygun boyuttaki videoları otomatik olarak sunar.

Okuduğunuz için teşekkürler ve daha fazlasını öğrenmek istiyorsanız, burada, Smashing Magazine'de ve blogumda en iyi video uygulamaları hakkında daha fazlasını okumak isteyebilirsiniz:

• Web'de Video Oynatma: Videonun Mevcut Durumu (1. Kısım)
• Web'de Video Oynatma: Video Teslimi En İyi Uygulamaları (Bölüm 2)
• Mobil Web'de Videoları Gizleme