Rychlost dekódovaní VP8 (diskuse)

[kotyz]

no baze, na starejch pc neni nad mpeg1. jediny co mi slo prehrat na mym Pentiu 166 MHz a po upgradu z S3 1 MB na ATi Rage XL 8 nebo 12 MB to ty pecka davalo bez sekani i na celou obrazovku

[Grunt]

no baze, na starejch pc neni nad mpeg1.

No to já pamatuju ještě větší mrdky. Některé dokonce v barevném prostoru PAL8 (např. od Blizzardu, když už jsme u toho Stracraftu … takové ty prokládané potvory co přehrál Penťák 90Mhz a nebo 486 o 100Mhz, které po sobě nestačilo mazat residua – ale jelo to). Docela by mě zajímaly méně komplexní video formáty (jenže si zas nepamatuju, které z nich byly perceptuální a jestli vůbec) a to klidně i než ten MPEG-1.

jediny co mi slo prehrat na mym Pentiu 166 MHz

Jenže dost pochybuju, že v HD. V dobách Pentii II o 300Mhz by to něco takového přehrálo jen těžko. Od těch dob v FFMpeg provedly takové optimalizace, že se to dostalo až sem. A to ještě trošku procesorového prostoru zbývá.

a po upgradu z S3 1 MB na ATi Rage XL 8 nebo 12 MB to ty pecka davalo bez sekani i na celou obrazovku

V tom není problém. Jak se jednou obraz dekóduje do paměti, pak se jen po PCI sběrnici odešle grafice pointer na začátek dat a ta už si to sama pomocí DMA natáhne, překonvertuje z YUV do RGB, přeškáluje a zobrazí, ať je to rozlišení jaké chce. Teda aspoň u Xv nebo nějaké takové odbdoby.

[Grunt]

takové ty prokládané potvory co přehrál Penťák 90Mhz a nebo 486 o 100Mhz, které po sobě nestačilo mazat residua – ale jelo to

Ty jo RAD Game Tools Smacker! Na něj bych málem zapomněl. Ty jo, to bude muset někde sehnat.

[kotyz]

jj, bink a smacker a rad game tools si pamatuju, mel sem ve sbirce par kratkejch filmecku (the hunt a join the empire pokud se dobre pamatuju) s priponou .bik. po archeologickym vyzkumu bych to mozna este nekde na starejch CD nasel ...

[Grunt]

Mně se nějaké ty potvory povalují na disku (třeba Intro z KKND2: Crossfire, trailer na Final Fantasy), ale má to moc mega než abych to uploadoval.

[kotyz]

uloz.to to jisti

[Grunt]

Dej pokoj. To intro do KKND2 má přes 120MB (zvuk je obyčejné PCMko o 22050Hz).

[kotyz]

by me zajimalo jestli to dokaze mplayer prehrat

[Grunt]

Všechno do posledního. Akorát víc procesorového času sežere konverze do YUV420 nebo BGRA než samotné dekódování videa.

[Grunt]

Vlastně vidiš to. Trailery z E3 rok 2001 mám na Publicu. Obsahuje trailer na:

• Duke Nukem Forever (Bink)
• Final Fantasy (SVQ1 s audio formátem co zní pomalu jako adaptivní PCM)
• Hidden & Dangerous 2 (MPEG-1 a Layer-III – ale jaký, z těch dob)
• Medal Of Honor. Alied Assault (to stejné jako FF)
• Warcarft 3 (SVQ1 a nějaký formát co využíval ADPCM)

[kotyz]

jo! per to do me at je po me!

tak koukam ze ty filmecky co sem o nich psal sou vsechny z cee-gee.net, ale ty bink verze odtamtud zmizeli a zustal jen divx aspon ze konecne dokoncili code guardiana!

[kotyz]

tak hovno, hovno, slavny soude. je to sama 404

[kotyz]

a prd, videa tam sou, ale linky sou blbe. staci prepsat url a uz to jede

1. 2. 3.

bink to sice neni, ale i presto ty videa stoji za skouknuti ...

[Grunt]

bink

Tak BINKů mám ještě spousty. Ty se využívají docela donedávna (FarCry, Panzers, THPS 2,… všechno ještě mám – a vlastně také docela nedávno se jejich otevřené dekodéry dostaly do ffmpeg), ale Smacker už ani jeden (ale pamatuju na jednu hru. Taková cipovina. Se to jmenovalo nějak Shogun 2 nebo tak něco a bylo to FPSko nebo RPGčko…to bych chtěl).

[kotyz]

lol, ten final fantasy trailer sem mel ve svy sbirce traileru. tenkrat mi to na 56k modemu stahovalo dve nebo tri hodiny

[kotyz]

jo, The Hunt je na YT, je tam odkaz i na web (cee-gee.net), takze mozna tam porad bude ke stazeni to puvodni video (pokud si vzpominam byla tam divx i bink verze, ale nejsem si tim zas tak uplne jistej). jeste se podivam na to imperium ...

[kotyz]

jj, je mi jasny o cem mluvis, in-game videa. to znam dobre z Total Annihilation a to sme snad i na tom P90 hrali ...

v diablu 1 to snad bylo taky.

[Grunt]

v diablu 1 to snad bylo taky

Trailer na Diablo z instalačního CD Starcraftu byl jeden z památných prokládaných Smacků, které bych chtěl sehnat.

[kotyz]

jestli najdu originalky total annihilation a prepaly diabla 1, tak bych ti naky ty smacky z toho moh vytahnout. ale to ma bracha v pokoji a ten ted pise bakalarku (ve wordu!) a nemuze to nikdy stihnout dokoncit v terminu, takze je moc nasranej kdyz mu tam nekdo vleze ...

[Grunt]

Ty jo, jestli se ti to povede, tak se snad i překonám a někam upnu ty FMVčka z KKND2.

[kotyz]

CD sem nasel, ale je tu nekolik problemu. Takze nejdriv Diablo, vsechny herni data sou zabaleny do .mpq souboru, to nastesti jde na linuxu rozbalit pomoci libmpq+mpq-tools, jenze to by se to muselo dat z toho CD precist, coz nejde (ono uz to puvodni CD bylo dost jety a nejaky data tam byly necitelny, takze ani ta jako-nova-a-skoro-nepouzivana-kopie na tom nemuze bejt lip). No a na CD Total Annihilation je to zase v .hpi, coz nevim cim rozbalit. Jedine zkusit uwarezit nekde ISO toho Diabla a z nej si to vytahnout. Ze to je ve smackeru je jisty, sou tam na ruznejch mistech .dll knihovny na jeho prehrani

[kotyz]

posledni nadeje - dragon unpacker pod wine ...

[kotyz]

tak z toho taky nic nebude. ten unpacker sice pod wine funguje napytel a musel sem ho nekolikrat zakilit, ale .hpi otevrel a nektery soubory i vytlacil (musel sem je vybirat rucne po jednom, pri pokusu o rozbaleni vseho najednou se to pokazdy seklo), nicmene video sem tam nikde nenasel. jinak ta hra samotna celkem dobre funguje pod wine, i to video se mi prehraje, jen nevim kde je schovany a jak ho dostat ven. akorat ze ta hra si prepina rozliseni do nakejch 640x480 tak mi to krapet rozhazi plochu, ale to by se dalo i prezit.

dokonce snad pro TA existuje nejakej novej, plne 3D a jeste ke vsemu opensourcovej engine ...

ze bych si ho po letech zase zahral?

[belisarivs]

Spring

[kotyz]

a taky TA3D, ta vypada vic jako puvodni TA.

[Grunt]

No jo, nezbude mi než si to někde uwarezit. Jsem se pokoušel i hledat samotné .smk na Googlu, ale z toho by se jeden…

[kotyz]

prolez sem vsechny 4 hpicka a zadny smkacko nikde nebylo. u toho diabla sem se nedostal ani k rozbaleni, protoze se to pri kopirovani seklo asi na 195 ze 400 MB ...

[kotyz]

byl sem rychlejsi, ale uspech byl jen castecnej. na CD s Diablem 1 sou ve slozce Extras nejaky 4 .bik videa a ty se nemusi nijak extrahovat a hrajou v mplayeru. i ten .mpq soubor sem rozbalil, ale v nem je asi tisic souboru s priponou .xxx a cert vi co maji bejt zac. neco sou obrazky a neco text, ale video tam ne a ne najit. zkusil sem nejaky z tech nejvetsich predhodit mplayeru ale nic se nestalo ...

ale nekde tam sou, ja to vim! kdyz uz tam je knihovna na prehrani smackeru, tak tam nekde bejt musi!

[kotyz@behemot diablo1]$ mplayer file001474.xxx
MPlayer SVN-r31774-4.5.0 (C) 2000-2010 MPlayer Team
158 audio & 340 video codecs
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing file001474.xxx.
Seek failed
libavformat file format detected.
[smk @ 0x924bdf0] max_analyze_duration reached
[lavf] stream 0: video (smackvid), -vid 0
[lavf] stream 1: audio (smackaud), -aid 0
VIDEO:  [SMK2]  320x156  0bpp  15.002 fps    0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffsmkvid] vfm: ffmpeg (FFmpeg Smacker Video)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 22050 Hz, 1 ch, s16le, 0.0 kbit/0.00% (ratio: 0->44100)
Selected audio codec: [ffsmkaud] afm: ffmpeg (FFmpeg Smacker Audio)
==========================================================================
AO: [alsa] 48000Hz 1ch s16le (2 bytes per sample)
Starting playback...
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
Movie-Aspect is undefined - no prescaling applied.
[swscaler @ 0x8a9b1e0]BICUBIC scaler, from pal8 to yuv420p using MMX2
VO: [xv] 320x156 => 320x156 Planar YV12
A:   0.1 V:   0.0 A-V:  0.101 ct:  0.000   0/  0 ??% ??% ??,?% 0 0


MPlayer interrupted by signal 11 in module: decode video
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.

takze neco bysme uz meli, ale mplayer to neprehraje, jen blikne a konec ...

[Grunt]

Ty jo, já už se na nějaké Smacky vykašlal a radši si udělal svůj kodek, aneb ať žije GIF o 16 barvách.

[kotyz]

tak hd to samozrejme nebylo, ale o to tenkrat vubec neslo. slo o to aby to vubec hralo a dalo se na to koukat.

[kotyz]

ta ATi mela hw akceleraci iDCT a motion compensation, takze s trochu lepsim CPU (tak P 233 MMX) by to davalo i DVD ...

[Grunt]

Tak MPEG-1/2 o 720x576 by Pentium II s MMX a jinými SIMD možná nějak dalo i dneska. No Trailer na Atlantis 3 to sice sekáním, ale dalo. Na to si ještě moc dobře pamatuju.

[kotyz]

jo a cely to bezelo v JAMP na Win 98 SE

[Jendа]

Teda aspoň u Xv nebo nějaké takové odbdoby.

No právě, a do 1 MiB VRAM S3 se to společně se zbytkem desktopu obvykle nevejde, takže se musí používat nějaká SW obluda jako x11.

[Grunt]

No tak je jasné, že implementace Xv u nějaké S3 o 1MB RAM ani nic jiného než SW převodník z YUV do RGB obsahovat snad nemůže.

[Mandarinka]

Co to bylo za celér? Něco na bázi P4? Oni bohužel na tento druh cpu kašlou a netestují s ním, takže úpravy kódu snadno mohou postupně jeho výkon na P4kách zhoršovat. Do jisté míry se to fakticky stává i s K8čkama... No vlastně mám pocit, že nikdo z vývojářů ffmpegu nebo x264 nemá K10, takže...

Ale na Core 2 (65nm i 45nm) a i3/5/7 by to mělo být optimalizované.

[Grunt]

Co to bylo za celér? Něco na bázi P4?

Yup. Jádro Prescott (myslím).

Ale na Core 2 (65nm i 45nm) a i3/5/7 by to mělo být optimalizované.

Jenže ty těžko srazím na 333Mhz abych z toho dostal nějakou přesnost u měření. Ale pořád je to dost nadupané, hlavně díky využití SIMD instrukcí jako je MMX2. Proto uvažuju o ARMu, ať to tak silně neovlivňují kdejaké nadupané optimalizace a kešování, ale ať ukáže každý jak vážně to s komplexností myslel.

[Mandarinka]

Však ono se to dá zkompilovat bez SIMD :) Ale není to moc fér... když jeden kodek by byl vymyšlen tak, aby se dalo (hlavně 128bitové) SSE2 dobře využít, a druhý by si to nějakou posrávkou znemožnil (tuším některé "fíčury" u rv40), tak by se tato jeho chybak bez SIMD neprojevila.

[Grunt]

No i tak. Např. můj Turion při 800Mhz mi mnohem silnější než když nataktuju Celerona na 800Mhz (on mi dokonce přijde i silnější proti Celeronu o 2.6Ghz vzhledem k dvou jádrům), jo ale když nabootuju 386 jádro. Budu muset něco takového ještě sehnat.

[kotyz]

hmm, SSE2 taky nemam

[VSi]

K těm embedded zařízením - dekódování pomocí CPU je u bateriových zařízení podle mě stejně reálně nepoužitelné, i kdyby to výkonově stačilo, protože vždy ten CPU bude dost vytížen, a jeho spotřeba se bude blížit maximu. Proto jsou tam HW implementace dekodérů, a časem se ustavil jako de-facto standard podpora H264. Proto takový iPhone 4 zvládá pokud vím bez problémů dekódovat 720p H264.

I když H264 není pro HW implementaci úplně nejjednodušší, což se projevovalo z počátku vysokou cenou dekódovacích čipů, tak nakonec díky výrobě ve velkém množství (např. DVB-T/S/C přijímače, HD diskové přehrávače, dnes už i TV) ceny spadly. Teoreticky je možné, že se nějakým způsobem VP8 protlačí jako "standard" pro HW dekódovací čipy společně s H264. Možná může být značná část toho HW dekodéru společná.

Dnes některé i celkem levné LCD TV přehrají z disku připojeného přes USB H264 High Profile Level 4.0. A to díky univerzálním dekódovacím čipům např. od Sigma Designs (třeba SMP8642).

[Grunt]

Jednu věc si ovšem neuvědomujete. Ta komplexnost kodeku/formátu IMHO musí nějak ovlivňovat odběr energie. Ten čip není napájen z vesmírné energie a debockovací filtr se HW implementací nijak nevytratí a furt ho někdo musí dělat. Je to jen zákeřnější o to, že u HW čipů nikdo nevidí kolik žerou a spoléhá na ně. Třeba takové C64+ (třeba v TouchBooku) jsou vesměs jednoúčelové procesory, které se dají programovat. A vzhledem k 480Mhz DSPčka moc komplexní mrchy ten TouchBook nepřehraje. U H.264 je třeba jen BaseLine profile, ale takových se k člověku moc nedostane.

Dnes některé i celkem levné LCD TV přehrají z disku připojeného přes USB H264 High Profile Level 4.0.

Mám to na notebooku, ale velice komplexní Blu-Ray Rip u kterého se mi i dvou-jádro potilo dává náš Samsung naprosto bez problémů a za nějaký High-End bych si též nedovolil označit.

[VSi]

Předpokládal jsem, že ten HW čip jistě nějakou spotřebu má. Ale vycházím z prostého srovnání: na některých souborech se zadýchá i slabší Core 2 Duo (což je CPU s celkem dobrým poměrem výkon/spotřeba), a ten samý soubor takovýhle čip dekóduje např. do podoby HDMI signálu bez problémů, a to je bez chladiče, nebo s malinkým pasivem, takže spotřeba řádově menší než to C2D.

Nemám v tom takový přehled, ale domnívám se, že ty čipy např. od Sigma Designs jsou silně optimalizované, takže jejich spotřeba na stejné úloze je menší než u relativně univerzálního programovatelného DSP. A přeci jen, pokud ten čip bude skutečně jednoúčelový pro MPEG-2/MPEG-4 a nic nepůjde programovat, tak bude jeho struktura jednodušší a tím i spotřeba menší.

Tu poslední větu jsem úplně přesně nepochopil...

[Grunt]

Předpokládal jsem, že ten HW čip jistě nějakou spotřebu má. Ale vycházím z prostého srovnání: na některých souborech se zadýchá i slabší Core 2 Duo (což je CPU s celkem dobrým poměrem výkon/spotřeba), a ten samý soubor takovýhle čip dekóduje např. do podoby HDMI signálu bez problémů, a to je bez chladiče, nebo s malinkým pasivem, takže spotřeba řádově menší než to C2D.

Jasně. vše co se snažím říct, že na komplexnosti formátu (popř. kodeku) záleží a že HW off-loading není samo-spásný. Určitě je směšné srovnávat nějaké C2D a HW dekodér, ale i do toho HW dekodéru se ta DCT musí nějak implementovat. Stejně jako de-blocking (jinými slovy, sám se neudělá) a to zabírá tranzistory, zvyšuje produkční cenu a spotřebu. Vše co jsem se snažil říct.

[Acci]

Co má společného „špatně“ nastavený FFmpeg s Googlem?

[Grunt]

Netuším. O čem konkrétním je řeč?

[Acci]

O tomto odkazu, který odkazuješ v článku, který pojednává o „špatně“ nastaveném FFmpegu, který ve výchozím nastavení enkóduje videa svou interní implementací Theory.

[Grunt]

Jo ták. Ne Theory ale Vorbisu. A souvisí to tak, že Google na YouTube samozřejmě tuto rozbitou verzi používal společně s HTML5 (že testovali AoTuV a jiné optimalizované verze Vorbisu a neplácli tam první (a ještě ke všemu rozbitý) krám, který jim přišel pod ruku si nedělám iluze). A to zase doklusala nějaká banda trollů (jeden by se klidně vsadil, že ze smečky nějakých Applistů) a začala nadávat na to jak je Vorbis (oficiálně jeden z nejlepších audio-formátů současné doby) ten největší křáp světa, jak nestojí ani za zlámanou grešli a jak může za skázu celého světa tím, že ho Google nasadil. Takže jen malé vysvětlení, jak se věci měly opravdu.

[Grunt]

Jinak už jsem tady o tom zmínil. Je tam i ukázka u které doporučuju si všimnout cca. 140kbps v tiché pasáži a 30kbps když jsou opravdu potřeba – prostě celý bitrate managment úplně naopak.

[Grunt]

Jinak už jsem tady o tom zmínil.

Jen jsem tehdy nevěděl čím to je a rozbitá implementace u majoritního poskytovatele obsahu by mě teda fakt nenapadla.

[Acci]

Tak podpora WebM na YouTube je v experimentální fázi a proto bych to nepovažoval za nějaký výrazný problém.

[Grunt]

YouTube celý mi přijde tak nějak v experimentální fázi. Zvláštní ovšem, že to nikomu výrazně nebrání nadávat na Vorbis.