Pierwsza wersja enkodera x265 wydana: czego można się w rzeczywistości spodziewać po kodeku HEVC?

Pomimo wszystkich starań zwolenników otwartych rozwiązań,prawdopodobieństwo tego, że obciążony patentowo kodek wideo H.264zostanie zastąpiony w przyszłości przez kodeki otwarte, takie jakgoogle'owy VP9 czy rozwijany przez Xiph.Org Daala jest corazmniejsze. Wśród dostawców treści jedynym znaczącym, który stosujewideo w formacie WebM jest YouTube, a obiecane wsparcie od Adobe iNvidii dla google'owej technologii nigdy nie nadeszło. Jednocześniewspółpraca organizacji zaangażowanych w prace nad kodekiem H.265(HEVC) doprowadziła w 2013 roku do przełomowych wydarzeń: udało sięukończyć standard (zatwierdzony jako ISO/IEC 23008-2 MPEG-H Part 2przez ITU-T Video Coding Experts Group), a na początku czerwcaudostępnionoza darmo całą specyfikację. To jednak nie koniec – w lipcustarania firmy MultiCoreWare doprowadziły do wydania wersji pre-alfa enkodera HEVC pod nazwą x265.Czy w ogóle potrzebujemy następcy H.264? Kodek ten, mimo swojegowieku, świetnie przecież sobie radzi ze wszystkimi nowościami wtechnologiach wideo: obsługuje obraz stereoskopowy, rozdzielczości 4Kczy częstotliwości rzędu 48-60 FPS. Problem jednak w tym, że kodująctakie formy wideo za pomocą H.264 otrzymujemy pliki wynikowe oogromnych rozmiarach. W czasie, gdy coraz więcej ludzi dysponujekamerami HD i środkami do umieszczania wideo HD w Sieci, znalezieniesposobu na zmniejszenie rozmiarów wideo staje się koniecznością,której zaniedbanie zagrozi udławieniem Internetu petabajtami głupichfilmików w rozdzielczościach 4K. To przede wszystkim (oprócz takichatrakcji jak wsparcie 10-bitowych kanałów kolorów) obiecuje HEVC. [img=hevc-opener]Nie ma oczywiście nic za darmo: mniejsze rozmiary plikówwynikowych oznaczają większe wymogi względem mocy obliczeniowejpotrzebnej do uzyskania wyjściowego obrazu. Np. zamiast systemumakrobloków 16x16 pikseli, stosowanych w H.264, HEVC stosujejednostki kodowania o rozmiarach nawet 64x64 piksele, pozwalajaceefektywnie opisywać mniej złożone obszary. W efekcie czas kodowaniawideo 1080p za pomocą HEVC ma być średnio 5-10 razy dłuższy, niż zużyciem H.264 (na tym samym sprzęcie), dając przy zachowaniu tejsamej jakości plik wyjściowy w teorii przynajmniej 25% mniejszy. [img=HEVC-Encode]Pierwsze wydanie x265, komercyjnego projektu, który dostępny jestjednak też na licencji GPL, i w którego rozwoju biorą udział ludzieodpowiedzialni za rewelacyjny x264, pozwoliło na pierwszą realnąocenę możliwości kodeka HEVC. Co prawda enkoder nie jest jeszcze wstanie zapewnić maksymalnego poziomu kompresji, ani nie zawieraoptymalizacji opracowanych dla x264, ale już teraz wykorzystujerozszerzenia instrukcji procesora takie jak AVX2 czy SSE4.1 Wynikitestów, przeprowadzonych na komputerze z czterordzeniowym (dobraparalelizacja to podstawa dla HEVC) Intelem Core i7-4770K są całkieminteresujące: dla testowego wideo 1080p Kimono1(YUV), udało się uzyskać na razie 1-4 FPS, w zależności odwielkości parametru kwantyzacji. Najistotniejsze dla przyspieszeniakodowania okazały się rozszerzenia SSE3 i SSE4.1, zaś wpływ AVX/AVX2był pomijalny. W porównaniu z kodowaniem do H.264 (przy zachowaniutego samego szczytowego stosunku sygnału do szumu), wielkość plikuwyjściowego była 25-35% mniejsza. Co ciekawe, x265 zapewniał bardziejrównomierne obciążenie CPU, „wyciskając” z testowegoHaswella non-stop 100%, podczas gdy obciążenie robocze dla x264 byłozmienne w czasie.1-4 FPS na jednym z najszybszych core i7 dostępnych na rynku niewygląda jednak za dobrze. Deweloperzy MultiCoreWare zapowiadają, że wkolejnych wydaniach swojego enkodera będą w stanie znacznie poprawićten wynik, tak by docelowo osiągnąć na 16-rdzeniowej maszynie zprocesorami Xeon kodowanie w czasie rzeczywistym – 1080p@30FPS.Pojawiły się też już inne ciekawetesty x265, potwierdzające wartość paralelizacji dla kodowaniawideo: sześciordzeniowy procesor Sandy Bridge 3960X okazał się okilkanaście procent lepszy od czterodzeniowego, nowocześniejszegoHaswella 4770K. Nic więc tylko czekać na wsparcie dla OpenCL, którepowinno się pojawić w niedalekiej przyszłości – powinno onouczynić takie rozwiązania jak architektura HSA (czyli integrowanierdzeni GPU i CPU ze wspólną pamięcią) od AMD idealnym rozwiązaniemdla kodowania do x265.W tej sytuacji realnej alternatywy dla HEVC chyba nie ma. Nawetjeśli Google zacznie forsować VP9 w Sieci poprzez Chrome, Androida iYouTube, to i tak trudno będzie dorównać H.265, który w ciąguostatnich kilku miesięcy zdobył realne poparcie (wyrażone wydaniemodpowiednich produktów) przez firmy takie jak Broadcom, DivX,Mitsubishi, Orange, Quallcom, Imagination Technologies czy LG. Jeśli chcecie sami wypróbować możliwości x265, to instrukcjekompilacji na Linuksa i Windows dostępne są w wikiprojektu.