Video oluşturuyor, mevcut dosyaları dönüştürüyor veya bir web sitesi için video hazırlıyorsanız en önemli kararlardan biri doğru biçimi ve sıkıştırma ayarlarını seçmektir. Mümkün olan en küçük dosya her zaman en iyi dosya değildir. Videonun tarayıcılarda sorunsuz oynatılması, akıllı telefonlarda çalışması, verimli biçimde çözümlenmesi ve kullanım amacına uygun görüntü kalitesini koruması da gerekir.
MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, x264 kodlayıcı ön ayarları, tarayıcı uyumluluğu, mobil cihazlarda donanımsal çözme ve video kalitesi ölçümünü inceledim. Ayrıca aynı kaynak videoyu farklı CRF değerleriyle kodlayıp sonuçları hem gözle hem de nesnel ölçümlerle karşılaştırdığım uygulamalı sıkıştırma deneyleri yaptım.
Tek bir video dosyasının mümkün olduğunca çok tarayıcıda, telefonda ve harici uygulamada çalışması gerektiğinde H.264 kodlu MP4 biçimine öncelik vermeye karar verdim.
Öncelikle telefonlarda izlenecek kısa videolarda, bütün ince ayrıntıları korumaktan çok hızlı yükleme ve küçük dosya boyutu önemli olduğundan x264 CRF 30 değerini seçtim. Çünkü büyük bir masaüstü monitöründe bile normal oynatım sırasında CRF 22 ile 30 arasında kayda değer bir fark göremedim.
Ancak bu kararın önemli bir sınırı var: CRF 30, filmler, yüksek prodüksiyon kalitesine sahip videolar veya en yüksek görüntü sadakatinin önemli olduğu çekimler için bir öneri değildir. Böyle içeriklerde genellikle CRF 20 civarı gibi çok daha temkinli bir değer daha uygun bir başlangıç olabilir. Uzun metrajlı filmler veya yüksek kaliteli sinema görüntüleri üzerinde benzer bir inceleme yapmadım; dolayısıyla bu ayarlar ayrıca sınanması gereken başlangıç noktalarıdır.
Bu yazıda teknik gerekçeleri, gerçek sıkıştırma sonuçlarını ve bunların sınırlarını anlatıyor; kendi projeniz için uygun video biçimini ve kalite ayarını nasıl seçebileceğinizi ele alıyorum.
1. Video kapsayıcıları ve kodekler aynı şey değildir
MP4 ile WebM'yi karşılaştırmadan önce kapsayıcı ile kodek arasındaki farkı anlamak gerekir.
Kapsayıcı, video, ses, zaman damgaları ve meta verileri tek bir dosyada bir araya getirir. Video kodeği ise video karelerinin nasıl sıkıştırılıp çözüleceğini belirler.
Örneğin bir MP4 dosyası H.264, HEVC veya AV1 video içerebilir. Dosya uzantıları aynı olsa da bu birleşimlerin sıkıştırma özellikleri ve cihaz gereksinimleri farklıdır.
| Bileşen | Örnekler | İşlevi |
|---|---|---|
| Video kapsayıcısı | MP4, WebM, MOV, MKV | Video, ses ve zamanlama verilerini bir arada tutar |
| Video kodeği | H.264, HEVC, VP9, AV1 | Video karelerini sıkıştırır ve çözer |
| Ses kodeği | AAC, Opus, MP3 | Sesi sıkıştırır ve çözer |
| Video kodlayıcısı | x264, x265, SVT-AV1, libvpx-vp9 | Video sıkıştırmasını gerçekleştirir |
Dosya adındaki .webm uzantısını .mp4 olarak değiştirmek video kodeğini dönüştürmez. Aynı şekilde AV1'i MP4 içine koymak da AV1 çözme desteği bulunmayan cihazlarda videonun oynatılmasını sağlamaz.
Video uyumluluğunu değerlendirirken daima bütün birleşimi göz önünde bulundurun: kapsayıcı, video kodeği, ses kodeği, kodek profili, bit derinliği ve oynatma ortamı.
2. MP4 mü WebM mi? Web videoları için hangisi daha iyi?
MP4 ve WebM, günümüzde kullanılan geçerli video kapsayıcılarıdır. Hiçbiri her durumda diğerinden üstün değildir; çünkü pratik özellikleri içerdikleri kodeklere bağlıdır.
H.264'lü MP4: En geniş pratik uyumluluk
H.264 video ve AAC ses içeren MP4'ün uzun yıllara dayanan son derece geniş bir uyumluluk geçmişi vardır. Başlıca masaüstü ve mobil tarayıcılar, işletim sistemlerinin video oynatıcıları ve çok sayıda üçüncü taraf uygulama tarafından desteklenir.
Akıllı telefonların ve bilgisayarların donanımsal video çözücüleri de bu biçimi yaygın olarak destekler. Donanımsal çözme, yazılımsal çözmeye kıyasla CPU kullanımını azaltabilir, oynatma verimliliğini artırabilir ve güç tüketimini düşürebilir.
Başlıca dezavantajı sıkıştırma verimliliğidir. Daha yeni kodekler, benzer algılanan kaliteyi çoğu zaman daha düşük bit hızlarında sağlayabilir.
Yine de güvenilir oynatma, mümkün olan en küçük dosyadan daha önemliyse H.264 hâlâ çok iyi bir seçimdir.
VP9'lu WebM: Verimli ve tarayıcı dostu
WebM genellikle VP8, VP9 veya AV1 video içerir; ses ise çoğunlukla Opus ya da Vorbis ile kodlanır.
VP9, karşılaştırılabilir görüntü kalitesinde çoğu zaman H.264'ten daha yüksek sıkıştırma verimliliği sunar. Safari'nin modern sürümleri dâhil güncel tarayıcılarda geniş destek görür.
Safari'nin WebM veya VP9'u kesinlikle desteklemediğini söylemek yanlış olur. Tarayıcı uyumluluğu zaman içinde önemli ölçüde gelişti.
Asıl önemli sınırlama, tarayıcı dışındaki uyumluluktur. İşletim sisteminin yerel uygulamaları, eski cihazlar ve üçüncü taraf yazılımlar WebM'yi geleneksel H.264 MP4 kadar tutarlı biçimde işleyemeyebilir.
Oynatma olanaklarını denetleyebildiğiniz, yalnızca tarayıcıda çalışan bir uygulama için WebM güçlü bir seçenektir. Ziyaretçilerin indirip farklı programlarda açabileceği videolarda ise MP4/H.264 daha öngörülebilir bir tercihtir.
Pratikteki farklar
| Gereksinim | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Modern tarayıcılarda oynatma | Mükemmel | Çok iyi |
| Eski tarayıcı ve cihaz desteği | Genellikle daha geniş | Ortama daha bağımlı |
| İndirilen dosyaların uyumluluğu | Genellikle daha geniş | Yerel uygulamalarda daha az öngörülebilir |
| Sıkıştırma verimliliği | İyi | Çoğu zaman daha iyi |
| Donanımsal çözme | Son derece yaygın | Yaygın, ancak cihaza bağlı |
| En uygun kullanım | Geniş uyumlu tek bir dosya | Bilinen istemcilere verimli web üzerinden sunum |
Asıl soru WebM'nin iyi bir biçim olup olmadığı değil; sıkıştırma avantajlarının sizin ortamınızdaki uyumluluk ödünleşimlerine değip değmediğidir.
3. H.264, H.265, VP9 ve AV1: Hangi kodeği seçmelisiniz?
Başlıca video kodeklerinin her biri sıkıştırma verimliliği, kodlama maliyeti, donanım desteği, yazılım uyumluluğu ve lisanslama arasında farklı bir denge kurar.
| Kodek | Sıkıştırma verimliliği | Pratik uyumluluk | Tipik kullanım |
|---|---|---|---|
| H.264 / AVC | İyi | Mükemmel | Genel web videoları, mobil oynatma, indirmeler |
| H.265 / HEVC | Genellikle H.264'ten daha iyi | Ortama bağlı | Uyumlu Apple cihazları, denetimli ortamlar, yüksek çözünürlüklü video |
| VP9 | Genellikle H.264'ten daha iyi | Modern tarayıcılarda çok iyi | Tarayıcı üzerinden video sunumu |
| AV1 | Potansiyel olarak mükemmel verimlilik | Yaygınlaşıyor, eski cihazlarda sınırlamalar var | Modern akış yayını ve uyumlu cihazlar |
Bunlar nitel karşılaştırmalardır; her durumda geçerli bit hızı sıralamaları değildir. Gerçek verimlilik videonun içeriğine, kodlayıcının uygulamasına, hedef kaliteye, kodlama ön ayarına ve ölçüm yöntemine bağlıdır.
H.264: Olgun, hızlı çözülen ve geniş destekli
H.264 büyük ölçüde optimize edilmiştir ve son derece geniş bir donanım ve yazılım yelpazesi tarafından desteklenir. Bir videonun özel bir oynatıcı gerektirmeden güvenilir biçimde çalışması gerektiğinde bu olgunluk önemli bir avantajdır.
Zayıf yönü, daha yeni kodeklerin videoyu çoğu zaman daha verimli sıkıştırabilmesidir. Ayrıca H.264 patent ve lisanslama konularına tabidir; ilgili ticari dağıtım senaryolarında bunlar değerlendirilmelidir.
H.265 / HEVC: Uyumluluk ödünleşimleriyle daha iyi sıkıştırma
HEVC, benzer kalitede H.264'e göre bit hızını önemli ölçüde azaltabilir. Özellikle yüksek çözünürlüklü içerikler ve cihaz uyumluluğunun denetlendiği ortamlar için caziptir.
Birçok Apple cihazı HEVC'yi çok iyi destekler. Ancak tarayıcı ve harici uygulama desteği işletim sistemine ve kurulu çözme bileşenlerine göre değişir. Lisanslama da ayrı bir konudur.
HEVC çok iyi bir tercih olabilir; ancak genel amaçlı bir web sitesinde indirilebilir videoların tek biçimi olarak otomatik biçimde seçmezdim.
VP9: Pratik, açık bir alternatif
VP9 iyi sıkıştırma ve modern tarayıcılarda geniş uyumluluk sunar. Videolar yalnızca tarayıcıda izleniyorsa ve oynatma ortamı öngörülebiliyorsa güçlü bir seçenektir.
Benim kullanım senaryomdaki temel dezavantajı, kullanıcıların videoyu indirmesi veya WebM ya da VP9'u tutarlı biçimde desteklemeyen yerel uygulamalarda açması hâlinde oluşan belirsizlikti.
AV1: Mükemmel verimlilik, ancak evrensel donanım desteği yok
AV1, en umut verici modern video kodeklerinden biridir. Eski kodeklere göre önemli bit hızı tasarrufu sağlayabilir ve donanımsal çözme desteği de giderek genişliyor.
Bununla birlikte eski cihazlarda AV1 çözücü bulunmayabilir veya yazılımsal çözme gerekebilir. Yüksek çözünürlüklü videonun yazılımla çözülmesi daha fazla CPU gücü ve pil tüketebilir, zayıf cihazlarda oynatma sorunlarına yol açabilir.
Oynatma ortamını kontrol ediyorsanız AV1'i ciddi biçimde değerlendirmeye değer. Tek dosyanın eski ve yeni cihazlarda ve sıradan harici video oynatıcılarda çalışması gerekiyorsa H.264 daha güvenli varsayılan seçenektir.
MDN'nin video kodekleri kılavuzu, bu kodekler ve tarayıcı gereksinimleri hakkında yararlı ayrıntılar içerir.
4. Tek video biçimi mi, birden fazla sürüm mü?
Video sunumuyla ilgili en önemli mimari kararlardan biri budur.
Birden fazla sürüm sunulabiliyorsa site uyumlu cihazlara AV1 veya VP9 verebilir, diğer ortamlarda H.264'e geçebilir. Böylece geniş oynatma desteği korunurken sıkıştırma verimliliği artırılabilir.
Ancak birden fazla sürümü yönetmek kodlama, depolama, önbellekleme, doğrulama ve oynatılacak sürümün seçimi açısından ek karmaşıklık yaratır.
Her kaynak için tam olarak tek bir bitmiş video dosyasına ihtiyacınız varsa genellikle uyumluluğu önceleyen yaklaşım daha uygundur.
MP4/H.264'ü seçtim; çünkü alternatif biçimlere bağımlı olmadan büyük tarayıcılarda, akıllı telefonlarda ve indirilen videoların yaygın kullanım senaryolarında çalışan tek bir dosya istiyordum.
Bu, MP4/H.264'ün en iyi sıkıştırmayı sunduğu anlamına gelmez. Bu seçim, daha yeni bir kodeğin sağlayabileceği boyut avantajından çok öngörülebilir oynatmaya önem verir.
5. Mobil videolarda öncelikler neden farklıdır?
Video sıkıştırması, içeriğin gerçekte nasıl tüketileceğine göre yapılmalıdır.
Öncelikle akıllı telefonda izlenen kısa bir klibin gereksinimleri, büyük televizyonda izlenen uzun metrajlı filminkinden farklıdır. İlkinde hızlı yükleme ve daha az mobil veri kullanımı, en ince görüntü ayrıntılarını korumaktan daha değerli olabilir. İkincisinde ise asıl hedef görüntü kalitesi olabilir.
Telefonlarda izlenecek kısa videolarda daha küçük dosyaların birkaç avantajı vardır:
- Oynatma başlamadan önce aktarılması gereken veri miktarı azalır.
- Kısıtlı bağlantılarda indirme daha erken tamamlanabilir.
- Cihazda daha az depolama alanı gerekir.
- Kullanıcılar daha az mobil veri harcar.
- Kodlanan bit hızı daha düşük olduğunda, sınırlı aktarım hızında oynatma daha dayanıklı olabilir.
Ancak daha küçük dosya, videonun hiçbir zaman takılmayacağını veya donmayacağını garanti etmez. Ağdaki değişkenlik, anlık en yüksek bit hızı, sunucu davranışı, oynatma tamponu ve cihazın çözme performansı da önemlidir.
Mobil uyumluluk yalnızca dosya uzantısına bağlı değildir: donanımsal çözme, kodek profili ve düzeyi, bit derinliği, kroma alt örneklemesi, çözünürlük, kare hızı ve en yüksek bit hızı önem taşır. 390 CSS piksel genişliğinde görüntülenen bir video, yüksek piksel yoğunluklu telefon ekranında fiziksel olarak çok daha fazla piksel kaplayabilir. Bu yüzden bir kareyi 390 piksele küçültüp incelemek, videonun özgün hâlini o telefonda izlemekle mutlaka aynı şey değildir. Gerçek cihazlarda ve gerçek oynatma koşullarında test yapın.
CRF tam bir azami bit hızı dayatmaz, kaliteyi kontrol eder. Genel dosya boyutu görece küçük olsa bile karmaşık bir videoda yüksek bit hızı zirveleri görülebilir. Özellikle yavaş bağlantılarda güvenilir oynatma şartsa açık bit hızı veya VBV sınırlarını, uygun çözünürlük sınırlarını ve gerçekçi ağ koşullarındaki testleri değerlendirin.
Temel ilke basit: soyut bir en yüksek kalite hedefi için değil, amaçlanan izleme deneyimi için optimize edin.
6. x264 CRF'yi anlamak: Daha düşük değer daha yüksek kalite, daha yüksek değer daha küçük dosya
H.264'ü seçtikten sonraki zorluk, videonun ne kadar yoğun sıkıştırılacağını belirlemektir.
x264'te Constant Rate Factor, yani CRF, korunan görüntü ayrıntıları ile dosya boyutu arasındaki dengeyi belirler.
Daha düşük CRF genellikle daha kaliteli ve daha büyük dosyalar üretir. Daha yüksek CRF ise genellikle daha küçük dosyalar ve daha fazla sıkıştırma kaybı anlamına gelir.
CRF kesin bir bit hızı ya da çıktı boyutu belirlemez. Kodlayıcı bitleri kaynak içeriğe göre dağıtır; bu nedenle basit bir sahneyle çok ayrıntılı bir sahne, aynı CRF'de son derece farklı dosya boyutlarına sahip olabilir.
CRF, çözücü uyumluluğunun temel özelliklerini de belirlemez. CRF 22 ve CRF 30 ile doğru kodlanmış iki H.264 video aynı kodeğe, profile, düzeye, piksel biçimine, boyutlara ve kare hızına sahip olabilir.
Temel fark, sıkıştırma kaliteleri ve bit hızı özellikleridir.
Önemli bir nokta: CRF sayıları farklı kodek uygulamaları arasında doğrudan karşılaştırılamaz. x264'teki CRF 30, bir AV1 kodlayıcısındaki CRF 30 ile aynı görüntü kalitesini ifade etmez.
7. Gerçek sıkıştırma deneyim: CRF 22'den 32'ye
Normal oynatma sırasında farkın önemli hâle gelmesinden önce ne kadar sıkıştırma yapabileceğimi öğrenmek istedim.
Önceden sıkıştırılmış tek bir kısa video kullandım ve CRF 22, 24, 26, 28, 29, 30, 31 ve 32 ile H.264 karşılaştırma dosyaları oluşturdum.
Çözünürlük, kare hızı, süre ve kare sayısı dâhil videonun temel özelliklerini korudum. CRF değişiminin etkisini değerlendirebilmek için kodlayıcı ayarlarını da sabit tuttum.
Sonuçlar dosya boyutlarında önemli farklar gösterdi.
| CRF | Orijinale göre yaklaşık boyut | Anlamı |
|---|---|---|
| 22 | 63% | Daha temkinli sıkıştırma, ayrıntıların daha iyi korunması |
| 24 | 49% | Kalitede sınırlı ek kayıpla daha küçük dosya |
| 26 | 38% | Önemli ayrıntılar korunurken ek tasarruf |
| 28 | 30% | Kaynağa görece yüksek benzerlikle küçük çıktı |
| 29 | 26% | Daha agresif sıkıştırma |
| 30 | 23% | Bu test içeriği için tercih ettiğim denge |
| 31 | 21% | Kaynak sadakati azalırken ek tasarruf |
| 32 | 19% | Test edilen en küçük çıktı ve ölçülen en yüksek kalite kaybı |
Bu yüzdeler yalnızca test edilen kaynağa aittir; herhangi bir videoda beklenen tipik tasarruflar olarak yorumlanmamalıdır. Tablodaki yüzdeler ayrı ayrı yuvarlanmıştır. Kesin göreli tasarrufları, yuvarlanmış değerleri birbirine bölerek değil, gerçek dosya boyutlarından hesaplayın.
En şaşırtıcı sonuç, büyük bir masaüstü monitöründe bile normal oynatma sırasında CRF 22 ile CRF 30 arasında kayda değer bir görüntü farkı göremememdi.
CRF 32 dâhil daha agresif sıkıştırılmış sürümleri de inceledim. O belirli klibi normal biçimde izlerken önemli bir fark fark etmedim.
Bu gözlem önemliydi; çünkü aynı videolar esas olarak daha küçük mobil ekranlar için hazırlanıyordu. Masaüstü monitörümde kalite düşüşü rahatsız edici değilse hedeflediğim izleme deneyimini iyileştirmeyen ayrıntılar için dosya boyutunu ciddi ölçüde artırmamın pek anlamı yoktu.
Ancak bu, belirli bir kaynak içerik türüne ilişkin öznel bir gözlemdi. Bütün kullanıcıların, telefonların veya videoların aynı sonucu vereceğini kanıtlamaz. Yüksek piksel yoğunluklu mobil ekranlar ve yakından izleme, özellikle ince ayrıntılarda veya renk geçişlerinde sıkıştırma kusurlarını yine de görünür kılabilir.
8. Nesnel ölçümler gerçek kalite kaybını doğruladı
Oynatma sırasında fark görememek, iki videonun matematiksel olarak aynı olduğu anlamına gelmez.
Kodlanmış çıktıları nesnel görüntü kalitesi ölçümleriyle de karşılaştırdım. CRF arttıkça kaynakla benzerlik azaldı.
Yüksek piksel yoğunluklu bir mobil ekranı yaklaşık olarak temsil etmek için tutarlı biçimde küçültülmüş görüntüler üzerinden yapılan karşılaştırmada, örnek SSIM ölçümleri şöyleydi:
| CRF | Yaklaşık SSIM | CRF 28'e göre çıktı boyutu |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
Eğilim açıktı: daha güçlü sıkıştırma, kodlanmış videonun ölçülen kaynak sadakatini azalttı. Yakından inceleme de ince çizgilerde ve dokuda küçük farklılıklar gösterdi.
Buna rağmen test edilen kaynakta normal izleme deneyimi çok benzer kaldı. Nesnel ölçümlerle öznel değerlendirmenin birlikte kullanılmasının nedeni tam da budur.
SSIM, görüntü benzerliğini ölçer; insanın tüm izleme deneyimini değil. Zamana bağlı sıkıştırma kusurlarını, algılanan keskinliği, hareketin görünümünü veya tek tek ayrıntıların öznel önemini bütünüyle hesaba katamaz.
VMAF da algısal kaliteyi ölçmek için yararlı bir metriktir. Netflix, telefonlarda izleme koşullarına göre tasarlanmış bir model de içeren VMAF v1 modellerini Haziran 2026'da yayımladı. Bu modeller algılanan kalitenin kısmen ekran boyutuna ve göreli izleme mesafesine bağlı olduğunu açıkça dikkate alıyor.
İncelemedeki temkinli ayarlarla kodlanmış bir örnek için bildirilen ortalama VMAF yaklaşık 95'ti; ancak agresif CRF ayarlarının tamamına ait tutarlı bir VMAF ölçüm dizisi yoktu. Dolayısıyla CRF 30 veya 32'nin evrensel bir kalite eşiğine ulaştığını iddia etmek için VMAF'ı kullanmadım.
Pratik sonuç daha sınırlıydı: test edilen kısa video, normal oynatma sırasında yoğun H.264 sıkıştırmasına son derece iyi dayandı.
9. Kısa mobil videolar için neden CRF 30'u seçtim?
Dosyaları karşılaştırdıktan sonra kararım, esas olarak mobil cihazlarda izlenen benzer kısa videolar için CRF 30 kullanmak oldu.
Gerekçelerim basitti:
- Videolar kısaydı ve sinema düzeyinde görüntü kalitesi sunmayı amaçlamıyordu.
- Hızlı yükleme ve küçük indirme boyutları önemliydi.
- Büyük bir masaüstü monitöründe CRF 22 ile 30 arasında belirgin fark göremedim.
- CRF 30, temkinli ayarlara göre çok daha küçük dosyalar üretti.
- CRF 32 de test örneğinde görsel olarak kabul edilebilirdi, ancak daha karmaşık içerikler konusunda daha az güven veriyordu.
CRF 28'e kıyasla CRF 30, test edilen çıktı boyutunu yaklaşık %21 azalttı. CRF 22'ye kıyasla azalma %60'ın üzerindeydi.
Hedefin hoş bir görüntü, hızlı yükleme ve makul bant genişliği tüketimi olduğu kısa mobil klipler için bu ödünleşime değdi.
Ama koşul son derece önemli: CRF 30'u, 30 değerinin akıllı telefonlar için doğası gereği en iyi CRF olduğu için değil, gerçek izleme amacı ve test edilen içeriğin sonuçları nedeniyle seçtim.
Bir mobil cihaz CRF 30 gerektirmez. Çok daha yüksek sadakatli bir kodlamayı da gayet iyi gösterebilir. CRF 30, bu değiş tokuş kabul edilebilir olduğunda daha küçük dosyalar karşılığında kaynak sadakatinin bir kısmından bilinçli olarak vazgeçmektir.
Bunu çok farklı içerikler barındıran bir koleksiyona uygulamadan önce zor hareketler, karanlık sahneler, renk geçişleri, metin ve ince dokular içeren birden fazla temsilî klibi test ederdim.
10. Filmler ve yüksek kaliteli videolar için neden CRF 30'u önermiyorum?
Deneyin en önemli sınırı budur.
CRF 30 ile aldığım sonucu uzun metrajlı filmlere, yüksek prodüksiyon kalitesindeki içeriklere, profesyonel çekimlere veya büyük ekranda izlenecek videolara düşünmeden uygulamayın.
Bu tür içeriklerde ince renk geçişleri, film greni, az ışıklı sahneler, karmaşık hareketler, ayrıntılı dokular ve özenle düzenlenmiş renkler bulunabilir. Bu ayrıntıları korumak, görece küçük bir bant genişliği tasarrufundan daha önemli olabilir.
Geleneksel, yüksek kaliteli 1080p video için CRF 20 civarı gibi çok daha temkinli bir x264 ayarından başlar, içeriğe göre bu değerin altını ve üstünü değerlendirirdim.
Görüntü sadakati önemliyse CRF 18–22 pratik bir başlangıç aralığı olabilir; ancak uygun değer çözünürlüğe, içeriğe ve gereksinimlere göre bu aralığın dışında da kalabilir.
Bu öneri, yaygın olarak yayımlanan kodlama rehberleriyle uyumludur. Örneğin HandBrake'in kalite belgeleri, birçok 1080p x264 kullanımında yaklaşık RF 20–24 değerlerini önerir.
Uzun metrajlı filmler veya yüksek kaliteli sinema çekimleri üzerinde aynı kontrollü araştırmayı yapmadım. Bu nedenle CRF 20'nin her zaman ideal, CRF 22'nin her zaman yeterli ya da belirli bir filmin CRF 30'da mutlaka kabul edilemez görüneceğini iddia edemem.
Doğru yöntem; temsilî sahneleri seçmek, birkaç kalite düzeyinde kodlamak, hedef ekranda karşılaştırmak ve daha fazla sıkıştırmanın görünür biçimde zarar vermeye başladığı noktayı belirlemektir.
Video arşivlenecekse, yeniden düzenlenecekse veya gelecekteki kodlamalara kaynak olacaksa yüksek kaliteli ana kopya, sunuma yönelik sıkıştırılmış sürümden ayrı saklanmalıdır.
11. Neden x264 veryslow ön ayarını kullandım?
CRF sıkıştırma kalitesinin bir yönünü kontrol ederken x264 ön ayarı, kodlayıcının verimli kodlama kararları aramak için ne kadar işlem yapacağını belirler.
x264, çok hızlıdan çok yavaşa uzanan ön ayarlar sunar. Genel olarak daha yavaş ön ayarlar daha fazla CPU zamanı kullanır ve benzer görüntü kalitesinde daha yüksek sıkıştırma verimliliği sağlayabilir.
Aynı kaynakta medium ve veryslow ön ayarlarını karşılaştırdım. Test edilen kalite ayarında veryslow daha küçük bir dosya üretti.
Bir kez çevrimdışı kodlanıp defalarca kullanılacak videolarda ek işlem süresi buna değebilir.
Bu yüzden -preset veryslow seçtim.
Ancak bu ayar her durumda en iyisi değildir. Videoların hemen işlenmesi gerekiyorsa, CPU kaynakları pahalıysa veya çok büyük bir işlem kuyruğu varsa slow ya da medium çalışma açısından daha iyi bir denge sunabilir.
Ön ayar esas olarak kodlamanın karmaşıklığını ve sıkıştırma verimliliğini değiştirir. H.264'ü farklı bir kodeğe dönüştürmez veya ortaya çıkan dosyayı mobil cihazlarla kendiliğinden uyumsuz kılmaz.
12. Anime videolarında x264'ün animation ayarını kullanıyorum
Kaynakta çizim animasyonu veya anime tarzı görüntüler varsa x264 ile -tune animation kullanıyorum.
Bu, CRF ayarından farklıdır. Bir tune ayarı, belirli görsel özelliklere uyması için kodlayıcının bazı kararlarını değiştirir. Animation ayarı; çizilmiş kenarlar, düz renkli alanlar ve stilize hareketler içeren materyaller için tasarlanmıştır.
Bu nedenle tercihim şöyle:
- Anime veya çizim animasyon videosu:
-preset veryslow -tune animation. - Normal gerçek çekim: animation ayarını otomatik olarak açmayın; kodlayıcının varsayılan ayarlarıyla başlayın veya uygun bir tune seçeneğini ayrıca değerlendirin.
Bu ayarın ne yaptığını yanlış anlamamak gerekir. -tune animation, gözle görülür biçimde daha yüksek kalite veya daha küçük dosyalar garanti etmez. Kodlayıcının davranışını değiştirir; sonuç içeriğe bağlıdır.
Animation ayarıyla ayrı bir sabit CRF karşılaştırması yaptım. Bu özel karşılaştırmada ayarı açmak dosyayı yaklaşık %6 büyüttü ve ölçülen görüntü benzerliğini biraz artırdı. Görsel fark küçüktü.
Ana CRF 22–32 boyut karşılaştırması animation ayarı olmadan yapıldı. Dolayısıyla bu deneydeki kesin dosya boyutlarının ve sıkıştırma oranlarının -tune animation etkinleştirildiğinde de aynı kalacağı varsayılmamalıdır.
Buna rağmen anime görüntülerinde animation ayarını kullanmayı, ortaya çıkan boyutu ve kaliteyi de o içeriğin kodlama profilinin bir parçası olarak değerlendirmeyi tercih ediyorum.
Kodlayıcıya yönelik tune ayarları, her zaman evrensel kalite yükseltmeleri olarak değil, içeriğe bağlı düzenlemeler olarak görülmelidir.
13. Kısa ve mobil odaklı anime videoları için önerdiğim FFmpeg ayarları
Gerçekten yeniden kodlanması gereken, geleneksel SDR anime videoları için aşağıdaki komut başlangıç olarak kullanacağım profili gösteriyor:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Bu komut temel tercihleri açıkça ortaya koyuyor:
-c:v libx264yazılımsal H.264 kodlayıcısını kullanır.-preset veryslowkodlama hızından çok sıkıştırma verimliliğine öncelik verir.-tune animationanimasyona yönelik kodlayıcı ayarlarını etkinleştirir.-crf 30bu tür kısa videolar için seçilen agresif sabit kalite hedefini uygular.-profile:v highmodern cihazlarda yaygın olarak desteklenen bir H.264 profili seçer.-pix_fmt yuv420p8 bit 4:2:0 video üretir.-map 0:v:0ilk video akışını seçer.-map '0:a:0?'varsa ilk ses akışını seçer.-c:a aac -b:a 128kses varsa onu standart AAC olarak kodlar.-movflags +faststartMP4 başlatma meta verilerini dosyanın başına taşır.
Bu bir örnektir; her girdi için evrensel bir komut değildir. Kaynak videonuzun özellikleri ek işlemler gerektirebilir.
Özellikle HDR ve 10 bitlik materyaller, doğru renk yönetimi olmadan düşüncesizce 8 bit SDR'ye dönüştürülmemelidir; yanlış renkler, parlak bölgelerde ayrıntı kaybı veya görünür renk bantlaşması oluşabilir. Döndürme meta verileri, değişken kare hızları, piksel en-boy oranları, geçmeli görüntüler, alışılmadık ses düzenleri ve uyumsuz çözünürlük sınırları da dikkat gerektirir.
Kaynağın kare hızı ve boyutları zaten uygunsa bunları korumak genellikle karşılaştırmayı kolaylaştırır, gereksiz ölçekleme ve hareket değişikliklerini önler. Zorunlu olmadıkça değişken kare hızlı kaynakları sabit kare hızına çevirmeyin; bu işlem kareleri çoğaltabilir veya atabilir. Boyutlandırma yaparken görüntünün en-boy oranını koruyun ve boyutların seçilen 4:2:0 piksel biçimiyle uyumlu olduğundan emin olun. Çok yüksek çözünürlük, kare hızı veya H.264 düzeyi eski cihazların çözme sınırlarını aşabilir; dolayısıyla uyumluluk bazen bilinçli çözünürlük ya da kare hızı düşürme gerektirir.
14. Yüksek kaliteli video için daha temkinli bir FFmpeg başlangıç ayarı
Görüntünün aslına sadakati dosya boyutundan çok daha önemliyse daha düşük bir CRF ile başlayıp sonucu değerlendirin.
Örneğin aşağıdaki ayarlar, geleneksel SDR gerçek çekim videosu için makul bir deneysel başlangıç noktasıdır:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Bu örnekteki slow ön ayarı genel kullanım için pratik bir başlangıçtır; veryslow ayarından üstün olduğu iddiası değildir. Ek kodlama süresi sorun değilse veryslow kullanmak da mantıklıdır.
Bu yüksek kaliteli profil, kısa video deneyimle kanıtlanmış bir yapılandırma değil, test edilmesini önerdiğim bir başlangıç ayarıdır.
Yüksek kaliteli içeriklerde yaklaşık CRF 18, 20 ve 22 değerlerini deneyip gözle görülen sonuçlara göre seçim yapın. Zorlu gren ve hareketler farklı ayarlar gerektirebilir; arşiv için tutulan ana kopyalar ise çok daha hafif sıkıştırılmalıdır.
15. Gereksiz yere videoyu yeniden kodlamayın
Kayıplı video sıkıştırmasının bir bedeli vardır. Daha önce sıkıştırılmış bir dosyanın yeniden kodlanması, yeni çıktı kaynağa benzer görünse bile ek bozulmalara yol açabilir.
Dönüştürmeye başlamadan önce özgün dosyanın uyumluluk, boyut ve kalite gereksinimlerinizi zaten karşılayıp karşılamadığını sorun.
Dosya zaten uyumlu H.264 video ve AAC ses içeriyorsa ve görüntüde değişiklik yapmak gerekmiyorsa yeniden kayıplı kodlamaktansa akışları kopyalamak daha iyi olabilir.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Bu işlem sıkıştırılmış akışları yeniden kodlamadan kopyalar. Böylece ek bir sıkıştırma kaybına yol açmadan kapsayıcı düzeni değiştirilebilir.
Ancak normalde kaliteyi düşürerek yeniden kodlama kadar büyük dosya boyutu tasarrufu sağlamaz.
Elinizdeki video zaten küçük, uyumlu ve görüntü kalitesi açısından kabul edilebilirse onu olduğu gibi bırakmak en iyi optimizasyon olabilir.
16. Yalnızca dosya boyutuna güvenmeyin, kodlanmış videoları doğrulayın
FFmpeg'in başarıyla çıkması videonun bütün gereksinimleri karşıladığını otomatik olarak kanıtlamaz.
Önce çıktı akışlarını FFprobe ile inceleyin:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Kodeği, piksel biçimini, boyutları, kare hızını, süreyi ve ses akışlarını doğrulayın.
Ardından bazı bozulmaları ve çözme hatalarını tespit etmek için çıktının tamamını çözümleyin:
ffmpeg -v error -xerror -i output.mp4 -f null -Sıkıştırma deneylerinde aynı kaynaktan oluşturulan çıktıları karşılaştırın. Önemli değişkenleri sabit tutun ve her seferinde yalnızca bir ana ayarı değiştirin.
Ortaya çıkan videoyu hareket hâlinde izleyin, ince ayrıntıları inceleyin; renk geçişlerine, karanlık bölgelere, hareketli nesnelere ve metne dikkat edin.
Mümkünse görsel karşılaştırmalara SSIM, PSNR veya VMAF gibi nesnel metrikler ekleyin. Tek bir yüksek puanı, bütün sıkıştırma kusurlarının görünmez olduğunun kanıtı saymayın.
Son olarak videoyu temsilî cihazlarda ve indirilmiş dosya kullanım senaryolarında test edin. Tarayıcı destek bilgileri değerlidir, ancak uyumluluk temel amaç olduğunda gerçek oynatma testleri özellikle önemlidir.
17. MP4 dosyalarınızı doğru biçimde sunun
İyi kodlama ayarları, kötü web sunumunun eksiklerini telafi edemez.
Normal aşamalı MP4 oynatımı için doğru Content-Type: video/mp4 başlığını yapılandırın ve kısmi veri alma ile videoda ileri geri sarma gereken yerlerde HTTP bayt aralığı isteklerini destekleyin.
FFmpeg'in +faststart seçeneği, standart bir MP4 dosyasının başlatma bilgilerini dosyanın başına yaklaştırır. Bu, aşamalı yüklemeyi kolaylaştırır; ancak görüntü kalitesini artırmaz veya bit hızını azaltmaz.
Temel bir HTML video öğesi tek bir H.264 MP4 sunabilir:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>preload özniteliği, tarayıcıya verilen bir ipucudur; katı bir indirme sınırı değildir. Tarayıcıların otomatik oynatma kuralları videonun sessize alınmasını veya hiç ses içermemesini de gerektirebilir.
Bir sayfada birden fazla video varsa hepsini hemen indirmekten kaçının. Videoları yalnızca gerektiğinde yüklemek mobil veri tüketimini azaltabilir ve algılanan yanıt hızını artırabilir.
Kısa mobil kliplerde indirmelerin ne zaman başlayacağını optimize etmek, kodlanan dosya boyutunu küçültmek kadar önemli olabilir.
18. Hangi video biçimini ve kaliteyi seçmelisiniz?
Doğru yanıt neyi optimize etmek istediğinize bağlıdır.
| Hedefiniz | Önerilen başlangıç noktası |
|---|---|
| Web'de ve indirilerek geniş uyumlulukla oynatılacak tek video | Ses varsa MP4 + H.264 + AAC |
| Birden fazla biçimle modern tarayıcılara sunum | H.264 yedek seçeneğiyle AV1 veya VP9 |
| Desteklenen cihazlarda en yüksek sıkıştırma | AV1'i değerlendirin |
| HEVC uyumlu, denetimli oynatma ortamı | MP4 + HEVC'yi değerlendirin |
| Dosya boyutunun öncelikli olduğu kısa mobil klipler | Temsilî testlerden sonra x264 CRF 30'u değerlendirin |
| Anime veya çizim animasyonu | x264 ve -tune animation ayarını değerlendirin |
| Yüksek kaliteli filmler veya seçkin video içerikleri | 20 civarında daha temkinli bir CRF ile başlayıp test edin |
| CPU zamanının daha az önemli olduğu çevrimdışı kodlama | x264 slow veya veryslow kullanmayı değerlendirin |
| Hızlı işlem ve sınırlı CPU kaynakları | x264 medium veya slow kullanmayı değerlendirin |
| Mevcut video gereksinimleri zaten karşılıyor | Olduğu gibi tutun veya yeniden kodlamadan kapsayıcıyı değiştirin |
| Arşivleme veya gelecekte düzenleme | Yüksek kaliteli ana kopyayı sunum dosyalarından ayrı saklayın |
19. Son kararım ve deneyin gerçekte kanıtladıkları
Video biçimlerini, uyumluluğu, kodlama verimliliğini ve gerçek sıkıştırma sonuçlarını inceledikten sonra kısa, mobil odaklı videolar için pratik bir sunum profili seçtim.
Seçtiğim biçim H.264'lü MP4 oldu; çünkü tarayıcılarda, telefonlarda, indirilen dosyalarda ve harici uygulamalarda öngörülebilir uyumluluk, daha yeni bir kodekle mümkün olan en küçük dosyayı elde etmekten daha önemliydi.
Seçtiğim kodlayıcı, veryslow ön ayarıyla libx264 oldu; çünkü videoları çevrimdışı kodlayabiliyordum ve ek işlem süresi kabul edilebilirdi.
Anime videolarında animation ayarını kullanıyorum; ancak bunun kodlayıcının davranışını değiştirdiğini ve daha küçük dosyalar ya da her durumda daha iyi görüntü garantilemediğini biliyorum.
Kısa, mobil odaklı videolarda CRF 30'u seçtim; çünkü karşılaştırmam büyük bir masaüstü monitöründe bile normal oynatma sırasında kayda değer görüntü farkı olmadan dosya boyutunun ciddi ölçüde azaldığını gösterdi.
Bu sonuç, CRF 30'un filmler veya yüksek kaliteli çekimler için ideal olduğu anlamına gelmez. İnce ayrıntıların, renk geçişlerinin, grenin ve genel görüntü sadakatinin daha önemli olduğu içeriklerde CRF 20 civarından veya benzer ölçüde temkinli başka bir değerden testlere başlardım. Sinema görüntüleri üzerinde buna denk bir kontrollü çalışma yapmadım; dolayısıyla bu sayıyı deneyle kanıtlanmış bir optimum olarak sunmuyorum.
En önemli sonuç şu: bütün videolar için evrensel olarak en iyi tek bir kodek, biçim veya CRF değeri yoktur.
En geniş uyumluluğa öncelik veriyor ve tek dosya istiyorsanız MP4/H.264 güçlü bir varsayılan seçenektir. Yedek biçimler sunabiliyor ve daha iyi sıkıştırma istiyorsanız VP9 ile AV1'i araştırın. Esas olarak telefonlarda izlenen kısa videolar kodluyorsanız daha yüksek bir CRF'nin hedeflenen deneyime zarar vermeden yeterince küçük dosyalar üretip üretmediğini test edin. Film veya yüksek kaliteli görüntü kodluyorsanız daha temkinli kalite ayarları kullanın ve sonuçları dikkatle doğrulayın.
Önce oynatma gereksinimlerini, sonra kodeği, en son sıkıştırma kalitesini seçin. Ardından sonucu gerçekten önemli olan cihazlarda ve koşullarda test edin. Bu yaklaşım, yalnızca yeni, daha verimli veya yaygın biçimde öneriliyor diye bir kodeği ya da CRF değerini sorgulamadan benimsemekten daha güvenilirdir.