H.264 Sihri (2016)
(sidbala.com)- İnternet videolarında, Blu-ray’de, cep telefonlarında, güvenlik kameralarında ve dronlarda kullanılan H.264, tam hareketli videoyu gerçekçi bant genişlikleriyle iletebilmek için gelişmiş bir video sıkıştırma standardıdır
1920×1080×60×3temelinde 1080p 60Hz sıkıştırılmamış video yaklaşık 370MB/s’ye ulaşır; bu da 50GB’lık bir Blu-ray diske yalnızca yaklaşık 2 dakika sığdırabileceğiniz anlamına gelir- Sıkıştırmanın özü kayıplı sıkıştırmadır; gözün daha az fark ettiği ayrıntılar azaltılır, frekans alanı dönüşümü, nicemleme ve renk farkı alt örnekleme ile veri miktarı düşürülür
- Zamansal sıkıştırma, kareleri I-frame, P-frame ve B-frame olarak ayırır; 16×16 piksellik makroblokların hareket vektörleriyle tüm kare yerine yalnızca değişim yeniden oluşturulur
- Örnekte 5 saniyelik 60fps, 300 karelik bir H.264 video 175KB iken tek bir PNG ekran görüntüsü 1015KB’dir; özgün 1.2GB video 175KB’ye kadar küçülür
H.264’ün azaltmaya çalıştığı veri
- H.264, internet videoları, Blu-ray, cep telefonları, güvenlik kameraları ve dronlar gibi alanlarda yaygın olarak kullanılan bir video sıkıştırma kodek standardıdır
- Amaç, tam hareketli video iletimi için gereken bant genişliğini azaltmaktır
- Burada ele alınan kavramların önemli bir kısmı yalnızca H.264’e değil, genel olarak video sıkıştırmaya da uygulanır
Sıkıştırılmamış videonun neden bu kadar büyük olduğu
- Basit bir sıkıştırılmamış video dosyası, her karenin piksel verilerini içeren 2D tampon dizilerinden oluşur ve uzayda iki, zamanda bir boyutu olan 3D bir bayt dizisi olarak görülebilir
- Her piksel kırmızı, yeşil ve mavi olmak üzere üç temel renk için 3 bayt kullanır
- 1080p 60Hz video aşağıdaki hesapla yaklaşık 370MB/s ham veri üretir
1920 × 1080 × 60 × 3
- Bu boyutta bir veri, 50GB’lık bir Blu-ray diske yalnızca yaklaşık 2 dakika sığar; taşımak ya da depolamak da zorlaşır
Tek bir PNG’den daha küçük 5 saniyelik video
- Apple ana sayfası örneği, H.264 sıkıştırma etkisini sezgisel olarak gösterir
- 5 saniyelik 60fps video 300 kare içerir, ancak dosya boyutu tek bir PNG karenin yaklaşık beşte biri kadardır
- Yüzeyde 300 kat daha fazla veri içeriyor gibi görünen video daha küçük olduğundan, H.264 PNG’ye kıyasla son derece verimli görünür
Kayıplı sıkıştırmayla atılan bilgi
- H.264 bir kayıplı sıkıştırma kodeğidir; daha az önemli bitleri atar ve yalnızca önemli bitleri korur
- PNG bir kayıpsız sıkıştırma kodeğidir; kodlanmış görüntüden özgün kaynak görüntü bit düzeyinde geri elde edilebilir
- H.264, görüntüyü kırpmak ya da belirli bir çeyreğini atmak yerine, diğer kayıplı görüntü algoritmaları gibi ayrıntı bilgisini azaltır
- Örnek görüntüde MacBook Pro hoparlör ızgarasındaki delikler gibi ayrıntılar kaybolur, ancak yakınlaştırmadan farkı görmek zordur
- Yalnızca bu aşamada bile görüntü özgün boyutunun %7’si seviyesine iner
Entropi ve tekrarın giderilmesi
- Bilgi entropisi, bir bilgiyi ifade etmek için gereken bit sayısıdır; verinin yalnızca ham boyutuyla aynı şey değildir
- Bunu, yazı tura atışı sonuçları gibi olası durumları ifade etmek için gereken en düşük bit sayısı olarak düşünebilirsiniz
- Para 10 kez atıldığında hepsi tura geldiyse bunu
HHHHHHHHHHdiye yazmak yerine “10 kez de tura” diye ifade ederek daha kısa anlatabilirsiniz - Bu süreç, bilginin kendisini değiştirmeden yalnızca ifadesini kısaltarak artıklığı ortadan kaldırır
- Bu tür genel amaçlı kayıpsız kodlayıcılara entropi kodlayıcı denir
Frekans alanı ve nicemleme
- Uzay ya da zaman boyunca değişen veriler başka koordinat sistemlerine dönüştürülebilir; görüntü parlaklık değerleri de frekans alanında ifade edilebilir
- Frekans alanında düşük frekans bileşenleri merkeze yakın, yüksek frekans bileşenleri ise kenarlara yakın bulunur
- Görüntüdeki ince ızgara gibi ayrıntı desenleri yüksek frekans bileşenlerine; yumuşak renk ve parlaklık değişimleri ise düşük frekans bileşenlerine karşılık gelir
- Frekans alanı görüntüsünün kenarlarını maskeleyerek yüksek frekans bilgisi atılabilir; ardından normal x-y koordinat sistemine geri dönüldüğünde, özgüne benzeyen ama daha az ayrıntı içeren bir görüntü elde edilir
- Maske boyutu değiştirilerek çıktı görüntüsünün ayrıntı seviyesi de ayarlanabilir
- Örnekte bilgi entropisi özgünün %2’si seviyesinde olsa bile, yakınlaştırmadan farkı görmek zordur
- Kayıplı sıkıştırmada bu sürece nicemleme (quantization) denir
Renk farkı alt örnekleme
- İnsan gözü ve beyni parlaklık değişimlerini iyi algılar, ancak renkteki ince farkları görece daha zor ayırt eder
- TV sinyalinde RGB renk verisi Y+Cb+Cr biçimine dönüştürülür
Y: parlaklık, fiilen siyah-beyaz aydınlık bilgisiCb,Cr: renk farkı, yani renk bileşenleri
- RGB ile YCbCr, bilgi entropisi açısından eşdeğerdir
- Siyah-beyaz TV döneminde yalnızca Y sinyali vardı; renkli TV ortaya çıktığında renk bilgisi Cb ve Cr içine kodlanıp Y ile birlikte iletilmeye başlandı
- Siyah-beyaz TV yalnızca Y bileşenine bakarken, renkli TV renk farkı bileşenlerini de kullanıp içeride RGB’ye dönüştürür
- H.264’te kullanılan yöntem, Y bileşenini tam çözünürlükte saklayıp C bileşenlerini çeyrek çözünürlükte saklamaktır
- Renk farkı alt örnekleme, renk bilgisinin bir kısmını atarak toplam bant genişliğini yarıya indirirken görsel farkı küçük tutar
- Bu teknik yalnızca H.264’e özgü değildir; onlarca yıldır yaygın biçimde kullanılmaktadır
Hareket telafisi ve zamansal sıkıştırma
- H.264 bir hareket telafili sıkıştırma standardıdır
- Tek bir karenin içindeki uzamsal sıkıştırmanın ötesine geçerek, birden fazla kareyi zaman yönünde birlikte ele alır
- Tenis maçı gibi kameranın sabit olduğu ve yalnızca topun hareket ettiği videolarda, tüm arka planı her seferinde yeniden kaydetmeye gerek yoktur
- Görüntü genellikle 16×16 piksellik makrobloklara bölünür ve hareket bu bloklar üzerinden tahmin edilir
- Kare türleri genel olarak üçe ayrılır
- I-frame: Tam karenin oluşturulması için gereken tüm bitleri içeren kare
- P-frame: Önceki kareden her makroblok için hareket vektörlerini kodlayan tahmin kare
- B-frame: Hem geçmiş hem gelecek karelerden tahmin yapan çift yönlü tahmin kare
- Kod çözücü son I-frame’den başlayıp sonraki karelerin hareket vektörü farklarını ekleyerek mevcut kareyi oluşturur
- Apple ana sayfası örnek videosu esasen üç I-frame üzerinde makroblokların hareket etmesinden ibaret olduğu için çok iyi sıkıştırılır
Geri sardıktan sonra neden kısa bir duraklama olur?
- YouTube gibi videolarda birkaç saniye geri sardığınızda oynatmanın hemen başlamayıp kısa süre duraksaması, H.264 yapısıyla ilgilidir
- Kullanıcı rastgele bir kareye atlarsa, kod çözücü en yakın I-frame’den başlayarak yeniden hesaplama yapmak zorundadır
- Sonraki kareye kadar hareket vektörü farklarını biriktirip mevcut kareyi oluşturması gerektiğinden hesaplama maliyeti yüksektir
- Bu yöntem alan verimliliği açısından çok güçlüdür, ancak kod çözme tarafında hesaplama gerektirir
Son kayıpsız sıkıştırma aşaması
- Kayıplı aşamalardan geçmiş I-frame içinde bile hâlâ yinelenen bilgiler kalır
- P-frame ve B-frame makrobloklarının hareket vektörlerinde de aynı değerlere sahip gruplar oluşabilir
- Özellikle test videosundaki gibi ekranın pan yaptığı durumlarda, birçok makroblok aynı miktarda hareket eder
- Entropi kodlayıcı bu tekrarları işler
- Entropi kodlayıcı genel amaçlı bir kayıpsız kodlayıcı olduğundan, girilen veri geri kazanılabilir
Örnek sıkıştırma oranı
- Özgün örnek video
1232×1154gibi alışılmadık bir çözünürlükte yakalanmıştır - 5 saniye 60fps için özgün boyut aşağıdaki hesapla yaklaşık 1.2GB’dır
1232 × 1154 × 60 × 3 × 5
- Sıkıştırılmış H.264 video 175KB’dir
- Yazıdaki otomobil benzetmesine göre bu, 3000 poundluk bir aracın 0.4 pound, yani 6.5 ons seviyesine düşmesi gibidir
- Bu sıkıştırma oranı açıklaması, onlarca yıllık araştırmayı büyük ölçüde basitleştirir; daha fazla ayrıntı için H.264/MPEG-4 AVC Wikipedia Page sayfasına bakılabilir
1 yorum
Hacker News yorumları
AV1, lisanslaması daha iyi olan, daha da büyülü bir codec
Meta, video streaming tarafında VP9/AV1 akışlarını kademeli olarak temel varsayılan haline getiriyor: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
Görüntülü görüşmelerde de AV1 kullanıyor: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft da Teams’te AV1 kullanmaya başladı ve AV1’de ekran paylaşımı için özellikle yararlı video kodlama araçları var: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
Bugünlerde YouTube’da gördüğünüz videoların çoğu VP9 veya AV1; H.264 ise ancak ara sıra karşınıza çıkıyor
H.264 epey uzun süre varlığını sürdürecek, ancak AV1’in internet videosunun yeni temel standardı olma ihtimali yüksek görünüyor
Geliştirici açısından herkesin erişebilmesi gerekiyor; şu anda ise bu özelliğin kullanıcıların çoğunluğuna ulaşmasını bekleme aşamasındayız
Daha fazla kullanıcının AV1 encoding/decoding’e sahip donanım alması iyi olurdu; “AV1 inside” gibi bir logoya ihtiyaç var gibi görünüyor
Örneğin iPhone serisinde şimdilik yalnızca iPhone 15 Pro donanımsal decoding sunuyor
Ders videolarını kaydedip 720p’de nispeten küçük dosyalar halinde yüklemem gerekiyordu; beyaz tahtadaki ince ve keskin çizgilerin önünde yavaş hareket eden bir kişiyi, vasat aydınlatmada çektiğim bir video olduğu için x264’ün varsayılan encoding profili pek uygun değildi
Yine de bir iki gün ayarlarla oynayıp, yaklaşık 2014 çıkışlı ve yalnızca iGPU’su olan bir dizüstünde dersin ertesi gecesi çalıştırıp sonraki gün çıktıyı yükleyebileceğim hale getirdim
Buna karşılık libaom, 3 saatlik videoyu render etmenin yaklaşık bir hafta süreceğini söylüyordu; varsayılanları da o kadar kötüydü ki denemeye ayıracak zamanım yoktu
Bu 4 yıl önceydi, şimdi daha iyi olmuştur ama mucize de beklemiyorum
Bu mutlaka sorun olmak zorunda değil, ama AV1’in asıl problemi sıkıştırmanın çok fazla hesaplama gerektirmesi
Ya da gözlerim iyileşmiş olabilir
Bu konuyu derinlemesine inceleyen bir yazı olsa iyi olurdu
İlgili yazılar:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - Mart 2022, 219 yorum
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - Mayıs 2019, 180 yorum
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - Mayıs 2018, 1 yorum
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - Kasım 2016, 219 yorum
O yazının yazılmasının üzerinden 8 yıl geçmişken, bugün H.264 patentlerinin önemli bir kısmı yakında, kabaca 1-2 yıl içinde sona erecek: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
H.264 standardının ilk sürümünün 2003’te çıktığını ve patentlerin genelde 20 yıl geçerli olduğunu düşününce bu şaşırtıcı değil
Önceki nesil H.263 ve MPEG-4 ASP’nin patentleri zaten sona erdi ve public domain’de
Peki H.265 nasıl? Sonuçta sayı bir büyük değil mi? https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
H.265 kodlama, sağladığı alan tasarrufuna kıyasla çok fazla ek hesaplama gerektiriyor
H.264 ile 1 saatte 1 GB’a düşüreceğiniz bir dosyayı, H.265 ile 12 saatte 850 MB’a düşürmek gibi
Kullanım yerine göre, istemci desteği çok daha geniş olan H.264 sürümüne zaten ihtiyaç duyabilirsiniz
Veri merkezi düzeyinde hesaplama kaynağınız varsa ya da video başına 150 MB tasarrufun biriktiği bir streaming hizmeti işletiyorsanız H.265’e geçersiniz; ama pek çok gerçekçi durumda bunu gerekçelendirmek zor
VP9 ile neredeyse aynı seviyede, ancak lisans sorunu yüzünden hâlâ her yerde benimsenmesi zor oldu
VVC/H.266 da aynı sorunu yaşıyor gibi; AV1 ise neredeyse aynı derecede iyi ve şimdiden çok daha yaygın benimsenmiş durumda
Daha yeni codec’ler daha iyi sıkıştırıyor, ama karmaşıklık doğrusal olmayan biçimde artıyor
Dosya boyutları H.264’e kıyasla çok daha küçüldü
Standart da H.264’ten 10 yıl daha genç; H.264 2003, H.265 ise 2013 tarihli
“Bir parayı 10 kez atıp hepsi tura geldiyse HHHHHHHHHH demek yerine ‘10 kez attım ve hepsi tura geldi’ denebilir” örneğinde, o H dizgesine biraz kayıplı sıkıştırma girmiş gibi
H.264’ün ilk çıktığı zamanı hatırlıyorum
O dönem mplayer’a takmıştım; en yeni sürümleri sık sık indirip derlerdim
İlk H.264 dosyamı aldığımda mplayer okuyamamıştı, bu yüzden geliştirme sürümünü indirip derlemem gerekmişti
Çalıştı ve iki şeyi fark ettim: görüntü kalitesi şaşırtıcıydı ve Athlon 1800+’ım bunun altından kalkamıyordu
Sonraki mplayer veya libavcodec sürümlerinde performans ciddi biçimde iyileşti, ama o günü hâlâ hatırlıyorum
mplayer kullanmayalı gerçekten çok uzun zaman oldu, ama o dönemde en iyisiydi
Eskiden video tabanlı bir ürün geliştiren bir şirkette çalışıyordum; Las Vegas’taki başka bir şirket yöneticilerimize “devrim niteliğinde bir video codec’i” ve oynatıcı satmıştı, kullanmak için NDA imzalamak gerekiyordu
Deneyince mplayer gibi çalışıyordu; hatta fazlasıyla aynıydı
5 dakika daha araştırınca iş ortaya çıktı ve o şirkete büyük para ödeyen yöneticiler rezil oldu
Teknoloji alanında bile teknik olmayan karar vericileri kandırmak şaşırtıcı derecede kolay
Çünkü geride kalma korkuları çok büyük
Akıllı biri değerlendirme için iyi bir mühendisi çağırır; Dunning-Kruger vakaları ise cüzdanlarıyla sıraya girer
1999’da satın alınmış bir startup’tan ayrılmayı düşündüğüm bir dönem vardı; o sırada MPEG encoding yapıyordum.
Görüştüğüm şirketlerden biri yeni bir video sıkıştırma yöntemi geliştirdiğini söyledi; NDA imzaladıktan sonra gerçek zamanlı olmayan bir yazılım codec’iyle encode/decode edilmiş kısa bir klip gösterdiler.
Ben algoritmanın ASIC sürümünü yapacak kişi olarak görüşmeye gidiyordum; çıktının 1-2 dakikasına bakınca ne yaptıklarını tahmin ettim.
Örneğin algoritmanın güçlü yanlarına göre seçildiğini düşündüm, daha zor bir sahne önerdim ve bana göre yöntemin ne olduğunu da anlattım.
Ne doğruladılar ne de reddettiler, ama ikinci görüşmeye çağırdılar.
İkinci görüşmede kurucu karı-koca CEO/CTO ile konuştum; planları ASIC satmak değil, codec’i gizli tutup ASIC ile DSL tabanlı bir kablo ağı kurarak video dağıtımı yapmaktı.
“Daha iyi bir karbüratör icat edip GM ile rekabet edecek bir otomobil fabrikası kurmaya çalışıyor gibisiniz” dedim; bunu pek iyi karşılamadılar.
Bu hikâyenin H.264 ile bağlantısı, iddialarının “mevcut sıkıştırma sınırına ulaştı; bu yüzden DSL hattı üzerinden yüksek kaliteli video gönderebilecek tek şey bizim codec’imiz” olmasıydı.
Ben sıkıştırıcıların gelişmeye devam edeceğini; öyle olmasa bile evlere daha hızlı internet girdiğinde, aşabileceklerine inandıkları eşiğin kendisinin ortadan kalkacağını söyledim.
Fizik yasaları gereği bir tel üzerinden gönderilebilecek bit hızının bir sınırı olduğunu ve o sınıra zaten ulaşıldığını söylediler.
İş teklifi almadım, zaten istemiyordum da.
Şirket VC parası aldı ama birkaç yıl sonra kapandı; başkaları çok daha verimli codec’ler yaptı ve 2 Mbps internet bağlantısı bir sınır değildi.
Gerçek algoritmada akıllı matematik ve algoritmik güç bolca kullanılmış olmalı; teknik açıdan aptal değillerdi, iş sezgileri eksikti.
Böyle yeniden anlatınca ukala bir her şeyi bilen gibi duruyor, ama hayatımda bir şeye bakıp birkaç saniye içinde gizli sosunu çözdüğüm iki olaydan biriydi.
Aptal olduğum örnekler çok daha fazla.
Algoritma bana hiçbir zaman doğrulanmadı ama silüet artefaktlarına bakınca oldukça açıktı.
MPEG, JPEG gibi görüntüleri küçük bloklar (8x8, 16x16 vb.) halinde sıkıştırır; bu, uzamsal tekrarları kullanabileceği alanı sınırlar ama aynı zamanda o tekrarları bulmanın hesaplama maliyetini de sınırlar.
Onların codec’i, Microsoft’un 1990’ların sonunda Talisman grafik mimarisi için önerdiği şeye benziyordu.
Sabit bloklara bölmek yerine, kare dizisini analiz edip yarı rastgele sınırlara sahip, yapısal olarak tutarlı bölgeler buluyor gibiydi.
Örneğin bir tenis maçında arka plan epey “rijit cisim”e yakındır; kamera pan yaparken bir piksel hareket ederse çevresindeki piksellerin de aynı uzamsal dönüşümü geçirme olasılığı yüksektir.
Oyuncu kareden kareye değişir ama o kütle içinde aydınlatma ve konum arasında korelasyon vardır.
Bu bölgeleri tanımladıktan sonra muhtemelen ilgili bölgenin görüntüsünü JPEG benzeri bir yöntemle sıkıştırıyor, sonraki karede de bir bölgenin bir sonraki kareye nasıl afin dönüşüm ya da daha genel bir dönüşüm geçirdiğini analiz edip birkaç parametreyle kodluyordu.
Bu, sonraki kare tahmininin temeli olur; iyi uyarsa tahmin hatasını düzeltmek için çok fazla bit gerekmez.
VC’lerden 32 milyon dolar yatırım almış ve 2002’de stealth moddan çıkmış.
Sonrasında ne olduğunu bulamadım.
Yazı çok hoş, ama Information Entropy ifadesinin ayrı bir terim gibi yan yana kullanılması, “ATM machine” türü ifadelerin en rahatsız edicilerinden biri.
Yazının kendisi iyi, ama ifade gerçekten çok çarpıcı.
02016’da H.264 birçok ülkede patentlerle sarılı bir sihirdi.
Bugün standart, 02004 Ağustos’unda bir yıllık açık standartlaştırma çalışmasının ardından yayımlanmış durumda; patentler başvuru tarihinden itibaren 20 yıl sürer ve zaten kamuya açıklanmış bir şeyin patenti alınamaz, dolayısıyla çoğu süresi dolmuş ya da birkaç ay içinde dolacak olmalı.
ABD’de kişinin kendi açıklaması için 1 yıllık bir hoşgörü süresi var, ama bir istisna varsa duymayı çok isterim.
userbinator https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264... adresini işaret etmişti, ama oradaki patentlerin çoğunun öncelik tarihi H.264 standardının kesinleşmesinden sonra; bu yüzden H.264’ün kendisini uygulamak için zorunlu olamazlar.
Ancak standartlaştırma sırasında bunun uygulanabilir olduğunun bilinmediği iddia ediliyorsa bilemem; ama bu oldukça ikna gücü düşük bir iddia.
Şaşırtıcı olan, son 20 yılda biraz daha iyi denebilecek şeyler çıkmış olsa da, ffmpeg uygulamalarıyla yaptığım testlere göre çok daha iyi bir şey olmaması.
Patentsiz statüsü garanti altına alınırsa, iyi ya da kötü H.264’ün bir süre daha standart codec olarak iyice yerleşmesi muhtemel görünüyor.
AV1 aynı bant genişliğinde görsel kaliteyi biraz daha iyi veriyor ama çok daha yavaş ve 02018 gibi geç tarihlerde başvurulmuş patentlere de açık.
“Decoder’a rastgele bir frame’e atlaması söylendiği için en yakın I-frame’den başlayıp motion vector deltalarını geçerli frame’e kadar yeniden toplaması gerekiyor, bu yüzden kısa süreliğine duruyor” kısmı 2016’nın hikâyesi.
Günümüzde sebep, YouTube’un senin Firefox kullandığını bilmesi.