Multimédia (vagy mi a szösz) faragás – továbbra is

Hobbiból sokszor foglalkozok régi gépekkel, de ezeknek a vasaknak mostanában van egy „problémájuk”, ami maga a megjelenítő. Eredetileg sima televíziót lehetett használni erre a célra, de manapság hol vannak már azok... Meg egyébként is, ha valaminek örülök, hogy az idők folyamán megváltozott, az pont a CRT-s monitorok eltűnése. Valahogy nem hiányzik a hatalmas helyfoglalás meg a villogás, a sorfrekvencia fütyülésével egyetemben... Megvan annak is a varázsa, de ez a rész annyira nem fog meg.

A probléma abból áll, hogy ezek a régi gépek olyan képet produkálnak, amit a mai monitorok legtöbbször nem tudnak fogadni. Ezen probléma nálam most úgy van megoldva, hogy van egy külső tv-tuner „kütyüm”, amin egyrészt van egy hagyományos RF antennabemenet, másrészt van rajta CVBS (kompozit videó) illetve S-Video bemenet. A régi gépek közül az RF általában adott, viszont annak elég tré a képe. De sokszor van CVBS, illetve S-Video is, ami már megfelelő. (De ha nincs, viszonylag könnyű „szerezni”, mivel az RF kimenet a kompozit videojelből alakul ki.) Ezt simán be lehet kötni a „tunerbe”, ami (valamilyen) szabvány VGA jelet generál ebből a képből, ezt meg már „megeszik” a mai monitorok is. (Már ameddig lesz még VGA csatlakozó rajtuk...) A jelenleg használt monitorom meg a VGA jelét egy kis ablakban meg tudja jeleníteni. Az eddigi régi gépes „képernyőképeim” pontosan azért ilyen bénák, mert a monitor lett lefényképezve, mivel a számítógép mit sem tud arról, hogy a megjelenítő abba a sarokba odavarázsolt még valamit.

Régi ötlet, hogy kellene valami „kütyü”, amivel a CVBS, illetve S-Video jelet a számítógépbe is be tudnám vezetni. Analóg tuner az persze nem szükséges, elég csak a CVBS + S-Video bemenet. Létezik persze ilyen eszköz, video grabber néven keresendő, egy USB-s verziót 1-2 éve használtam is belőle. De az most nincs meg, egyszer talán visszakapom... :) Ettől függetlenül ez nem annyira triviális feladat, mint kiderült. Alapesetben a szabvány kompozit videojellel nincs egyiknek sem gondja, de a „régi vasak” közel sem ilyen jelet produkálnak. Az alap PAL videojel mindenestől 625 sorból áll, ebből 576 sor az „aktív” képtartalom. (A többi az keret + a képvisszafutás ideje.) Az ilyen képekből 25 van másodpercenként, de ezt két menetben rajzolja ki a megjelenítő. (Interlaced megjelenítés, „mai” megnevezéssel 576i@25Hz.) Az egész kép két félképből tevődik össze, a félképekből így másodpercenként 50 db. van. A régi hardverek viszont hanyagolni szokták az interlaced megjelenítést, mert a „statikus” (sokszor sima szöveggel teli) képen nagyon zavaró a 25 Hz-es villogás. Ezért „ők” sima progresszív, 50 Hz-es videojelet állítanak elő. Erre egy ötletes megnevezés az LDTV (az SDTV/HDTV mintájára). Igaz, hogy így a függőleges felbontás feleződik, de legalább kevésbé villog. (A sorok száma itt 312, az „aktív” ebből 288, de ez progresszív, szóval a „mai” megnevezése 288p@50Hz.) Ennek a „kevésbé szabványos” videojelnek a feldolgozása régen az analóg tv-knek nem okozott gondot. A mai digitális csodák meg a ténylegesen szabvány jelet próbálják feldolgozni / feljavítani, amikor meg ilyen „furcsa” bemenő jelet kapnak, akkor jönnek az érdekességek.

De vissza a régi ötlethez... Jelenleg van nálam két ilyen video-grabber kütyü is. (A végén meg majd az fog kiderülni, hogy – egyelőre – egy harmadik megoldás lesz a nyerő.) Ezek mindketten USB-s csatlakozásúak. Alapvető gond szokott lenni, hogy a specifikációk általában nem említik, hogy milyen csipeszettel is készültek, így azért nehéz okosan választani... (Mivel Linux alatt óhajtom használni a hardvert, nem fog menni a „rakd be az install lemezt a meghajtóba” verzió.) Persze ha ott van, abból sem derül ki, hogy egy non-interlaced videojellel hogyan is boldogul a típus. Az előző ilyen eszközömmel az volt a gondom, hogy mindegy volt neki a bejövő jel, a programok 25 Hz-es képet állítottak elő belőle, mindenáron összefűzték a bejövő – szerintük - félképeket. (A mozgások 50 Hz-es bemeneti jelnél így elég mókásak...) Viszont – utólag – már úgy sejtem, hogy rossz helyre tettem a „hibát”, de erről később.

Az egyik eszköz a kettő közül az „USB 2.0 Audio/Video Grabber” nevet viseli. Az előző pótlására szereztem be. Nem volt éppen a legolcsóbb, cserébe a specifikációk között ott volt a csip megnevezése: CX23102. („Szeretem”, amikor csak ilyen semmitmondó marketing-katalógust lehet találni valamiről...) Kép nem lesz róla, eléggé össze van növesztve, nem akarom összetörni. :) Papíron támogatják a frissebb kernelek, de a működéséhez kell némi binary blob. Viszont itt ettől nem kell megijedni, ez egy firmware, ami magába a kütyübe töltődik be csatlakoztatáskor (azaz ezt nem a gép futtatja). Az lsusb egy rakás dolgot elmond róla, de a lényeg:

Bus 001 Device 009: ID 1f4d:0102 G-Tek Electronics Group 
  idVendor           0x1f4d G-Tek Electronics Group 
  idProduct          0x0102 

Linux alatt az installálás a dugd be és használd módszerrel megy, dmesg:

[25528.551970] usb 1-4: new high-speed USB device number 5 using ehci-pci 
[25528.668175] usb 1-4: New USB device found, idVendor=1f4d, idProduct=0102 
[25528.668187] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 
[25528.668194] usb 1-4: Product: OTG102 
[25528.668200] usb 1-4: Manufacturer: Geniatech 
[25528.668205] usb 1-4: SerialNumber: 20090427 
[25528.901967] cx231xx #0: New device Geniatech OTG102 @ 480 Mbps (1f4d:0102) with 5 interfaces 
[25528.901976] cx231xx #0: registering interface 1 
[25528.902230] cx231xx #0: Identified as Geniatech OTG102 (card=17) 
[25528.966721] cx231xx #0: cx231xx_dif_set_standard: setStandard to ffffffff 
[25529.045455] cx25840 11-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0) 
[25529.063724] cx25840 11-0044:  Firmware download size changed to 16 bytes max length 
[25531.120349] cx25840 11-0044: loaded v4l-cx231xx-avcore-01.fw firmware (16382 bytes) 
[25531.154561] cx231xx #0: cx231xx #0: v4l2 driver version 0.0.2 
[25531.171200] cx231xx #0: cx231xx_dif_set_standard: setStandard to ffffffff 

Firmware automatikusan letöltve, v4l2 driver betöltve. De van neki „szép” képe is:

A helyzet csak azért tragikus ennyire, mert a kábeltévé analóg jele meglehetősen zajos. (A kép a régi külső tv-tuneremből van kivezetve CVBS formában, abban – ahogy a neve is mutatja – van még tuner is. Lassan célszerű lesz valamilyen DVB verziót beszerezni, bár amennyit tévézek... :) ) Tehát ez még nem is lenne annyira gáz, de van itt más is:

Na, ezt képes produkálni a non-interlaced 288p@50Hz bemeneti jelre. (Nekem meg még a régivel volt bajom... :) ) Kár érte, mert kifejezetten szimpatikus darab. Ráadásul a firmware külön töltődik be, még esély is lenne rá, hogy ki lehet javítani. De ezt persze csak a gyártó tudná megtenni, mert saját fw írásához nincs elég (semmilyen) információ... Bármennyire is szimpatikus ez a darab, amire nekem kellene, arra sajnos használhatatlan. Következő!

Erről a kütyüről nem lesz link, ugyanis sanszos, hogy ez csak másolat. EasyCAP néven fut, de ebből eredetileg is van egy rakás verzió, más-más csippel szerelve (ez is egy „kedves gesztus”). A házát azért ennek egyszerű kinyitni:

A benne levő csip típusáról a szerencse dönt, ugyanis ezt nem szokták előre elárulni. A képekről kiderül, hogy ez ebben az esetben a Somagic SMI2021. Az eszközről sokat elárul, hogy a típusra általánosan rákeresve a találatok jelentős része Linuxszal kapcsolatos, ami lehet jó hír is (működik), meg rossz is (nem működik). Dokumentáció? Na, azt elfelejthetem.

Van viszont lsusb kimenet:

Bus 001 Device 006: ID 1c88:0007 Somagic, Inc. SMI Grabber (EasyCAP DC60+ clone) (no firmware)
                                 [SMI-2021CBE]
  idVendor           0x1c88 Somagic, Inc. 
  idProduct          0x0007 SMI Grabber (EasyCAP DC60+ clone) (no firmware) [SMI-2021CBE] 

A (no firmware) megjegyzés nem azt jelenti, hogy ehhez ne kellene, hanem azt, hogy jelenleg nincs betöltve. :( dmesg:

[26831.026040] usb 1-4: new high-speed USB device number 6 using ehci-pci 
[26831.140905] usb 1-4: New USB device found, idVendor=1c88, idProduct=0007 
[26831.140913] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 
[26831.140917] usb 1-4: Product: SM-USB 007 
[26831.140920] usb 1-4: Manufacturer: Somagic, Inc. 
[26831.140923] usb 1-4: SerialNumber: SMBL007 

Ez így már keményebb dió, kérdés, hogy van-e értelme vele küzdeni. Egy kicsit régebbi ez a történet, valamikor az év elején próbálkoztam vele, a mostani keresési eredmények már biztatóbbak mint akkor. De ez rajtam most sem segít, a CentOS7 alapból nem ismeri, de még a Fedora21 sem. (Az F21 → F22 frissítésem még hátra van, ha egyáltalán megejtem... Ha akkor még nálam lesz, az eredményt jelzem.) Viszont sikerült akkor működési jeleket kicsikarni belőle, ezen az oldalon található ehhez egy programcsomag némi leírással fűszerezve. Ami egy kicsit talán trükkös, hogy ehhez az eszközhöz is kell a bele töltendő firmware, viszont azt „csak úgy” nem lehet megszerezni. A Windows®-os telepítője egy darab futtatható fájl. Ezt a Wine segítségével fel lehet telepíteni (ehhez jelenleg a Fedora alatti Wine a jó, emiatt a többi kísérletezés is az alatt folyt), majd a felpakolt cuccokból kimásolandó az SmiUsbGrabber3*.sys fájl. Ez még önmagában mindig „sok”, de az oldalon található programcsomagban van egy somagic-extract-firmware nevű szerszám, ami már képes kimazsolázni ebből azt, ami kell. (A végeredmény a /lib/firmware/somagic_firmware.bin fájl lesz.) Ezután szintén az oldalon található programcsomag somagic-init parancsát futtatva betöltődik a firmware az eszközbe. lsusb:

Bus 001 Device 011: ID 1c88:003c Somagic, Inc. SMI Grabber (EasyCAP DC60+ clone) [SMI-2021CBE] 

A (no firmware) eltűnve, az USB PID 003C-re változva, remek! A végeredmény itt – egyelőre – nem kernel-modul, a csomagban levő somagic-capture programmal lehet közvetlenül kezelni az eszközt, ez a --help paraméterre ad példát a használatra. A sima CVBS bemenet PAL képnél a következő paranccsal jeleníthető meg:

./somagic-capture | mplayer -vf yadif,screenshot -demuxer rawvideo -rawvideo pal:format=uyvy:fps=25" -aspect 4:3 -

(A somagic-init illetve a somagic-capture root-ként futtatandó...) A „lejátszást” ez esetben az MPlayer végzi, valahogy így:

A minőség szintúgy hagy némi kívánnivalót, mondjuk ebből egy jó adag megint a rossz minőségű forrásnak tudható be. De mit csinál a non-interlaced képpel?

Nem túl hízelgő... :) Egy másik példa:

Ez utóbbi se állókép, hanem néha ugrik / fut. Mindezt ugyanazzal a beállítással, amivel a „normális” PAL jel használható. Valószínű, hogy firmware módosítással ez is jó lehetne, de itt sincs ehhez semmi dokumentáció. (Ami egy kicsit idegesít, hogy a „régi” USB-s grabberem szintén valamilyen EasyCAP (klón) volt, annak nem kellett (emlékeim szerint) betöltendő firmware, az csak úgy működött jól. :) ) A v4l2 meghajtó – a jelek szerint – ugyan „úton van”, előbb-utóbb lesz hozzá kernel-szintű támogatás, de az azért kiderült, hogy várnom rá teljesen fölösleges. Konklúzió: ez is kuka. :( Következő!

Itt egy kicsit elfogyott a lendület a témával kapcsolatban, de aztán eszembe jutott, hogy van nekem régről egy tv-tuner kártyám, ezt anno használtam ilyen szerepkörben ami most érdekes, és nem volt vele gondom. Aztán ki kellett vennem a gépből, mert az egyik kernel-frissítés után (ekkor még Gentoo-t farigcsáltam) nekiállt fagyni véletlenszerűen a gép, ez a jelenség viszont ezen kártya nélkül nem jelentkezett. Akkor amúgy is csak a slotot foglalta, annyira nem bántam ezt. Mivel „tonnaszámra” nem találtam ilyen hibaleírásokat, akkor ráfogtam arra, hogy valamilyen hardveres kompatibilitási problémába futottam bele. De azóta sok év eltellett, az alaplap (amivel a hibát produkálta) közben meghalt, a pótlását is már régen lecseréltem, szóval egy új próbát megérhet a dolog. Ha be is válik, végleges megoldásnak sajnos nem lesz jó, mivel PCI-buszos a darab. Ezt egyrészt notebookhoz nem lehet használni, másrészt a jelenlegi alaplapomon ugyan van még PCI slot, de az újakon ez egyre inkább nem lesz. (Mondjuk most így rákeresve találtam PCIe-to-PCI adaptert. Hogy egy ilyen kártya működne-e vele... :) ) Egy régebbi képet találtam is róla:

Ez egy Pinnacle PCTV Studio Pro nevű eszköz, BT878 alapon. (Ha jól tudom, a Booktree-t időközben megvette a Conexant, ezért a más név a csipen.) Nem volt ez rossz cucc annak idején, járt hozzá még soros portra kötendő infrás távirányító is! :) Van rajta (természetesen analóg) rádió + tévé tuner, illetve CVBS + S-Video bemenet is. Az élcsatlakozó egy kissé „retkes”, érdekes módon rengeteget javult egy kis csiszolás hatására a felület. (Lehet, hogy csak ez volt anno is a baj? :) ) A gépbe berakva előjött az igazi Plug&Play érzés, az aktuális Linuxok automatikusan felismerik, és egyszerűen csak működik. :) (Amúgy ezért is szeretem én a Linuxot. Erről a kártyáról azt érdemes tudni, hogy nem mai gyerek, ehhez hivatalosan már Windows® XP™-s meghajtó sem készült! Én meg 15 évvel később csak bedugom és megy...? :) )

Tévés képet most nem csinálok (nem ér oda a videókábel a tunerhez, ennyit úgyse ér, enélkül is tudom, hogy zajos), de a non-interlaced vajon milyen?

A körülményekhez képest rendben van szerencsére. Valahogy ezt vártam volna el az előző két USB-s versenyzőtől is. Mi olyan nehéz ezen? :) Fagyást szerencsére nem tapasztaltam azóta, maradjon is így! (Amúgy az eddigi próbálkozások közül ez a megoldás tudja a legnagyobb felbontást. A függőleges ugye adott, de a vízszintes érték a többi esetében max. 720 pixel volt, itt meg 920. A „kedvenc” 768 is megvan...)

Érdekességek persze azért vannak. Az eszköz kernel-modulja(i) létrehoz(nak) a /dev alatt pár eszközfájlt. Ilyen a /radio0, mivel ezen a kártyán a tuner tud rádiót is. Aztán lesz egy /video0 eszköz is, ezen keresztül „látszik a kép”. Meg van itt egy /vbi0 („Vertical Blanking Interval”) is, ezen keresztül kezelhető például a tuner. De ami az igazi érdekesség: a /dev/snd alatt megjelenik a kártya hang-része, amiről azt érdemes tudni, hogy nincs. :) A BT878-as tunerkártyák a hangot (ami a tévé / rádió részből jön) tudnák már digitális formában, a PCI buszon keresztül továbbítani a gép felé. Viszont a BT878 önmagában nem tudja a hangot digitalizálni, csak a képet... A hang úgy van kezelve, hogy I²S buszon keresztül egy külső codecet (itt a co rész az érdekes...) tud maga a BT878 használni, az onnan jövő (már digitális) adatfolyamot szépen tudja is továbbítani a PCI buszon. Ezen a kártyán viszont még nincs audio codec, csak a sima analóg hang van egy (két) csatlakozóra kivezetve. A tuner hangját egy, a kártyához adott kb. 10 centis kábellel, a gépen kívül kell „visszahurkolni” a rendes hangkártya Audio In bemenetére. (Illetve ugyanezt el lehet játszani a gépen belül is, a fenti képen az a lefele menő vezeték nálam pont ezt a célt szolgálta.) Szóval a BT878 tudná a hangot is továbbítani, viszont azt nem detektálja, hogy a megfelelő lábain ott lóg-e a codec csip. A driver meg Linux alatt ilyen „általános” BT8x8 kezelő, ő „nem látja”, hogy nincs semmi hozzádrótozva a kívánt vonalakhoz, emiatt lesz hangeszköz is. Használható is, csak éppen mindig a csönd hangjai szólnak belőle... :) Amúgy a hang rész a leginkább elbénázott oldala a kártyának, ha működne, akkor se jutna eszembe használni. A tunernek van „saját” tápja, de a hang jelútjában lévő alkatrészek a PCI portról közvetlenül jövő, zajos +5V-ról vannak megtáplálva. A hangba emiatt belehallatszik a HDD-k aktivitásától kezdve az egér tologatásáig minden. (Studio? Pro? Persze... :) ) De nem hangot jöttünk ide digitalizálni, hanem képet. Az meg jó.

A feladat – egyelőre – letudva, most már csak valami egyszerű stuff kellene, amivel a képet a lehető leg-sallang-mentesebben meg lehet jeleníteni. Az MPlayer / VLC kiváló erre, viszont a beállításaik nem túl bőbeszédűek, meg (a VLC-nél legalábbis) elég nagy a késleltetés. (Sokat pufferel...) Régen erre a célra az igazán fapados xawtv-t használtam. Utoljára a „jól működő” USB-s grabber esetén próbálkoztam vele, de – érdekes módon – olyan szintű fagyásokat produkált tőle a gép, hogy csak a ki/bekapcsolás segített. :) Emiatt inkább nem kísérleteznék újra vele. Sebességben a Cheese ugyan teljesen kiváló, de ez meg webkamerák kezelésére van, emiatt elég szűkösek a konfigurációs lehetőségei. Nem lehet benne például bemenetet váltani, az meg egy kissé nyűgös, hogy VLC-vel „bekonfigurálom” a kártyát, majd a Cheese-t elindítva az már a jó bemenetet használja... :) Keresgélés közben akadtam az UCView nevű kis tool-ra, ami viszont szinte tökéletes a célra. Azért szinte, mert a beállított paramétereket nem akarja megjegyezni, ezért indításkor ezeket mindig be kell állítani, de amúgy megfelelően minimalista, ráadásul van belőle csomag CentOS (epel-ből) és Fedora alatt is! Ugyan ez is mindenáron de-interlace-el, de ezzel egyelőre meg kell barátkoznom... De hogy ez miért is zavaró, arra jöjjön itt egy példa. Itt van két kép egymás mellett:

A nagy fekete négyzet a második képen el van tolva jobbra 8 karaktert. (A kicsi négyzet a kurzor, az most nem érdekes.) Csináltam egy (7 soros :) ) programot, ami félképenként ezt a két képet cserélgeti. (Egy másodperc alatt 25× látszik az egyik is meg a másik is.) A „sima” összefűzés ebből ezt csinálja:

(UCView akcióban, egyszerű képernyőkép...) Ez ugyan állókép, de ez látszik állni 25× másodpercenként. Holott a „nagy négyzetnek” ugrálnia kellene a két állapot között... Viszont kezd az a gyanúm lenni, hogy ezt a gépen futó program (esetleg a v4l2) csinálja. Ha mást nem is, azt meg lehetne csinálni, hogy „megvárok” egy 25 Hz-cel „érkező” képet, majd páros/páratlan sorokra bontva megjelenítem 50 Hz-cel. Ez ugyan behoz két félképnyi késleltetést, viszont nem lesz ilyen „vicces” a végeredmény. Ehhez már csak kódolni kellene megtanulni... :) De van egy másik probléma is, a jelenlegi monitor 60 Hz-cel frissíti a képet, azaz itt 5 bejövő képkocka alatt kb. 6 kimeneti képkockát kellene produkálni. Ha a két sebesség nincs szinkronizálva, akkor jön a klasszikus képtörés, ha van, akkor néha képkockát kell duplázni, ami „akadásokat” produkál. Kell valami szoftver, ami az 50 Hz-es képet „felskálázza” 60 Hz-re (tuti van ilyen, kellemes és erőforrás-zabáló feladat), de ettől megnő a késleltetés. (Hogy nekem semmi se jó..? :) ) Megoldás most erre nem lesz, de a közelmúltban történt pár fejlesztés a monitorok világában, ami segíthetne ezt a problémát megoldani. Az egyik ilyen technológia a G-Sync, ami kizárólagos nv, az én kártyám nem tudja, monitorom nem tudja. A másik a FreeSync, ami szerencsére VESA szabvány lett időközben. De a monitorom ezt se tudja (videokártya pláne...), azt meg egyelőre nem tervezem lecserélni. Így ezek most nem játszanak.

A konklúzió? A feladat átmenetileg meg van oldva valamilyen szinten, de érdemes lesz még futni pár kört. Ha előkerül a régi USB-s grabberem, akkor annak a típusát majd ideírom, illetve ha sikerül egyéb ilyen kacatot is kipróbálni, arról is beszámolok. A hang rész itt most kimaradt, a régi USB-s darabnál azt akkor nem sikerült működésre bírni (a PCI-os kártyámon meg ugyebár nincs is), de most sem igazán érdekelt. Az alap probléma (LDTV...) viszont zűrösebb mint hittem! Azt sejtettem, hogy a Linux-támogatása problémás lehet egy-egy ilyen eszköznek, de hogy az alap feladattal se tudnak megbirkózni, az egy kissé lehangoló.

Az igazi „ász” tesztet még meg se csináltam, de majd most! (Egy kis update...) Ez egy VIC20 képének a megjelenítése lesz, abba még a „külső” tévé-tuneremnek is beletörik a bicskája. (Mondjuk „csak” színprobléma, de elég az is. Ja, és ez a dobozka is mindenáron de-interlace-el...) Most végre összeforrasztottam egy video-kábelt a VIC20-hoz. (A gépért ezúton is köszönet annak, akitől kaptam!) Ez a gép a benne levő videovezérlő IC-ről, a VIC-ről (Video Interface Chip) kapta a nevét, a 20-as szám meg a gépben gyárilag található 20 KBYTE-nyi ROM-ból jön (a legendák szerint). Itt most a VIC / VIC-I a lényeg, ugyanis ez volt a MOS első olyan integrált videovezérlője, ami kompozit PAL/NTSC videojelet állított elő. A csip felépítése olyan, hogy alapból szín / világosságjellel dolgozik már belül is, ott sincs meg az RGB! (Ez akkor egy nagy újítás volt, gondolom körbe is pakolták szabadalmakkal, ahogy szokás.) Mivel ez volt az első ilyen videovezérlő IC-jük, a gépből kijövő kompozit videojellel ezért – hogy is mondjam – vannak problémák. Hagyományos TV esetén ez nem okoz gondot, de a mai modern, digitális csodák képesek tőle „megőrülni”. A külső tunerem se szereti:

A fotón még annyira nem is látszik durvának; a keretszínen függőleges csíkok látszanak, „szép” átmenetekkel. Effektnek még elmenne, de ennek homogén kb. zöldeskéknek kellene lennie! Ettől azért ez elég távol van... Viszont a BT878-as kártya már egészen más képet mutat:

Na, ennek valami ilyesminek kell lennie! Természetesen a teljesen tökéletestől messze van, de szerintem azért vállalható. A régi USB-s digitalizálóm ugyanolyan csíkos képet csinált belőle, mint a külső tunerem. Az itt tesztelt kettővel inkább ki se próbálom... :) Újra egy plusz pont a BT-s kártyának.

Közben a de-interlace kapcsán is van egy kis fejlemény. Talán még Gentoo-n, de mindenképpen jó régen használtam a tvtime nevű programot ezzel a kártyával, de valahogy most eszembe se jutott megnézni, pedig van benne több de-interlace algoritmus is. A program UI valahogy nem tetszik (távirányítós, valódi TV-t utánzó megoldás, ablakban egy kissé „típusidegen”), meg néha hanyatt esik, CentOS alatt csomag sincs, de ezektől függetlenül egy próbát megér:

A kép tetején levő fekete négyzet úgyszintén két pozícióban van felváltva, viszont mindkét Progressive üzemmód ugyanúgy összefűz. :) A kiválasztott Motion Adaptive: Simple Detection módban viszont a gyorsteszt alapján rendben van a kép, a screenshoton is csak egy négyzet látszik. Majd még tesztelem, de első ránézésre elfogadhatónak tűnik...

Linkek:

• A téma folytatása
• V4L2 doksi ahhoz, hogy mi micsoda
• Somagic SMI2021 (felhasználói) programok
• UCView
• tvtime, több fajta de-interlace lehetőséggel
• EasyCap blog, akár ilyen is lehetett volna az „elkallódott” grabberem, de nem ilyen...

balagesz

---

2015.06.21.
2015.08.02. VIC20 + tvtime kiegészítés
2016.09.25. Folytatás link + hibajav.
2019.12.16. D8.
2024.08.24. Kép.jav. + elírások