Większość współczesnych kodeków wideo korzysta z pewnej oczywistej zależności między poszczególnymi klatkami sekwencji wideo. Otóż jeśli kompresowana jest scena w miarę naturalna, to znaczy to co na ekranie ma pewną ciągłość, to klatka obrazu i jej sąsiedzi w ogólności niewiele się od siebie różnią. Zatem nie sposób z tej sytuacji nie skorzystać, aby zwiększyć stopień kompresji bez utraty jakości. Jednak samo dostrzeżenie różnic i wyliczenie prostej różnicy klatek w formie rastra i zakodowanie tej różnicy niczym pojedynczego obrazka tak jak to robi koder JPEG nie jest wystarczająco efektywne. Prosta różnica między sąsiednimi klatkami wprawdzie w części będzie niemal zerowa, jednak dostrzegalne będą wyraźne kontury poruszających się obiektów, które kompresują się nienajlepiej. Gorzej, jeśli to kamera jest w ruchu, wtedy wszystko na ekranie się porusza i prosta rastrowa różnica dwóch sąsiednich klatek jest znaczna. Właśnie po to kodeki wideo stosują mechanizm kompensacji ruchu, który postaram się zilustrować, podpierając się biblioteką OpenCV.
Archiwum miesiąca: marzec 2014
Demonizacja procesu – linux
Ech… blog miał być o cyfrowym audio/wideo, a tu linux i demony.
Ukończyłem wstępną implementację pewnej aplikacji, która docelowo ma działać jako demon w systemie, czyli działać bezustannie jako usługa, bez bezpośredniej interakcji z poziomu terminala. Typowe aplikacje „konsolowe”, czy to interaktywne, czy nie, po uruchomieniu przypisane są po pierwsze do procesu macierzystego, czyli shella (np bash), a po drugie do terminala sterującego (controlling terminal), którym może być terminal lokalny (tty, konsole w trybie tekstowym komputera), terminal realizowany przez port szeregowy lub modem, czy też pseudoterminal kontrolowany czy to przez serwer zdalnego shella (telnet, ssh), czy przez okienkową aplikację terminala (np. gnome-terminal). Taka aplikacja jest aplikacją interaktywną, zamknięcie czy to shella, czy też terminala poprzez np. przerwanie połączenia powoduje, że shell wysyła do swoich potomków sygnał hang up (czyli SIGHUP) historycznie symbolizujący odłożenie słuchawki telefonu-modemu. Demon, to proces działający bez „pana”, jedynym zwierzchnikiem jest proces init, a demon nie korzysta z terminala, czyli nie posiada standardowego wyjścia, wejścia czy strumienia błędów (stdout, stdin, stderr). Jak przygotować aplikację do roli demona?