r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościOPROGRAMOWANIE

Pomimo wszystkich starań zwolenników otwartych rozwiązań, prawdopodobieństwo tego, że obciążony patentowo kodek wideo H.264 zostanie zastąpiony w przyszłości przez kodeki otwarte, takie jak google'owy VP9 czy rozwijany przez Xiph.Org Daala jest coraz mniejsze. Wśród dostawców treści jedynym znaczącym, który stosuje wideo w formacie WebM jest YouTube, a obiecane wsparcie od Adobe i Nvidii dla google'owej technologii nigdy nie nadeszło. Jednocześnie współ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 2 przez ITU-T Video Coding Experts Group), a na początku czerwca udostępniono za darmo całą specyfikację. To jednak nie koniec – w lipcu starania 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 swojego wieku, świetnie przecież sobie radzi ze wszystkimi nowościami w technologiach wideo: obsługuje obraz stereoskopowy, rozdzielczości 4K czy częstotliwości rzędu 48-60 FPS. Problem jednak w tym, że kodując takie formy wideo za pomocą H.264 otrzymujemy pliki wynikowe o ogromnych rozmiarach. W czasie, gdy coraz więcej ludzi dysponuje kamerami HD i środkami do umieszczania wideo HD w Sieci, znalezienie sposobu na zmniejszenie rozmiarów wideo staje się koniecznością, której zaniedbanie zagrozi udławieniem Internetu petabajtami głupich filmików w rozdzielczościach 4K. To przede wszystkim (oprócz takich atrakcji jak wsparcie 10-bitowych kanałów kolorów) obiecuje HEVC.

Nie ma oczywiście nic za darmo: mniejsze rozmiary plików wynikowych oznaczają większe wymogi względem mocy obliczeniowej potrzebnej do uzyskania wyjściowego obrazu. Np. zamiast systemu makrobloków 16x16 pikseli, stosowanych w H.264, HEVC stosuje jednostki kodowania o rozmiarach nawet 64x64 piksele, pozwalajace efektywnie opisywać mniej złożone obszary. W efekcie czas kodowania wideo 1080p za pomocą HEVC ma być średnio 5-10 razy dłuższy, niż z użyciem H.264 (na tym samym sprzęcie), dając przy zachowaniu tej samej jakości plik wyjściowy w teorii przynajmniej 25% mniejszy.

Pierwsze wydanie x265, komercyjnego projektu, który dostępny jest jednak też na licencji GPL, i w którego rozwoju biorą udział ludzie odpowiedzialni za rewelacyjny x264, pozwoliło na pierwszą realną ocenę możliwości kodeka HEVC. Co prawda enkoder nie jest jeszcze w stanie zapewnić maksymalnego poziomu kompresji, ani nie zawiera optymalizacji opracowanych dla x264, ale już teraz wykorzystuje rozszerzenia instrukcji procesora takie jak AVX2 czy SSE4.1

Wyniki testów, przeprowadzonych na komputerze z czterordzeniowym (dobra paralelizacja to podstawa dla HEVC) Intelem Core i7-4770K są całkiem interesujące: dla testowego wideo 1080p Kimono1 (YUV), udało się uzyskać na razie 1-4 FPS, w zależności od wielkości parametru kwantyzacji. Najistotniejsze dla przyspieszenia kodowania okazały się rozszerzenia SSE3 i SSE4.1, zaś wpływ AVX/AVX2 był pomijalny. W porównaniu z kodowaniem do H.264 (przy zachowaniu tego samego szczytowego stosunku sygnału do szumu), wielkość pliku wyjściowego była 25-35% mniejsza. Co ciekawe, x265 zapewniał bardziej równomierne obciążenie CPU, „wyciskając” z testowego Haswella non-stop 100%, podczas gdy obciążenie robocze dla x264 było zmienne w czasie.

1-4 FPS na jednym z najszybszych core i7 dostępnych na rynku nie wygląda jednak za dobrze. Deweloperzy MultiCoreWare zapowiadają, że w kolejnych wydaniach swojego enkodera będą w stanie znacznie poprawić ten wynik, tak by docelowo osiągnąć na 16-rdzeniowej maszynie z procesorami Xeon kodowanie w czasie rzeczywistym – 1080p@30FPS.

Pojawiły się też już inne ciekawe testy x265, potwierdzające wartość paralelizacji dla kodowania wideo: sześciordzeniowy procesor Sandy Bridge 3960X okazał się o kilkanaście procent lepszy od czterodzeniowego, nowocześniejszego Haswella 4770K. Nic więc tylko czekać na wsparcie dla OpenCL, które powinno się pojawić w niedalekiej przyszłości – powinno ono uczynić takie rozwiązania jak architektura HSA (czyli integrowanie rdzeni GPU i CPU ze wspólną pamięcią) od AMD idealnym rozwiązaniem dla kodowania do x265.

W tej sytuacji realnej alternatywy dla HEVC chyba nie ma. Nawet jeśli Google zacznie forsować VP9 w Sieci poprzez Chrome, Androida i YouTube, to i tak trudno będzie dorównać H.265, który w ciągu ostatnich kilku miesięcy zdobył realne poparcie (wyrażone wydaniem odpowiednich 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 instrukcje kompilacji na Linuksa i Windows dostępne są w wiki projektu.

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.