Dlaczego procesor jest „lepszy” do kodowania niż GPU?

Czytałem ten artykuł i zobaczyłem, że procesor jest lepszy do kompresji wideo niż GPU.

Artykuł mówi tylko, że tak się dzieje, ponieważ procesor może obsługiwać bardziej złożone algorytmy niż GPU, ale chcę bardziej technicznego wyjaśnienia, szukałem w Internecie, ale nic nie znalazłem.

Czy ktoś wie, aby wyjaśnić lub link do strony, którą ja miałam bardziej szczegółowe wyjaśnienie?

Artykuł, który podłączyłeś, nie jest zbyt dobry.

Zwykle kodowanie z pojedynczym przepływem bitrate przekształca bitrate na wartość RF z maksymalnym limitem bitrate i bierze go stamtąd.

Jednoprzebiegowa kontrola ratunkowa ABR x264 nie jest zaimplementowana jako ograniczenie CRF +. Ma jednak rację, że 2-pass jest zdecydowanie najlepszym sposobem na osiągnięcie docelowej przepływności.

I najwyraźniej nie zdaje sobie sprawy, że mógłby uruchomić x264 z wątkami = 3 lub czymś takim, aby zostawić trochę czasu procesora na inne zadania. Lub ustaw priorytet x264 na bardzo niski, aby uzyskać czas procesora, którego nie potrzebuje żadne inne zadanie.

On także miesza wątki = 1 z użyciem CUDA lub czegoś takiego. Nic dziwnego, że masz pytania, ponieważ ten artykuł ma OKAZJNE wyjaśnienie. Cały artykuł w zasadzie sprowadza się do: użyj x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, a może użyj filtrowania światła za pomocą wejściowego skryptu AviSynth. W rzeczywistości zaleca „placebo”. To przezabawne. Nigdy nie widziałem pirackiego pliku zakodowanego za pomocą placebo. (możesz określić z me=esalub me=tesazamiast me=umhwszystkich ustawień wstępnych dobrej jakości, aż do veryslow.

Nie wspomina także o użyciu 10-bitowej głębi kolorów. Wolniej koduje i dekoduje, ale nawet po konwersji z powrotem do 8-bitowego, masz lepszy 8-bitowy SSIM. Najwyraźniej pomaga większa precyzja wektorów ruchu. Pomaga to również nie zaokrąglać do dokładnie 8-bitowej wartości. Możesz myśleć o 8 bitach na komponent jak o szybkim hacku; kwantowanie w dziedzinie częstotliwości, a następnie kompresowanie tego za pomocą CABAC oznacza, że ​​wyższe współczynniki głębi bitowej nie muszą zajmować więcej miejsca.

(BTW, h.265 ma mniejsze korzyści z kodowania 10-bitowego dla 8-bitowego wideo, ponieważ ma już większą precyzję dla wektorów ruchu. Jeśli istnieje korzyść z używania 10-bitowego x265 dla 8-bitowych wejść wideo, jest mniejszy niż z x264. Więc mniej prawdopodobne jest, że kara prędkości będzie tego warta.)

Aby odpowiedzieć na twoje aktualne pytanie:

edytuj: doom9 jest teraz znowu gotowy, więc uporządkuję link. Przejdź do właściwego cytowania, kto powiedział co.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

google buforuje tylko głupią wersję do wydruku, która nie wyświetla poprawnie cytatu. Nie jestem do końca pewien, które części tych wiadomości są cytatami i które są przypisywane samej osobie.

Wysoce nieregularne wzorce rozgałęziania (tryby pomijania) i manipulowanie bitami (kwantyzacja / kodowanie entropijne) nie pasują do obecnych układów GPU. IMO jedyną naprawdę dobrą aplikacją w tej chwili są algorytmy ME pełnego wyszukiwania, ostatecznie przyspieszone pełne wyszukiwanie jest wciąż wolne, nawet jeśli jest szybsze niż na procesorze.
- MfA

Właściwie w zasadzie wszystko można rozsądnie zrobić na GPU, z wyjątkiem CABAC (co można zrobić, po prostu nie można go zrównoleglić).

x264 CUDA początkowo zaimplementuje algorytm ME fullpel i subpel; później moglibyśmy zrobić coś takiego jak RDO z przybliżeniem kosztów nieco zamiast CABAC.

Ponieważ musi robić wszystko z zmiennoprzecinkową pojedynczą precyzją
- MfA

Źle, CUDA obsługuje matematykę całkowitą.

- Dark Shikari

Dark Shikari jest opiekunem x264 i twórcą większości funkcji od około 2007 roku.

AFAIK, ten projekt CUDA się nie sprawdził. Obsługiwane jest używanie OpenCL do odciążania niektórych wątków z wyprzedzającego wątku (szybka decyzja I / P / B, a nie wysokiej jakości końcowe kodowanie ramki).

Rozumiem, że przestrzeń wyszukiwania dla kodowania wideo jest tak duża, że ​​inteligentna heurystyka do wczesnego kończenia ścieżek wyszukiwania w procesorach pokonuje brutalne siły GPU, które przynoszą do tabeli, przynajmniej dla kodowania wysokiej jakości. Jest to porównywane tylko z tym, -preset ultrafastgdzie można rozsądnie wybrać kodowanie HW zamiast x264, szczególnie. jeśli masz powolny procesor (np. laptop z podwójnym rdzeniem i bez hyperthreading). Na szybkim procesorze (czterordzeniowy i7 z hyperthreading) x264 superfastprawdopodobnie będzie tak samo szybki i będzie wyglądał lepiej (przy tej samej przepływności).

Jeśli tworzysz kodowanie, w którym liczy się zniekształcenie szybkości (jakość na rozmiar pliku), powinieneś użyć x264 -preset mediumlub wolniej. Jeśli coś archiwizujesz, poświęcenie nieco więcej czasu procesora pozwoli zaoszczędzić bajty, o ile utrzymasz ten plik w pobliżu.

na marginesie, jeśli kiedykolwiek zobaczysz wiadomości od deadrats na forum wideo, nie będzie to pomocne. Mylił się co do większości rzeczy, o których mówi w każdym wątku, jaki kiedykolwiek widziałem. Jego posty pojawiły się w kilku wątkach, w których przeglądałem kodowanie GPU x264. Najwyraźniej nie rozumie, dlaczego nie jest to łatwe, i napisał kilka razy, aby powiedzieć programistom x264, dlaczego są głupi ...

Aktualizacja 2017:

ffmpeg obsługuje kodowanie wideo akcelerowane przez GPU h264 i h265 NVENC . Możesz wykonać kodowanie 1-przebiegowe lub 2-przebiegowe w wybranej przez ciebie jakości, dla hevc_nvenc lub h264_nvenc, a nawet z kartą graficzną klasy podstawowej jest znacznie szybsze niż kodowanie nieprzyspieszone i kodowanie akcelerowane Intel Quick Sync.

2-przebiegowe kodowanie wysokiej jakości:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4

Domyślne kodowanie 1-przebiegowe:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4

Pomoc i opcje NVENC ffmpeg:

ffmpeg -h encoder=nvenc

Użyj go, jest znacznie szybszy niż kodowanie procesora.

Jeśli nie masz procesora graficznego, możesz użyć kodeka Intel Quick Sync, h264_qsv, hevc_qsv lub mpeg2_qsv, które są również znacznie szybsze niż kodowanie nieprzyspieszone.

Aby rozwinąć nieco dalej to, co mówi Peter, generalnie używanie wielu procesorów pomaga w przypadkach, gdy masz kilka niezależnych zadań, które wszystkie trzeba wykonać, ale nie są od siebie zależne, lub jedno zadanie, w którym wykonujesz to samo matematyka na ogromnych ilościach danych.

Jeśli jednak potrzebujesz danych wyjściowych z obliczeń A jako danych wejściowych do obliczeń B, a danych wyjściowych z obliczeń B jako danych wejściowych do obliczeń C, nie możesz tego przyspieszyć, wykonując inną podstawową pracę dla każdego zadania ( A, B lub C), ponieważ nie można rozpocząć, dopóki drugi się nie skończy.

Jednak nawet w powyższym przypadku możesz zrównoleglić go w inny sposób. Jeśli możesz podzielić dane wejściowe na części, możesz mieć jedną podstawową pracę nad wykonaniem A, następnie B, a następnie C z jedną porcją danych, podczas gdy inny rdzeń działa na zrobieniu A, a następnie B, a następnie C na innej części danych .

Są też inne względy. Może uda ci się znaleźć sposób na zrównoleglenie obliczeń, ale po prostu odczyt danych z dysku lub przez sieć albo przesłanie ich do GPU zajmie więcej czasu niż wykonanie obliczeń. W takim przypadku nie ma sensu zrównoważyć go, ponieważ samo wczytywanie danych do pamięci zajmuje więcej czasu niż zaoszczędzony czas, wykonując obliczenia równolegle.

Innymi słowy, jest to zarówno sztuka, jak i nauka.