Malé nahlédnutí do tajů komprese videa

Diskuze čtenářů k článku

Jakub Hegenbart  |  16. 04. 2005 02:16  | 

Nejsem si jist, zda to má smysl. Ona už z převodníku snad chodí barva podvzorkovaná (kvůli způsobu přenosu videosignálu, pracujeme samozřejmě v YUV), takže vzorkování 4:4:4 je plýtvání. Násobil bych radši dvěma.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jarda Houska z Rakouska  |  16. 04. 2005 09:29  | 

Ano, barvy muzete zakodovat do barevneho signalu YUV, kde se pocita s tim ze lidske oko je nejcitlivejsi na jasovou slozku obrazu a na barvy uz mene. Takze se pak daji data ulozit 4:2:2, ale rozdil oproti plnemu RGB tu je, takze za uplne bezeztratove kodovani barev to povazovat nelze.

Souhlasím  |  Nesouhlasím  |  Odpovědět
m0rph  |  16. 04. 2005 11:29  | 

Jasne, ale uz vzhledem k tomu, ze se clanek venuje mpegu, se mohli jen tak mimochodem zminit o tom, ze drtiva vetsina videa se koduje v YUV 4:2:0. Rozhodne je znalost tohoto faktu pri praktickem pouzivani videokomprese daleko uzitecnejsi, nez znalost principu hufmannova kodovani.

Souhlasím  |  Nesouhlasím  |  Odpovědět
m0rph  |  16. 04. 2005 11:32  | 

omlouvam se Davidu A. Huffmanovi za zkomoleni jmena

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub Hegenbart  |  16. 04. 2005 17:39  | 

Já barvy _nemusím_ kódovat do YUV. Ony už v YUV jsou. Kromě monitorů s RGB BNC konektory (případně klasický VGa kabel) nevím o přenosu, který by nebyl YUV. Kompozitní, S-video i komponentové video jsou všechno luminance+chrominanční složky. YUV je i ve 4:4:4 vzorkování (resp. v analogovékm ekvivalentu s přenosem barvonosných složek se stejnou šířkou pásma), ale k tomu se smrtelník nedostane.

Jinými slovy, pokud Vám to nedošlo (asi ne), obsah mého sdělení zněl, že když televizní signál ma menší šířku pásma pro barvonosné složky, je 4:4:4 kravina a ne „bezeztrátové kódování“. Že rozumně použitelné digitální formy přenosu dělají totéž (byť v digitální podobě) už ani nepovažuji za potřebné zmiňovat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
JeCh, JeCh  |  17. 04. 2005 20:21  | 

A co takový RGB vstupy/výstupy? Každej solidní přehrávač a televize to umí. Na DVD se zase používá YV12. Tvrdit, YUV je jedinej možnej formát je nesmysl. TV karty dokážou používat RGB. Navíc je tohle nativní formát pro počítače. YUV už je způsob ztrátové komprese.
Vláďa

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub Hegenbart  |  18. 04. 2005 14:56  | 

YUV není žádná ztrátová komprese. YUV nemá co dělat s kompresí. YUV je barevný prostor. Přehrávač a televize můžou umět, co chtějí. Ale studiovou kameru k D1 videu tím nepřipojíte. Skoro mi připadá, jo kdybyste mluvil o kódování digitalizovaných dat, o čemž vůbec není řeč. Pokud to mám ještě jednou zopakovat, tak po dekódování videosignálu mám tři analogové signály – Y, Cr a Cb (viz http://www.quantel.com/domisphere/infopool.nsf/html/774137046A74945880256CD100458059 ), přičemž Cr a Cb mají omezenou šířku pásma a vzorkovat je se stejnou frekvencí jako Y je nesmysl. (A tedy i počítat se třemi bajty na pixle nekomprimovaného videa.) Takže nechápu, kam s tím příspěvkem míříte.

Souhlasím  |  Nesouhlasím  |  Odpovědět
JeCh, JeCh  |  18. 04. 2005 18:56  | 

To asi bude to nedorozumění - já mluvím o kódování barev v digitálním videu na počítači. O tom byl článek. Že se to potom převede do třeba značně nekvalitního kompozitní signálu už je jiná věc. YUV bych označil za ztrátovou kompresi, protože oproti RGB vypouští nějaká dat tak, aby to lidské oko nepoznalo. To samé dělají i všechny ostatní ztrátové komprese.
Potom jsem také poukazoval na to, že plno přístrojů má analogové RGB vstupy/výstupy. Dokonce bych si dovolil tvrdit, že jsou běžnější než YUV.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub Hegenbart  |  19. 04. 2005 13:53  | 

„Že se to potom převede do třeba značně nekvalitního kompozitní signálu“ –> O kompozitním signálu jsem NEMLUVIL. Že je nekvalitni, je jedna věc. Ale i komponentový a S video přenos jsou YUV!

Jak dostanete obraz do elektronické podoby? Snímačem, který __nevzorkuje__ barvu v plné spaciální frekvenci svých pixelů. Proto nemá smysl přenášet ani analogem, ani digitálně barvonosné složky ve stejné šířce pásma jako jas. A pořád ještě vám nedošlo, že mluvím o barevném prostoru YUV, nikoliv o nějakém formátu chunků pro shluky pixelů. Barevný prostor nic nevypouští, je to prostor.

Zřejmě neumíte číst nebo já už nevím co.

Souhlasím  |  Nesouhlasím  |  Odpovědět
radecek, radecek  |  16. 04. 2005 08:18  | 

Obrazek stromu Huffmanova kodovani je chybne. Popis je spravne. Spojit 2 prvky s nejnizsi cetnosti, takze ne 11+19, ale 11+12.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel  |  16. 04. 2005 08:50  | 

1. Chválím, že se autor pokusil širší veřejnosti vysvětlit Huffmanovo kódování. Svůj výklad však zjednodušil natolik, že se v článku objevilo několik chyb.
2. Sloučením dvou uzlů s nejnižší četností vzniká nový uzel. Tento a zbývající uzly se však musí znovu (!) seřadit podle klesající četnosti. Pak následuje nové sloučení a nové seřazení dokud nevznikne jediný uzel.(V příkladu se bude slučovat takto: a+b, e+d, ab+c a abc+ed).
3. Kód znaku je postupností hodnot slučovacích hran na cestě od společného uzlu k výchozímu uzlu znaku. (Pokud horní hranu budeme značit 0 a dolní 1, pak bude kód následovný: c=00, e=10, d=11, b=010, a=011).
4. Kódy znaků jsou různě dlouhé - v příkladu 2 a 3 bity. Nejkratší kódy mají znaky s nejvyšší četností a nejdelší kódy mají znaky, které se vyskytují zřídka. Důležité je, že kód žádného znaku v sobě neobsahuje kód znaku jiného. Tak lze znaky v přijaté postupnosti jednoznačně rozlišovat. Například 01001111 = bad.
5. Porovnání efektivnosti kódování 16 bitů versus 48 bitů u věty "abeced" není korektní. V příkladu se předpokládá, že abeceda bude sestávat pouze z 5 znaků. K tomu stačí, aby každý znak byl vyjádřen třemi bity (2^3 = 8 kombinací > 5 znaků) a ne celým bajtem. Potom je zmíněný poměr 16 bitů versus 18 bitů (6 znaků x 3 bit/znak).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin  |  16. 04. 2005 10:38  | 

Jen doplnim k bodu 4: zadny kod nesmi byt prefixem jineho, ne ze zadny nesmi obsahovat jiny. To si odporuje, kdyz na zacatku oznacis jeden uzel treba 0 a ten druhy 1ckou. To by pak zadny kod nesmel obsahovat 0 ani 1cku :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel  |  16. 04. 2005 15:54  | 

Děkuji Martinovi za upřesnění.
Správná je skutečně formulace, že kód žádného znaku nesmí být předponou (neboli prefixem) jiného kódu.
Například u kódu c=00, e=10, d=11, b=010, a=011 vidíme, že předpona nejdelších kódů (tj. b a a) je 01. Tato dvojice bitů však není kódem žádného znaku a nemůže tak dojít k nejednoznačnému dekódování.
Dekódování výše uvedené postupnosti 01001111 probíhá takto. Dekodér přijme první bit (tj. 0) a podívá se do kódovací tabulky. Zjistí, že samotné nule není přiřazen žádný znak. Čeká tedy na druhý bit. Ten připojí za první a vznikne tak dvojice 01. Nahlédnutím do tabulky opět zjistí, že 01 nereprezentuje žádný znak. Počká proto na třetí bit, čímž získá trojici 010. Z tabulky kódů zjistí, že tato trojice reprezentuje znak b. Stejným způsobem zpracovává následující bity až se dopracuje k výsledku, tj. ke slovu bad.

Souhlasím  |  Nesouhlasím  |  Odpovědět
anywherehome  |  16. 04. 2005 09:55  | 

když tu čtu ty komentáře, tak se jen pozvrzuje pravidlo: kdo umí, ten to dělá, kdo neumí, píše o tom. Ale nejhorší je, že mate neznalé! Pak se nedivme, je tu hromada laiků, kteří melou nesmysle! protože ten, co to umí, si věc nechá pro sebe a nevytvoří brief :(

Souhlasím  |  Nesouhlasím  |  Odpovědět
rmsten  |  16. 04. 2005 13:26  | 

Ano, autor článku píše o něčem, čemu vůbec nerozumí .

Souhlasím  |  Nesouhlasím  |  Odpovědět
notch  |  16. 04. 2005 15:53  | 

Coz je tady ovsem casty jev

Souhlasím  |  Nesouhlasím  |  Odpovědět
David  |  17. 04. 2005 10:39  | 

Naopak rozumprdi, kterých je tady taky celá řada, se omezují na pouhé kritizování. Pro počítačovou veřejnost, která má o dané téma zájem, žádný pořádný článek napsat nedovedou...

Souhlasím  |  Nesouhlasím  |  Odpovědět
anywherehome  |  17. 04. 2005 21:26  | 

jasně, takže já, neznalý, mám být rád za přiblížení tématu, kde sou napsaný nesmysle?!!
máš trochu pokroucený myšlené. Takže podle tebe je lepší, ať tu je spousta blbců, co vědí mnoho, ale blbě? "Non multa, sed multum" asi nikdy nepochopíš, vole

Souhlasím  |  Nesouhlasím  |  Odpovědět
anywherehome  |  17. 04. 2005 21:32  | 

ještě dodám: To teda podle tebe nemůžu být kritický ani na svého učitele?
To je blbost, co? :) Už ti došlo, že si řekl nesmysl? Budeš se bránit a nepřiznáš svou hloupost? :) Překvap nás

Souhlasím  |  Nesouhlasím  |  Odpovědět
RedTop  |  16. 04. 2005 14:03  | 

Odkaz v článku na tento výborný codecpack je chybný, vede na podvržené stránky. Správně je:
http://www.codecguide.com/ nebo http://www.k-litemegacodecpack.com/ (jen redirect na přdchozí).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Lemur  |  16. 04. 2005 14:42  | 

Ja to tak delam uz jakou dobu na grabovani z TV, a jediny problem je, ze to sakra narocne na misto (bezne 30-70GB, jednou i 97GB). Pouzivam rozliseni 384x288 24bit RGB, 25 fps. Se zvukem 44 100 Hz 16 mono PCM (tuner neumi stereo) je to cca. 8 MB/s. Video jsou jen samotne snimky (zadny kontainer) a zvuk se uklada zvlast do WAVu. Disk (120 GB Seagate Baracuda V) to zvlada v pohode.
Dokonce jsem zkousel i 640x480, ale vzrust kvality vzhledem k male kvalite TV signalu nebyl takovy, aby se to vyplatilo (pri pousteni pres TV-Out jsem nepoznal rozdil), a navic, pro 384x288 se nemusi odstranovat prokladani a jak sirka, tak vyska jsou cele nasobky 16 (velikost bloku pro DCT, dulezit pro kompresi). Pokud se vam zda 384x288 malo, tak VHS ma efektivne tak 320x240, a navic je to analogove (a ohraje se). A CD je levnejsii nez VHS kazeta, a pokud je kvalitni a dobre vypalene, vydrzi mnohem vice (a muze se z nej udelat kopie bez ztraty kvality).
Hlavni vyhoda grabovani do RAW formatu je to, ze se komprese dela jednou a jen jednou. Pokud se grabuje do jakehokoliv ztratoveho formatu, pro rekompresi se vzdy snizi kvalita. Pokud ma zdroj vyssi rozliseni a dobro kvalitu (jako treba DVD), propripade s pouzitim dobrych filtru, nebudou artefakty patrne. Navic, vzhledem k tomu, ze zatez CPU je nepatrna, zbyde dost casu na ukladani dat na disk a na pocitaci se da v klidu pracovat (ale nesmi se moc sahat na disk).
U TV signalu je navic prokladani, a pokud se zkomprimuje prokladany signal, tak i pri "odprokladani" (deinterlacingu) jsou jeho zbytky patrne, protoze vsechny metody zalozene na DCT trochu rozmazou obrysy (orezanim vysokych harmonickych - na idealni, zcela ostre hrany je treba nekonecne mnoho harmonickych, pokud se nebere v uvahu kvantovani). Jedine spolehlive reseni je bud deinterlacing jeste pred kompresi, nebo grabovat na 50 fps kazdy pulsnimek zvlast. Obe dve metody jsopu celkem narocne na vykon procesoru (a treba muj tuner nezvladte grabovat >30 fps), ale dneska to uz neni problem. Ale to by melo smysl jen pokud by byl TV signal dostatecne kvalitni (dobra antena nebo kabelovka).
Pro mne ma navic RAW video jeste dalsi vyhodu - je mozne naprosto presne urcit zacatek a konec, popripade vysekat reklamy na frame presne (neexistuji keyframes - kazdy snimek je zcela plnohodnotny). Dokud Nova a Prima nedavaly ty jejich zatraceny oznameni po reklamne (kdo to proboha vymyslel!), byl jsem schopny odstranit reklamu tak, ze to nebylo poznat ani pri pomalem prehravani. Mam vlastni sw, ktery posila pres pipe mencoderu jen ty snimky, ktere vyberu pomoci vlastnio prohlizece RAWu. A na RAW se taky lepe aplikuji filtry, takze video vypada o dost lepe, protoze se odstranuje jen opravdovy sum, a ne ten kvatnizacni z DCT (a HQ denoise filter je v tom opravdu dobry).
Tesim se na digitalni TV - tam budu take ukladad "raw" data, ale ty jsou uz komprimovane, ale pomerne kvalitne. Nejen ze to zabere mene mista, ale odpadnmou problemy s prokladanim a zvukem, a hlavne s A/D konverzi.
Takze zaverem: ukladani RAW videa neni zadna primitivni metoda (tvrdi nekdo, ze fotit do RAWu je primitivni metoda?). Naopak. Je to nejkvalitnejsi zpusob, jak ukladat video, ale je velmi narozny na diskove misto, rychlost disku, souborovy system (ja pouzivam ext3 s data=writeback) a spoustu pameti na opravdu velike buffery (pouzivam 32x2MB bufferu v jadre a 64 buferu na snimky v graberu, tj. celkem cca. 85MB). Ale kdyz porovnam kvalitu z RAWu vuci treba MJPEG (stejna velikost, 98% komprese, taky gigove soubory), RAW je jednoznacne kvalitnejsi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ssssssssss  |  16. 04. 2005 15:34  | 

to je sice vsechno moc hezky, ale v TV stejne neni nic co by stalo za to nahravat.
To si radsi pujcim nejaky DVD nebo jdu za holkama.

Souhlasím  |  Nesouhlasím  |  Odpovědět
aaa  |  16. 04. 2005 15:50  | 

chcete vedet vice:
Zpracování videa ve VirtualDubModu
VirtualDub pro začátečníky

Souhlasím  |  Nesouhlasím  |  Odpovědět
aaa  |  16. 04. 2005 15:51  | 

chcete vedet vice:
http://www.cdr.cz/a/13355 ... Zpracování videa ve VirtualDubModu
http://www.cdr.cz/a/13547 ... VirtualDub pro začátečníky

Souhlasím  |  Nesouhlasím  |  Odpovědět
ui  |  16. 04. 2005 20:09  | 

Ty jsi mel napsat ten clanek a ne ten lamerskej redaktor. Jsi odbornik, narozdil od nej.

Souhlasím  |  Nesouhlasím  |  Odpovědět
JeCh, JeCh  |  17. 04. 2005 20:37  | 

On i autor tohohle příspěvku tam má pár hloupostí. No pár, spíš hodně. My jsme v Evropě a tady je norma PAL, která má 576 (viditelnych) řádků, včetně VHS! Proto nahrávat v ajkymkoliv rozlišení jinym než 768(nebo 720)x576 je ztráta na kvalitě. Navíc z toho vyplývá, že rozměry 640x480 nebo 320x240 jsou zcela zcestný, vycházejí z normy NTSC (USA/Japonsko). Bezztrátový kodeky mají na výstupu stejně kvalitní video jako na vstupu, proto je úplnym nesmylem jejich službu nevyužít. Kromě profláklýho HuffYUV se dají použít třeba Alparysoft, Lagarith, MSU, Snow nebo CorePNG (ten je ale dost pomalej).
Lemur sice správně zmiňuje prokládání, ale už neříká, že pokud budu zachytávat v rozlišení nižšim než 288 řádek, žádný prokládání tam nebude. Pokud bych se dostal kamkoliv mezi 288 a 576, tak prokládání zmršim a už ho nikdy neodstranim. Pokud ale zachovam správně 576 řádek, můžu ve výsledku získat 50 snímků za vteřinu místo 25. To se někdy může hodit. MJPEG kodeky si s prokládánim poradí tak, že komprimujou půlsnímky samostatně, to samé udělá i MPEG-2 a MPEG-4, pokud zaškrtneme příslušný checkbox v enkoderu.
A poslední věc - s nástupem digitální TV půjde kvalita obrazu dolů. Televize se budou snažit nacpat co nejvíc služeb do jednoho multiplexu a nedělam si iluze, že datovej tok 3 Mbps bude běžnou věcí. Navíc doměnka, že zmizí prokládání je zcela zcestná.
Celá problematika je značně složitá a vypíchl jsem jenom ty nejdůležitější nepřesnosti, aby to ostatní nezmátlo. Víc informací můžete najít třeba na mych stránkách - http://jech.webz.cz nebo na http://tvfreak.cz.
Vláďa

Souhlasím  |  Nesouhlasím  |  Odpovědět
Lemur  |  18. 04. 2005 13:30  | 


My jsme v Evropě a tady je norma PAL, která má 576 (viditelnych) řádků, včetně VHS! Proto nahrávat v ajkymkoliv rozlišení jinym než 768(nebo 720)x576 je ztráta na kvalitě. Navíc z toho vyplývá, že rozměry 640x480 nebo 320x240 jsou zcela zcestný, vycházejí z normy NTSC (USA/Japonsko).


Rozmery maji smysl jen pro TV signal. Na pocitaci je to putna, alespon pokud se zachova pomer stran. 320x240 je EFEKTIVNI rozliseni VHS dane zaznamovou technologii (i kdyz je signal v 768x576). Pokud je sirokuhly film, tak je lepsi ho oriznout, protoze prechody do cerne zerou dost pasma (DTC vadi nespojitosti), ktere by slo vyuzit hodnotneji. TV-Out stejne vzdy udela spravny signal, takze u prehravani na pocitaci neni co resit.

Ale je pravda, ze pouzivat jine nez nativni rozliseni (nebo jeho polovinu) nema smysl, protoze scalery capture chipu nejsou nic moc. Proto jsou optimalni rozliseni pro PAL:
384x288 (polovina PALu, zadne prokladani)
768x576 (plny PAL, prokladani)
768x(2x288) na 50 fps, musi se roztahnou, ale neni prokladani
384x(2x288) na 50 fps, neni prokladani, horsi nez predchozi, ale mene dat.


Bezztrátový kodeky mají na výstupu stejně kvalitní video jako na vstupu, proto je úplnym nesmylem jejich službu nevyužít. Kromě profláklýho HuffYUV se dají použít třeba Alparysoft, Lagarith, MSU, Snow nebo CorePNG (ten je ale dost pomalej).


Ano, bezestratove kodeky maji stejnou kvalito jak na vstupu, tak na vystupu. Proto jsou bezestratove . Ale maji i nevyhody:
1) Kodovani on-the-fly je pomerne narocne na vykon procesoru.
2) I tak je to komprese pri nejlepsim 3:1, v praxi (HuffYUV) tak 1.5:1 (asi kvuli sumu). Takze stejne vylezaji gigove soubory. Pro jinak by existovaly stratove kodeky?
A v mem pripad jeste jeden:
3) Nalezeni prislusneho frame je netrivialni, protoze se musi pocitat s nestejnou velikosti a kontainerem. RAW video kontainer nema a vsechny framy jsou stejne dlouhe, takze staci par vypoctu a jeden seek (s 64 offsetem).

S nástupem digitální TV půjde kvalita obrazu dolů.

Pokud by se porovnavala digitalni televize s analogovou, s opravdu kvalitnim a cistym signalem, je jasne, ze analogova bude (alespon teoreticky) lepsi. Ale v praxi je vetsinou signal nekvalitni, takze digitalni televize umozni velmi dobry obraz i na kus dratu na miste, kd eby na analog byla treba olbrimi antena na strechu.
A hlavne - bude mozne nahravat presne v takove kvalite, v jake je puvodni signal, takze odpadne ta nejhosti cast konverze - demodulovani analogoveho signalu a D/A konverze. Navic - prenos signalu na vysilace je digitalni uz dnes, jenom s vyssi bitrate.


Celá problematika je značně složitá a vypíchl jsem jenom ty nejdůležitější nepřesnosti, aby to ostatní nezmátlo. Víc informací můžete najít třeba na mych stránkách - http://jech.webz.cz nebo na http://tvfreak.cz.

Ano, kvalitni grabovani TV signalu je netrivialni. http://tvfreak.cz doporucuji, jsou tam i slusne recenze o hardware. I http://jech.webz.cz jso velmi slusne a navic, musim autora pochvalit za kvalitu XHTML a CSS - zcela validni stranky se bohuzel vidi jen zridka.
Pro plne pochopeni to chce jeste nastudovat samotny TV signal, jak funguje digitalizace, co je (a proc je) prokladani, jak funguji kodeky a proc je u vsech MPEG-based kodeku dulezita delitelnost rozmeru sestnacti (nebo alespon osmi) a proc neni dobre nechavat v snimku cerne okraje (presne vysvetleni je ale docela husta matematika), nebo tzv "bit per pixel" jako meritko kvality pro MPEG4-based kodeky (viz dokumentace MPlayeru, v encoding-tips.txt).



Souhlasím  |  Nesouhlasím  |  Odpovědět
JeCh, JeCh  |  18. 04. 2005 20:07  | 

Uf, to je dlouhá odpověď, nicméně se pustim do námitek, ať vznikne něco konstruktivního.

Signál z VHS má 575 viditelnych řádků a ve vodorovnym směru je to analogovej signál. Nadá se proto říct, že by měl 768x576. Je to analog, nemá horizontální rozlišení. Nicměně efektivně se blíží rozlišení 250x576. 768 nebo 720 je při tomhle pohledu trochu luxus, ale ve výsledku to kvalitě trochu pomůže.

Černý pruhy je samozřejmě vhodný oříznout, pokud teda nedělam DVD. Tam někdy musí bejt. TV-OUT stejně jako DVD zná pouze pměry stran 4:3 a 16:9. Já to řešim tak, že pomocí FFDShow přidávam řerný pruhy na 4:3. Potom do nich třeba taky umisťuju titulky.

co se týká bezztrátovych kodeků a seekování, nemyslim si, že by to mělo nějaký zásadní vliv. Hledání konkrítních snímků nechávam na programu (VirtualDub) a je to rychlé a přesné. Některý dobrý kodeky (FFV1, Lagarith) dávají kompresní poměr 3:1. A jestli má mít moje video 100 GB nebo 300 GB už je dost podstatná věc. Já osobně používam MJPEG, kterej má při vysokej kvalitě kompresi cca 1:10. Ta kvalita je tak dobrá, že to nelze poznat od originálu. Kdysi jsem dokonce dělal porovnání - zdroj -> MPEG-4 a zdroj -> MJPEG -> MPEG-4 a nenašel jsem žádný rozdíly.

No a s digitálem to je přesně tak jak řikáš. Já osobně mam třeba obraz z analogu tragickej a modlim se, ať už přijde digitál. Výhody jsou nesporný. Na druhou stranu právě na faktu, že signál na vysílače jde digitálně už teď je vidět, co s tim dokážou udělat . I na tom ubohym signálu vidim poměrně zřetelně artefakty způsobený kompresí. V práci máme testovací vysílání BBC, jednou tam byl záběr, jak anglická královna vstoupila do sálu a spustily blesky foťáků. Jeden snímek přepálenej další dva normální, potom další zase úplně bílej. No zkrátka MPEG-2 to absolutně nepobral, obraz se rozpadl do nějakych 10-ti obřich kostek a vůbec už nebylo možný poznat, kdo to vlastně vešel. Tohle by se analogu nestalo. Řešenim by bylo používat nějakej buffer, kterej by zpožďoval třeba o 1 vteřinu, ale dovoloval by krátkodobý výkyvy datovýho toku. To ale technologie neumožňuje, jedině se prej používá přesouvání bitrate mezi kanálama na multiplexu podle momentální potřeby. Ve výsledku Ti tak královská rodina zprasí i obraz na dalšich 3 kanálech

K doporučovanym stránkam bych ještě přidal www.doom9.org. Je to sice anglicky, ale mají nejlepší návody a rozumí tomu. Na TVFreak chodim pravidelně a svoje stránky se taky snažim jakž takž udržovat. Nějaký chyby v XHTML tam určitě budou, ale snažim se jich vyvarovat.

Vláďa

Souhlasím  |  Nesouhlasím  |  Odpovědět
KillerZero, KillerZero  |  19. 04. 2005 19:44  | 

Cože? digitální TV nepoužívá ani 1s buffer?

Souhlasím  |  Nesouhlasím  |  Odpovědět
zdeneks, zdeneks  |  16. 04. 2005 23:57  | 

Nechapu smysl vaseho prispevku.
Kodeky maji casto moznost k volbe, ze vstup je prokladany. Po zaskrtnuti policka se koduji dve pulky obrazu zvlast.
Nahravat 50fps je nesmysl, tolik snimku neni. Maximum je 25, dal uz budou drople framy nebo nektere stejne.

Nahravam pomoci kodeku HUFFYUV, ktery je bezztratovy a nabizi kompresni pomer asi 1.3:1 na nejnizsi kvalitu. Zkousel jsem i DivX, ale ten na na plne PAL rozliseni nestiha 25fps. Pouzivam Win98 a FAT32, vypnuty SWAP, buffer ve VirtualDUBu asi 640MB. Na 100GB si mi vejde asi hodina zaznamu. Hodi se to pri prehravani starych videi na CD. Prece nebudu skladovat plny suplik VHS

A propos, v jakem nativnim formatu grabuje tuner obraz? YUV nebo RGB? :-p

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub Hegenbart  |  17. 04. 2005 00:27  | 

Tuner, řekl bych, nic negrabuje. Tuner jen demoduluje RF signál a výsledkem je normální anoalogový YUV videosignál.

Souhlasím  |  Nesouhlasím  |  Odpovědět
zdeneks, zdeneks  |  17. 04. 2005 11:56  | 

Tim 'tuner' jsem mel na mysli kartu v pocitaci. Tedy vcetne AD prevodniku. Ale s tim YUV souhlasim, pokud pocitac dostava digitalni YUV data, pak prevod 'do RAW RGB formatu' je ztratovy. Nehlede na to, ze pak pri kompresi kodeky casto prevadi video opet do YUV, ci jineho barevneho modelu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Lemur  |  18. 04. 2005 12:40  | 

Tuner, řekl bych, nic negrabuje.

Ano, mate pravu. Tuner je analogovy obvod, ktery chytra signal (takova ta plechova stinena pixla s antenim vstupem).
Plny nazev karty je v anglictine capture card, ale v cestine to pak vychazi jako "karta na zachytavani videa", a to zni strasne. Vzdycky si vzpomenu, jak mi kdosi vypravel o muzi, na ktereho jeho zena behem rozvodove hadky hodila z okna video (melo pry 10kg). On ho sice chytil, ale stravil ctrnact dni v nemocnioci a video bylo stejne kaput.
Takze pokud je kontext jasny, pouziva se vetsinou jen nazev TV tuner nebo TV karta, nebo jen tuner.

Souhlasím  |  Nesouhlasím  |  Odpovědět
BoodOk  |  18. 04. 2005 12:35  | 

Stravil jsem problematikou prepisu z VHS do DVD tolik casu a experimentovani, ze jsem si na to radeji poridil DVD rekorder a usetril si spoustu boleni hlavy. Tudiz mam behem tydne prepsanych asi 30 kazet, vc. jejich rozcleneni do kapitol v naprosto dostacujici kvalite. Nevim sice v jakem datovem toku, ale je mi to ted uz sumafuk. S temi 100G na 1h zaznamu to je sranda, protoze, kdyz stahuju DV z digitalni kamery, dostavam 13G na 1h. Clovek se na PC proste zene za co nejlepsi kvalitou, ale stoji to spoustu casu a nakonec je to furt jen experimentovani a experimentovani. Napr. 30 kazet je cca 100hod. zaznamu. A ted, kdyz si predstavim, ze musim 100x otocit 100G dat a stale byt na pochybach, jestli jsem vsechny parametry nastavil absolutne dokonale ... znam lepsi zpusob traveni casu. Tim ale nijak nechci shazovat co delate, nakonec Vam to mozna vyhovuje, jen popisuji, k cemu jsem nakonec dospel ja.

Souhlasím  |  Nesouhlasím  |  Odpovědět
fox  |  16. 04. 2005 17:34  | 

Vlastní algoritmus funguje na podobném principu jako bezztrátová JPEG komprese... jpeg je ztrátová komprese :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
medvidek  |  16. 04. 2005 20:41  | 

Aaaa, pan je zrejme odbornik... Bezstratova JPEG komprese je soucasti JPEG standardu. Vice viz. napr. http://www.faqs.org/faqs/jpeg-faq/part1/ otazka (a zejmena odpoved :) 13.

Souhlasím  |  Nesouhlasím  |  Odpovědět
medvidek  |  16. 04. 2005 20:43  | 

Bezstratova - samozrejme mysleno Bezztratova. Fuj, davam si facku. Kazdopadne to nic nemeni na tom, ze bezztratova JPEG komprese je soucasti JPEG standardu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
VaK  |  17. 04. 2005 10:12  | 

Obávám se, že už musím v zájmu "boji proti nebetyčné blbosti" reagovat, protože JPEG formát je skutečně typickým zástupcem ztrátových formátů (bez ohledu na to, zda používá i některý z mechanizmů bezeztrátového formátu). Typickým zástupcem bezeztrátových formátů jsou např. formáty GIF nebo PNG. MP3 je také ztrátový. Každý uživatel, který se s těmito formáty setkal ví, že čím vyšší zadá kompresi, tím horší výsledek z hlediska kvality dostane. 
Na uvedeném odkazu http://www.faqs.org/faqs/jpeg-faq/part1/ jsou uvedeny otázky k "lossless rotation and cropping of JPEGs", tj. bezeztrátové rotaci a ořezávání, protože JPEG je tak ztrátový, že běžně "ztrácí" i při těchto jednoduchých operacích. Jinak je zde o něco dál správně vysvětleno, že "JPEG is "lossy," meaning that the decompressed image isn't quite the same as
the one you started with. ", tj. že JPEG je ztrátový, tz. že dekomprimovaný obrázek není úplně stejný jako ten, se kterým začal.
Základní myšlenku JPEG komprese lze vzdáleně přirovnat postupu používaném pro omezení šířky přenosového pásma ve sdělovacích zařízeních. Největší nároky na šířku pásma mají rychlé změny (tj. akusticky vysoké tóny) a proto se v případech kde je pásmo omezeno (telefony, osobní vysílače, rádia dlouhých až krátkých vln a pod.) potlačují. Stejně tak se v JPEG potlačují rychlé změny jasu a barvy, obrázek se při malé kompresi jakoby trochu rozostří a při větších kompresích se začnou objevovat další chyby, zejména obrysy a mozaikování. To je logickým důsledkem postupu, při kterém se snímek rozdělí rastrem (tj. ta občas viditelná mozaika) aplikuje se na každý prvek rastru de facto fourierova transformace, která rozloží průběhy jasu a barvy na sinusové signály s různou frekvencí, pak se vypustí sinusové signály s vysokou frekvencí a to úměrně zvolené kompresi. Důsledkem použití rozkladu pomocí sinu jsou právě známé obrysy kontrastních přechodů.
JPEG komprese je použita při MPEG kompresi a tak můžeme tyto vlastnosti vidět i u ní.

Souhlasím  |  Nesouhlasím  |  Odpovědět
medvidek  |  17. 04. 2005 11:09  | 

Ach jo, cetl jste aspon tu odpoved 13???

"There's a great deal of confusion on this subject, which is not surprising
because there are several different compression methods all known as "JPEG".
The commonly used method is "baseline JPEG" (or its variant "progressive
JPEG"). The same ISO standard also defines a very different method called
"lossless JPEG". [...] When I say "lossless", I mean mathematically lossless: a lossless
compression algorithm is one that guarantees its decompressed output is
bit-for-bit identical to the original input"

Takze bezztratovy jpeg proste existuje a netvrdte, ze ne. Je ovsem pravda, ze se prakticky nepouziva (coz je ostatne uvedeno v te same odpovedi dale), o to se rozhodne nepru.

Souhlasím  |  Nesouhlasím  |  Odpovědět
VaK  |  17. 04. 2005 12:45  | 

Vaše odpověď je postavena tak, že obhajujete článek. V článku se píše o "bezeztrátovém" JPEG, MP3, a MPEG. Žádná z těchto kompresních metod není bezeztrátová minimálně v aplikacích, které uživatelé běžně používají a které podporují jejich aplikace. Pokud si někdo článek přečetl, musel nabýt dojmu, že to co zná pod označením JPEG, MP3, a MPEG je bezeztrátově komprimováno, a to je hloupost. Na tom příliš ani nemění to, že kdysi byl vyvinut i bezeztrátový JPEG, který se ale již prakticky nepoužívá.
Chci tedy jenom říci, vážení čtenáři, bezeztrátové formáty jsou např. ZIP, RAR, GIF, TIFF, PNG, RAW. Formáty MP3, JPEG, MPEG jsou ztrátové, i když byl kdysi byl vyvinut dnes již nepoužívaný bezeztrátový JPEG.
 

Souhlasím  |  Nesouhlasím  |  Odpovědět
KillerZero, KillerZero  |  17. 04. 2005 17:26  | 

O bezztrátovém MP3 ani MPEG se tam nic nepíše.
TIFF podporuje i ztrátovou kompresi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
VaK  |  17. 04. 2005 23:09  | 

1) Reagoval jsem pouze na větu: „Huffmanovo kódování bylo navrženo přibližně v polovině minulého století a stále patří mezi nejpoužívanější bezztrátové komprese. Své využití toto kódování už našlo v JPEG, MP3, PKZIP (metoda deflate) a mnoha multimediálních kodecích.“ Sice tu není přímo napsáno, že JPEG, MP3, PKZIP jsou bezeztrátová kódování, ale minimálně to navozuje, proto si myslím, že to stálo za komentář. Uznávám však, že MPEG tu není.

2) O tom, že TIFF podporuje i ztrátovou kompresi jsem nikdy neslyšel a ani pro prohledání internetu (www.google.com/search?hl=cs&lr=&oi=defmore&q=define:TIFF) jsem nic podobného nenašel. Můžete mi sdělit, kde se skrývá definice ztrátového TIFF?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mirek  |  17. 04. 2005 23:22  | 

TIFF 6.0 podporuje i JPEG kompresi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
KillerZero, KillerZero  |  18. 04. 2005 19:35  | 

1) Mě to připadá naprosto jasný. Když se ti to nelíbí, tak piš sám. Mimochodem, když už tak kritizuješ, tak z toho tvýho přízpěvkuse zdá, jako by PKZIP byl ztrátový.
2) Už tu za mě někdo odpověděl. Mimochodem, už na prvním odkazu z google (http://home.earthlink.net/~ritter/tiff/) by ses to dozvěděl.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub Hegenbart  |  17. 04. 2005 21:49  | 

Ale no tak, nedělejte si z nás srandu. Jestliže ISO standard používá termín „lossless JPEG“ pro bezeztrátovou modifikaci běžně ztrátového algoritmu, _bude_ tento termín do češtiny přeložen jako „bezeztrátový JPEG“. Nebo budete kritizovat ISO normu za její terminologii, stejně jako toho, komu právě odpovídáte? Myslím, že uživatelé nejsou tak hloupí, jak se snažíte předestřít.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Shottoush  |  16. 04. 2005 20:58  | 

Autor patrně poukazoval na fakt, že při jpeg kompresi, která sestává z několika po sobě jdoucích komprimačních metod, se v závěru aplikuje bezstrátová komprese založená také na principu přiřazení nejkratšího kódu nejčetnějšímu znaku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Shottoush  |  16. 04. 2005 21:03  | 

Omlouvam se za "bezstratovost" i za to, že jsem si před svou reakcí nerefrešoval prohlížeč :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
MM_tank, MM_tank  |  17. 04. 2005 23:56  | 

odkaz na ten K-Lite codec pack stojí zahovno, je to nějaká stránka prolezlá kdoví čím asi podobná kazza.cz. Se dívím že autor to sem klidně hodí. Fuj! To vypadá v životě to z tama nestahoval. Tu je normální link http://www.codecguide.com/

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Test 9 bezdrátových reproduktorů

Jak ovládnout Instagram

Test levných 27" herních monitorů

Jak se zbavit nepotřebných věcí na internetu