Jaderné noviny - Video4Linux2 - 5a (barvy a formáty)

20. 2. 2007 | Robert Krátký | Jaderné noviny | 4009×

Než může aplikace začít pracovat s video zařízením, musí se s ovladačem dohodnout na tom, jak budou video data formátována. Takové dohadování může být docela komplikovaná záležitost, protože 1) podpora formátů v různých typech video hardwaru se dost výrazně liší a 2) provádění převodu formátů v jádře není vítáno.

Pátý díl nepravidelného seriálu o psaní video ovladačů pro Linux. Pokud jste ještě nečetli první díl, možná by stálo zato začít tam.

Než může aplikace začít pracovat s video zařízením, musí se s ovladačem dohodnout na tom, jak budou video data formátována. Takové dohadování může být docela komplikovaná záležitost, protože 1) podpora formátů v různých typech video hardwaru se dost výrazně liší a 2) provádění převodu formátů v jádře není vítáno. Aplikace tedy musí zjistit, které formáty hardware podporuje, a nastavit prostředí tak, aby to všem zúčastněným vyhovovalo. Tento článek se bude zabývat základy popisu formátů; další díl probere API implementované V4L2 ovladači pro dohadování o formátech s aplikacemi.

Prostory barev

Prostor barev [colorspace] je v podstatě koordinační systém pro popis barev. Specifikace V4L2 jich popisuje několik, ale doopravdy používány jsou jen dva:

• V4L2_COLORSPACE_SRGB. Tento prostor barev pokrývá známé n-tice (red, green, blue) [tuples]. Obsahují hodnotu intenzity pro každou z primárních barev, jejichž smícháním vzniká iluze širokého spektra barev. Jak bude vysvětleno níže, RGB hodnoty lze znázorňovat mnoha způsoby.

  Kromě toho pokrývá tento barevný prostor i YUV a YCbCr. Toto znázornění vychází z potřeby mít možnost zobrazovat barevný televizní signál na monochromatických televizích. Takže hodnota Y (neboli "svítivost" [luminance]) je hodnota jasu [brightness]; když je zobrazena samostatně, dostaneme obraz v odstínech šedi. Hodnoty "chrominance" [barevný rozdíl] U a V (neboli Cb a Cr) popisují modré a červené části barvy; zelenou lze odvodit odečtením těchto částí od svítivosti. Převod mezi YUV a RGB však není tak docela prostý; na výběr je z několika vzorců.

  YUV a YCbCr nejsou přesně totéž, i když se ty termíny často používají ve stejném významu.

  
  
• V4L2_COLORSPACE_SMPTE170M je používán pro analogové znázornění barev v televizních signálech NTSC a PAL. TV tunery většinou produkují data v tomto prostoru barev.

Existuje docela dost dalších prostorů barev; většinou jde o varianty standardů souvisejících s televizí. Kompletní seznam najdete ve specifikaci V4L2.

Packed a planar

Jak jsme si řekli, hodnoty pixelů jsou vyjadřovány n-ticemi, které obyčejně obsahují RGB nebo YUV hodnoty. Pro organizaci těchto n-tic do obrazu existují dvě nejčastěji používané metody:

• Packed [spojené, sloučené] formáty ukládají všechny hodnoty jednoho pixelu v paměti dohromady.


• Planar [planární, "ploché"] formáty rozdělují všechny části do samostatných polí. Planar YUV formát tedy bude mít všechny hodnoty Y uloženy postupně v jednom poli, hodnoty U v dalším a hodnoty V ve třetím. Planes [plochy] jsou obvykle uloženy postupně v jediném bufferu, ale není to pravidlo.

Packed formáty se možná používají trochu častěji, především ve spojení s RGB, ale oba druhy lze hardwarem generovat a aplikace je mohou vyžadovat. Pokud video zařízení podporuje jak packed, tak planar formáty, ovladač by je měl uživatelskému prostoru nabízet oba.

Kódy fourcc

Barevné formáty jsou v V4L2 API popsány pomocí mechanismu "fourcc" kódů. Tyto kódy jsou 32bitové hodnoty generované ze čtyř ASCII znaků. Lze s nimi tedy lehce manipulovat a jsou snadno čitelné. Když například vidíte kód barevného formátu 'RGB4', není nutné vyhledávat význam v tabulkách.

Kódy fourcc jsou využívány v mnoha různých případech, z nichž některé jsou starší než Linux. MPlayer je používá interně. Fourcc však označuje pouze mechanismus a neříká nic o tom, jaké kódy jsou vlastně používány - MPlayer má překládací funkci pro převod mezi fourcc kódy a těmi, které používá V4L2.

RGB formáty

V popisech formátů (níže) jsou bajty vždy řazeny podle paměti - na little-endian stroji jsou nejméně významné bajty první. Nejméně významný bit každého bajtu je vpravo; u každého pole barev je nejsvětlejší odstín nejvýznamnější.

Název	fourcc	Byte 0	Byte 1	Byte 2	Byte 3
V4L2_PIX_FORMAT_RGB332	RGB1
V4L2_PIX_FORMAT_RGB444	R444
V4L2_PIX_FORMAT_RGB555	RGB0
V4L2_PIX_FORMAT_RGB565	RGBP
V4L2_PIX_FORMAT_RGB555X	RGBQ
V4L2_PIX_FORMAT_RGB565X	RGBR
V4L2_PIX_FORMAT_BGR24	BGR3
V4L2_PIX_FORMAT_RGB24	RGB3
V4L2_PIX_FORMAT_BGR32	BGR4
V4L2_PIX_FORMAT_RGB32	RGB4
V4L2_PIX_FORMAT_SBGGR8	BA81

Když jsou použity formáty s prázdným místem (v tabulce zobrazena jako šedá políčka), mohou to místo aplikace využít pro alfa hodnotu (průhlednost).

Jedná se o "Bayer" formát, který je obvykle dost blízko opravdovým datům ze senzorů většiny kamer. Zelené hodnoty jsou pro každý pixel, ale modré a červené jen pro každý druhý. V podstatě jde o to, že zelená nese důležitější informace o intenzitě, přičemž červená a modrá jsou - tam, kde chybějí - přes pixely interpolovány. Podobné to bude u YUV formátů.

YUV formáty

Nejprve packed YUV formáty. Klíč pro čtení této tabulky:

= Y (intenzita)

= U (Cb)

= V (Cr)

Název	fourcc	Byte 0	Byte 1	Byte 2	Byte 3
V4L2_PIX_FORMAT_GREY	GREY
V4L2_PIX_FORMAT_YUYV	YUYV
V4L2_PIX_FORMAT_UYVY	UYVY
V4L2_PIX_FORMAT_Y41P	Y41P

Používá se i několik planar YUV formátů. Nemá cenu je všechny vykreslovat - vystačíme si s jedním příkladem. Běžně používaný formát "YUV 4:2:2" (V4L2_PIX_FMT_YUV422, fourcc 422P) využívá tři samostatná pole. Obrázek 4x4 by byl znázorněn takto:

Y plane:
U plane:
V plane:

Stejně jako u formátu Bayer i YUV 4:2:2 má jednu hodnotu U a jednu hodnotu V na každou druhou hodnotu Y; zobrazení obrázku vyžaduje interpolaci chybějících hodnot. Ostatní planar YUV formáty jsou:

• V4L2_PIX_FMT_YUV420: formát YUV 4:2:0, s jednou hodnotou U a jednou hodnotou V na každé 4 hodnoty Y. U a V musí být interpolovány v horizontálním i vertikálním směru. Planes jsou uloženy v pořadí Y-U-V, stejně jako u příkladu výše.


• V4L2_PIX_FMT_YVU420: jako YUV 4:2:0, jen jsou prohozeny pozice polí U a V.


• V4L2_PIX_FMT_YUV410: jediná hodnota U i V na každých šestnáct hodnot Y. Pole jsou v pořadí Y-U-V.


• V4L2_PIX_FMT_YVU410: jediná hodnota U i V na každých šestnáct hodnot Y. Pole jsou v pořadí Y-V-U.

Existuje ještě pár dalších YUV formátů, ale ty se používají jen zřídka; vizte kompletní seznam.

Jiné formáty

Dva další formáty, které se mohou hodit pro některé ovladače:

• V4L2_PIX_FMT_JPEG: neurčitě definovaný JPEG stream; trochu více informací najdete ve ve specifikaci V4L2.


• V4L2_PIX_FMT_MPEG: MPEG stream. Formátu existuje několik variant; práce s nimi bude popsána v některém z dalších dílů.

Kromě toho jsou ještě další formáty, některé proprietární; seznam opět součástí specifikace.

Popis formátů

Když už formátům barev rozumíme, můžeme se podívat na to, jak V4L2 API popisuje formáty obrazu obecně. Hlavní strukturou je struct v4l2_pix_format (definována v <linux/videodev2.h>), která obsahuje tato pole:

• __u32 width: šířka obrázku v pixelech.


• __u32 height: výška obrázku v pixelech.


• __u32 pixelformat: kód fourcc popisující formát obrázku.


• enum v4l2_field field: mnohé zdroje obrázků data prokládají [interlace] - nejdříve jsou přenášeny všechny sudé řádky skenu, které jsou následovány lichýými. Skutečné kamery obyčejně prokládání nepoužívají. V4L2 API aplikacím umožňuje pracovat s prokládanými poli překvapivě mnoha způsoby. Běžné hodnoty jsou V4L2_FIELD_NONE (pole nejsou prokládaná), V4l2_FIELD_TOP (jen vrchní pole) nebo V4L2_FIELD_ANY (je to jedno). Vizte kompletní seznam.


• __u32 bytesperline: počet bajtů mezi dvěma sousedními řádky skenu. Zahrnuje veškerou výplň [padding], kterou může zařízení vyžadovat. U planar formátů tato hodnota popisuje největší (Y) plane.


• __u32 sizeimage: velikost bufferu potřebná k pojmutí celého obrázku.


• enum v4l2_colorspace colorspace: používaný prostor barev.

Dohromady tyto parametry poměrně uceleně popisují buffer video dat. Aplikace může vyplnit strukturu v4l2_pix_format a vyžadovat v podstatě jakýkoliv formát, jaký si vývojář dokáže vymyslet. Na straně ovladače však musí být omezení na formáty, se kterými hardware umí pracovat. Takže každá V4L2 aplikace s ovladačem vyjednává ve snaze najít formát obrazu, který by byl jak podporovaný hardwarem, tak vhodný pro potřeby aplikace. V dalším díle se podíváme na to, jak toto vyjednávání vypadá z pohledu ovladače.

       

Komentáře

[zabza]

K V4L2 nic nemam ...

... ale ten "serialovy" box je hrozny... Vim ze tezko vymyslet neco lepsiho, ale aspon by mohly byt boxy trochu jednotne co se tyce vzhledu. V prohlizeci jsou videt tri boxy zaraz - serialovy, hodnoceni a souvisejici odkazy. Kazdy vypada uplne jinak.

Jsem se lekl, co je to za hruzu, jestli nemam neco spatne nastavene, protoze takovou osklivost jsem na ABC jeste nevidel... tak proto to sem pisu...

[Robert Krátký]

Vím o tom (i když tak strašný mi nepřipadá ). Jen zatím nějak nebyl čas. Mám to v TODO.

[Haaja]

Než může aplikace začít pracovat s video řízením, <- nema to byt zarizenim?

[Robert Krátký]

Jasně