Strict Standards: Static function gapiAuthMethod::getMethodName() should not be abstract in /home/zajec/domains/zajec.net/public_html/include/gapi.class.php on line 598

Strict Standards: Static function gapiAuthMethod::getTokenName() should not be abstract in /home/zajec/domains/zajec.net/public_html/include/gapi.class.php on line 605
WWW by Zajec (Rafał Miłecki)

Rafał Miłecki ─ Zajec

Zmieniona obsługa kamerek

Jak to zazwyczaj bywa, początkowo tylko nieliczne kamery internetowe były obsługiwane przez Linuksa. Brakowało sterowników, a z kolei do ich napisania odpowiedniej wiedzy oraz dokumentacji protokołów i formatów. Z czasem na szczęście sytuacja się poprawiła (niestety głównie za pomocą inżynierii wstecznej, a nie opublikowania dokumentacji przez producentów) i hakerzy zaczęli tworzyć kolejne sterowniki. Wszystko zapowiadało się dobrze, jednak w rzeczywistości doprowadziło do sporego bałaganu.


Okazało się, że [em]rozmowa[/em] z kamerą i odbieranie sygnału video to nie wszystko. Poszczególne chipsety wysyłają obraz w różnych formatach i przed wyświetleniem trzeba je dodatkowo konwertować na coś bardziej uniwersalnego (bgr24 lub yuv420).

Jednym z możliwych rozwiązań było przeprowadzenie konwersji jeszcze na poziomie modułu jądra i udostępnianie sygnału w zrozumiałym formacie. Powstał nawet przykładowy sterownik ov51x-jpeg bazujący na ov511, który dokonuje właśnie takiego typu operacji (w tym wypadku dekompresji JPEG). Rozwiązanie jest więc skuteczne, jednak zupełnie niewłaściwe biorąc pod uwagę pewnie zasady, których przestrzega się w kodzie jądra. Zadaniem modułu jest sama [em]rozmowa[/em] ze sprzętem, a nie zabawa z formatami, która powinna mieć miejsce już w przestrzeni użytkownika. W rezultacie w wersji 2.6.27 jądra usunięto kod konwertujący i część kamerek straciła bezpośrednie wsparcie.

W międzyczasie wybrano inną drogę i zaczęto implementować obsługę kolejnych formatów w samych odtwarzaczach. Zrodził się jednak kolejny problem, bo w ten sposób MPlayer zaczął radzić sobie z formatami niektórych kamer (np. Creative Live! Cam Vista IM VF0420 ─ 041e:4064), jednak już z tą samą kamerą nie współpracuje Skype. Ostatecznie doprowadziłoby to prawdopodobnie do masowego powielania kodu konwertującego we wszystkich odtwarzaczach.

Z prawdziwym i porządnym rozwiązaniem (istotnym zwłaszcza dla użytkowników kernela 2.6.27 i nowszych) przyszedł wreszcie Hans de Goede, który stworzył bibliotekę libv4l. Używając jej funkcji do otwierania i kontrolowania kamery otrzymujemy automatyczną konwersję na zrozumiały format. Wystarczy więc zastąpić w programach standardowe wywołania open i ioctl nowymi v4l2_open i v4l2_ioctl, a każda kamera powinna zacząć działać niezależnie od jej wewnętrznego formatu. Biblioteka jest szczególnie przydatna

Co więcej, Hans przewidział również możliwość zmuszenia dowolnej aplikacji do korzystania z libv4l bez ingerencji w jej źródła (przydatne gdy nie mamy ochoty lub umiejętności modyfikowania kodu, lub gdy kod jest w ogóle niedostępny). W takiej sytuacji wystarczy uruchomić dowolny program ze zmienną LD_PRELOAD wskazującą na v4l1compat.so, czyli przykładowo
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so mplayer tv:// -tv device=/dev/video0
LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so mplayer tv:// -tv device=/dev/video0
. Należy przy tym jedynie uważać na uruchamianie apliakcji 32bitowych w systemie 64bitowym. W takiej sytuacji konieczna jest instalacja libv4l w wersji wersji dla x86 (nie x86_64) i wskazanie v4l1compat.so w katalogu "lib" (nie "lib64").

Oczywiście w przyszłości gdy libv4l się ustabilizuje, wszystkie programy powinny już jej domyślnie używać.

[EDIT]
W przypadku problemów z kolorami, można spróbować rozwiązania podanego przez dve w komentarzach.