Avidemux/H264'e kodlama rehberi

Bu sayfa H.264'ün ne demek olduğunu, Avidemux'a nasıl H.264'e kodlama yeteneği kazandırılacağını ve Avidemux'taki x264 ayarlarını anlatmaktadır. Bu sayfa x264 kodlayıcısnın rehberi gibi düşünülebilir.

Giriş

"MPEG-4 Part 10" veya "MPEG-4 Advanced Video Coding" (AVC) olarak da bilinen H.264, çok yüksek oranda veri sıkıştırmaya izin veren bir video sıkıştırma standardıdır. H.264 videoları, eski MPEG-4 Part 2 standardındaki (Xvid ve DivX bu standarda kodlarlar) videolara oranla oynatılmaları için daha fazla işlemci gücüne ihtiyaç duymalarına rağmen çok daha yüksek oranda sıkıştırma verimi sağlarlar. Yani H.264/AVC ile MPEG-4 ASP'ye oranla eşit dosya boyutunda daha yüksek video kalitesi veya aynı video kalitesinde daha küçük dosya boyutu elde edersiniz. H.264'ün sıkıştırma verimi MPEG-4 Part 2'den daha yüksek olduğuna göre elbetteki MPEG-2'den hayli hayli yüksektir.

H.264 hakkında daha ayrıntılı bilgiyi ilgili Vikipedi maddesinde ve H.264'ün çeşitli kodekleri ile MPEG-4 Part-2 ve MPEG-2 gibi formatların çeşitli kodeklerinin kıyaslamasını http://mirror05.x264.nl/Dark/website/compare.html adresinde bulabilirsiniz.

x264'e giriş

Avidemux, H.264'ü çözmek için FFmpeg'den tümleşik libavcodec'i kullanırken H.264'e kodlamak için ek (harici) bir kütüphaneye ihtiyaç duyar. Avidemux bu amaç için x264'ü kullanabilir. x264, H.264/AVC akımları üretmeye yarayan özgür lisanslı bir kütüphanedir. x264, Laurent Aimar, Loren Merritt, Eric Petit (OS X), Min Chen (VfW/asm), Justin Clay (VfW), Måns Rullgård, Radek Czyz, Christian Heine (asm), Alex Izvorski (asm) ve Alex Wright tarafından sıfırdan yazılmış ve GPL ile lisanslanmıştır. Yani olayı basitleştirmek gerekirse kodlamaya yarayan kütüphaneye x264, kodlama sonucunda üretilen videonun formatına H.264 (veya MPEG-4 AVC) denir. Şu unutulmamalıdır ki x264 özgür ve ücretsiz bir yazılım olmasına rağmen gerek üretilen videonun kalitesi ve gerekse kodlama hızı konularında diğer ticari H.264 kodlayıcılarıyla ciddi bir rekabet içindedir. İnternetteki Youtube ve Facebook gibi birçok büyük şirket H.264 videolarını üretmek için x264'ü kullanmaktadırlar.

Avidemux'a x264 özelliği ekleme

Eğer Avidemux'un elinizdeki versiyonunda x264 mevcut değilse, x264'ü nasıl indirip derleyeceğiniz kitabın x264'ü derleme bölümünde anlatılmıştır.

x264'ü derledikten sonra ilgili x264 kodlarını Avidemux'a gömmek için Avidemux'u yeniden derlemelisiniz. Bu işlem için de kitabın Avidemux'u derleme bölümüne bakabilirsiniz.

Eğer Avidemux'un Microsoft Windows için önceden derlenmiş build'lerini kullanıyorsanız, x264 kütüphanesi zaten Avidemux'la paketli gelecektir. Bu yüzden herhangi ek bir yazılım kurmanıza gerek yoktur. "Codec Pack", "VFW Codecs" veya "DirectShow Filters" gibi isimlere sahip programlar Avidemux'la çalışmayacaktır! Ancak yine de isterseniz Avidemux için en güncel x264 kütüphanesi burada bulunur (en güncel sürümü bulmak için en son gönderilen mesaja gidin!). Bu build'ler genellikle Avidemux'la paketli gelenlere oranla daha yeni ve daha az test edilmiştir.

Avidemux'taki x264 ayarları

Avidemux, x264 kütüphanesinin sahip olduğu ayarların çoğunu içerir. Avidemux'a henüz eklenmemiş x264 ayarları için bu sayfanın "Mevcut olmayan ayarlar" bölümüne bakın.

General

Rate Control

• Encoding Mode:
  • Single Pass - Constant Quantizer: "QP Mode" olarak da bilinen bu mod videonuzu sabit bir quantizer'e kodlayacaktır. Bu durumda hedef bit oranını değil, hedef quantizer'i seçeceksiniz. Quantizer kaybedilen verinin miktarını göstermektedir. Yüksek quantizer daha fazla kaybedilen veri, daha fazla sıkıştırma, daha küçük dosya boyutu ve daha kötü görüntü kalitesi demektir. Düşük quantizer ise daha az kaybedilen veri, daha iyi görüntü kalitesi, daha az sıkıştırma ve daha büyük dosya boyutu demektir. H.264 için 0'dan 52'ye kadar bir quantizer değeri belirlenebilir. Varsayılan quantizer değeri 26'dır. Eğer belirli bir görüntü kalitesi hedefliyorsanız, sonuçta oluşacak dosyanın boyutu sizi ilgilendirmiyorsa QP modu sizin için uygun demektir. Ancak belirli bir dosya boyutu veya belirli bir ortalama bit oranı istiyorsanız QP modundan uzak durun. Çünkü bu modda sonuçta oluşan dosyanın boyutu ve ortalama bir oranı tahmin edilemez.
    • NOT: CRF modu QP modundan daha fazla avantaja sahiptir. CRF modunda varsayılan olarak aktif olan Adaptive Quantization (AQ) (Uyarlanabilen Kuantizasyon) QP modunda pasif durumdadır.
  • Single Pass - Constant Rate Factor: "CRF Mode" veya "Constant Quality" (sabit kalite) modu olarak da bilinen bu mod az önce gördüğümüz QP moduna benzer şekilde çalışır, bu moddaki tek fark videoların sabit bir quantizer yerine ortalama bir quantizer'le kodlanmasıdır. Yani daha açık konuşmak gerekirse bu modda videolar belirtilen quantizer'i baz alan sabit oran faktörüyle (rate factor) kodlanır. Avidemux'taki CRF modu x264'ün ABR moduyla aynı oran kontrol algoritmasına sahiptir, aradaki tek fark CRF'de hedef bit oranı olmamasıdır. CRF modunun avantajı, QP moduna oranla insan algısına çok daha iyi hitap etmesidir. Örneğin CRF, kayıp verinin çok fazla dikkat çekmediği hızlı sahnelerde quantizer'leri artırıp, yavaş sahnelerde azaltır. Bu sayede CRF modu, QP moduyla aynı subjektif (insanın gözüyle belirlediği) görüntü kalitesi vermesine rağmen önemli oranda daha fazla sıkıştırma sağlar. CRF biraz daha yavaş olsa da QP modu yerine CRF modunu kullanmanız tavsiye edilir. Kodlama modunu QP'den CRF'ye değiştirirken quantizer'i biraz azaltmak isteyebilirsiniz. Bu sayede öncekiyle yaklaşık olarak aynı dosya boyutunu, ama daha iyi görüntü kalitesi elde edeceksiniz. CRF'nin diğer önemli bir avantajı ise uyarlanabilir kuantizasyondan (adaptive quantization) yararlanmasıdır -ki QP'de böyle bir imkan yoktur.
    • NOT: CRF modu halen "mükemmel" bir sabit kalite vermez. Sabit bir CRF değeri, diğer ayarları değiştirmediğiniz müddetçe çeşitli kaynaklara benzer kalite dağıtır. Aynı CRF değeriyle birlikte "daha yavaş" ayarları kullanmanız aynı kalitede daha küçük dosya boyutu veya aynı dosya boyutunda daha yüksek kalite elde etmenizi sağlar. Ayrıca hem dosya boyutunun ve hem de kalitenin artırılması da mümkündür. Boyut başına düşen kalite bir şekilde artırılabilir.
  • Açıklamalar: CRF veya QP kodlaması için düzgün bir quantizer ayarı seçmek önemsiz değildir. Çünkü görsel kalite son derece subjektifitir. Bir videonun görsel kalitesini birisi beğenirken bir başkası beğenmeyebilir. Ayrıca quantizer ayarları videonuzun içeriğine de bağlıdır. Ancak yine de 16 ile 32 arasında bir değer çoğunlukla tatminkar sonuçlar verecektir. 16'dan daha düşük bir quantizer değeri ayarlamak -öğrenme amaçlı yapmıyorsanız- çoğunlukla israftır. 32'den daha yüksek bir quantizer değeri ise neredeyse izlenemeyecek derecede düşük kaliteli bir video üretecektir. Quantizer değerini 22'ye ayarlamak çoğu durumda makul sonuçlar üretir. Ancak yine de çizgi filmler gibi içeriğinde çok fazla doku olmayan videolarda quantizer değeri artırılabilir. Ancak içeriğinde çok fazla doku olan gerçek hayat videolarında daha düşük quantizer (özellikle karanlık sahnelerde) daha uygun olacaktır. Ayrıca bir pratik kural vardır: CRF değerini 6 birim düşürmek dosya boyutunu ikiye katlayacak, 1 birim düşürmek dosya boyutunu yaklaşık % 12.5 oranında artıracaktır. Bununla ilgili yaygın pratik şöyledir: 16 gibi düşük bir CRF değeriyle başlayın. Sonra bu değeri 1'er 1'er artırın. Her artırışınızda videonun kalitesine bakın. Videonun kalitesi kabul edilemez olduğu anda deneyi bırakın ve en son kabul edilebilir değeri seçin. Bu sayede kalitesi sizi tatmin eden en yüksek CRF değerini elde edeceksiniz. İlgili değeri bulduktan sonra gelecekte yapacağınız diğer bütün kodlamalar için de aynı değeri kullanabilirsiniz.
  • Single Pass - Bitrate: Bu modda videonuz tek geçişte ve ortalama bir bit oranıyla kodlanır. Yani bu mod, "Two Pass" kodlamasının gerektirdiğinin yarı zamanını gerektirir. CRF ve QP modunun aksine sonuçta oluşan dosyanın ortalama bit oranı önceden bellidir. Böylece sonuçta oluşacak dosyanın boyutu basit bir matematiksel hesaplamayla anlaşılabilir. Yüksek bit oranı daha iyi görüntü kalitesi ve daha büyük dosya boyutu, düşük bit oranı daha küçük dosya boyutu ve daha kötü görüntü kalitesi anlamına gelir. Bu modda tek geçiş yapıldığı için kodlayıcı videonun içeriğini önceden bilmemektedir. Bundan dolayı kodlayıcının içeriğe göre bit oranını ayarlama yeteneği son derece sınırlıdır. Yalnızca yerel iyileştirmeler yapılır. Bu modda bir "Two Pass" kodlamasına oranla daha kötü video kalitesi elde edilir (özellikle orta ve düşük bit oranlarında). Bu yüzden bu modu -tek geçiş yapmak zorunda değilseniz- kullanmamanız tavsiye edilir.
  • Two Pass - Average Bitrate: Bu modda videonuz iki geçişte ve ortalama bir bit oranıyla kodlanır. Bu nedenle bu mod bir "Single Pass" modun gerektirdiğinden yaklaşık olarak bir kat daha fazla zaman gerektirir. CRF ve QP modunun aksine sonuçta oluşacak olan dosyanın ortalama bit oranı (ve dolayısıyla dosya boyutu) önceden bellidir. Yüksek bit oranı daha yüksek kalite ve daha büyük dosya boyutu, düşük bit oranı daha düşük kalite ve daha küçük dosya boyutu demektir. İlk geçişte kodlayıcı videonun detaylı bir analizini yapar ve "stats" isminde bir dosya üretir. Sonra ikinci geçişte asıl kodlama yapılır ve sonuçta oluşacak dosya üretilir. İki geçişin avantajı kodlayıcının ikinci geçişte, ilk geçişte elde ettiği verilere güvenebilmesidir. Bu sayede kodlayıcı videonun her bir kısmına yalnızca gerekli bit oranlarını dağıtır (ne eksik ne fazla). Örneğin hareketli sahnelere, sabit sahnelere oranla daha fazla bit oranı verilir. Bu işlem, videonun tamamında sabit kalite elde etmek için yapılır. "Single Pass" kodlamalarında hızlı/spontane sahnelerde gözüken çirkin bloklar bu modda olmaz. Bu sayede "Two Pass" kodlamaları verilen ortalama bit oranında (veya dosya boyutunda) maksimum görüntü kalitesi sağlar. Eğer belirli bir ortalama bit oranı istiyorsanız bu modu kullanmanız tavsiye edilir.
  • Two Pass - File Size: Bu mod aslında "Two Pass - Average Bitrate" modunu kullanır. Bu moddaki tek ve en önemli fark Avidemux'un otomatik olarak gereken bit oranını sizin yerinize hesaplamasıdır. Bu sayede belirli bir dosya boyutu kolayca elde edilebilir. Sadece istediğiniz dosya boyutunu girin (örneğin CD-R'lar için "700 MB" veya DVD-R'lar için "4700 MB") ve bu kadar! Diğer bütün şeyler "Two Pass - Average Bitrate" modunda açıklandığı gibi yapılır.
    • NOT: x264 sesin bit oranını ve kapsayıcının getirebileceği ek yükü hesaba katmamaktadır. Bu yüzden x264 için hedef dosya boyutu belirtirken dosyanın sadece video bileşeninin dosya boyutunu belirttiğinizi unutmayın. Eğer videonuz en az bir ses parçası içeriyorsa gerçek dosya boyutu belirttiğinizden daha yüksek olacak demektir. Ayrıca kapsayıcı dosyaya bazı ek yükler ekler. Bu yüzden lütfen hedef dosya boyutunu düzgünce hesaplamak için Avidemux'un "Calculator" aracını kullanın.
  • Açıklamalar: Bit oranı tabanlı bir kodlama ("Two Pass" veya "Single Pass") için düzgün bir hedef bit oranı seçmek kesinlikle önemsiz değildir. Çünkü tatminkar sonuçlar elde etmek için gerekli bit oranı büyük oranda videonuzun sıkıştırılabilirliğine ve kişisel tercihlerinize bağlıdır. Örneğin basit videolar ciddi oranda daha küçük bir bit oranı gerektirirken, karmaşık videolar daha fazla bit oranı gerektirir. Ayrıca çizgi filmler, genellikle gerçek hayat videolarına oranla çok daha az bit oranı gerektirir. Ancak son tahlilde, çoğu durumda 500 kbps ile 2500 kbps arasında bir ortalama bit oranı DVD-Video gibi HD olmayan medya ortamları için makul sonuçlar verecektir. 2500 kbps'in üstündeki ortalama bit oranları HD olmayan medya ortamları için çoğunlukla israf olarak görülür. Ancak elbetteki istisnalar vardır! Ayrıca şunu unutmayın ki HD videolarla (720p veya 1080p) çalışıyorken ciddi oranda daha yüksek bit oranları gerekecektir. 10 mbps ve üstü bit oranları HD kodlamarı için nadir değildir. Ayrıca denoise işlemi gibi önişlemeler videonun bit oranı ihtiyacını azaltabilir.
    • NOT: Belirli bir bit oranına karar vermek oldukça zor olduğu için genellikle bit oranı tabanlı modlar yerine CRF modunu kullanmanız tavsiye edilir.
  • Kayıpsız Mod: x264 ayrıca "gerçek" kayıpsız sıkıştırmayı destekler. Bu modu kullanmanız durumunda videonuzun verisinde kesinlikle bir azalma olmayacaktır. Ancak kayıpsız sıkıştırma, kayıplı sıkıştırmalara kıyasla ciddi oranda daha fazla bit oranı gerektirecektir. Bu yüzden kayıplı bir formattan (örneğin MPEG-2 veya MPEG-4 ASP'den) kayıpsız bir formata dönüşüm yaparsanız dosya boyutu çok daha büyük olan bir video elde edersiniz. Ayrıca x264, HuffYUV veya FFV1 gibi diğer kayıpsız kodlayıcılara kıyasla kayıpsız modda videoyu çoğunlukla daha az bit oranıyla kodlayacaktır. Ve elbetteki x264'ün kayıpsız sıkıştırması, sıkıştırılmamış videodan (örneğin ham YUV/RGB verisi) çok daha az bit oranı gerektirecektir. Kayıpsız sıkıştırmayı zorlamak için Constant Quantizer modunu seçip quantizer değerini 0'a ayarlamalısınız. Kayıpsız H.264 videosunun çalınması için "Predictive Lossless" profilini destekleyen bir çözücü kullanmalısınız. libavcodec/ffmpeg (ffdshow, MPlayer, vb.) ve CoreAVC Decoder bu profili destekler. Diğer çözücüler bozuk bir çıktı gösterebilirler veya hiçbir şey göstermeyebilirler.

Macroblock-Tree Rate Control

• Macroblock-Tree Rate Control ayarını (diğer adıyla "MB-Tree") etkinleştirir. MB-Tree, gelecek bloklardan geçmiş bloklara hareket vektörleri boyunca bilginin ilerleyişini izler. Bütün sahne yerine tek tek blokları etkilemek için qcomp'u (quantizer curve compression) yerelleştirmek olarak tanımlanabilir. Bu sayede karmaşık sahnelerde kaliteyi düşürmek yerine (MB-Tree olmadan x264'ün yaptığı gibi), kalite yalnızca sahnenin karmaşık kısımlarında düşürülecektir, örneğin sabit arkaplan kaliteli kalacaktır. Ayrıca bu ayarın daha birçok ince etkisi vardır, bazıları potansiyel olarak olumsuz, birçoğu da muhtemelen olumludur. Bu ayar, bütün bit oranlarında yardım eder, ve hatta videonun aksi durumda tamamen başa çıkılamaz olacağı çok düşük bit oranlarında da yardım edebilir. Artık MB-Tree yavaş yavaş sönen sahneleri çok daha iyi işliyor, Weight-P'ye teşekkürler. Genel kaliteyi büyük oranda artırdığı için MB-Tree'nin daima etkin olması tavsiye edilir. MB-Tree'nin nasıl çalıştığı üzerine daha fazla bilgi için x264 "Macroblock Tree Ratecontrol" testing konusuna bakın.
• Frametype Lookahead: Bu ayar frame-type lookahead için frame sayısını belirtir, MB-Treenin ne kadar ileriye bakacağı bu ayarla ayarlanır. MB-Tree'nin daha ilerideki frame'lere bakması demek, MB-Tree'nin daha verimli çalışması demektir. Veya diğer bir deyişle daha büyük bir değer sonucun daha iyi olmasını sağlayacak, daha küçük bir değer sonucun daha kötü olmasına neden olacaktır. Bu yüzden mümkün olan en büyük değeri kullanmanız tavsiye edilir. Ancak maalesef büyük bir lookahead kodlama hızını düşürürken bellek tüketimini artıracaktır. Varsayılan değer birçok durum için en dengeli olan 40'tır. Eğer sizin için kalite kodlama hızından önemliyse değeri artırmanız tavsiye edilir. Ancak 60'tan büyük bir değer vermeniz tavsiye edilmez, çünkü çok yüksek değerler görüntü kalitesinde çok çok küçük bir iyileşme verir (hatta hiç vermeyebilir). Eğer hız sizin için kaliteden daha önemliyse daha düşük bir değer seçebilirsiniz. Ancak 30'dan daha düşük bir değer tavsiye edilmez.
• Uyarı: Eğer yüksek Frametype Lookahead değerlerinde çökmelerle karşılaşırsanız, muhtemelen belleğinizin sınırlarını aşmışsınız demektir. Bu tür durumlarda çökmelerden kaçınmak için değeri düşürmelisiniz.

Multi-Threading

• Bu ayar, x264'ün kodlama için kaç tane thread kullanacağını belirtmenizi sağlar. x264, multi-threading uygulaması sayesinde modern çok çekirdekli işlemcilerin işleme gücünden çok iyi faydalanmaktadır. Bu, çeşitli frame'lerin paralel olarak kodlanmasıyla başarılmıştır (ayrıntılar için buraya bakın). Testler göstermiştir ki x264 en az 16 çekirdeğe kadar çok iyi ölçekleme yapabilmektedir. Son tahlilde, çok çekirdekli makinelerin en uygun kullanımını yapmak için thread sayısı doğru seçilmelidir. Ayrıca aşağıdaki seçenekler de mevcuttur:
• Disabled: Multi-threading pasifleştirilir. Yalnızca tek bir thread kullanılır. Bunun sonucunda tek çekirdekli makinelerde hızda bir artış veya azalma olmazken çok çekirdekli makinelerde hız önemli oranda düşer.
• Auto-Detect: Uygun thread sayısına x264 karar verir. Kullanılan formül thread sayısı = çekirdek sayısı * 3/2 dir. Testler, bu formülün (çoğunlukla) en uygun performansı verdiğini göstermiştir. Bu ayarı etkinleştirmeniz kesinlikle tavsiye edilir.
• Custom: x264'ün otomatik thread sayısı tespitini pasifleştirip elle yeni değer girmek için kullanılır. Bu ayarı, yalnızca x264'ün otomatik tespitine güvenmemeniz için çok iyi bir sebebiniz varsa etkinleştirin.
• Notlar: Birçok insan, x264'le kodlama yaparken görev yöneticisinde işlemci kullanımının hiçbir zaman (multi-threading etkinken bile) %100'e ulaşmadığından şikayetçidir. Bunun çeşitli sebepleri olabilir. En muhtemel olanı işleme zincirindeki bazı şeylerin x264'ün yavaşlamasına neden olmalarıdır. Örneğin multi-threading desteği olmayan bir çözücü ve/veya yoğun hesaplama yapan video filtreleri performansta darboğaz oluşturabilirler. Böyle bir durumda x264 girdi için süre boş halde bekleyecektir. Yani aslında bu, x264'ün kendi problemi değildir. Başka bir "problem" ise Pentium 4 ve Core i7 (Nehalem) işlemcileri tarafından kullanılan Intel'in Hyperthreading teknolojisidir. Hyperthreading teknolojisinde her bir fiziksel çekirdekte ikişer tane sanal çekirdek vardır. Bu yüzden işlemci kullanımının %50 olması, fiziksel işlemcinin tamamının kullanıldığına işaret eder (ki bu da Hyperthreading desteği olmayan bir işlemci için %100'e tekabül eder). Son fakat aynı derecede önemli olarak, multi-threading'in verimliliği sadece görev yöneticisinde işlemcinin kullanım yüzdesine bakarak öğrenilemez. Bunun yerine iş/zaman oranı (yani saniye başına kodlanan frame sayısı) ölçülmelidir. Yani yüksek işlemci kullanımı performansın iyi olduğunu tek başına göstermeyebilir.

Motion

Motion Estimation

• ME Method: Video sıkıştırma ardışık frame'ler arasındaki gereksiz bilgileri silerek yapılır. Örneğin P-frame'ler önceki frame'(ler)den tahmin edilecektir. Sonra bit akımında, yalnızca orijinal kaynakla tahmin edilen frame arasındaki farklar saklanacaktır. Bu farklara "kalıntı" denir. Bir frame ne kadar doğru tahmin edilebilirse o kadar az verinin depolanması gerekecek demektir. Çünkü nesneler komşu frame'ler arasında hareket etme eğilimdedir, hareketi algılama ve yerini doldurma doğru bir tahmin için olmazsa olmazdır. ME Method ayarıyla hareketi arama ve "hareket vektörleri"ni hesaplama için hangi algoritmanın kullanılacağı belirtilir. Daha iyi bir arama yöntemi daha iyi bir görüntü kalitesi verecek ancak kodlama için daha fazla vakit gerekecektir. Daha hızlı bir yöntem, kodlama işlemini hızlandıracak ancak daha kötü bir görüntü kalitesi verecektir. Hareket tahmin yönteminin kodlama hızı ve videonuzun görsel kalitesi üzerinde çok büyük etkisi olduğu için çok bu ayarı kullanırken çok dikkatli karar vermelisiniz. Varsayılan ayardan daha düşük bir ayar seçmemeniz şiddetle tavsiye edilir. Hatta sizin için kalite hızdan önemliyse daha yavaş bir modu seçebilirsiniz. Bu ayarda aşağıdaki yöntemler mevcuttur:
• Diamond Search (DIA): Dört taraflı şekil analizi - En hızlı ancak en düşük kaliteli metod budur. Bu metodu yalnızca sizin için kodlama hızı kaliteden önemliyse seçin.
  • Karmaşıklık: en kötü durumda O(n), ortalama durumda daha hızlı.
• Hexagonal Search (HEX): Altı taraflı şekil analizi - Varsayılan metot budur. Makul bir kalite ve hayli hızlı bir kodlama sağlar.
  • Karmaşıklık: en kötü durumda O(n), ortalama durumda daha hızlı.
• Uneven Multi-Hexagon Search (UMH): Hexagonal search'ün daha detaylı versiyonu - Bu metot yüksek kalite verir ancak sıradan "HEX" metoduna göre daha yavaştır. Eğer kaliteyi hıza tercih ediyorsanız bu metodu kullanın.
  • Karmaşıklık: O(n).
• Exhaustive Search (ESA): Tam ve kapsamlı analiz - Bu metot çok yavaş çalışır, ancak sonuçta oluşan videonun kalitesi "UMH" metodununkiyle kıyaslandığında arada çok çok az fark olduğu görülür (hatta bazen hiç fark olmaz).
  • Karmaşıklık: O(n²).
• Hadamard Exhaustive Search (TESA): "ESA" metodunun Hadamard dönüşümü kullanan geliştirilmiş versiyonu - Bu metot "ESA" metodundan bile yavaş çalışır. Bu metodu çok fazla müsait vaktiniz varsa kullanın.
  • Karmaşıklık: O(n²).
• Notlar: Testler "Exhaustive Search"ün "Uneven Multi-Hexagon Search"ten ciddi oranda daha yavaş olduğunu ama videoya kazandırdığı kalitenin hissedilemeyecek oranda düşük olduğunu göstermiştir. Ayrıca "Hadamard Exhaustive Search", "Uneven Multi-Hexagon Search"ün en az iki katı oranında vakit almaktadır. Bu yüzden "Uneven Multi-Hexagon Search"ten daha yavaş bir metot seçmek çoğunlukla harcanan kodlama zamanına değmeyecektir.
• Subpixel Refinement: Bu ayarla ("Sub ME" olarak da bilinir) hareket tahmin işleminin hassasiyeti belirtilir. Daha yüksek bir hassasiyet daha iyi sonuç demektir. Bu yüzden daima mümkün olan en yüksek değeri kullanmanız tavsiye edilir. Elbetteki daha yüksek hassasiyet kodlamanın daha uzun sürmesi demektir. Şunu unutmayın ki bu ayardan bağımsız olarak QPel hareket tahmini her zaman kullanılır. RDO, Xvid kodlayıcısındaki VHQ'ya eşdeğerdir. Varsayılan 6 değerinden daha düşük bir değer seçmemeniz şiddetle tavsiye edilir, çünkü Psy-RDO, Sube MEnin en az 6 olmasını gerektirmektedir. Eğer vaktiniz varsa daha yüksek değerleri kullanmayı da düşünebilirsiniz. Görsel kalitenin kodlama hızından daha önemli olduğu durumlarda en yüksek değerlere çıkabilirsiniz. 9 (ve hatta 10) en iyi kaliteyi verir. Eğer hızı kaliteye tercih ediyorsanız, 2'yi seçin. Hiçbir zaman 2'nin altına inmemeniz tavsiye edilir (hatta hızlı ve önemsiz kodlamalarda bile). Aşağıdaki Sub-ME modları mevcuttur:

1. QPel SAD (Fastest, worst quality)
2. QPel SATD
3. HPel on MB, then QPel
4. Always QPel
5. QPel & bidirectional ME
6. RD on I- and P-Frames (Default, lowest mode that supports Psy-RDO)
7. RD on all frames
8. RD refinement on I- and P-Frames
9. RD refinement on all frames
10. RD refinement on all frames + QPRD (Slowest, best quality)

Motion Vector

• Range: Bu ayarla hareket tahmini için kaç tane pikselin analiz edileceği belirtilir. Yüksek range değerleri daha doğru bir analiz sağlar ancak kodlama hızını önemli ölçüde düşürür. Düşük değerler kodlama işlemini hızlandırır ancak analizin doğruluğunu düşürür. Genellikle, yüksek çözünürlüklü materyaller düşük çözünürlüklü materyallere kıyasla yüksek range değerlerinden daha fazla fayda sağlar. Çünkü HD videoda nesneler piksel cinsinden daha uzağa hareket etme eğilimindedir. Ancak son tahlilde, varsayılan değer olan 16 videoların çoğunluğu için yeterlidir. Hatta "Diamond Search" ve "Hexagonal Search" metotları maksimum range değerini 16'da sınırlarlar. Eğer sizin için kalite kodlama hızından önemliyse ve "Uneven Multi-Hexagon Search" metodunu veya daha yavaş bir metodu kullanıyorsanız range değerini 24'e ve hatta 32'ye çıkarabilirsiniz. Seçilen hareket tahmin metoduna göre range değeri ikinin veya dördün katına yuvarlanabilir.
• Maximum Motion Vector Length: Bu ayar her bir hareket vektörünün maksimum uzunluğunu sınırlamak için kullanılabilir. Varsayılan durumda x264 algılanan seviyeye göre maksimum hareket vektörü uzunluğunu sınırlayacaktır. Bu ayarı, x264'ün tercihini iptal etmek için kullanabilirsiniz. Kullanmanız için çok iyi bir nedeniniz olmadığı müddetçe bu ayarı kullanmamanız şiddetle tavsiye edilir.
• Minimum Buffer Between Threads: x264, frame tabanlı bir multi-threading metodu kullanır. Birden fazla frame'in paralel olarak kodlanmasını sağlamak için, verilen herhangi bir macroblock'un daha önce kodlanmış referans frameler'i parçaları arasından yalnızca hareket vektörlerini kullandığından x264'ün emin olması gerekir. Bu çoğunlukla fark edilemez, ancak zaten de çok hızlı yukarı doğru hareketler de önem teşkil eder. Varsayılan olarak x264 thread'ler arasındaki minimum boşluğu thread'lerin sayısına göre ayarlayacaktır. Bu ayarı x264'ün tercihini iptal etmek için kullanabilirsiniz. Kullanmanız için çok iyi bir nedeniniz olmadığı müddetçe bu ayarı kullanmamanız şiddetle tavsiye edilir.

Prediction

• B-Frame Direct Mode: Bu özellik B-frame'lere, her bir frame'in hareketini tam olarak kodlamak yerine "tahmin edilen" hareket vektörleri kullanma izni verir. Bu sayede bazı bit oranları korunurken sıkıştırma iyileştirilir. Bu yüzden bu seçeneği daima etkin yapmanız tavsiye edilir. Dört farklı kullanılabilir mod vardır:
• None: Pasif. Yalnızca deneme için. Tavsiye edilmez.
• Auto: Her bir frame için en uygun ayarın kodlayıcı tarafından yapılmasını sağlar. Bütün oran kontrol modları için şiddetle tavsiye edilir, ancak Two Pass modunda daha verimlidir.
• Temporal: Komşu frame'lerden tahmini zorla.
• Spatial: Geçerli frame içindeki komşu bloklardan tahmini zorla (çoğunlukla Temporal'dan daha iyidir).
• Weighted Prediction for B-Frames: Bu özellik, simetrik olmayan bir yolla referans frame'lerinin ağırlaştırılmasıyla kodlayıcının daha doğru B-frame'ler üretmesine izin verir. Bu özellik kodlama hızını biraz düşürecektir. Sizin için kodlama hızı kaliteden önemli değilse, ağırlaştırılmış B-frame'lerin genel anlamda görsel kaliteyi artırmasından ötürü bu özelliği daima etkin yapmanız tavsiye edilir.
• Weighted Prediction for P-Frames: Bu özellik, kodlayıcının yavaş yavaş sönmeleri tespit ederek buna göre P-Frame'leri ağırlaştırmasına izin verir. Bu sayede yavaş yavaş sönmelerdeki kalite çok büyük oranda artırılır, bu yüzden de bu seçeneği daima etkin yapmanız tavsiye edilir.
• Blind Offset: Herhangi bir analiz yapılmadan "kör" bir offset kullanılır. Yavaş yavaş sönmelerde çok az bir kalite artışı sağlar.
• Smart Mode: Yavaş yavaş sönmelerin tespiti etkinleştirilir. Yavaş yavaş sönmelerde tam bir kalite artışı sağlar. Özellikle MB-Tree ile kullanımı son derece faydalıdır. Tavsiye edilen mod budur.
• Disabled: Ağırlaştırılmış P-frame'leri hiç kullanma. Tavsiye edilmez.
• Uyarı: Bazı H.264 çözücülerinin ağırlaştırılmış P-frame'leri çözerken sorun yaşadığı bilinmektedir. Sorun yaşayan çözücülerin bir listesi için buraya bakın. Sorun yaşayan çözücülerin herhangi birisini kullandığınızda ağırlaştırılmış P-frame'ler etkinse bozuk bir çıktıyla karşılaşacaksınız. En kayda değer olarak CoreAVC Decoder 1.9.x bilinen ve düzeltilmeyen bir ağırlaştırılmış P-frame bug'ına sahiptir. CoreAVC 2.0'ye güncelleme yaparak veya farklı bir çözücü kullanarak (ffdshow veya DivX H.264 decoder gibi) veya ağırlaştırılmış P-Frame'i pasifleştirerek sorunu çözebilirsiniz. Elbette ki son çözüm en kötüsüdür.

Partition

Partition Search

• 8x8 Adaptive DCT Transform: Bu ayar uyarlanabilen 8x8 DCT dönüşümünü etkinleştirir. Bu sayede, hızda çok az bir düşüş yaşanırken görsel kalitede çok büyük oranda artış olacaktır. Aslında bakarsanız bu seçenek bütün seçenekler arasında en iyi hız/kalite oranını vermektedir. Ancak maalesef bu seçenekle kodlanmış bir videoyu yalnızca "High Profile" desteği olan çözücüler çözebilir. Bu seçeneği mümkünse etkinleştirmeniz şiddetle tavsiye edilir.
• 8x8, 8x16 and 16x8 P-Frame Search: Bu ayar P-Frame'lerde 8x8 bölümlerini etkinleştirir. Bu yüzden de bu frame'lerin görsel kalitesi artar. Bu seçeneği etkinleştirmeniz tavsiye edilir.
• 8x8, 8x16 and 16x8 B-Frame Search: Bu ayar B-Frame'lerde 8x8 bölümlerini etkinleştirir. Bu yüzden de bu frame'lerin görsel kalitesi artar. Bu seçeneği etkinleştirmeniz tavsiye edilir.
• 4x4, 4x8 and 8x4 P-Frame Search: Bu ayar P-frame'lerdeki 4x4 bölümlerini etkinleştirir, ancak çoğunlukla kalite artışı düşük seviyelerdedir. Bu yüzden bu seçenek gerektirdiği kodlama vaktine değmez, bu yüzden de güvenle pasifleştirilebilir.
• 8x8 I-Frame Search: Bu ayar I-Frame'lerdeki 8x8 bölümlerini etkinleştirir ve bu yüzden bu frame'lerin kalitesini artırır, ancak bu ayar 8x8 Adaptive DCT Transform ayarının etkin olmasını gerektirir. Mümkünse bu seçeneği etkinleştirmeniz önerilir.
• 4x4 I-Frame Search: Bu ayar I-Frame'lerdeki 4x4 bölümlerini etkinleştirir ve bu yüzden bu frame'lerin görsel kalitesini artırır. Bu seçeneği etkinleştirmeniz tavsiye edilir.
• Notlar: Kodlama işlemi esnasında kodlayıcı videoyu "makrobloklar"a bölecektir. Sonra gereksiz veriyi silmek için benzer bloklar arayacaktır (bkz: Motion Estimation). Makrobloklar 16x8, 8x16, 8x8, 4x8, 8x4 ve 4x4'lük bölümlere tekrar bölünebilirler. Bu bölümlerin daha fazlasını analiz etmek daha doğru bir tahmin verecek ve bu sayede de görsel kaliteyi artıracaktır. Ancak maalesef bunun sonucunda kodlama için gereken zaman artacaktır. Genel olarak "4x4 P-Frame" bölümleri hariç bütün bölüm tiplerini etkinleştirmeniz tavsiye edilir. Çünkü P-Frame'lerde 4x4/4x8/8x4 bölüm araması kodlama hızının önemli ölçüde düşmesine neden olurken kalite artışı genellikle çok küçük olur (belki düşük çözünürlüklü videolarda işe yarayabilir). Ayrıca şunu unutmayın ki bazı bölüm seçenekleri birbirlerine bağlıdır. Ayrıca 8x8 Adaptive DCT Transform (ve sonuç olarak 8x8 I-Frame Search "High profile" özelliklerdir ve bu ayarlarla kodlanmış videoları sadece MPlayer, ffdshow ve CoreAVC gibi uygun H.264 çözücüleri çözebilir. Ama yine de 8x8 Adaptive DCT Transform ve 8x8 I-Frame Search çok faydalı özelliklerdir.

Frame

Frame Encoding

• CABAC: Bu ayar x264'ün en etkileyici özelliklerinden biri olan CABAC entropi kodlamasını etkinleştirir. CABAC (Context Adaptive Binary Arithmetic Coding - İçeriği Uyarlanabilir İkili Aritmetik Kodlama) tam anlamıyla kayıpsız çalışırken yaklaşık %15 ekstra sıkıştırma sağlar. Daha yüksek quantizer değerlerinde CABAC daha yüksek bit oranlarını bile saklayabilir - %50'ye kadar ve daha fazlası mümkün (bkz [1]). Sonuç olarak CABAC'ı etkinleştirdiğinizde aynı kalitede daha az boyutlu bir dosya (CRF ve QP modu) veya aynı dosya boyutunda daha iyi kalite (2-Pass modu) elde edeceksiniz. Sonuç olarak bütün durumlarda CABAC'ı etkinleştirmeniz şiddetle tavsiye edilir. Ancak CABAC gerek kodlama ve gerekse çözme olarak ek işlemci gücü gerektirir. CABAC için gerekli olan ek işlemci gücü büyük oranda bit oranına bağlıdır. Şunu unutmayın ki CABAC kolaylıkla H.264 çözümünün en çok işlem yapılan kısmı olabilir. Eğer CABAC'ı pasifleştirmeye karar verirseniz (ki böyle bir şeyi yapmamanız tavsiye edilir), daha az etkili ama daha hızlı olan CAVLC'yi (Context Adaptive Variable Length Coding - İçeriği Uyarlanabilir Değişken Uzunluklu Kodlama) kullanın.
  • Notlar: CABAC en az "Main" profile destekli bir H.264 çözücüsü gerektirir. Eğer "Baseline" veya "Extended" Profile'ı hedefliyorsanız CAVLC'yi kullanın.
• Pure Interlaced Mode: Bu ayar interlace edilmiş kodlamayı etkinleştirir, yani yalnızca videonuz interlace edilmiş ise bu ayarı etkinleştirin. Videonuz progressive (yani interlace edilmemiş) ise veya interlace'nin ne anlama geldiğini bilmiyorsanız bu ayardan uzak durun. Şunu unutmayın ki interlace edilmiş bir videoyu progressive olarak kodlamak içeriğe zarar verecektir. Progressive bir videoyu interlace olarak kodlamanın ise videonun görünüşüne etkisi yoktur, ancak kodlama verimini önemli oranda düşürür. Son ama aynı derecede önemli olarak şunu unutmayın ki x264'ün interlace kodlama uygulaması olabileceği kadar etkili değildir. Dolayısıyla interlace edilmiş bir kaynakla çalışıyorsanız deinterlace filtresi uygulayıp videoyu progressive olarak kodlamanız çok daha iyidir.
  • Notlar: Günümüzde dünyada CRT ekranlar popülerliğini yitirip LCD/Plasma ekranlar yaygınlaşmaya başlıyor, interlace edilemiş içeriğin bir şekilde çalma esnasında deinterlace edilmesi gerekiyor. Maalesef bazı ekranlar bir hayli zayıf deinterlace yöntemleri uyguluyor, bunun sonucunda titrek ve keskin olmayan bir görüntü oluşuyor. Bu yüzden tavsiye edilen yöntem videoyu kodlamadan önce Yadif veya TDeint gibi kaliteli bir deinterlacer/bobber ile deinterlace etmektir.
• Loop Filter: Bu ayar x264'ün en önemli özelliklerinden birisi olan Inloop Deblocking filtresini kontrol eder. MPEG-4 ASP'nin (DivX, Xvid, vb.) aksine Inloop Deblocking özelliği H.264 standardında zorunlu tutulmuştur. Böylelikle kodlayıcı (bu durumda x264), blok çözme konusunda çözücüye tam anlamıyla güvenebilmektedir. Ayrıca H.264 akımlarındaki bütün P- ve B-Frame'ler işlenmemeiş olanlar yerine blokları çözülmüş frame'leri baz alırlar, bu sayede sıkıştırılabilirlik artar. Inloop Deblocking'i tamamen pasifleştimek için kesinlikle hiçbir sebep yoktur, bu yüzden bu ayarı her durumda etkin yapmanız şiddetle tavsiye edilir. Inloop Deblocking filtresini yapılandırabileceğiniz iki ayar vardır:
  • Strength: Bu ayar "Alpha Deblocking" olarak da adlandırılır. Deblocking filtresinin videoyu ne kadar yumuşaklaştıracağı buradan ayarlanır, bu yüzden bu ayar videonuzun ortalama keskinliği üzerinde önemli bir etkiye sahiptir. Varsayılan değer 0'dır ve videonuzdaki bütün blokları yumuşaklaştırmak yeterli olacaktır (özellikle Quantizer modlarında (QP veya CRF)). Negatif değerler videoya daha fazla keskinlik verirken görülebilen blok artifact'leri riskini artırır. Tam aksi olarak da pozitif değerler daha yumuşak bir görüntü verirken bazı detayların kaybolmasına yol açar.
  • Threshold: Bu ayar "Beta Deblocking" olarak da adlandırılır, kullanması Alpha Deblocking'den daha zordur. Blok tespiti için minimum değeri kontrol eder. Varsayılan değer 0'dır ve videonuzdaki bütün blokları tespit etmesi yeterli olacaktır. Negatif değerler sonucunda daha fazla detay saklanırken daha fazla blok kayabilir (özellikle düz bölgelerde). Tam aksi olarak da pozitif değerler daha fazla detayı silerken daha fazla bloğu tutabilir.
  • Notlar: Genel olarak Strength:Threshold için varsayılan 0:0 değerlerini değiştirmeye gerek yoktur, çünkü birçok video için 0:0 değeri çok iyi sonuçlar verir. Ancak yine de kendi gözleriniz için en uygun ayarı bulmak için farklı ayarlar deneyebilirsiniz. Daha keskin bir görüntü istiyor ve orada buradaki birkaç bloğu önemsemiyorsanız -2:-1 değeri sizi tatmin edebilir. Bu ayarı MPEG-4 ASP (DivX, Xvid, vb.) kullanıcıları da deneyebilir. Eğer yumuşak ve temiz bir görüntü istiyorsanız veya bir çizgi film kodlayacaksanız 1:2 sizin için uygun olabilir. Ancak son tahlilde her iki ayar için -3 ve +2 aralığının dışına çıkmamanız tavsiye edilir.
• Max. Ref. frames: MPEG-4 ASP'nin aksine, H.264 çoklu kaynak frame'ine izin verir. P- ve B-frame'lerin kaç tane kaynak frame kullanacağı buradan ayarlanır. Büyük değerler çoğunlukla daha etkili bir sıkıştırma yani aynı dosya boyutunda daha iyi görsel kalite sağlar. Ancak maalesef daha fazla kaynak frame kullanımı daha fazla kodlama zamanı ve çalma esnasında birazcık daha işlemci gücü gerektirir. Varsayılan durumda kaynak frame sayısı 1'dir. Kaynak frame sayısını en azından 3'e çıkarmanız şiddetle tavsiye edilir. Ancak yine de gerçek hayat videoları için 4 veya 5'den daha fazla kaynak frame kullanımından kaçınılmalıdır, çünkü yüksek değerler artık videonun kalitesini artırmamaya başlar. Ancak çizgi filmler ek kaynak frame'lerden çok yarar görür. Bu yüzden maksimum değer olan 16 kaynak frame'i bile çizgi filmler için yararlı olabilmektedir.
  • Notlar: Yazılımsal medya oynatıcılarının kullanılabilecek kaynak frame'i sayısında çoğunlukla bir sınırlaması olmamasına karşın donanımsal medya oynatıcıların kullanabileceği bir maksimum kaynak frame'i vardır. Maksimum kullanılabilecek kaynak frame'i sayısı Maksimum Çözülen Resim Tampon Boyutu (Max Decoded Picture Buffer Size - MaxDPB) ve videonun çözünürlüğü kullanılarak hesaplanabilir. MaxDPB değeri oynatıcı tarafından desteklenen H.264 profiline göre belirlenir (ayrıntılı bilgi için H.264 yapılandırmasının A ekine bakın).

B-Frames

• Max Consecutive: Bu ayarla art arda gelebilecek maksimum B-Frame sayısı belirlenir. B-Frame'ler hem bir önceki ve hem de bir sonraki I-Frame'i (veya P-Frame'i) kaynak olarak alabilirler. Bu sayede B-Frame'ler P-Frame'lerden daha etkili bir sıkıştırma sağlarlar. B-Frame'ler, aynı dosya boyutunda videonun kalitesini önemli oranda artırabilirler. Bu yüzden B-Frame kullanımı şiddetle tavsiye edilir. Ayrıca şunu unutmayın ki daha fazla B-Frame kullanımı hiçbir zaman kalite düşüşüne sebep olmayacaktır, hatta art arda gelen maksimum B-Frame sayısı olarak rahatlıkla maksimum değer olan 16'yı seçebilirsiniz. Bu ayarla art arda gelecek B-Frame sayısı için yalnızca üst sınırı belirtebildiğiniz için x264 halen gerçekte kaç tane art arda gelen B-Frame kullanılacağına kendisi karar verecektir. Yani 16 art arda gelen B-Frame seçseniz bile kodlayıcı nadiren bu değere çıkacaktır. Ancak yine de art arda gelen maksimum B-Frame sayısını 16'dan düşük bir değerde sınırlamak mantıklıdır, çünkü videoların çoğu yaklaşık 4'ten daha çok art arda B-frame'den zaten fayda görmeyecektir. B-Frame limitini 4'ten büyük bir değere ayarlamak kodlama hızını düşürürken hiçbir gerçek fayda vermeyecektir. Eğer B-Frame limitini varsayılan değer olan 0'a ayarlarsanız videoda B-Frame'ler kullanılmayacaktır. Elbetteki B-Frame'leri pasifleştirmek önerilmez.
• B-Frame Bias: Bu ayarla P-Frame yerine B-Frame kullanım olasılığı belirtilir. Önerilen değer varsayılan değer olan 0'dır. Pozitif bir değer B-Frame kullanma olasılığını artırırken negatif bir değer B-Frame kullanma olasılığını düşürür. Elbetteki kodlayıcı burada ne ayarlamış olursak olalım az önceki Max Consecutive ayarında belirttiğimiz limiti ihlal etmeyecektir.
• Adaptive B-Frame Decision: Bu ayarla kodlayıcının art arda gelecek olan B-Frame sayısına nasıl karar vereceği belirlenir. Burada neyi seçmiş olduğunuzun önemi olmaksızın kodlayıcı maksimum art arda gelecek olan B-Frame sayısını aşmayacaktır (ancak buradaki ayarla kodlayıcı daha az B-Frame kullanmaya yönelebilir). Aşağıdaki modlardan biri seçilebilir:
  • Fast: Bu modda hızlı ve vasat bir B-Frame karar algoritması kullanılır. Bu mod sonucunda videoda çoğunlukla -oldukça yüksek bir B-Frame limiti seçmiş olsanız bile- çok az sayıda B-Frame kullanılır. Bu modu yalnızca hızı kaliteye tercih ediyorsanız kullanın.
  • Optimal: Bu mod "Trellis B-Frame decision" olarak da bilinir, ancak Trellis kuantizasyon seçeneğiyle hiçbir alakası yoktur. "Fast" B-Frame karar metodundan önemli oranda daha yavaştır, ancak en uygun B-Frame sayısını bulacaktır ve bu yüzden de şiddetle tavsiye edilir. Bu metotta özellikle yavaş yavaş sönmeler çok daha başarılı işlenir. Bu metodun hızı büyük oranda B-Frame limitine bağlı olduğu için art arda gelecek olan maksimum B-Frame sayısını makul bir değere ayarlamanız önerilir.
  • Disabled: Bu ayar uyarlanabilen B-Frame kararını pasifleştirir. Bu seçeneği yalnızca deneme maksatlı seçin.
• B-Frames as reference: Bu özellik sıklıkla "B-Pyramid" olarak da bilinir. Bu ayarı etkinleştirmeniz durumunda bit oranı kullanımını ve kaliteyi iyileştirmek için B-Frame'ler doğrusal olmayan bir şekilde kaynak yapabilirler. Bu sayede B-Frame'ler başka B-Frame'lerin kaynağı olabilirler. Sonuçta oluşacak videonun görüntü kalitesini artırdığı için bu seçeneği etkinleştirmeniz çoğunlukla tavsiye edilir. ancak yine de bu özelliğin bir "High Profile" özellik olduğunu hesaba katmalısınız, bu yüzden bu seçenek etkinken kodlanmış bir videoyu yalnızca libavcodec (MPlayer, ffdshow, vb.) veya CoreAVC gibi uygun çözücüler çözebilir. Bu ayarda aşağıdaki modlar mevcuttur:
  • Strict: Katı bir şekilde hiyerarşik B-Piramit. Bu mod BluRay ile tam olarak uyumludur.
  • Non-Strict: Normal B-Pyramid modu. "Strict" moddan daha iyi sonuç verir, ancak BluRay ile uyumlu değildir (BluRay'in tuhaf spesifikasyonları yüzünden).
  • Disabled: B-Frame'ler kaynak frame olarak kullanılmaz. Tavsiye edilmez.

I-Frames

• Minimum GOP Size: Bu ayarla iki IDR frame arasındaki minimum frame sayısı belirlenir. IDR frame'ler MPEG-4 ASP'deki keyframe'lere benzer: çalma yalnızca bir IDR frame'den başlayabilir, IDR frame'den sonraki hiçbir frame IDR frame'den önceki frame'leri kaynak olarak alamaz. H.264'te bu olay -çoklu kaynaklardan dolayı- normal I-Frame'lerle mümkün değildir. Bu yüzden IDR frame'ler video içinde arama yapmak için gereklidir. Ancak yine de çok fazla IDR frame kullanımı verimsiz bir kodlamaya yol açar, bu yüzden IDR frame'ler arasında minimum bir süre vardır. Bu süreyi pratik olarak videonun frame oranına eşit yapmanız tavsiye edilir. Örneğin frame oranı 25 fps olan bir videoda 25, 29.97 fps olan bir videoda da 30 değerinin kullanılması tavsiye edilir.
• Maximum GOP Size: Minimum IDR frame süresinin aksine bu ayarla iki IDR frame arasındaki maksimum frame sayısı belirlenir. Büyük bir değer daha uzun bir IDR frame süresi ve dolayısıyla daha yavaş arama; küçük bir değer daha kısa bir IDR frame süresi ve dolayısıyla daha hızlı bir arama anlamına gelir. Pratik olarak, IDR frame süresinin videonun frame oranının 10 katından düşük olmaması tavsiye edilir. Örneğin bu değerin, frame oranı 25 fps olan bir video için en azından 250, frame oranı 29.97 fps olan bir video içinse en azından 300 olması tavsiye edilir. Daha yüksek değerler kullanmak sıkıştırmayı artıracak ancak arama hızını düşürecektir. Elbetteki uzun bir süre boyunca ekranda hareket olmayan (örneğin sanat filmleri) veya belirli bir objenin ekranda sabit kalıp sadece arkaplanın değiştiği filmler, kısa kısa ve hızlı sahne içeren filmlere kıyasla uzun GOP değerlerinden çok daha iyi faydalanır. Şunu unutmayın ki uzun GOP değerleri Blu-Ray yazmada ve akan medya için sorun teşkil etme riski olan hata düzeltmede aksamalara neden olabilir.
• Scene Cut Threshold: Bu ayarla x264'ün sahne değişimini tespit etmesi için minimum değer belirlenir. Bu sayede kodlayıcı her sahne değişimine P- veya B-Frame yerine I-Frame koyabilir, bu sayede daha iyi gözüken sahne kesmeleri elde edilir. Küçük bir minimum değer fazla belirgin olmayan sahne geçişlerinin bile tespiti sağlar, çok fazla karanlık sahne olan videolarda küçük bir minimum değer vermek mantıklıdır. Büyük bir minimum değer sahne geçişlerinin tespitinde detaycı olunmamasını sağlar. Varsayılan değer 40'tır ve videoların çoğu için uygundur.

Analysis

Analysis Configuration

• Mixed Refs: Bu ayarı etkinleştirirseniz her 16x16'lık makroblok kendi en uygun kaynak frame'ini seçebilir. Bu ayar kodlama hızını düşürür ama daha etkili bir sıkıştırma sağlar. Özellikle çok sayıda kaynak frame kullanıyorsanız bu ayar videonuza çok yarayacaktır ve gereken ek kodlama zamanına değecektir. Eğer az sayıda kaynak frame kullanıyorsanız bu ayar daha az etkili olacaktır. Sizin için kalite kodlama hızından önemliyse bu ayarı etkinleştirmeniz tavsiye edilir.
• Chroma ME (Motion Estimate): Bu ayarı etkinleştirirseniz renk bilgisi (renk parlaklığı) hareket tespitinde hesaba katılacaktır, etkinleştirmezseniz hesaba katılmayacaktır. Bu ayarı etkinleştirmeniz durumunda hareket tespiti daha yavaş ama daha doğru olacaktır. Dolayısıyla çoğunlukla videonun görsel kalitesi artarken kodlama hızı biraz düşecektir. Sonuç olarak sizin için kodlama hızı görsel kaliteden daha önemli olmadığı müddetçe bu ayarı etkinleştirmeniz tavsiye edilir.
• Trellis Quantization: Bu ayar Trellis RD kuantizasyonunu etkinleştirir. Basitçe söylemek gerekirse Trellis ek bir kuantizasyon adımı gerçekleştirir, bu sayede hem normalde silinecek olan bazı detaylar korunacak ve hem de normalde korunacak olan bazı detaylar silinecektir. Trellis çoğunlukla ortalama kaliteyi fark edilir ölçüde iyileştirecek, ancak kodlama hızını ciddi oranda düşürecektir. Psy optimizasyonlarının x264'e eklenmesinden önce Trellis değerini 2 olarak ayarlamanın iyi detayları öldürüp kenarları iyileştirme eğiliminde olduğu söyleniyor. Bu yüzden çoğunlukla Trellis'i 1 olarak ayarlamak en iyi seçim olarak düşünülüyordu. Ancak artık Psy RDO kullanılmaya başlandıktan sonra, getirdiği fark edilir yavaşlamaya rağmen Trellis'i 2 olarak ayarlamanız şiddetle tavsiye edilir. Eğer sizin için hız kaliteden önemliyse Trellis'i pasifleştirmek için 0 değerini kullanın. Şunu unutmayın ki Psy-Trellis, Trellis kuantizasyonu gerektirir; yani burada Trellis 0'a ayarlanırsa Psy-Trellis otomatikman pasifleştirilecektir. Ayrıca şunu da unutmayın ki Trellis, CABAC'ı gerektirir. Bu ayarda aşağıdaki modlar mevcuttur:
  • 2: Always On (Yavaş, en iyi kalite)
  • 1: Final Makroblock only (Daha hızlı, orta kalite)
  • 0: Disabled (En hızlı, en kötü kalite)
• Fast P-Skip: Bu ayarı etkinleştirirseniz "Fast P-Skip" kullanılacaktır. Fast P-Skip, görsel kaliteyi biraz düşürürken kodlama hızını artıran bir optimizasyondur. Ancak görsel kalitedeki düşüş belli belirsiz olurken hızdaki artış fark edilir seviyede olacaktır. Bu yüzden bu seçeneği etkinleştirmeniz tavsiye edilir. Ancak maalesef nadiren de olsa bu ayar, düz sahnelerde görüntüde hissedilir bozulmalara neden olabilmektedir, dolayısıyla eğer sizin için kalite kodlama hızından önemliyse bu ayarı pasifleştirebilirsiniz.
• DCT Decimate: Bu ayarı etkinleştirirseniz "DCT Decimation" kullanılacaktır. Bu özellik x264'ün "gereksiz" DCT bloklarını silmesine izin verir. Söz konusu DCT blokları bit akımına yazılmayacaktır, bu sayede sadece bazı bit oranları saklanırken kodlama verimi iyileşir. Elbetteki videonun kalitesinde kolayca fark edilmeyen bir düşüş olacaktır. DCT Decimation, Quantizer tabanlı modlarda (QP veya CRF) ciddi oranda daha küçük dosya boyutu elde edilmesini sağlar. Bu ayarı etkinleştirmeniz tavsiye edilir. Çok iyi bir sebebiniz yoksa bu ayarı pasifleştirmemeniz tavsiye edilir. Söylentiler sonucunda DCT Decimation'ın Trellis kuantizasyonu ile kullanılmaması gerektiği algısı oluşmuştur, ancak böyle bir şey yoktur.
• Noise Reduction: Bu ayar x264'ün dahili denoise filresini kontrol eder. Denoise işleminin H.264 spesifikasyonlarında olmadığını unutmayın. Dolayısıyla bu seçenek ek bir önişleme özelliği olarak görülmelidir. Varsayılan değer x264'te denoise filtresini tamamen pasifleştirecek olan 0 değeridir. Kodlama öncesinde videonuza bilinçli olarak ek denoise filtresini uygulamak istemiyorsanız bu değeri değiştirmenize gerek yoktur. Çoğunlukla gürültü azaltma için iyi değerler 1000'den büyük olmayanlardır. Ancak yine de çoğunlukla bu dahili filtre yerine FluxSmooth veya MPlayer denoise3d gibi bağımsız denoise filtrelerini kullanmanız daha iyidir. Eğer bu bağımsız filtrelerden birini kullanacaksanız bu ayarı pasifleştirdiğinizden emin olun.

Psycho-visually optimized RDO & Trellis

İnsan gözü, resmin orijinaline benzemesi dışında resmin orijinaliyle benzer karmaşıklığa da sahip olmasını ister. Bu yüzden biraz deforme edilmiş ama halen ayrıntılı gözüken bir bloğu deforme edilmemiş ancak tamamen bulanıklaştırılmış bir bloğa tercih ederiz. Bunun sonucunda The result is a bias towards a detailed and/or grainy output image, a bit like xvid except that its actual detail rather than ugly blocking (see [2] and [3] for more info). The purpose of **Psy RDO** is to keep the complexity of an encoded block similar to the complexity of the original block. This way //Psy RDO// produces an image that looks much sharper and more detailed in many cases (compared to //none// Psy RDO). It also helps to preserve film grain greatly! Please note that Psy RDO will inherently //hurt// metrics, such as PSNR and SSIM. As soon as psycho-visual optimizations are involved, the classical metrics become useless! Also note that Psy RDO will work with //RDO// modes only: If //Partition Decision// is set to **6** (or higher), then Psy RDO will be on by default, otherwise it will be disabled. In addition to //Psy RDO// there also is **Psy-Trellis** now. This is still considered an "experimental" feature and //disable// by default, but it seems to help greatly for retaining textures in the video. Note that Psy Trellis is based on //Trellis// quantization. Consequently it will only be effective with Trellis quantization enabled too (Trellis **1** is sufficient now, but **2** will be more effective).

 * **Psy RDO Strength:** This setting controls the strength of //Psy RDO//. Note that the latest //Psy RDO// patch will automatically scale the strength of Psy RDO, based on the quantizer of the frame! Therefore the "strength" stetting is simply an additional factor, which will be multiplied to the //internal// scaling factor. The default value for //Psy RDO Strength// is **1.0**, which should be sufficient for "Film" material. Using even higher values may introduce artifacts! Furthermore it is recommended to //lower// Psy-RDO to a value of **0.4** for "Animation" material. This does //not// mean that Psy-RDO is generally harmful for "Animation" material, you just needs to //lower// the strength for such material.

 * **Psy Trellis Strength:** This setting controls the strength of //Psy Trellis//. The default value is **0.0** currently, so Psy Trellis will be //disabled// by default. Anyway, it //may// be beneficial to use Psy Trellis for encoding "Film" material. But be careful! Tests have shown that a value of **1.0** usually is too strong for Psy Trellis. For most sources a value of **0.15** should be sufficient. Even higher values may introduce artifacts! Also using Psy-Trellis for "Animation" footage is not recommended.

 * **Note:** At the moment //Psy Trellis Strength// isn't available in Avidemux. The default strength of **0.0** will be used. Patched builds of libx264 may behave differently though.

Luma Quantization Deadzones

 * **Intra Luma Quantization Deadzone**
   * [TO-DO] If you know what information to put here, please contact us!

 * **Inter Luma Quantization Deadzone**
   * [TO-DO] If you know what information to put here, please contact us!

Quantization Matrix

 * **Flat Matrix:** The quantization is the //lossy// part of video compression: The coefficients will be divided through the //quantization matrix// and then rounded off. The "Flat Matrix" is the default quantization matrix of the H.264 specifications - all entries are simply filled with 16's. This matrix is known to give //pretty good// results for a wide range of videos and bitrates. This means //subjective// quality as well as PSNR values.

 * **JVT Matrix:** This is the alternative quantization matrix of the H.264 specifications. Tests have shown that the "JVT Matrix" performs //poorly//, although it's part of the official specifications. Therefore it's highly recommended to **not** use this matrix, except for testing and comparison! You will be far better off with the "Flat Matrix" in almost any case.

 * **Custom Matrix:** This setting allows you to load your //own// quantization matrices. Creating quantization matrices as a complex task an needs a //deep// understand of how video compression works in detail. So creating new quantization matrices should be reserved to the H.264 gurus. Nevertheless you can find a list of suitable matrices at [4] and [5] location. Please note that your "Deblocking Filter" settings have a huge impact on how good/bad a certain quantization matrix performs! Also most custom matrices are targeting a certain bitrate range (e.g. ultra high or ultra low bitrates) and will perform //bad// outside this range. Last but not least you should //not// use any custom matrices, except you know what you are doing. In most cases you will get satisfactory results simply by sticking with the "Flat Matrix" (default).
 * **Remarks:** Now that x264 contains various //psycho-visual optimizations// (Adaptive Quantization, Psy-RDO, Psy-Trellis) custom quantization matrices have become obsolete! Most of the things that people tried to achieve with custom matrices, such as  detail and grain retention, can now be achieved by Psy optimizations in a more sophisticated way. Furthermore the Psy optimizations are tuned for the default //flat// matrix. So using "extreme" custom matrices may result in undesired effects when Psy optimizations are involved! Therefore we highly recommend to stick with the "flat" matrix, unless you have a very good reason to use a custom matrix.

Quantizer Control

 * **Minimum Quantizer:** Specifies the //minimum// quantizer to be enforced. This means //every// frame will get //at least// this amount of data loss. The default value is **10**, which makes sure no bitrate is wasted on too low quantizers. This value should be okay, even for high quality videos.

 * **Maximum Quantizer**: Specifies the //maximum// quantizer to be allowed. This means //none// of the Frames will get a higher amount of data loss than this. The default value is **51**, which is the maximum quantizer possible. So "Max Qp" is //not// limited by default. Of course the encoder will only go that high when it's really necessary, so don't worry!

 * **Maximum Quantizer Step:** Specifies how much the quantizer can change between two consecutive frames. The default value is **4**. This makes sure that two consecutive frames won't get //too// different quantizers. If you allow significant greater QP Steps, this might result in visible quality "jumps" between frames, so don't do that.

 * **Average Bitrate Tollerance:** This setting effects the "Single Pass" bitrate-based mode only. It controls how //precise// the encoder will hit the target bitrate (or target file size). The goal of "Bitrate Variance" is to get as close as possible to the quality of an CRF mode encode, while still being somewhere near the target file size. A value of **0.0** would restrict the encoder to //exactly// hit the desired bitrate. The default value of **1.0** allows an discrepancy of //1%//, which is still pretty restrictive but already a lot better than pure CBR. Please note that the discrepancy usually should be within a range of //30%//. Furthermore CRF mode still gives much better results than the bitrate-based mode and therefore is the recommended method!

 * **Factor between I- and P-Frame Quants:** This setting controls how much //stronger// P-Frames will be compressed compared to I-Frames. A value of **1.0** would assign the //same// quantizers to P-Frames and I-Frames, while the default value of **1.4** assigns //40%// higher quantizers to P-Frames (compared to I-Frames). This equals the "I-Frame Boost" option of Xvid. Compressing P-Frames stronger than I-Frames is recommended, as I-Frames serve as the initial reference of a scene and thus have a huge impact on the quality of the following frames. Therefore you should //not// change the default value, unless you have a very good reason to do so!

 * **Factor between P- and B-Frame Quants:** This setting controls how much //stronger// B-Frames will be compressed compared to P-Frames. A value of **1.0** would assign the //same// quantizers to B-Frames and P-Frames, while the default value of **1.3** assigns a //30%// higher quantizer the B-Frames (compared to P-Frames). Compressing B-Frames stronger than P-Frames is recommended, as B-Frames are //not// referenced by other frames (except for the B-Pyramid), while P-Frames server as reference for the following frames. Therefore you should //not// change the default value, unless you have a very good reason to do so!

 * **Chroma to Luma Quantizer Offset:** This setting controls how much //stronger// the color information (chroma) will be compressed compared to the brightness information (luma). Sometimes it's makes sens to compress the color information stronger than the brightness information, as data loss in the color information is //less// visible to the human eye than data loss in the brightness information. The specified offset will be //added// to the chroma quantizers. It can be configured between **-12** and **+12**. The default value is **0** and usually it's recommended to keep the default value! Note that both, //Psy-RDO// and //Psy-Trellis//, will lower the offset by one or by two, if enabled. So you may end up with an offset of **-4** by using Psy optimizations.

Quantizer Curve Compression

 * **Quantizer Curve Compression (%):** This setting is also called "qcomp" or "bitrate variability" (**not** to be confused with //bitrate variance//). It controls how much the bitrate can fluctuate over the entire video. Setting this to **0%** would enforce a //constant bitrate// stream, while a value of **100%** would result in a //constant quantizer// stream. The default value is **60%**, which gives good results for most videos. So do **not** change the default, unless you have a very good reason to do so! Note that //adaptive quantization// (AQ) partially replaces the effect of //qcomp// and x264 will internally raise qcomp to compensate based on the adaptive quantization strength. Also note that using //CRF// mode together with a //qcomp// of 100% is technically equivalent to //QP// mode, except that CRF mode still is able to use AQ (which QP mode can't do). Hence the more you raise //qcomp//, the closer //CRF// mode gets to a //QP// encode.

 * **Reduce Fluctuation Before Curve Compression:** This setting will apply a temporal Gaussian blur to the quantizer curve //before// the "Quantizer Compression" step. This is done in order to flatten unwanted quantizer fluctuations, which should make the visual quality more stable, especially in Anime content. The default value is **20.0** and usually doesn't need to be changed.

 * **Reduce Fluctuation After Curve Compression:** This setting will apply a temporal Gaussian blur to the quantizer curve //after// the "Quantizer Compression" step.  This is done in order to //further// flatten unwanted quantizer fluctuations. The default value is **0.5** and usually doesn't need to be changed.

 * **Remarks:** Further information on how x264' rate control works in detail can be found at [6] location.

Adaptive Quantization

//Adaptive Quantization (AQ)// allows each macroblock within the frame to choose a //different// quantizer, instead of assigning the //same// quantizer to //all// blocks within the frame. The purpose of AQ is moving more bits into "flat" macroblocks. This is done by adaptively lowering the quantizers of certain blocks (and raising the quantizers of other blocks). Without AQ, flat and dark areas of the image tend to show ugly blocking or banding. Thanks to the new AQ algorithm, blocking and banding can be greatly reduced! With AQ enabled, you can expect a significant(!) gain in overall image quality. Especially in dark scenes and scenes with "flat" backgrounds (sky, grass, walls, etc.) much more details can be preserved. Nevertheless AQ seems to perform less efficient with "Animation" material than it does with "Film" material, but still helps to prevent banding. Note that AQ can be used with the bitrate-base modes (//Single-Pass// and //Two-Pass//) as well as with the //CRF// mode. It can **not** be used with the //QP// mode! That's because QP mode uses constant quantizers per definition, which is one of the reasons why QP mode generally should be avoided nowadays.

 * **AQ Strength:** This setting controls the amount of AQ that is applied to the frames. The default //AQ Strength// is **1.0** now, so AQ will be //enabled// by default. The default value should be well-balanced and give good AQ results for most sources. If you think your video requires stronger AQ, then you can raise the //AQ Strength//. A value of **1.5** is considered "strong" AQ. If you think the AQ effect is too strong, you can lower the //AQ Strength//. A value of **0.5** is considered "low" AQ. While sticking with an AQ value of **1.0** is recommended for "Film" material, it should be lowed to **0.6** for "Anmiation" material.

 * **AQ Mode:** This setting chooses the AQ algorithm. The following modes are currently available:
   * **Variance AQ:** The default AQ algorithm. Recommended.
   * **Auto-Variance AQ:** New //experimental// AQ algorithm that tries to adapt the AQ strength per frame (now improved for //MB-Tree//).
   * **Disabled:** Don't use AQ at all. //Not// recommended.

 * **Example:** with VAQ -vs- No AQ (animated GIF image)

Video Buffer Verifier

VBV (Video Buffering Verifier) defines a specific buffering model. In that model the decoder (player) reads the input data from a buffer. That buffer has a limited size. Also the buffer is filled at a limited data rate. VBV makes sure that the buffer will //never// run out of data, i.e. it makes sure that there is always enough data left in the buffer to decode the next frame. Therefore VBV forces additional bitrate and buffering constraints on the encoder. It's highly recommended to **not** use VBV, unless you can't get around it. VBV //may// hurt the video quality, but it never will improve the quality! Unfortunately hardware players (including mobile devices) may need VBV for proper playback. You will have to look up the particular VBV requirements for each device individually. In particular BluRay has strict VBV requirements. Note that x264's VBV implementation now works just fine with both, 1-Pass and 2-Pass modes. There's no need to use 2-Pass mode for VBV anymore. (See [7] for details about VBV)

 * **Maximum VBV Bitrate**: Specifies the maximum bitrate (in kbit/s) at which data enters the buffer. This equals the bandwidth of the network (for streaming media) or the maximum disc read speed (for local playback). Note that this setting does //not// restrict the maximum (local) video bitrate. The (local) video bitrate is allowed to exceed the //maximum VBV bitrate// as long as there's enough data left in the buffer. A value of **0** indicates that VBV is //not// used (Default).
 * **Maximum Buffer Size**: Specifies the buffer size of the device/player (in kilobit). This is the maximum amount of data that can be hold inside the buffer. Usually this is pre-defined by the individual device/player you are encoding for. A value of **0** indicates that VBV is //not// used (Default).
 * **Initial VBV Buffer Occupancy**: Specifies the filling level of the device buffer at the start of playback. **90%** is the default.
 * **Note:** VBV cannot be used without specifying both, the Maximum VBV Bitrate //and// the VBV Buffer Size. Specifying only one of them (while the other one is **0**) does nothing!

Slicing

H.264 allows to segment each frame into several parts. These parts are called "slices". The advantage of using multiple slices (per frame) is that the slices can be processed independently and in parallel. This allows easy multi-threading implementations in H.264 encoders and decoders. Unfortunately using multiple slices hurts compression efficiency! The more slices are used the worse! Therefore you should **not** use slices, if you don't have to. But if your H.264 decoder uses //slice-based// multi-threading (i.e. multiple slices are decoded in parallel), then multi-threading will only be used, if the video was encoded with multiple slices. Fortunately most software decoders do //not// require slices, because they use //frame-based// multi-threading (i.e. multiple frames are decoded in parallel). Hardware decoders may require slices though. In particular the Blu-ray specs say that at least **4** slices must be used.

 * **Maximum Size per Slice**: Specifies the maximum size per slice (in byte). x264 will use as many slices as required to comply with that restriction. A value if **0** means that multiple-slices are //not// used.
 * **Maximum Size per Slice**: Specifies the maximum number of macroblocks per slice. x264 will use as many slices as required to comply with that restriction. A value if **0** means that multiple-slices are //not// used.
 * **Slices per Frame:** Specifies the number of slices per frame. A value if **0** means that multiple-slices are //not// used.
 * **Note:** x264 does //not// require multiple slices to take advantage of multiple processor cores. Since r607 x264 uses //frame-based// multi-threading.

Zones

 * **Add**: Add a new zone to the list.

 * **Edit**: Edit an existing zone.

 * **Add**: Remove a zone from the list.

Zones can be used to //manually// assign a lower or higher bitrate to a certain başlık of the video (e.g. enforce a lower bitrate for the ending credits). There are two modes to control the bitrate of a zone: Using a "Bitrate Factor" you can change the bitrate //relative// to the encoders decision and using a "Quantizer" you can overwrite the encoders decision with a //constant// quantizer value.

Output Settings

 * **IDC Level:**
   * By default x264 will detect the Level of the resulting H.264 stream based on the encoder settings you have chosen (and based on the properties of your video). //This// option can be used to overwrite x264 decision. Be aware that x264 will **not** enforce the selected Level for you! You only specify what Level will be signaled in the header of your H.264 stream. But this does **not** mean that your stream actually complies to that level! Hence you can easily produce an //invalid// stream by specifying an improper level. Therefore it's //highly// commended to keep the //IDC Level// setting on **Auto** and let x264 detect the proper Level. If you want your H.264 stream to comply to a specific H.264 Level, then you //must// choose your encoder settings accordingly. Also you must make sure that your video's resolution and framerate don't exceed the Level's limits. In short: Don't change //this// option, unless you have a very good reason to do so!

 * **Sequence Parameter Set Identifier:**
 * [TO-DO] If you know what information to put here, please contact us!

 * **Enforce Repeatability:**
 * [TO-DO] If you know what information to put here, please contact us!

 * **Use Access Unit Delimiters:**
 * [TO-DO] If you know what information to put here, please contact us!

Pixel Aspect Ratio

This setting defines the "Pixel Aspect Ratio" (PAR) of the video. Do **not** change the default value of **1:1** (aka "Square Pixels"), unless you are encoding [8] video! In case you are encoding anamorphic material //and// you want to keep it anamorphic, then you will have to set the correct PAR value. Otherwise your video would be displayed with wrong //aspect ratio//! If you have an //anamorphic// source and you want to convert it to "Square Pixels" (PAR = 1:1), then you must invoke the Resize filter and resize the video accordingly. Note that "Pixel Aspect Ratio" is **not** equal to "Display Aspect Ratio" (DAR). Anyway, the DAR can be calculated from the PAR using this formula: DAR = Width/Height * PAR. For example: 720/576 * 64/45 = 16/9. The advantage of working with PAR values is that the PAR of a video won't change when cropping the video, while the DAR most likely //will// change. The following PAR options are available:

   * **Custom:** Enter a user-defined PAR value
   * **Predefined Aspect Ratio:** Choose one of the most common PAR values from the list
   * **As Input:** Keep the PAR of the source video

Video Usability Information

These settings are only suggestions for the playback equipment. Use them at your own risk!

 * **Overscan**
 * **Video Format**
 * **Color Primaries**
 * **Transfer Characteristics**
 * **Color Matrix**
 * **Chroma Sample Location**
 * **Full Range Samples**

Unavailable x264 options in Avidemux

 * **AQ Mode** - currently Avidemux sticks with //AQ mode// **1**, mode **2** isn't available yet.
 * **Sub-ME 10** - currently the highest //Sub-Me// mode available in Avidemux is **9**, mode **10** (aka "QPRD") is not available yet.
 * **Psy-Trellis** - currently Psy-Trellis will be //disabled// in Avidemux (Psy-RDO //is// available though!)
 * **Progressive Intra Refresh**
 * [9] and [10] calculations

Obsolete x264 options

 * **B-RDO:** RD based mode decision for B-Frames. This option has been removed in r996. It's now enabled implicitly at //Sub ME 7// or higher.
 * **Pre-Scenecut:** Since r1117 x264 will //always// use Pre-Scenecut, because it's generally better than regular scenecut in terms of accuracy and regular scenecut didn't work in threaded mode anyways.
 * **Bidirectional ME:** Jointly optimize both motion vectors in B-Frames. This option has been removed in r996. It's now enabled implicitly at //Sub ME 5// or higher.
 * **AQ Sensitivity:** This option //never// existed in official x264. It was used only in experimental //Adaptive Quantization// patches. Current AQ doesn't use it.

H.264/AVC Profiles and Levels

The H.264/AVC specifications define a number of different **profiles**. Each profile specifies which //features// of H.264 are allowed (or not allowed). If you want your H.264 video stream to be compliant to a certain profile, then you may only enabled features allowed in //this// profile. Profiles are needed to make sure your video file will play fine on a certain decoder. For example a "Main" profile compliant video will play 100% fine on //every// "Main" profile capable decoder/player. When working with the **x264** encoder, there are basically two profiles you have to take care of: the "Main" profile and the "High" profile. Nevertheless x264 is //missing// the Error Resilience feature from the "Baseline Profile" as well as the Interlacing Support from "Extended Profile". If you want to play your video on //software// players, then you don't need to care about profiles that much. The H.264 decoder from "libavcodec", which is used in MPlayer, VLC Player, ffdshow and many more, supports all of x264' features, including the "High" and "Predictive Lossless" profile features. Same for proprietary decoders, such as CoreAVC. Nevertheless if you are targeting a //hardware// player, then profiles are very important, as hardware players are very //restrictive// on what profile they support.

In addition to the //profiles//, the H.264/AVC specifications also define a number of **levels**. While //profiles// define which compression features of H.264 may (or may not) be used, the //levels// put further restrictions on other properties of the video. These restrictions include the maximum resolution, the maximum bitrate, the maximum framerate (for a given resolution) and the maximum number of reference frames (indirectly limited though MaxDPB). In order play your H.264 video on a specific //hardware// player, that player must not only support your videos //profile//, but also your video's //level// (or a higher one). Again //software// players usually don't have such restrictions, as long as you CPU is powerful enough.

• • Note:** The common notation for Profiles and Levels is "Profile@Level", for example //High@4.1//. Furthermore there is //no// way to directly encode your video to a specific level and/or profile. If you want your video to comply to a certain profile/level, you must choose the encoder settings accordingly. Presets may be helpful to find the correct settings. Anyway, it may still be necessary to resize your video and/or change the framerate.

List of all H.264/AVC Profiles

^ ^Baseline ^Extended ^Main ^High ^High 10 ^High 4:2:2 ^High 4:4:4 Predictive ^ |I and P Slices |YES |YES |YES |YES |YES |YES |YES | |B Slices |NO |YES |YES |YES |YES |YES |YES | |SI and SP Slices |NO |YES |NO |NO |NO |NO |NO | |Multiple Reference Frames |YES |YES |YES |YES |YES |YES |YES | |In-Loop Deblocking Filter |YES |YES |YES |YES |YES |YES |YES | |CAVLC Entropy Coding |YES |YES |YES |YES |YES |YES |YES | |CABAC Entropy Coding |NO |NO |YES |YES |YES |YES |YES | |Flexible Macroblock Ordering (FMO) |YES |YES |NO |NO |NO |NO |NO | |Arbitrary Slice Ordering (ASO) |YES |YES |NO |NO |NO |NO |NO | |Redundant Slices (RS) |YES |YES |NO |NO |NO |NO |NO | |Data Partitioning |NO |YES |NO |NO |NO |NO |NO | |Interlaced Coding (PicAFF, MBAFF) |NO |YES |YES |YES |YES |YES |YES | |4:2:0 Chroma Format |YES |YES |YES |YES |YES |YES |YES | |Monochrome Video Format (4:0:0) |NO |NO |NO |YES |YES |YES |YES | |4:2:2 Chroma Format |NO |NO |NO |NO |NO |YES |YES | |4:4:4 Chroma Format |NO |NO |NO |NO |NO |NO |YES | |8 Bit Sample Depth |YES |YES |YES |YES |YES |YES |YES | |9 and 10 Bit Sample Depth |NO |NO |NO |NO |YES |YES |YES | |11 to 14 Bit Sample Depth |NO |NO |NO |NO |NO |NO |YES | |8x8 vs. 4x4 Transform Adaptivity |NO |NO |NO |YES |YES |YES |YES | |Quantization Scaling Matrices |NO |NO |NO |YES |YES |YES |YES | |Separate Cb and Cr QP control |NO |NO |NO |YES |YES |YES |YES | |Separate Color Plane Coding |NO |NO |NO |NO |NO |NO |YES | |Predictive Lossless Coding |NO |NO |NO |NO |NO |NO |YES | ^ ^Baseline ^Extended ^Main ^High ^High 10 ^High 4:2:2 ^High 4:4:4 Predictive ^

From Wikipedia, the free encyclopedia

List of all H.264/AVC Levels

^Level number ^Max macroblocks per second ^Max frame size (macroblocks) ^Max video bit rate (VCL) for Baseline, Extended and Main Profiles ^Max video bit rate (VCL) for High Profile ^Max video bit rate (VCL) for High 10 Profile ^Max video bit rate (VCL) for High 4:2:2 and High 4:4:4 Predictive Profiles ^Examples for high resolution @ frame rate (max stored frames) in Level ^ |1 |1485 |99 |64(nbsp)kbit/s |80(nbsp)kbit/s |192(nbsp)kbit/s |256(nbsp)kbit/s |128x96@30.9(nbsp)(8) 176x144@15.0(nbsp)(4) | |1b |1485 |99 |128(nbsp)kbit/s |160(nbsp)kbit/s |384(nbsp)kbit/s |512(nbsp)kbit/s |128x96@30.9(nbsp)(8) 176x144@15.0(nbsp)(4) | |1.1 |3000 |396 |192(nbsp)kbit/s |240(nbsp)kbit/s |576(nbsp)kbit/s |768(nbsp)kbit/s |176x144@30.3(nbsp)(9) 320x240@10.0(nbsp)(3) 352x288@7.5(nbsp)(2) | |1.2 |6000 |396 |384(nbsp)kbit/s |480(nbsp)kbit/s |1152(nbsp)kbit/s |1536(nbsp)kbit/s |320x240@20.0(nbsp)(7) 352x288@15.2(nbsp)(6) | |1.3 |11880 |396 |768(nbsp)kbit/s |960(nbsp)kbit/s |2304(nbsp)kbit/s |3072(nbsp)kbit/s |320x240@36.0(nbsp)(7) 352x288@30.0(nbsp)(6) | |2 |11880 |396 |2(nbsp)Mbit/s |2.5(nbsp)Mbit/s |6(nbsp)Mbit/s |8(nbsp)Mbit/s |320x240@36.0(nbsp)(7) 352x288@30.0(nbsp)(6) | |2.1 |19800 |792 |4(nbsp)Mbit/s |5(nbsp)Mbit/s |12(nbsp)Mbit/s |16(nbsp)Mbit/s |352x480@30.0(nbsp)(7) 352x576@25.0(nbsp)(6) | |2.2 |20250 |1620 |4(nbsp)Mbit/s |5(nbsp)Mbit/s |12(nbsp)Mbit/s |16(nbsp)Mbit/s |352x480@30.7(nbsp)(10) 352x576@25.6(nbsp)(7) 720x480@15.0(nbsp)(6) 720x576@12.5(nbsp)(5)| |3 |40500 |1620 |10(nbsp)Mbit/s |12.5(nbsp)Mbit/s |30(nbsp)Mbit/s |40(nbsp)Mbit/s |352x480@61.4(nbsp)(12) 352x576@51.1(nbsp)(10) 720x480@30.0(nbsp)(6) 720x576@25.0(nbsp)(5) | |3.1 |108000 |3600 |14(nbsp)Mbit/s |14(nbsp)Mbit/s |42(nbsp)Mbit/s |56(nbsp)Mbit/s |720x480@80.0(nbsp)(13) 720x576@66.7(nbsp)(11) 1280x720@30.0(nbsp)(5) | |3.2 |216000 |5120 |20(nbsp)Mbit/s |25(nbsp)Mbit/s |60(nbsp)Mbit/s |80(nbsp)Mbit/s |1280x720@60.0(nbsp)(5) 1280x1024@42.2(nbsp)(4) | |4 |245760 |8192 |20(nbsp)Mbit/s |25(nbsp)Mbit/s |60(nbsp)Mbit/s |80(nbsp)Mbit/s |1280x720@68.3(nbsp)(9) 1920x1080@30.1(nbsp)(4) 2048x1024@30.0(nbsp)(4) | |4.1 |245760 |8192 |50(nbsp)Mbit/s |62.5(nbsp)Mbit/s |150(nbsp)Mbit/s |200(nbsp)Mbit/s |1280x720@68.3(nbsp)(9) 1920x1080@30.1(nbsp)(4) 2048x1024@30.0(nbsp)(4) | |4.2 |522240 |8704 |50(nbsp)Mbit/s |62.5(nbsp)Mbit/s |150(nbsp)Mbit/s |200(nbsp)Mbit/s |1920x1080@64.0(nbsp)(4) 2048x1080@60.0(nbsp)(4) | |5 |589824 |22080 |135(nbsp)Mbit/s |168.75(nbsp)Mbit/s |405(nbsp)Mbit/s |540(nbsp)Mbit/s |1920x1080@72.3 (13) 2048x1024@72.0 (13) 2048x1080@67.8 (12) 2560x1920@30.7 (5) 3680x1536@26.7(nbsp)(5) | |5.1 |983040 |36864 |240(nbsp)Mbit/s |300(nbsp)Mbit/s |720(nbsp)Mbit/s |960(nbsp)Mbit/s |1920x1080@120.5 (16) 4096x2048@30.0 (5) 4096x2304@26.7 (5) | ^Level number ^Max macroblocks per second ^Max frame size (macroblocks) ^Max video bit rate (VCL) for Baseline, Extended and Main Profiles ^Max video bit rate (VCL) for High Profile ^Max video bit rate (VCL) for High 10 Profile ^Max video bit rate (VCL) for High 4:2:2 and High 4:4:4 Predictive Profiles ^Examples for high resolution @ frame rate (max stored frames) in Level ^

From Wikipedia, the free encyclopedia

For more detailed information, please refer to "Annex A" in the official ITU-T H.264 specifications!

GPU support

Since [11] has become a hot topic, people began asking for GPU support in Avidemux. These people need to understand that Avidemux cannot offer GPU support for H.264 encoding, until GPU support is implemented in the //x264// library. There is a project scheduled to add [12] support to x264 (see [13]), but there are no results yet (May 2009). We know that there are //commercial// H.264 encoders with GPU support available already. But if you look at these encoders closely, you will notice that their speed-up claims are marketing blabber. These encoders may be fast, but their quality isn't anywhere near x264's quality! Also note that marketing people tend to compare their encoders to the completely unoptimized //H.264 Reference Encoder//. x264 is faster than the reference encoder by several orders of magnitude, which renders these speed comparisons meaningless. x264 can run extremely fast on a CPU and scales up to at least 16 cores. So don't believe everything that marketing people claim!

IDR-frames

IDR frames are: An IDR frame is what has been traditionally known as an I frame. An IDR frame, just like an I frame in MPEG-1/2 and MPEG-4 ASP, starts with a clean slate, and all subsequent frames will make reference to the IDR frame and subsequent frames. Non IDR I frames should be rare, but since they cannot be ruled out, enforcing a minimal IDR interval can help improve compression in some high motion scenes. In H.264/AVC you can also have I frames inside a GOP, which are not seekable, since the long time references introduced in H.264/AVC could result in a P frame after the I frame to reference a P frame before the I frame.

Max IDR-keyframe interval indicates the maximum distance between two IDR frames. Similarly, Min IDR-keyframe interval indicates the minimum distance between two IDR frames.

List of References

 * ITU-T H.264 Specifications - provided by Neuron2
 * - A high performance H.264/AVC encoder - by Loren Merritt and Rahul Vanam
 * Thread on Doom9's Forum - especially posts by //akupenguin//, //Dark Shikari// and //*.mp4 guy//
 * qualitative overview of x264's ratecontrol methods - by Loren Merritt
 * x264 multi-threading threading method - by Loren Merritt
 * ffmpeg mapping and options guide
 * the free encyclopedia - article about the "x264" encoder (version)
 * AVC VfW Guide
 * - x264 settings
 * man x264 (Hilfe zum x264 CLI) - German documentation
 * Digest - x264 Options Explained

Ayrıca bakınız

 * build:Compiling x264