Jaderné noviny - Video4Linux2 - 5b (výběr formátu)

22. 5. 2007 | Robert Krátký | Jaderné noviny | 4215×

Pokračování nepravidelného seriálu o psaní video ovladačů pro Linux. Tento díl dokončí téma video formátů popisem procesu, pomocí kterého je společně s aplikací vybrán formát, který hardware podporuje.

Úvodní díl popisuje rozsah seriálu a obsahuje odkazy na dřívější články. Minule se mluvilo o tom, jak Video4Linux2 API popisuje video formáty: velikosti obrázků a reprezentace pixelů v nich.

Jak bylo řečeno již minule, existuje mnoho způsobů reprezentace obrázkových dat v paměti. Pravděpodobně se však neprodává žádné video zařízení, které by zvládalo všechny formáty, se kterými umí rozhraní Video4Linux pracovat. Od ovladačů se také neočekává, že by podporovaly formáty, které neumí hardware, pro který jsou určeny; provádět konverzi formátů v jádře je vyloženě nevhodné. Ovladač tedy musí aplikaci umožnit, aby si vybrala formát, který s hardwarem funguje.

Prvním krokem je umožnit aplikaci, aby se vyptala na podporované formáty. Pro ten účel je poskytováno ioctl() VIDIOC_ENUM_FMT; v ovladači se příkaz promění v následující zpětné volání (pokud se jedná o zařízení pro zachytávání videa):

    int (*vidioc_enum_fmt_cap)(struct file *file, void *private_data,
			       struct v4l2_fmtdesc *f);

Toto zpětné volání zachytávací zařízení požádá, aby popsalo jeden z formátů. Aplikace k tomu předá strukturu v4l2_fmtdesc:

    struct v4l2_fmtdesc
    {
	__u32		    index;
	enum v4l2_buf_type  type;
	__u32               flags;
	__u8		    description[32];
	__u32		    pixelformat;
	__u32		    reserved[4];
    };

Pole index a type nastaví aplikace. index je obyčejné celé číslo používané k identifikaci formátu; stejně jako ostatní indexy používané ve V4L2, i tento začíná nulou a zvyšuje se až na maximální počet podporovaných formátů. Aplikace tak může zvyšováním hodnoty indexu očíslovat všechny podporované formáty - dokud ovladač nevrátí EINVAL. Pole type popisuje typ datového toku [data stream]; pro zachytávací zařízení (kamera nebo tuner) to bude V4L2_BUF_TYPE_VIDEO_CAPTURE.

Pokud index odpovídá podporovanému formátu, měl by ovladač dovyplnit zbytek struktury. Pole pixelformat by měl být fourcc kód popisující způsob reprezentace videa a description krátký textový popis formátu. Jedinou definovanou hodnotou pro pole flags je V4L2_FMT_FLAG_COMPRESSED, což značí komprimovaný video formát.

Výše uvedené zpětné volání je pro zachytávací zařízení; bude voláno, pokud je type rovno V4L2_BUF_TYPE_VIDEO_CAPTURE. Volání VIDIOC_ENUM_FMT se rozdělí na různá zpětná volání podle pole type:

    /* V4L2_BUF_TYPE_VIDEO_OUTPUT */
    int (*vidioc_enum_fmt_video_output)(file, private_date, f);

    /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
    int (*vidioc_enum_fmt_overlay)(file, private_date, f);

    /* V4L2_BUF_TYPE_VBI_CAPTURE */
    int (*vidioc_enum_fmt_vbi)(file, private_date, f);

    /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */ */
    int (*vidioc_enum_fmt_vbi_capture)(file, private_date, f);

    /* V4L2_BUF_TYPE_VBI_OUTPUT */
    /* V4L2_BUF_TYPE_SLICED_VBI_OUTPUT */
    int (*vidioc_enum_fmt_vbi_output)(file, private_date, f);

    /* V4L2_BUF_TYPE_VIDEO_PRIVATE */
    int (*vidioc_enum_fmt_type_private)(file, private_date, f);

Typy parametrů jsou pro všechna volání stejné. Stojí za zmínku, že ovladače mohou pomocí kódů začínajících na V4L2_BUF_TYPE_PRIVATE podporovat speciální druhy bufferů, ale to by zjevně vyžadovalo pochopení i na straně aplikace. Pro účely tohoto článku se omezíme na zachytávací a výstupová video zařízení; další druhy budou probrány v příštích dílech.

Aplikace může zjistit aktuální nastavení zařízení pomocí volání VIDIOC_G_FMT. V tomto případě je předávaným parametrem struktura v4l2_format:

    struct v4l2_format
    {
	enum v4l2_buf_type type;
	union
	{
		struct v4l2_pix_format		pix;
		struct v4l2_window		win;
		struct v4l2_vbi_format		vbi;
		struct v4l2_sliced_vbi_format	sliced;
		__u8	raw_data[200];
	} fmt;
    };

type opět popisuje typ bufferu; vrstva V4L2 volání rozdělí na jedno z několika zpětných volání ovladače - v závislosti na typu. U zachytávacích zařízení vypadá zpětné volání takto:

    int (*vidioc_g_fmt_cap)(struct file *file, void *private_data,
    			    struct v4l2_format *f);

V případě zachytávacích a výstupových video zařízení nás zajímá pole pix v union. Je to struktura v4l2_pix_format z minulého dílu; ovladač by měl strukturu dovyplnit informacemi o aktuálním nastavení hardwaru a pak vrátit. Volání by nemělo selhat, pokud nemá hardware nějaký vážný problém.

Další zpětná volání jsou:

    int (*vidioc_s_fmt_overlay)(file, private_data, f);
    int (*vidioc_s_fmt_video_output)(file, private_data, f);
    int (*vidioc_s_fmt_vbi)(file, private_data, f);
    int (*vidioc_s_fmt_vbi_output)(file, private_data, f);
    int (*vidioc_s_fmt_vbi_capture)(file, private_data, f);
    int (*vidioc_s_fmt_type_private)(file, private_data, f);

vidioc_s_fmt_video_output() používá pole pix stejným způsobem jako zachytávací rozhraní.

Většina aplikací bude nakonec chtít hardware nakonfigurovat tak, aby poskytoval formát, který se hodí k jejich práci. Pro změnu video formátů existují dvě rozhraní. První je volání VIDIOC_TRY_FMT, které se v ovladači změní na jedno z těchto zpětných volání:

    int (*vidioc_try_fmt_cap)(struct file *file, void *private_data,
			      struct v4l2_format *f);
    int (*vidioc_try_fmt_video_output)(struct file *file, void *private_data,
			      	       struct v4l2_format *f);
    /* A tak dále pro další typy bufferů */

Ovladač volání zpracuje tak, že se podívá na požadovaný video formát a rozhodne, jestli ho hardware umí nebo ne. Vyžaduje-li aplikace něco nemožného, měl by ovladač vrátit -EINVAL. Takže například fourcc kód popisující nepodporovaný formát nebo požadavek na prokládané video na zařízení, které pracuje jen s progresívním, by selhal. Na druhou stranu, ovladač může pole s velikostí upravit tak, aby odpovídala velikosti obrázku, kterou hardware podporuje; běžný postup je v případě potřeby velikost snížit. Ovladač zařízení, které zvládá pouze obrázky v rozlišení VGA, by podle toho změnil parametry width a height a vrátil úspěch. Struktura v4l2_format bude po dokončení volání zkopírována zpátky do uživatelského prostoru; ovladač by ji měl aktualizovat, aby obsahovala nové parametry a aplikace věděla, co vlastně dostane.

Obsluhy [handlers] VIDIOC_TRY_FMT jsou u ovladačů nepovinné, ale nedoporučuje se je vynechávat. Pokud jsou implementovány, může být tato funkce volána kdykoliv, dokonce i v případě, že je zařízení v právě provozu. Neměla by však měnit parametry; je to jen způsob, pomocí kterého může aplikace zjistit, jestli je to možné.

Když pak chce aplikace doopravdy změnit video formát, provede volání VIDIOC_S_FMT, které k ovladači dorazí v této podobě:

    int (*vidioc_s_fmt_cap)(struct file *file, void *private_data,
    			    struct v4l2_format *f);
    int (*vidioc_s_fmt_video_output)(struct file *file, void *private_data,
    			             struct v4l2_format *f);

Na rozdíl od VIDIOC_TRY_FMT nemůže být toto volání prováděno kdykoliv. Je-li hardware zrovna v provozu, nebo pokud má alokované streamovací buffery (téma některého z dalších dílů), povede změna formátu k pořádným zmatkům. Představte si například, co by se stalo, kdyby byl nový formát větší než právě používané buffery. Takže ovladač by se měl vždy ujistit, že se s hardwarem nepracuje - a pokud ano, tak by měl požadavek selhat a vrátit -EBUSY.

Změna formátu by měla být atomická - měly by být změněny všechny požadované parametry nebo žádný. Opět: parametry velikosti obrazu mohou být v případě potřeby změněny. Tato zpětná volání vypadají většinou takto:

    int my_s_fmt_cap(struct file *file, void *private, 
                     struct v4l2_format *f)
    {
	struct mydev *dev = (struct mydev *) private;
	int ret;

	if (hardware_busy(mydev))
	    return -EBUSY;
	ret = my_try_fmt_cap(file, private, f);
	if (ret != 0)
	    return ret;
	return tweak_hardware(mydev, &f->fmt.pix);
    }

VIDIOC_TRY_FMT zabrání duplikování kódu a je odpovědí na všechny výmluvy, proč tu obsluhu neimplementovat. Pokud je úspěšná funkce "try", tak víme, že bude výsledný formát fungovat, a může být přímo naprogramován do hardwaru.

Video I/O ovlivňuje ještě celá řada dalších volání. Příští díly se na některá z nich podívají. Podpora nastavování formátů však stačí k tomu, aby mohly aplikace přenášet obrázky, což je hlavním účelem této struktury. Další díl se tedy bude věnovat podpoře pro čtení a zapisování dat.

       

Komentáře

[Karry]

Rád bych upozornil na nepřesnost, která je uvedena i v originále a podle které se někteří vývojáři bohužel řídí, což dokazuje nefunkčnost mplayeru a dalších aplikací s gspca driverem. Jediný závazný dokument kterým by se vývojáři měli řídit je V4L2 API (linuxtv.org). (Tím ale nechci tvrdit že tento seriál není užitečný, právě naopak!)

Jedná se o to, jak se má ovladač chovat při TRY_FMT nebo S_FMT.

Vyžaduje-li aplikace něco nemožného, měl by ovladač vrátit -EINVAL. ... Na druhou stranu, ovladač může pole s velikostí upravit tak, aby odpovídala velikosti obrázku, kterou hardware podporuje...

Ovladač by měl vracet -EINVAL pouze v případě, kdy nepodporuje požadovaný typ bufferu, nebo v případě S_FMT vrátit -EBUSY pokud zařízení zrovna pracuje a nemůže formát změnit. Ve všech ostatních případech by měl driver vrátit 0 a nastavit parametr VČETNĚ PIXEL FORMAT na některý z podporovaných formátů! Takže aplikace by si po tomto volání měla zkontrolovat vrácenou hodnotu a pokud vrácený pixelformat nepodporuje, zkusit požádat o jiný formát!

Ve V4L2 API přímo stojí:

Very simple, inflexible devices may even ignore all input and always return the default parameters.

Bohužel hodně aplikací vrácenou hodnotu nekotroluje a pokud volání vrátí nulu, předpokádají že dostanou data ve formátu, jaký požadovali. Například mplayer zavolá S_FMT třeba s pixelformat YV12, gspca driver na zařízení podporující pouze BA81 vrátí 0 a nastaví pixelformat na BA81. Mplayer vrácenou hodnotu nezkontroluje a když potom dostane data v jiném formátu "než si nastavil", tak velkým rachotem spadne...