Jaderné noviny - Video4Linux2 - 6a (základní I/O snímků)

1. 8. 2007 | Robert Krátký | Jaderné noviny | 3358×

Ačkoliv tento seriál o video ovladačích běží už nějaký čas, ještě jsme nepřenesli ani jediný snímek video dat. V tuto chvíli už však máme probráno dost podrobností o vybírání formátu, takže se můžeme pustit do toho, jak se mezi aplikací a zařízením pohybují video snímky.

Video4Linux2 API definuje tři různé způsoby přenosu video snímků, z nichž dva už jsou v současné implementaci k dispozici:

Systémová volání read() a write() mohou být použita běžným způsobem. V závislosti na hardwaru a implementaci ovladače může být tato technika poměrně pomalá - ale není to jediný způsob.

Snímky mohou být streamovány přímo z a do bufferů, ke kterým má aplikace přístup. Streamování je obyčejně nejúčinnější způsob přenosu video dat; toto rozhraní také umožňuje přenášet spolu se snímky užitečná metadata. Existují dvě varianty streamovací techniky - rozlišují se podle toho, jestli jsou buffery umístěny v jaderném nebo uživatelském prostoru.

Specifikace Video4Linux2 API obsahuje i asynchronní I/O mechanismus pro přenos snímků. Tento režim však zatím nebyl implementován, a nemůže být používán.

V tomto díle se podíváme na jednoduché rozhraní read() a write(); streamované přenosy budou tématem dalšího dílu.

read() a write()

link

Implementace read() a write() není specifikací Video4Linux2 vyžadována. Ale mnohé jednodušší aplikace očekávají, že budou tato systémová volání k dispozici, takže by autor ovladače měl zařídit, aby fungovala. Pokud ovladač tato volání podporuje, neměl by zapomenout reagovat na volání VIDIOC_QUERYCAP (vizte část 3) nastavením bitu V4L2_CAP_READWRITE. Většina aplikací se však neobtěžuje kontrolovat, jestli jsou volání dostupná, než se je pokusí použít.

Ovladačové metody read() a write() musejí být uloženy v poli fops příslušné struktury video_device. Nezapomeňte, že specifikace Video4Linux2 vyžaduje, aby ovladače, které implementují tyto metody, poskytovaly i operaci poll().

Naivní implementace read() na zařízení pro zachytávání snímků je jednoduchá: ovladač řekne hardwaru, ať začne zachytávat snímky, jeden doručí do bufferu v uživatelském prostoru, zastaví hardware a znovu. Je-li to možné, tak by měl ovladač zařídit, aby DMA operace přenášela data přímo do cílového bufferu, ale to jde pouze v případě, že řadič umí scatter/gather I/O. Jinak bude muset ovladač snímek bufferovat přes jádro. Stejně tak zápisové operace by měly jít, pokud možno, přímo na zařízení - jinak budou bufferovány přes jádro.

Implementace však nemusí být tak jednoduchá. Například ovladač "Cafe" od Jonathana Corbeta ponechává řadič kamery běžet po operaci read() ve spekulativním režimu. Po další zlomek vteřiny budou následující snímky z kamery bufferovány v jádře; pokud aplikace provede další volání read(), bude jí vyhověno mnohem rychleji, bez nutnosti znovu startovat hardware. Po několika nevyžádaných snímcích je řadič vrácen do klidového stavu. Podobně by mohla i operace write() pozdržet o pár desítek milisekund první snímek, aby se aplikaci pomohlo snímky streamovat rychlostí, kterou hardware očekává.

Parametry streamování

link

ioctl() volání VIDIOC_G_PARM a VIDIOC_S_PARM upravují některé parametry, které jsou specifické pro implementace read() a write() - a také některé obecnější. Vypadá to, že jde o volání, kam byly uklizeny různé volby, které nebylo kam jinam dát. Popíšeme ho teď, i když se některé parametry týkají i streamovaného I/O.

Ovladače Video4Linux2, které toto volání podporují, poskytují následující dvě metody:

    int (*vidioc_g_parm) (struct file *file, void *private_data,
    			  struct v4l2_streamparm *parms);
    int (*vidioc_s_parm) (struct file *file, void *private_data,
			  struct v4l2_streamparm *parms);

Struktura v4l2_streamparm obsahuje jeden z těch union prvků, které by už pravidelní čtenáři tohoto seriálu měli znát:

    struct v4l2_streamparm
    {
	enum v4l2_buf_type type;
	union
	{
		struct v4l2_captureparm	capture;
		struct v4l2_outputparm	output;
		__u8 raw_data[200];
	} parm;
    };

Pole type popisuje typ operace, o kterou půjde; bude to V4L2_BUF_TYPE_VIDEO_CAPTURE pro zachytávací zařízení a V4L2_BUF_TYPE_VIDEO_OUTPUT pro výstupní zařízení. Může to však být i V4L2_BUF_TYPE_PRIVATE a pak je pole raw_data využito pro předání nějakých soukromých, nepřenosných, pravděpodobně nedoporučovaných dat ovladači.

U zachytávacích zařízení nás bude zajímat pole parm.capture. Struktura vypadá takto:

    struct v4l2_captureparm
    {
	__u32		   capability;
	__u32		   capturemode;
	struct v4l2_fract  timeperframe;
	__u32		   extendedmode;
	__u32              readbuffers;
	__u32		   reserved[4];
    };

capability je sada příznaků určujících schopnosti; zatím je definován jen jeden: V4L2_CAP_TIMEPERFRAME, který říká, že zařízení umí měnit snímkovou frekvenci [frame rate]. capturemode je další příznakové pole, ve kterém je definován jediný příznak: V4L2_MODE_HIGHQUALITY. Ten má za úkol přepnout hardware do režimu vysoké kvality, který je vhodný pro zachytávání jednotlivých snímků. Tento režim si může dělat, cokoliv ho napadne (z hlediska podporovaných datových formátů, expozičních časů atd.), jen aby dosáhl nejkvalitnějšího obrazu, jakého je zařízení schopno.

Pole timeperframe se používá pro specifikaci požadované snímkové frekvence. Je to opět struktura:

    struct v4l2_fract {
	__u32   numerator;
	__u32   denominator;
    };

Kvocient popisovaný v numerator a denominator udává čas mezi po sobě jdoucími snímky na zařízení. Další pole specifické pro daný ovladač je extendedmode, které v API nemá žádný definovaný význam. Pole readbuffers ukazuje počet bufferů, které by mělo jádro využít pro příchozí snímky, když je použita metoda read().

Pro výstupní video zařízení vypadá struktura takto:

    struct v4l2_outputparm
    {
	__u32		   capability;
	__u32		   outputmode;
	struct v4l2_fract  timeperframe;
	__u32		   extendedmode;
	__u32              writebuffers;
	__u32		   reserved[4];
    };

Pole capability, timeperframe a extendedmode jsou úplně stejná jako u zachytávacích zařízení. outputmode a writebuffers fungují stejně jako capturemode a readbuffers.

Když si aplikace přeje získat aktuální parametry, provede volání VIDIOC_G_PARM, což způsobí zavolání metody ovladače vidioc_g_parm(). Ovladač by měl poskytnout aktuální nastavení, přičemž by neměl zapomenout nastavit pole extendedmode na nulu, pokud není používáno, a reserved vždy na nulu.

Pokus o nastavení parametrů způsobí volání vidioc_s_parm(). V takovém případě by měl ovladač parametry nastavit tak, aby co nejvíce odpovídaly požadavkům aplikace, a upravit strukturu v4l2_streamparm, aby odrážela hodnoty, které byly nakonec použity. Aplikace může například požadovat vyšší snímkovou frekvenci, než dokáže hardware nabídnout; pak by měla být naprogramována nejvyšší možná snímková frekvence a pole timeperframe nastaveno na skutečnou frekvenci.

Je-li timeperframe aplikací nastaveno na nulu, měl by ovladač zvolit nominální snímkovou frekvenci přiřazenou k aktuální video normě. Pokud jsou nuly v readbuffers nebo writebuffers, měl by ovladač vrátit aktuální nastavení - ne se aktuálních bufferů zbavit.

V tuto chvíli už jsme toho probrali dost, abychom mohli napsat jednoduchý ovladač, který by podporoval přenos snímků pomocí read() nebo write(). Většina aplikací, které to myslí vážně, však bude chtít používat streamovaný I/O: streamovaný režim usnadňuje dosahování vyššího výkonu a umožňuje přibalovat ke snímkům relevantní metadata (např. sekvenční čísla). Další díl seriálu bude tedy popisovat implementaci streamovacího API.