Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
MJPEG není základem pro další komprimační formáty. Je to sled obyčejných JPEGů, každý z nich samostatný. Ztrátová komprese je založena na DCT (diskrétní kosinové transformaci), přesně DCT-II. Dekodér obsahuje IDCT (inverzní DCT).
Intraframe (I) u MPEG4, H.264 i H.265 používá sice také v zásadě DCT/IDCT (HT transformaci neboli "integer transform" a další varianty), ale úplně jiné zpracování, o dost složitější. Tedy I-frame není to samé co jednotlivý JPEG. Co mají společné s MJPEGem, že I-frame také obsahuje celý obrázek, ne jenom změny (jako P-frame a B-frame).
Proto se při profesionálním použití používá často proud samých I-frame, protože to pak jde snadno stříhat a neztrácí se tolik kvalita. Pochopitelně, za cenu mnohem vyššího datového toku.
Pokud není u dekodéru specifikováno, jaký datový tok a při jakých konkrétních profilech je schopen stíhat, jedná se prakticky jen o hausunmera. Marketing, nic víc. Takže informace o 60 fps při 4K stojí poněkud na vodě.
Ale je to super, že to ten procesor umí.
Nové formáty používají taky mnohem větší velikosti transformace (až 32x32 u VP9 a HEVC) a mají loopfiltery a intrapredikci, AQ, flexibilní partitions a nakonec také silnější entropy coding (CABAC). Proto je třeba BPG potenciálně o tolik lepší než JPEG.
Přesně tak, nové formáty používají mnoho technik navíc - proti JPEGu, takže jsou sice komprimačně průměrně mnohem úspěšnější, ale také mají o hodně vyšší požadavky na procesorový výkon, i v dekodéru, který je nesouměrně méně náročný než kodér. Je tam spousta proměnných, rychlost kódování i dekódování se hodně liší v závislosti na scéně. Nové formáty jsou pro některé účely špatně použitelné, jsou zaměřeny na filmy - preferují ve scéně jen několik hlavních objektů, ale když mají zabírat třeba celou ulici s mnoha detaily v celém záběru, úspěšnost komprimace mnohokrát klesne a radikálně stoupá požadavek na výkon. Z tohoto důvodu je pro mnoho účelů - třeba CCTV dohledy - stále používán letitý MJPEG, ačkoliv je to vykopávka z pravěku.
Ale nehrozí u něj neočekávané problémy - třeba že se kódování/dekódování najednou přestane stíhat, pokud začnou padat velké sněhové vločky - moc objektů v záběru - následkem čehož se při očekávaném datovém toku "rozpliznou" všechny detaily sledované scény, což se stává u těch sofistikovanějších komprimací. Také reakce na zvýšení šumu v záběru, při špatných světelných podmínkách, může být problém.
Je to složité.
To myslím není úplně pravda. Třeba to s těma vločkama a pozadím je čistě záležitost rate control. Existují sice techniky, které definují, co je ve scéně nejpodstatnější (třeba hlava při videokonferenci) a pak tomu dávají víc bitů, ale to je esperimentální věc, v praxi to žádný enkodér pokud vím nedělá.
To, že u videa v H.264 nebo jiném podobném formátu máte rozmazané pozadí nebo se to rozsype při dešti/sněhu nebo jiné náročné scéně, je čistě efekt nízké bitrate, vůbec to není dáno kompresí, která je i při režimu 100% intra lepší než u jpeg/mjpegu. Kdybyste do toho nalili stejné množství bitů, tak dostanete efekt lepší, tedy pokud není zprasená RC. Jinak třeba při použití x264 s aktivním psy RD a AQ se právě ten efekt rozmazaného pozadí a artefaktů při sněhu/deště/větru už neobjeví, pokud zároveň neomezujete bitrate. Komerčně distribuované video má špičky omzené VBV, takže tam se to stát může, ale je to zase jenom a čistě o bitrate.
Ona se taky dnes už lepší komprese než jpeg používá i ve studiích a pro čistě intra kompresi. Například AVC-Intra a XAVC jsou jak název napovídá 10-bitové H.264 pouze s intra snímky. Ty bitrate jsou tam IIRC 50 nebo 100 Mb/s pro AVC Intra, u xavc už nevím.
Máte pravdu. V podstatě je to tak složitá otázka, že jednoduchá odpověď je nemožná. Na MJPEGu je cenné hlavně to, že je blbuvzdorný a prakticky nic neumí, takže se téměř nedá blbě nastavit. O nějakém dynamickém řízení bitrate se nedá mluvit - pokud se někdo o něco takového pokusí, výsledek je nepoužitelný - takže se to nepoužívá :-)
Jistěže to s vločkami a pozadím je věc rate control - a mnoha dalších věcí. Čím je komprimace složitější, tím více parametrů to má. Problém je v tom, že mnoho komerčních implementací má tyto parametry do určité míry napevno. Zprasená rate control, to je přesně ten výraz.
Samozřejmě, časem JPEG a MJPEG zahyne, ... už jen kvůli omezení v barvách na 8-bit (JPEG2000 se moc nechytil) a nemožnosti HDR. Novější komprimace jsou mnohem lepší - jak píšete. Ale složitější a nastavit je optimálně není věc pro amatéra.
Pro specifické použití je důležitá i otázka latence. U IPB proudů je to zabité tuplem, u I-frame only lepší komprimace/dekomprimace intraframe v H.263, H.264, H.265 trvá déle, je řádově složitější a vyžaduje mnohem více přístupů do paměti. Tohle všechno vede často k tomu, že ačkoliv to nabízí velkou výhodu užšího pásma (lepší komprimace), je to implementačně nepoužitelné.
Např. při použití u konkrétní aplikace trvá komprimace/dekomprimace 0.2ms/0.1ms při MJPEGu, ale 30ms/16ms při H.264 (I only). Takže zpoždění při celém zpracování MJPEG řetězce kamera-snímač-komprimace-přenos-dekomprimace-zobrazení je pod 1ms, kdežto při H.264 je to nepoužitelné. Je to samozřejmě také otázka implementace - kódování/dekódování MJPEGu je řádově mnohem jednodušší - a navíc se dá opravdu snadno a stupidně paralelizovat.
MJPEG zkrátka zdaleka není mrtvý, přes všechny nevýhody. Kdyby se rozšířil o více bitů na kanál, ... aplikace něco tak blbého potřebují.
Me hlavne zajima, kdy - a jakej - notas s tim bude... kdyz se podivam do historie, nejsu moc optimista :\
Ucast prislubili velke firmy. Uz priamo na Computexe bolo vidno modely Toshiby, Lenovo to da do novej Yogy do konca mesiaca, Asus 17 palcovi, 2 Inspirony od Dellka a nejake HPcko.
Na nemeckej stranke uz su na predaj 2 Acery a niekde som zahliadol Lenovo.
http://www.saturn.de/mcs/product/_ACER-Aspire-E-15,48352,241166,2044084....
Tu je 15ka, pri troske hladania na tej istej stranke najdes aj 17ku :) Skutocne to vyzera tak, ze si AMD dalo zalezat :)
AMD si nemůže dovolit vydat Carrizo jako papírovýho draka.
Chyba mi trosicku zrovnanie s konkurenciou, alebo aspon vyjadrenie autora, ci su tieto multimedialne vylepsenia nieco, co by mohlo tieto laptopy predavat.
chýba mi info o podpore 10bitových profiloch h264 aj hevc
10bitové H.264 nebude zcela určitě, to nemá nikdo a asi pro to ani neexistuje snadno licencovatelné IP.
HEVC Main 10 se naopak v grafikách/igp asi uchytí, ale jestli to umí Carrizo, to bych taky rád věděl. Taky tam AMD nikde neuvádí, že to umí 4K rozlišení pro HEVC, jestli jste si v těch slajdech všimli. Takže je možný, že H.265 bude jen pro 1080p.
AMD uvádí explicitně UHD HEVC @60 FPS
Hmm, už to asi vidím taky.
Když jsem to studoval prvně, tak jsem si všiml, že tam všude je něco ve stylu "podpora pro 4K a HEVC", ale nikde přímo "podpora pro 4K HEVC". Ale když jsem se díval teď, tak je pravda, že na slajdu 20 je v tabulce "HEVC ultra HD content" a u toho "smooth playback". Těch 60 FPS při UHD už je tam zase napsané zvlášť, ale celý ten slajd je věnován HEVC, tak snad...
Stejně je ale divné, že jsou ve zbytku prezentace tak opatrní.
Ale zase na druhou stranu, vzhledem k tomu, že UHD Blu-ray vyžaduje 10-bit/4K/60FPS, tak trochu doufám, že zvolili dekodér, který to dokáže dekódovat. Ono s HEVC se počítá hlavně jako s kodekem pro 4K.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.