Dlaczego kodowanie VP8 / 9 jest tak wolne w porównaniu do H.264?

Ostatnio chciałem wypróbować kodeki Webm VP8 i VP9, ale kiedy pobierałem ffmpegkodować plik H.264 MP4 do jednego z pozostałych dwóch kodeków, zdałem sobie sprawę, że kodowanie jest (prawie o rząd wielkości) wolniejsze.

Wideo 1080p30 z H.264 na VP9 przy 3 MBit / s jest kodowane z prędkością około 6-7 fps, podczas gdy to samo wideo koduje z około 40 fps do H.264. Użyłem libvpx-vp9kodeka w ffmpegformacie VP9. Otrzymuję te same wyniki dla VP8 i Theory.

Czy ktoś może mi wyjaśnić, dlaczego VP9 jest o wiele wolniejszy? Wypróbowałem inną maszynę, która dała mi podobne powtórki za pomocą hamulca ręcznego.

video ffmpeg video-conversion encoding codec comfreak
źródło

askubuntu.com/questions/270625/...

Ciro Santilli 冠状病毒审查六四事件法轮功

Odpowiedzi:

libvpx-vp9jest znacznie wolniejszym koderem niż, libx264ale domyślne ustawienia wątków w ffmpeg (0 = auto) nie działają w libvpx. Ręczne ustawienie powoduje wzrost prędkości. na przykład

ffmpeg -i in.mp4 -c:v libvpx-vp9 -threads 4 out.mp4

Na 4-rdzeniowym komputerze, gdy koduję strumień H.264 1080-30p, dostaję bump od 3.8 fpsdo 10 fps.

Gyan
źródło

Należy również wspomnieć, że istnieją różne wstępne ustawienia prędkości, tj. -presetDla libx264i -speeddla libvpx-vp9. Zobaczyć ffmpeg -h full. Mogą mieć znaczącą różnicę, ale wpływają również na jakość lub wydajność kompresji.

slhck

Wypróbowałem to na raczej starych maszynach, ale użyłem 4 wątków, ponieważ obie maszyny są czterordzeniowe. Ta -speedopcja nie zrobiła dla mnie ogromnej różnicy

comfreak

@comfreak Zobacz także: developers.google.com/media/vp9/the-basics

slhck

VP9 jest bardziej złożonym kodekiem zapewniającym lepszą kompresję. Współczynnik kompresji / wydajności wideo ma tendencję wykładniczą. Należy oczekiwać, że wymiana VP9 (AV1) będzie jeszcze wolniejsza.

szatmary
źródło

Innymi słowy, nawet jeśli kodek „tylko” zapewnia względnie małą poprawę rozmiaru, może być znacznie wolniejszy? Czy wyniki mam reprezentatywne?

comfreak

@ 9 może być nawet o 50% bardziej wydajny pod względem jakości, @comfreak. Nie nazwałbym tego tak małym. Nie można po prostu porównać wynikowego rozmiaru pliku.

slhck

@slhck: Mówisz więc, że 3 MBit / s może zakodować więcej oryginalnych informacji niż H.264, a zatem niższa przepływność niż materiał źródłowy w H.264 może być opcją przyspieszenia?

comfreak

@comfreak Użycie niższej szybkości transmisji nie spowoduje automatycznego zwiększenia szybkości procesu kodowania. Mówię tylko, że istnieje kompromis między wydajnością kompresji a szybkością, a na przykład wielu dostawców transmisji strumieniowych wolałoby zainwestować czas procesora w tworzenie strumieni o wyższej jakości przy niższej ogólnej przepływności, aby zaoszczędzić miejsce i przepustowość. Użycie bardziej wydajnych kodeków (takich jak VP9 lub HEVC nad H.264) również pomaga w tym zakresie.

slhck

Ale w gruncie rzeczy, jeśli szybkość jest dla Ciebie najważniejszym czynnikiem, powinieneś trzymać się starszych kodeków (np. H.264), mniej wydajnych ustawień wstępnych kompresji, a być może także zajrzeć do kodowania wspomaganego przez GPU, np. Z NVENC.

slhck