Rychlost dekódovaní VP8

25.7.2010 18:25 | Přečteno: 1663× | Expresivní zabručení |

Možná jste zaznamenali novou implementaci nedávno otevřeného svobodného formátu VP8 do kodeku (a nebo spíš zatím jen dekodéru) ffvp8, který přichází z dílen společné práce autorů ffmpegu/mplayeru/x264. Samozřejmě jsem si to nemohl nechat uniknout a ihned jsem musel ještě teplou a křupavou implementaci vyzkoušet, zda-li o ní platí to, čím se Jason chlubí aneb nevěřím nikomu.

Úvod

A skutečně tomu tak je. Je to možná komické (společně s některými skutečnostmi o kterých se Jasnon zmiňuje ještě komičtější – dokonce je to lepší než Trnky Brnky a Acciho blogy dohromady), ale konečně od dob uvolnění referenční implementace Googlem pojmenovanou libvpx se VP8 dostalo do takového stavu, kdy je přehratelé i na normálním stolním počítači (ovšem nedělejte si iluze, že se něco takového podaří i v podání Googlu na YouTube – tam se po technické stránce pokazí kompletně všechno, co se vezme do ruky … včetně toho co snad ani pokazit nejde). I tak mi přišla konzumace času procesoru nemalá (rozhodně ne tak malá aby při vzetí věci do ruk Googlem něco takového i na mojí šunčičce mělo nějakou reálnou šanci na fungovaní) a když už jsem byl u toho, tak jsem se rozhodl udělat menší testík či srovnání. Vzal jsem si ovšem Jasonovu radu k srdci a místo tolik diskutované obligátní (a především neexistující) kvality jsem se zaměřil na něco trošičku jiného: Rychlost dekódování.

Nečekejte ovšem nic směrodatného a především se prosím nesnažte výsledek nijak vážněji interpretovat. Udělal jsem si srovnání pro vlastní účely abych získal aspoň nějaký přehled a mohl se začít trošičku orientovat v situaci a jen mi bylo líto aby tyto výsledky skončili společně se zavřením mého textového editoru. To totiž ani za méně než jeden den prostě udělat nejde (a to ještě jen z toho důvodu, že většina binárek se mi na disku už válela a stačilo provést jen svn update && make). To by tedy doufám jako pojištění proti tomu, že někdo bude hulákat, že něco dělám špatně mohlo stačit.

Metodika

Provedl jsem test tří svobodných video-formátů a originálu (ale to jen z důvodů kompletnosti a aby bylo se pro začátek od čeho odrazit). Takže formátů VP8 alias Webm, Ogg Theory, MPEG-1 a originál v podobě MPEG-4 AVC alias h.264. Vzhledem k tomu, že jsem neuvěřitelně líný, snažil jsem překódovávat jen minimálně (ale poněvadž netestujeme komprimační schopnosti jednotlivých kodeků je to i vcelku irelevantní):

• Originál, tedy H.264 v rozlišení 720p a 1080p dostupný přímo na YouTube.
• VP8 kódované pravděpodobně pomocí libvpx dostupný tamtéže jen je potřeba mít aktivovanou podporu HTML5.
• Theora kódovaná pomocí kodeku libtheora 1.1+ 20100314 (Ptalarbvorm) a MPEG-1 pomocí kodeku ffmpeg revize těžko_říct_u_gitu_ale_věřte_že_nic_novějšího_neseženete obojí uploadované na smetišti internetu.

Vycházel jsem z Webm verze, tudíž HD rozlišení rozlišení kolem 1280x720, nominální bitrate videa kolem 2048kbps. Samozřejmě to není u všech úplně přesné, ale přibližně stejné. Vzhledem k tomu, že ale testujeme rychlost dekódování videa na detailech parametrů videa zas tak moc nesejde. Teda aspoň ne u samotného kódování. U dekódování jsem srazil rychlost mého Celeru ze standardních 2.8Ghz na 333Mhz a na tom téže testoval dekódování pomocí Mplayeru, SVN revize 31793 následovně:

/opt/mplayer/bin/mplayer ~/Videa/starcraft_2.[mp4,webm,ogv,mpg] -nosound -quiet -benchmark -vo null

Výsledek

libTheora 1.1+ (Ptalarbvorm):
BENCHMARKs: VC: 276.247s VO:   0.112s A:   0.000s Sys:   3.905s =  280.265s
BENCHMARK%: VC: 98.5667% VO:  0.0399% A:  0.0000% Sys:  1.3934% = 100.0000%
Total: 43.2115  (Y': 42.1755  Cb: 46.5481  Cr: 46.5974)

fftheora:
BENCHMARKs: VC: 279.688s VO:   0.074s A:   0.000s Sys:   3.696s =  283.459s
BENCHMARK%: VC: 98.6699% VO:  0.0261% A:  0.0000% Sys:  1.3040% = 100.0000%

ffvp8:
BENCHMARKs: VC: 601.958s VO:   0.123s A:   0.000s Sys:   4.736s =  606.817s
BENCHMARK%: VC: 99.1993% VO:  0.0202% A:  0.0000% Sys:  0.7805% = 100.0000%

ffh264:
BENCHMARKs: VC: 623.073s VO:   0.119s A:   0.000s Sys:   3.690s =  626.882s
BENCHMARK%: VC: 99.3924% VO:  0.0190% A:  0.0000% Sys:  0.5886% = 100.0000%
 
ffmpeg1:
BENCHMARKs: VC: 121.998s VO:   0.069s A:   0.000s Sys:   3.621s =  125.688s
BENCHMARK%: VC: 97.0643% VO:  0.0550% A:  0.0000% Sys:  2.8806% = 100.0000%
frame= 3746 fps= 11 q=2.0 LPSNR=Y:42.06 U:45.30 V:45.37 *:42.90 size=   42938kB time=156.04 bitrate=2254.2kbits/s

A jak výsledek číst? Každý odstavec začíná jménem kodeku, kterým byl dekódován. Za ním je spousty nesmyslů z nichž nejdůležitější je VC: v sekundách. Znamená procesorový čas jež byl spotřebován při dekódování pro celou délku videa. Pokud si jako příklad vezmeme hned ten první (libTheora) s časem 276.247s, znamená to, že na Celeronu o taktu 333Mhz dekódování nijak nezatěžované režií systému a bez zpomalování způsobeného A/V synchronizací a jakéhokoliv zobrazování výsledku stejně jako bez vlastní režie přehrávače trvalo 276.247s. Vzhledem k tomu, že celková délka traileru je 156.04s, tak dekódování něčeho takového na podobném stroji by fungovalo průměrnou rychlostí 13fps a to ještě bez zobrazování a všeho jiného, takže by jsme se asi na nic nepodívali. Teda rozhodně ne snímek po snímku, což můžu jen potvrdit.

Možná jste si všimli ještě dalších dvou přebytečných řádků u Theory a MPEG-1. Ty tam nejsou omylem. I když jsem řekl, že se nebudu snažit srovnávat zkreslení výsledků, PSNR jsem tam orientačně umístil. A to čistě z toho důvodu, abych poukázal na to, že Ogg Theora ve své nejnovější verzi (libtheora 1.1+ 20100314 (Ptalarbvorm)) jak objektivně, tak hlavně subjektivně ve zkreslení malinko předhání ffmpeg1. Proč? Není dlouho tomu tak nebylo a i když jsem Accimu nelhal, taktně jsem zamlčel (taktně jsem toho zamlčel trochu víc), že u vydání Theory Thusnleda a Theory 1.0 a dřívějších tomu tak úplně nebylo (hlavně subjektivně – i když to záviselo především na rozlišení a bitrate). Otázkou ovšem zůstává zda-li je menší pokrok v kompresních schopnostech u Theory dostatečnou cenou za komplexnost při kódování a hlavně pak dekódování (a to téměř 2,2× větší rychlostí).

Závěr

I když je zrychlení, které se Jason Garrett-Glaserovi a vůbec celému týmu dalších lidí povedlo oproti sr…exkrementu z On2 Technologies (tak nějak se zdá, že oni vůbec s tím vydáváním výsledků trávení komunitě, aby jim technicky dodělala to co banda manažerů jemně řečeno po technické stránce nezvládla a po marketingové do nebes vychvalovala, mají dlouholetou zkušenost) je určitě potěšující, ovšem v případě nasazení do reálného provozu na YouTube bych si moc naděje nedělal. Absolutně netuším, jak mají v plánu něco takového rozběhat na Embedded zařízeních. I když je pravda, že ve srovnání s hulákáním některých jedinců o tom, jak Embedded zařízení vůbec mohou zvládnou něco jiného než h.264, takové obavy vypadají více než směšně. Jednoznačný závěr tedy? Pokud chcete přehrát HD video na Celeronu o 333Mhz, do ničeho jiného než do 19 let starého MPEG-1 v podání ffmpeg1 se ani nepouštějte.

       

Komentáře

[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.