abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 22:33 | Nová verze

    Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.

    Ladislav Hagara | Komentářů: 2
    2.5. 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 0
    2.5. 19:11 | IT novinky

    Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.

    Ladislav Hagara | Komentářů: 3
    2.5. 11:22 | Zajímavý projekt

    Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.

    Ladislav Hagara | Komentářů: 2
    2.5. 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 2
    1.5. 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 3
    1.5. 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    30.4. 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    30.4. 12:11 | Humor

    Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).

    Ladislav Hagara | Komentářů: 7
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (2%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 513 hlasů
     Komentářů: 19, poslední 30.4. 11:32
    Rozcestník

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

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

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Karry avatar 19.10.2008 15:18 Karry | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny - Video4Linux2 - 5b (výběr formátu)
    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...
    unzip; strip; touch; grep; finger; mount; fsck; more; yes; umount; sleep
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.