H.265 czyli idzie nowe

[kasper93]

a jakich wersji używasz?

Różnych

Zobaczcie sobie tę wersję

32-bit: http://files.1f0.de/lavf/LAVFilters-0.6 ... c3f78b.zip
64-bit: http://files.1f0.de/lavf/LAVFilters-0.6 ... 8b-x64.zip

Powinno być ponad dwa razy szybciej Zależy od pliku, ale jest wiele lepiej.

Podzielcie się linkami do plików, które testujecie, bo też bym zerknął.

[lustracja]

używam jak wiesz MPC-HC 32 bit
nie widzę żadnego zysku. 4k dalej obciążenie 80-90 %.
jakieś ustawienia?

[kasper93]

Jaki plik testujesz to zobaczę u siebie.

Ogólnie ~70% szybciej dla 32bit i ~110% dla 64bit powinno być, ale to też zależy od pliku.

Po za tym 4k na i3 to ciężki orzech do zgryzienia. Ogólnie nie tylko HEVC ;p


EDIT:

Na 4k 33Mbps

x86:
Lentoid ~36fps
LAV ~24fps

x64:
LAV ~48fps

[lustracja]

to znaczy o czym mówisz? o h264 HD?
z tymi to nie ma problemu. robi to grafika. i o tym pisze. bo grafiki do HEVC nie ma.

pliki np.
http://www.libde265.org/hevc-bitstreams ... -tiles.mkv

na i3 30-60% obciążenie procesora ale nie lav=90%

[kasper93]

Faktycznie na tym pliku dobrze widać, że jeszcze potrzeba trochę pracy, acz wersja 64bit jest szybsza od dekodera Lentoid.

LAV x86: 29.3461 FPS
LAV x64: 89.4249 FPS
Lentoid: 81.1206 FPS

Na innym pliku testowym różnice już nie są takie duże.
LAV x86: ~24fps
LAV x64: ~48fps
Lentoid: ~36fps

Jasne jak będzie wsparcie DXVA dla HEVC to zupełnie inna bajka, ale na razie walczymy z tym co mamy Na tę chwilę mi 64bitowa wersja LAV wystarcza i tak nie ma materiałów z prawdziwego zdarzenia, a jak się pojawią to prawdopodobnie nie będą aż tak wymagające jak te sample.

[lustracja]

z niczym nie walczymy bo nic nie ma.
i dopóki nie ma DXVA to sensu brak.
taki mój pogląd.
chyba że piszesz o walce o wzrost wydajności kodeków lav ale dekodowanie software to archaizm
H264 w kombinacji z DVB-T2 a i tak nie mają czym tego wypełnić w sensie treści.
HD h264 można łatwo dekodować i jakość jest DOBRA.
Niech najpierw tak nadają.
Popatrzę co wymyślą w MUX8

[giaur500]

Hmm no jesli te sample które linkowaliście były wg was wymagające to ja czegoś nie rozumiem. Żaden z nich nie był w pełnym 4k dci. Jeśli chcecie przetestować prawdziwy plik 4k to jest film, który ja zrobiłem:

https://mega.co.nz/#!mEtWhaTT!dInLS5oLc ... 2xXVCQW3SY

Parametry:
- average bitrate 15 Mbps
- rozdzielczość 4096x2160
- fps: 24
- kodek: hevc/hev1
- czas trwania: 90 sekund

Źródło to h264/60 Mbps z takimi samymi parametrami obrazu (fps, rozdzielczość). Film wykonany telefonem OnePlus One i przekonwertowany do hev1.

[kasper93]

Nie jest o jakiś bardzo wymagający.

LAV x64: 58.1048 FPS
Lentoid: 47.8750 FPS

Ja głównie testuje na prawdziwych transmisjach z Japonii, podobne wymagania ma do Twojego sampla, o ile dobrze pamiętam miałem coś ponad 56 FPS.

[giaur500]

To by był rzeczywisty plik. Więc tragedii nie ma.

[kasper93]

Dodam tylko, ze to na dość leciwym i7 920 podkręconym do 4GHz z wyłączonym HT, ale to nie wiele daje zysku... A warto zaznaczyć, że ten procesor nie obsługuje instrukcji AVX, a są one wykorzystywane do optymalizacji, więc nie jest to pełna prędkość jaką można wyciągnąć, nawet przy tej samej mocy obliczeniowej.

Dla kontrastu na wolniutkim dwurdzeniowym Celeronie 2955U 1.4GHz http://ark.intel.com/pl/products/75608/ ... e-1_40-GHz daje radę wyciągnąć 14.54 FPS, więc nie ma tragedii i na średniej klasy procesorach powinno działać, zresztą przyjdzie sprzętowe dekodowanie i będzie po problemie nawet na ultrabookach.

[giaur500]

Ja testuję na i7 3770K bez podkręcania. Odtwarzanie przez ffmpeg na Linuksie, obciąża procesor na około 30-35%.

[Maniek99]

Na G550 (2x2,6GHz) i najnowszym MPC-HC wyciąga ~20 klatek.

[giaur500]

Co to znaczy że wyciąga 20 albo 50 klatek? Film jest 24 klatki/sekundę. W przyspieszeniu oglądacie czy jak?

[kasper93]

@Maniek99: Najnowszy MPC-HC ma dość starą wersję dekodera. Możesz sobie podmienić pliki z tej paczki http://forum.emitel.pl/viewtopic.php?p=195316#p195316 powinno być o wiele szybciej.

@giaur500: Przy czystym dekodowaniu nie musisz trzymać się prędkości klatek i jest dekodowany z pełną prędkością na jaką pozwala procesor. Takie porównanie prędkości dekoderów jest bardziej wiarygodne. Ja używam GraphStudioNext do testu. Sam LAV aktualnie jest szybszy od FFmpeg, bo ma przesortowane optymalizacje z openHEVC, które dają niezłego kopa.

[Maniek99]

@kasper93
Rzeczywiście wyraźnie szybciej teraz chodzi, choć na wskaźniku FPS cały czas koło 20.
Trzeba by było chyba jakoś inaczej mierzyć.
W każdym razie na w miarę aktualnej czterordzeniowe powinno chodzić płynnie.

Pozdro

[giaur500]

Sam LAV aktualnie jest szybszy od FFmpeg, bo ma przesortowane optymalizacje z openHEVC, które dają niezłego kopa.

Przeciez OpenHEVC to składnik ffmpega, lav stamtąd to wziął. Ostatnia aktualizacja ffmpega dała niezłego kopa, sprawdź ffplay

[kasper93]

To nie jest takie proste. Oficjalne drzewo FFmpeg nie ma optymalizacji, które miałem na myśli. Natomiast wersja OpenHEVC ma. Open source ma to do sobie, że jest wiele różnych projektów opartych na jednym i nie można tego tak uogólnić. Nie ma co dyskutować, bo jeżeli się tego nie śledzi to i tak się nie załapie co jest gdzie.

[giaur500]

Gdzie można pobrać wersję ffmpeg z OpenHEVC? Tylko nie interesują mnie bianria dla Windowsa, chcę albo źródła do kompilacji albo ewentualnie pakiety/binarki dla Linuksa. Skoro to OpenSource to gdzieś pewnie wystawione na jakimś githubie, masz namiary?

Porównałbym jak sobie radzi xbmc (on też ma swojego forka ffmpega i tego używa), oficjalny ffplay i ta wersja o której piszesz.

[kasper93]

https://github.com/OpenHEVC/FFmpeg/

[giaur500]

Sprawdziłem. Faktycznie jest szybszy przy dekodowaniu, z moich testów wynika że dekoduje o około 10% szybciej niż oficjalna wersja.

Na i7 przy moich testowych plikach oficjalny ffplay obciąża procek na około 25-30%, wersja którą podlinkowałeś max 15-20%, przeciętnie około 15%.