Dlaczego procesor “ jest lepszy ” pod względem kodowania niż GPU?

Podlinkowany artykuł nie jest zbyt dobry.

Zwykle jednoprzebiegowe kodowanie szybkości transmisji bitów konwertuje szybkość transmisji na wartość RF z maksymalny limit bitrate i pobiera go stamtąd.

x264 „jednoprzebiegowa kontrola tempa ABR nie jest zaimplementowana jako CRF + limit. Ma rację, że 2 przejścia to zdecydowanie najlepszy sposób na osiągnięcie docelowej szybkości transmisji bitów.

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

On także miesza wątki = 1 z użyciem CUDA, czy coś w tym stylu. Nic dziwnego, że masz pytania, ponieważ to artykuł ma STRASZNE wyjaśnienie. Cały artykuł sprowadza się w zasadzie do: użyj x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, a może użyj trochę filtrowania światła ze skryptem wejściowym AviSynth. Właściwie zaleca ” placebo „. To jest przezabawne. „Nigdy nie widziałem pirackiego pliku zakodowanego za pomocą placebo. (Można to stwierdzić z me=esa lub me=tesa zamiast me=umh dla wszystkich presetów dobrej jakości, aż do veryslow.

Nie wspomina też o 10-bitowej głębi kolorów. kodować i dekodować, ale nawet po konwersji z powrotem do 8-bitowego, uzyskujesz lepszy 8-bitowy SSIM. Większa precyzja wektorów ruchu najwyraźniej pomaga. Pomaga również brak zaokrąglania do całej wartości 8-bitowej. Możesz pomyśleć o 8 -bit na komponent jako hack; kwantyzacja w dziedzinie częstotliwości, a następnie kompresja za pomocą CABAC oznacza, że wyższe współczynniki głębi bitowej nie muszą zajmować więcej miejsca.

(BTW, h. 265 uzyskuje mniejszą korzyść z 10-bitowego kodowania dla 8-bitowego wideo, ponieważ ma już większą precyzję dla wektorów ruchu. Jeśli jest korzyść z używania 10-bitowego x265 dla 8-bitowych wejść wideo, jest on mniejszy niż w przypadku x264. Więc jest mniej prawdopodobne, że kara za prędkość zostanie wyrzucona Byłem tego wart.)

Aby odpowiedzieć na twoje aktualne pytanie:

edit: doom9 znów jest już dostępny, więc uporządkuję link. Przejdź do niego, aby poprawnie zacytować, kto co powiedział.

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

Google zapisuje w pamięci podręcznej tylko głupią wersję drukowaną, która nie pokazuje poprawnie cytatów. Nie jestem do końca pewien, które części tych wiadomości są cudzysłowami, a które przypisywane są samej osobie.

Bardzo nieregularne wzorce rozgałęzień (tryby przeskoku) i manipulacja bitami (kwantyzacja / kodowanie entropii) nie pasują do obecnych procesorów graficznych. IMO jedyne w tej chwili naprawdę dobrą aplikacją są algorytmy pełnego wyszukiwania ME, w końcu jednak przyspieszone pełne wyszukiwanie jest nadal wolne, nawet jeśli jest szybsze niż na CPU.
– 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 tego zrobić równolegle).

x264 CUDA zaimplementuje fullpel i początkowo algorytm subpel ME; później moglibyśmy zrobić coś takiego jak RDO z podejściem do kosztu bitowego ximation zamiast CABAC.

Ponieważ musi robić wszystko na pojedynczej precyzji zmiennoprzecinkowej
– MfA

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

– Dark Shikari

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

AFAIK, ten projekt CUDA się nie powiódł. Istnieje wsparcie dla używania OpenCL do odciążania wątku lookahead (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 wczesnego kończenia ścieżek wyszukiwania na procesorach pokonuje brutalne GPU przynieść do stołu, przynajmniej dla wysokiej jakości kodowania. Porównuje się to tylko z -preset ultrafast, w którym rozsądnie można wybrać kodowanie sprzętowe zamiast x264, zwłaszcza jeśli masz wolny procesor (np. Laptop z dwurdzeniowym i bez hiperwątkowości). CPU (czterordzeniowy i7 z hiperwątkowością), x264 superfast prawdopodobnie będzie równie szybki i wyglądał lepiej (przy tej samej przepływności).

Jeśli robisz kodowanie, w którym zniekształcenie szybkości (jakość w przeliczeniu na rozmiar pliku) ma w ogóle znaczenie, użyj x264 -preset medium lub wolniej. Jeśli tak, ponowne archiwizowanie czegoś, poświęcenie nieco więcej czasu procesora pozwoli teraz zaoszczędzić bajty na tak długo, jak długo przechowujesz ten plik.

uwaga dodatkowa, jeśli kiedykolwiek zobaczysz wiadomości od deadratów na forum wideo, to nie będą 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, które wyszukałem w Google na temat kodowania GPU x264. Najwyraźniej nie rozumie, dlaczego to nie jest łatwe, i kilka razy publikował, aby powiedzieć programistom x264, dlaczego „są głupi …

Aktualizacja 2017:

ffmpeg obsługuje kodowanie wideo h264 i h265 NVENC przyspieszane przez GPU . Możesz wykonać jedno- lub dwuprzebiegowe kodowanie z wybraną jakością dla hevc_nvenc lub h264_nvenc, a nawet z podstawowym procesorem graficznym jest znacznie szybsze niż kodowanie bez akceleracji i kodowanie z akceleracją Intel Quick Sync.

2-przebiegowe kodowanie wysokiej jakości:

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

1-przebiegowe domyślne kodowanie:

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

NVENC ffmpeg – pomoc i opcje:

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 bez akceleracji.

Komentarze

• Użyj go jeśli ponad jakość na rozmiar pliku cenisz szybkość (i niskie zużycie procesora). W niektórych przypadkach, np. przesyłanie strumieniowe do twitcha, ' to to, czego chcesz (szczególnie niskie zużycie procesora). W innych, np. Zakoduj raz, aby utworzyć plik, który będzie przesyłany strumieniowo / oglądany wiele razy, nadal nie jesteś nie pobije -c:v libx264 -preset slower (co nie jest tak wolne, jak prawie w czasie rzeczywistym w rozdzielczości 1920x1080p24 na Skylake i7-6700k).
• Użycie ffmpeg z -vcodec h264_qsv na moim starym notebooku Intel z Intel HD Grpahics 4000 znacznie przyspieszyło renderowanie!

Aby bardziej szczegółowo opowiedzieć o tym, co mówi Piotr, generalnie używanie wielu procesorów pomaga w przypadkach, gdy masz kilka niezależnych zadań, trzeba zrobić, ale nie musisz mieć wzajemnych zależności ani jednego zadania, w którym wykonujesz te same obliczenia na ogromnych ilościach danych.

Jeśli jednak potrzebujesz wyniku obliczenia A jako dane wejściowe do obliczeń B i dane wyjściowe obliczeń B jako dane wejściowe do obliczeń C, nie możesz ich przyspieszyć, wykonując różne podstawowe prace nad każdym zadaniem (A, B lub C), ponieważ nie można rozpocząć aż do zakończenia drugiego.

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

Są też inne kwestie. Może udałoby się znaleźć sposób na zrównoleglenie obliczeń, ale samo odczytanie danych z dysku lub przez sieć lub wysłanie ich do GPU zajmie więcej czasu niż wykonanie obliczeń. W takim przypadku nie ma sensu zrównoleglanie tego, ponieważ samo umieszczenie danych w pamięci zajmuje więcej czasu niż czas, który można zaoszczędzić, wykonując obliczenia równolegle.

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

Komentarze

• O tak, x264 całkiem dobrze pracuje równolegle na procesorach wielordzeniowych. Skaluję prawie liniowo do co najmniej 8 rdzeni, a przyzwoicie nawet powyżej 32. Estymację ruchu można przeprowadzić równolegle, pozostawiając tylko koniecznie szeregową pracę dla innego wątku i podobnych sztuczek.
• Pytanie nie brzmi ' t ogólnie równoległość, w szczególności ' GPU. ' są znacznie bardziej restrykcyjne w kodzie, w którym można je uruchomić niż procesory. Myślę, że ' s, ponieważ możesz ' t mieć kod z gałęziami, które przechodzą w różny sposób w różnych blokach obrazu. Nie ' nie rozumiem dokładnie dlaczego, ale wydaje mi się, że ' to coś takiego. Każdy procesor strumieniowy jest tak prosty i przy tak ograniczonych możliwościach uruchamiania go niezależnie od innych, że albo zawsze musisz czekać na zakończenie najwolniejszego, albo w ogóle masz ograniczone możliwości rozgałęziania, albo jedno i drugie.
• Jeśli masz klaster komputerów (procesory z niezależną pamięcią RAM, które nie ' nie konkurowały ze sobą o przepustowość pamięci i pamięć podręczną procesora), ' d podziel wejściowe wideo na grupy GOP i wyślij sekcje wciąż skompresowanego wejściowego wideo w celu zdekodowania i skompresowania na innych komputerach w klastrze.Zatem tylko skompresowane wideo wejściowe lub wyjściowe musiałoby być przesłane. Jeden wielordzeniowy system współdzielonej pamięci podręcznej / pamięci RAM, jak nawet wielogniazdowa stacja robocza x86, pozwala na jednoczesne działanie wielu wątków na tych samych ramkach. (oznacza również, że nie ' nie potrzebujesz nowego kodu do globalnej kontroli tempa dla kodowania segmentacji).