To me reknete kdo se chce divat na mobilu na ksicht moderatora kterej hejbe pantama????? K cemu me to bude to si to muzu pustit jen jako zvuk omfg.

Sem se prave koukal do kalendare, jestli neni dneska prvniho dubna. No ja nevim jak ostatnim, ale zda se mi to nejak pritazeny za vlasy.

Revoluční komprese ... něco takového už jsem kdysi dávno četl tady http://hackles.org/cgi-bin/archives.pl?request=310

do 1 519 bajtů nejde ulozit ani slusnej obrazek, natoz video.

Pro info, i to jejich logo co je tady u clanku ma 2085B (= je o 30% vetsi nez to jejich 23MB video), pri podobym rozliseni videa je 23MB nekolik minut (bez zvuku samozrejme). Ale jestli to lze nazvat videem ...

Je jasny, ze kdyz vemu obrazek trebas 1024x768 a 90% sceny bude staticky, muzu docilit obrovsky komprese, ale to plati i pro Mpeg4.

Mam takove podezreni ze chlapci z Euclidu skutecne neco vymysleli, ale bohuzel nejakej jejich marketingovej srac se toho chytil a chtel z toho udelat senzaci, coz se mu sice mozna povedlo, ale taky se mu asi jenom tak mimochodem podarilo diskreditovat celou firmu v odbornych kruzich

Mpeg 4 part 2 (H.263) používá bloky 8x8 pixelů. Mpeg 4 part 10 (H.264) používá bloky velikosti 4x4 až 16x16. Čím větší blok, tím vyšší kvalita (nebo nižší datový tok), ale také vyšší výpočetní nároky. Proto pro H.264 je už někdy třeba podpory HW. Pokud by se blok zvětšil třeba na celou plochu, pak se výrazně sníží datový tok. Ale co tohle dokáže dekódovat v reálném čase? Nebo také mohli použít místo klasického DCT původní KLT. Pak by zas bylo třeba pro kompresi nějakého superpočítače. Takže dokud nezprovozní SDTV na notebooku, tak to nemá velké naděje.

2qwer - a este k tomu by to mala byt bezztratova technologia

uprimne,ak to bude co i len 2xlepsie ako xvid,tak je to uspech celkom pekny krok vpred

Myslim si, ze tady se pujde spis cestou analyzy obrazku. Podle toho, ze se jedna o staticke pozadi bych ten proces tipoval na naledujici kroky:
1. Ziskani oblasti zajmu. Protoze se jedna o video, asi budou vyuzivany nejake dynamictejsi algoritmy, jako treba AAM, ktere pomoci elastickeho grafu popisi sledovanou oblast.
2. Redukce poctu uzlu grafu. Timto bodem si pri fazi komprese nejsem uplne jisty, spis bych jeho pouziti videl ve fazi treninku kompresniho algoritmu. Nicmene toto bude mit nejspis nejvznamejsi vliv na pomer velikost/kvalita. Vyuzito PCA ????
3. V podstate pouze popis pohybu uzlu elastickeho grafu. Neco podobneho je bezne k videni v dnesnich pocitacovych hrach, kde jsou videni pouze syntetizovane sceny. Zde jsou videodata generovana na zaklade analyzy realneho vizualniho zaznamu.

Ano. Takto vyznamne redukovat data je teoreticky mozne. Samotny viditelny zaznam pak ale vznika jakymsi renderem extraovanych dat pomoci "kodeku". Ovsem vypocetni narocnost by dle meho nazoru byla hodne vysoka.
Neco podobneho by slo realizovat i u prenosu hlasoveho zaznamu, kdy bychom predpokladali rozsegmentovani promluvy na fonemove znacky a vzduchem by se pak vlastne prenasela pouze komprimovana informace o uzitem fonemu, zakladnim tonu hlasu a rozmery modelu hlasoveho traktu.

v tom případě ale odpadá realiztovatelnost na mobilních telefonech atd.. . jejich výkon je dóóóóóst nízký

Jinak receno teoreticky staci poslat informaci o tom co se na scene deje a na druhe strane to zrekonstruovat :0)

Myslim, ze pho neni daleko od pravdy. Matematicky se da vygenerovat prakticky libovolny objekt, vcetne textur, tim se usetri spousta zbytecnych dat. Pak se uz jenom popisuje chovani takovych objektu v casove ose. Pochopitelne to vyzaduje adekvatni vypocetni vykon.

Pro ilustraci kouknete na toto: http://kk.kema.at/files/kkrieger-beta.zip
Ma to pouze 96kByte a je to takove demo hry-strilecky, neco na zpusob doomu, kde neni nic ulozene vo forme obrazku, ani textury, vse je vygenerovano matematicky vcetne zvuku. A je to dokonce i hratelne :-).

Hmm, takze televizne spravy v par kilobajtoch... A k tomu pre dekoder asi 300 GB databaza vsetkych moderatorov a hercov sveta, kedze ten format bude zmeny v obraze analyzovat v style "kod #0AB9" (zmurknutie praveho oka). :-)

"Videl si vcera spravy? Nejak sa ta <meno moderatorky> divne rozpadala."
"Stiahni si novu databazu, ona bola na plastike, tak ti to nepasuje."

Substance: Ta databaze praveze bude treba pouze pro vytrenovani deskriptoru. Z nich bude ziskan jisty prostor, ktery muze byt dale redukovan a v nemz pak budou tyto xichty zobrazovany.

Proč vymýšlet už vymyšlené. Nejlepší kompresí videa je textový scénář. Dekomprese je hardwarově nenáročná, hardware včetně slovníku vzorů nezbytného pro dekompresi má každý v case na krku, a parser kontejneru se instaluje zdarma v základní škole. :-D

2pho: Jasne, tohle vsecho je realizovatelny, ale jen ve velmi omezenym meritku, bez ohledu na potrebny vypocetni vykon.
I tu texturu musis z neceho vygenerovat, nebo muzes mit jen nejaky matematicky model, ktery ovlivnis parametry, ale tim ziskas vetsinou jen velmi chude moznosti, protoze vsechno bude proste vypadat "podobne". Cim lepe bys chtel obraz matematicky popsat, tim vic modelu potrebujes a tim slozitejsi je vypocet. Ve finale bys nemusel trebas vubec prenaset obraz, stacily by jen vzorce, otazka je, jestli je to to prave.

2All: Prave sem vymyslel jeste lepsi kompresi, ale nejsem skrob popisu vam ji. "Pan prstenu", techto 11B dat obsahuje min 14,5MB (tolik maj ty PDF co mam na disku, jako text to asi bude min), alternativne az 6x 8,5GB komprimovanych informaci :D.

Predpokladam totiz, ze drtiva vetsina (urcite pres 95%) ctenaru zna bud knihu nebo film, tudiz tech 11B staci k prenosu veskere informace (knihy nebo kompletniho filmu). Zbyvajici % jsou akceptovatelne ztraty kvality prenosu.

J: kdyby to bylo, jak rikas, tak by se jednalo pouze o syntezu. Jelikoz jsem je ale na prvnim miste analyza sceny, je textura ziskana z obrazu. Vlastnosti textury jsou pak ziskany pomoci vypoctu koeficientu z redukovaneho prostoru, ve kterem se tradicne realizuji vsechny mozne linearni kombinace, z cehoz vyplzva ze kvalita tedy zalezi na kvalite trenovaci mnoziny.

Tahle "objektova" komprese byla fakt vymyslena davno v minulosti. Velke pouziti to bude mit na malych zarizenich (PDA apod.) ale kodovat takhle cely HDTV film by bylo asi casove dost kriticke :o)

Spirit: Seš naprosto mimo.

1) komprimovat do 576×324 muze jen tydyt protoze to neni delitelne 16-ti a tedy snizuje efektivitu prenosu v techto necelych blocich a tedy celkove snizuje pomer tok/kvalita.
2) reseni teto zahady je jednoduche, h264 zkolaboval protoze byl pri tomto ultra nizkem datovem toku na dne svych vypocetnich schopnosti - kvantizer by musel byt <51 coz je maximum ktery avc umi, je tedy jasne ze tento novy zazrak pracuje s kvantizery se kterymi se dnes nesetkavame respektive je ani zadny kodek nepodporuje, jde proste o optimalizaci na nizke datove toky, pravdepodobne nebude schopny podat kvalitni obraz pri vysokych tocich nebo vybec umet vytvorit video s vysokym datovym tokem, stejne jako h.263 neumi vytvorit vice nez 25Mbit/s pri palu - Q1 takze to bude vypadat nejspis takto - prumerny
kvantizer Q140 a matice o trech urovnich - Q70 Q140 Q350.

Vidím to tak, že mobil bude obsahovat cca 4GB ROM se všemi možnými polohami komentátora a jejich komprimované "video" obsahuje pouze pointery na tyto snímky..... :-)

No nic. To byl jen vtip. Ale třeba to konvertuje video do ansi grafiky, kdo ví? :-)

Rovnake sracky pozuviva asf nie potom moze mat film a par ich aj mam 200M ale pohyblive objekty hlavne plynule sa pohybujuce sa potom zrazu prestanu plynule pohybovat a vyzera to zvlastne aj ked na nejakom pda by to stacilo.

Čau lidi,
podle mých výpočtů mělo zdrojové video 23MB délku 3,33 vteřiny.
Je to možné?

Určitě to půjde i na celovečerní filmy. Jenom takový drobný háček: Bude muset být celý složen ze záběru komentátorů.

Hehe, konečně to někdo odhalil - informační hodnota televizních zpráv, které v MPEGu zaberou přes 23 MB je často skutečně pouhých 1,5kB :-D

Pokud si to predstavuji jako ze tam poslou obrazek komentatora + dalsi snimky jen parametry warpingu, tak to bych rad videl jejich analyzator pro celovecerni film .. i kdyz treba SouthPark by sel takhle zakomprimovat dobre, tak to mozna bude spis na kresleny filmy :-)

Tak jsem vcera testoval jejich prodikt EuclidStudio. Je to jakysi encoder ktery prevede video na ten jejich novy format. Pripravil jsem si 10s video 720x384 bitrate 135 kbps (bez audia) z filmu Pribeh zraloka (takze hodne statickych scen s pevnym pozadim). EuclidStudio jsem nijak nenastavoval, poze natahl video a pustil konverzi. Puvodni soubor ve formatu DivX mel 1,23MB. Po konverzi se vytvoril jakysi soubor "test.624" s velikosti 400KB coz uz je prevedene video. Tento soubor lze zpetne otevrit v EuclidStudio a podivat se na vysledek. Nutno rici ze konverze 10s videa trvala na P4 3GHz skoro 2 hodiny!!! Na vyslednem konverzi jsem nenasel zadne znamky degradace prevedeneho snimku. Kompresni pomer pri zachovani velice dobre kvality je solidni a rozhodne lepsi nez DivX ale nedosahuje takovych vysledku jak je uvadeno. Vysledky ktere uvadeji je skutecne mozne dosahnout ale pouze se stalym statickym pozadim (komentator). Podle mych vypoctu je mozne takto dostat na 1 CD 3 filmy ve velice solidni kvalite.