Powrót   Forum CDRinfo.pl > Różne > Komputery - oprogramowanie i sprzęt

Komputery - oprogramowanie i sprzęt Pytania i problemy niezwiązane z nagrywaniem, backupem i grami.



Witaj Nieznajomy! Zaloguj się lub Zarejestruj

Zarejestrowani użytkownicy mają dostęp do dodatkowych opcji, lepszej wyszukiwarki oraz mniejszej ilości reklam. Rejestracja jest całkowicie darmowa!

Odpowiedz na post
 
Opcje związane z dyskusją Tryby wyświetlania
Stary 31.07.2015, 10:20   #16
misiozol
Moderator
 
Avatar użytkownika misiozol
 
Data rejestracji: 26.10.2008
Lokalizacja: Carnew
Posty: 6,686
misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>misiozol jest wybitnie uzdolniony i zna sie rzeczowo na sprawach <1500 - 1999 pkt>
Andy stralem sie to znalezc ale gdzies poszlo w dupe , zajrzyj na forum laki tam masz link wyzej , jeszcze bylo forum sat-elita nie pamietam na ktorym byly opisy historyczne , generalnie ciezko jest znalezc cos sensownego jako takiego do nowych aktywnych systemow bo kazdy stara sie aby nie wyciekaly dane , jedyne co mozna znalesc obszernie to jak to dzialalo z 10lat temu ale zasada generalnie jest taka sama tylko bardziej dopracowane chipy itd.

http://sat-elita.net.pl/forum/index.php tutaj sa lepsze opisy
__________________
Reballing, BGA, Reflow, Service of all consoles and devices. Based in IRELAND for all your needs.

Ostatnio zmieniany przez misiozol : 31.07.2015 o godz. 10:37
misiozol jest offline   Odpowiedz cytując ten post

  #ads
CDRinfo.pl
Reklamowiec
 
 
 
Data rejestracji: 29.12.2008
Lokalizacja: Sieć globalna
Wiek: 31
Posty: 1227
 

CDRinfo.pl is online  
Stary 31.07.2015, 16:46   #17
Iskander
Wyjadacz ;)
 
Data rejestracji: 12.10.2009
Posty: 341
Iskander niedługo stanie się sławny ;) <50 - 149 pkt>
andy,wyslalem Ci przeciez kilka rzeczy na PW do poczytania.

moze cos z klasyki gatunku,czyli opisy berzerkera:

Cytat:
1. Szyfrowanie streamu MPEG2 w standardzie DVB:
Przesyłanie w standardzie DVB odbywa się w oparciu o 188-bajtowe pakiety, które są nadawane w streamie cały czas, jeden po drugim. Zadaniem tunera jest dostrojenie się na odpowiednią częstotliwość transpondera i odbiór tych pakietów oraz oczywiście, co najważniejsze, ich interpretacja. Każdy pakiet zawiera w swoim nagłówku tzw. PID (Packet ID), który go identyfikuje. Są różne typy pakietów - video, audio, data. Gdy wchodzisz na jakiś kanał, dekoder dostraja się na odpowiednią częstotliwość, transpondera i ustawia pozostałe parametry, aby zacząć odbierać dane z tego kanału. Parametr APID i VPID każdego kanału odpowiada za wybór pakietów, które zawierają obraz i dźwięk. I dlatego na jednym kanale może być np. kilka ścieżek dźwiękowych - ich przełączanie to po prostu wybór innego APID, do przerabiania dźwięku wykorzystywane są wtedy pakiety audio o danym ID. To, co najbardziej nas interesuje to oczywiście sprawy związane z kodowaniem, więc przejdźmy dalej. Po wejściu na kanał pobierana jest tzw. tablica PMT, z której dekoder wie m.in. czy kanał jest kodowany, w jakich systemach i jakie PIDy mają pakiety niosące dane dla konkretnego providera w konkretnym systemie. Możemy się więc dowiedzieć, że np. dany kanał jest w simulcrypcie z dwoma prov Seca o danych ID oraz w np. Viaccess z 3 providerami i ich ID. Każdy z tych providerów ma przypisany parametr ECMPID, który wskazuje na pakiet danych z odpowiednimi informacjami potrzebnymi do odkodowania obrazu. A są to tzw. ECMy, o których dokładniej za chwilę. ECM to ciąg danych wysyłanych do karty w regularnych odstępach czasu, który odpowiada za deskrypcję. Są jeszcze tzw. EMMy z informacjami wysyłanymi przez operatora na konkretną kartę, wszystkie karty lub grupę kart, w celu wywołania określonych zmian, np. przesłania nowych kluczy, dezaktywacji, zmiany pakietu, itp. Będzie to dokładnie omówione przy okazji systemu Seca. Oczywiście pominęliśmy proces startowy karty. Gdy karta zostanie wsadzona do slotu lub, gdy dekoder startuje z włożoną kartą, jest z niej pobierana mapa providerów wraz z datami uprawnień, informacjami o nr albo, nr seryjny karty itp. Omówię to dokładnie przy okazji opisywania samego protokołu Seca. Następna sprawa to trochę teorii o kodowaniu. Ramki MPEG2 są zakodowane w algorytmie CSA używającym 46-bitowego klucza zmienianego, co 10s. Provider w swoim centrum nadawczym posiada kodery (scramblery) dla każdego kanału, które losują jakąś wartość klucza i za jego pomocą kodują ramki video i audio (chociaż tutaj istnieje rozgraniczenie - może być kodowany np. sam obraz, tak jak w przypadku FreeXTV). Następnym etapem jest stworzenie ECM-a, tzn. ciągu, który wysyłany jest na kartę w celu przetworzenia i podania klucza kodującego obraz. Teraz dokładniej o tym. Klucz, który został wylosowany do zakodowania obrazu na dane kilkanaście sekund wędruje do kodera systemu używanego przez danego providera, gdzie tworzony zostaje ECM. Zawiera on wiele informacji - główna to CW czyli zakodowane słowo, które musi zostać odkodowane przez kartę i wynik wysłany dekoderowi. Poza tym jest wiele innych informacji takich jak data uprawnień, ID providera, maska pakietu, itp. Bez odpowiednich wartości któregoś z nich CW nie zostanie odkodowane, ale dokładnie będzie to omówione podczas opisu systemu Seca. Wracając do wyniku wysyłanego dekoderowi przez kartę po przetworzeniu ECMa to jest to tzw. DW (decrypted word - odkodowane słowo), i jest to nic innego jak ten klucz, który został użyty podczas kodowania ramek i za pomocą, którego nastąpi dekrypcja w descramblerze odbiornika, żeby można było oglądać. Więcej o CW - dokładnie są 2 zakodowane słowa, każde po 64 bajty. Po odkodowaniu dostajemy 2 DW, również każde po 64 bajty, przy czym do odkodowania obrazu w descramblerze odbiornika przy pomocy algorytmu CSA używanych jest tylko 46 pierwszych bitów, ponieważ jest to właśnie ten 46-bitowy klucz, którym zakodowano ramki. Teraz pytanie po co 2 CW oraz DW a nie jedno? Ano dlatego, żeby zapewnić płynność oglądania. Przypuśćmy, że aktualnie obraz kodowany jest przy użyciu klucza A. Koder CSA losując klucz zawsze losuje również drugi, który będzie użyty do kodowania po tym okresie 10-sekundowym ważności danego klucza. Czyli mamy 2 klucze, z których tworzone są 2 CW. Wchodzimy na kanał i karta dostaje ECM z danymi CW. Pakiety danych zawierające aktualny ECM lecą cały czas, więc możemy wejść na kanał w dowolnej chwili i zawsze tuner będzie w stanie wyciągnąć aktualny ECM ze streamu bez czekania na jego zmianę. Po odkodowaniu tuner otrzymuje 2 DW. Pierwsze zostaje użyte od razu do dekodowania, a drugie wędruje do bufora. Gdy minie czas ważności danego klucza (max 10s gdy włączymy zaraz po zmianie klucza), kolejny jest pobierany z bufora, a do karty zostaje wysłany kolejny ECM ze streamu zawierający znów 2CW, z czego pierwsze jest takie samo jak to użyte aktualnie do odkodowywania. DW obliczone z drugiego CW wędruje do bufora i czeka 10s na swoją kolej. I tak w kółko. Czyli CW, a tym samym DW zmieniają się w kolejności: ECM1 - A B, ECM2 - B C, ECM3 - C D, itd. Potrzebne jest buforowanie drugiego DW po to, aby dekoder był odporny na rwanie obrazu. Gdyby nie było następnego klucza, ECM musiałby zostać wysłany bardzo szybko do karty, a wiadomo, że mogą się zdarzyć różne przypadki, dekoder załapie jakieś opóźnienie, albo karta się nie wyrobi, itp. Wiemy już, więc jak zachodzi samo dekodowanie obrazu. Parametr ECMPID jest potrzebny, aby do karty dochodziły odpowiednie ECMy. Jeśli kanał nadawany jest w kilku systemach możemy więc zmieniając ten parametr wybrać danego providera w interesującym nas systemie. Oczywiście, jeśli chodzi jeszcze o możliwość odbioru ECMów przez tuner i wysyłanie ich do karty to muszą zajść również inne warunki niż tylko dobrze ustawiony ECMPID. Podczas pobierania danych z karty podczas jej startu tworzona jest mapa providerów. Na jej podstawie tuner wie czy na włożonej karcie jest provider, do którego są kierowane ECMy providera wybranego z tablicy PMT. Jeśli go nie ma to ECMy nie będą słane do slotu. Jeśli chodzi o oprogramowanie multisystemowe to tutaj sprawa się komplikuje, bo ECMy innych systemów teoretycznie wogóle nie powinny być słane do karty Seca. Jednak znaleziono na to sposoby i istnieją 2 rodzaje oprogramowań - AllCam i MultiCam. Oba różnią się sposobem kierowania ECMów systemów innych niż Seca do kart rozkodowywujących opartych o protokół Seca. Opowiem o tym dokładniej przy zagadnieniu multisystemu, bo nie jest to ściśle związane ze sprawą kodowania obrazu. Nas interesuje tylko w tej chwili, że dekoder musi puścić do karty odpowiedni ECM, karta musi go przetworzyć i dać DW do odkodowania obrazu w descramberze odbiornika. Należy, więc z tego tekstu zapamiętać, że kodowanie obrazu jest zawsze takie samo (CSA) w przypadku dowolnego systemu kodowania. Zadaniem całości dekodowania w danym systemie jest tylko podanie przez kartę prawidłowych DW, żeby mogła zajść dekrypcja w descramblerze. Dzięki temu każdy dekoder jednosystemowy można teoretycznie przekształcić w wielosystemowy. Jedyny warunek, które trzeba spełnić to umożliwienie dojścia odpowiednich ECMów do karty, a potem już normalnie odbiór DW i podanie ich do descramblera, co zachodzi w każdym odbiorniku standardu DVB. Oczywiście karta musi umieć rozkodowywać CW w danym systemie. Zamiast karty może być oczywiście EMU, ale jego zadanie jest dokładnie takie samo. W oprogramowaniu podpięta jest procedura przetwarzająca i dekodująca ECMy różnych systemów w miejsce wysyłania ECMów do karty oraz procedura zwracająca obliczone DW w miejscu ich odbioru z karty. Tak, więc wszystko zachodzi jakby karty nie było, ale zasada jest dokładnie taka sama.

2. Komunikacja tunera z kartą Seca i protokół ISO7816:
Tuner komunikuje się z kartą używając jednożyłowego protokołu szeregowego. Jest to komunikacja typu half-dupex, czyli w jednym czasie urządzenie tylko nadaje lub tylko odbiera dane. Podczas nadawania urządzenie nie może odbierać i odwrotnie. Protokół szeregowy używany do komunikacji jest taki sam jak w przypadku standardu RS232, czyli przesyłanie pojedynczych bajtów danych. Omówię format bajtu dla protokołu ISO7816 używanego przez Seca, gdyż mówimy tyko o tym systemie. Bajt jest zbudowany wg następującego schematu:
t01234567pss
gdzie:
t-bit startu
0:7-bity danych w kolejności od najmniej do najbardziej znaczącego
p-bit parzystości
s-bit stopu
Komunikacja odbywa się z brędkością 9600 bitów na sekundę. A ponieważ cały bajt to 12 bitów to nie należy mylić prędkości 9600 z ilością przesyłanych bajtów na sekundę. Gdy żadne z urządzeń nie nadaje danych linia jest w stanie wysokim. Aby zainicjować komunikację nadajnik ściąga linię do zera. I jest to własnie bit stopu, który ma zawsze wartość 0. Następnie następuje wysyłanie 8 bitów danych w kolejności od bitu najmniej do najbardziej znaczącego. Po wysłaniu danych kolejny bit to bit parzystości. W przypadku ISO7816 parzystość jest w trybie Even, co oznacza, że ten bit przyjmuje wartość 1 gdy w 8 bitach danych jest parzysta ilość jedynek, a 0 gdy w 8 bitach danych jest nieparzysta ilość jedynek. Ma to na celu wyeliminowanie błędów przesyłu na linii w przypadku przekłamań pojedynczych bitów. Czyli jeśli bit parzystości nie ma odpowiedniej wartości to nastąpiło przekąłmanie jakiegoś bitu i bajt zostaje uznany za niewłaściwy. Po bicie parzystości następują 2 bity stopu, które mają zawsze wartość 1. Czyli po prostu linia jest zwalniana na okres trwania co najmniej 2 bitów i dopiero po tym czasie może być zainicjowane wysyłanie kolejnego bajtu. Jak już wcześniej wspominałem, iość bitów wysyłanych na sekundę to 9600, więc każdy pojedynczy bit musi trwać 1/9600 sekundy, a cały bajt w konsekwencji 12/9600 sekundy. Karty Seca są taktowane zegarem 3,579MHz i ta prędkość odpowiada 372 taktom zegara. Procesor w karcie nadając lub odbierając bajt, wysyłą lub odbiera kolejne bity właśnie po upływie 372 taktów od rozpoczęcia wysyłąnia ub odbierania aktualnego. W przypadku odbioru musi oczywiście poczekać czas 1,5 bita po wykryciu bitu startu i dopiero po upływie tego okresu zacząć odczytywać kolejne bity, żeby odczyt wypadał zawsze na śreodku okresu nadawania przez tuner. Teraz przykłady jakichś przesyłanych bajtów (jeśli ktoś chciałby to jeszcze zobaczyć w praktyce):
- wartość: 0x3B=00111011b, format przesyłanego bajtu: 011011100111
- wartość: 0x7D=01111101b, format przesyłanego bajtu: 010111110011
- wartość: 0x5C=01011100b, format przesyłanego bajtu: 000111010011
To by było tyle jeśli chodzi o stronę sprzętową. Teraz omówię strukturę logiczną protokołu ISO7816. Po pierwsze komunikacja jest zawsze inicjowana przez tuner. Czyli karta sama nie może zgłosić się do tunera, dopiero on musi wysłać odpowiednią komendę i dopiero wtedy wysłać, albo odebrać od niej odpowiednie dane. Każda instrukcja wysyłana do karty ma 5-bajtowy nagówek o budowie:
CLA INS P1 P2 LEN
gdzie:
CLA - klasa
INS - numer instrukcji
P1 - parametr pierwszy
P2 - parametr drugi
LEN - długość bloku danych
Klasa oznacza w jakim systemie pracuje tuner i jest zawsze stała dla danego systemu i jednakowa dla wszystkich komend. W Seca klasa ma wartość 0xC1 (dla przykładu inne systemy, których karty również używają protokołu ISO7816 mają klasy: Viaccess - 0xCA, Conax - 0xDD, EuroCrypt - 0x87). Parametr INS wskazuje na numer instrukcji, którą ma wykonać karta. Każdy system może mieć inne instrukcje i ich numery, więc to już od tego zależy. Spis wszystkich instrukcji Seca będzie omówiony przy okazji omawiania samego systemu. Parametry P1 i P2 również zależą od systemu oraz instrukcji i niosą różne dane potrzebne do wykonania instrukcji. LEN to długoąść bloku danych, które zostaną wysłane lub odebrane z karty. Teraz dokłądniej o wysyłaniu instrukcji. Gdy tuner musi pobrać lub wysłać jakieś dane do karty, tak jak już wcześniej powiedziałem, musi do niej wysłać pięciobajtowy nagłówek. Ogólną budowę procesu porozumiewania się karty z tunerem można przedstawić tak:
>CLA INS P1 P2 LEN
<INS lub SW1 SW2
> lub < blok danych
<SW1 SW2
gdzie:
> - tuner wysyła do karty
< - karta wysyła do tunera
SW1 SW2 - 2 bajty statusu
Jak widać tuner wysyła najpierw do karty 5-bajtowy nagłowek. Następnie karta przetwarza ten nagłówek. Najpierw sprawdzana jest klasa, potem instrukcja, a następnie długość. Jeśli wszystko się zgadza karta w odpowiedzi podaje bajt acknowledge, czyli po prostu numer instrukcji. Wtedy tuner wie, że wszystko ok i w zależności od tego jaka to instrukcja zaczyna odbierać lub wysyłać bajty z/do karty. Ilość tych bajtów jest określona przez parametr LEN. Po odebraniu wszystkich bajtów karta przetwarza je i w odpowiedzi daje 2 bajty statusu. Infrmują one o tym jak wykonała się instrukcja. W zależności od systemu mogą być tutaj rozbieżności. Generalnie status 0x90 0x00 informuje, że wszystko przebiegło ok. Ale niekoniecznie, bo np. w przypadku EMMów jeśli zaszły zmiany na karcie to drugi bajt statusu informuje jakie dane zostały wpisane, więc nie jest to wartość 0x90 0x00. Możliwe statusy we wszystkich instrukcjach Seca będą omówione dalej przy omawianiu samego systemu Seca. Jeśli instrukcja wymagała od karty podania jakichś danych to oczywiście po wysłaniu ich przez kartę nic już nie jest przetwarzane i status jest z reguły 0x90 0x00. Wróćmy jeszcze do przetwarzania przez kartę nagłówka. Napisałem co się dzieje jak wszystko się zgadza i karta odpowiada bajtem acknowledge równym INS. Jak widać ze schematu może być inaczej. Są 3 przypadki błędów w nagówku jeśli chodzi o protokół ISO7816:
- nieprawidłowa klasa: status 0x6E 0x00
- nieprawidłowa instrukcja: status 0x6D 0x00
- nieprawidłowa długość bloku danych: status 0x67 0x00
Jeśli wystąpi któryś z tych błedów to karta zamiast bajtu acknowledge zwraca odpowiedni status i transmisja jest na tym kończona. Jeśli nie wystąpi któryś z tych błędów to karta zawsze musi dać bajt acknowledge. Nawet jeśli w jakimś systemie podamy np. nieprawidłowy parametr P1 to będzie on przetworzony dopiero później i odpowiedni status oznaczający błąd zostanie wysłany na końcu instrukcji. Na koniec należy jeszcze wspomnieć o czymś takim jak ATR. Jest to ciąg wysyłany przez kartę po jej resecie. NA podstawie tego ciągu tuner rozpoznaje kartę. Jeśli ATR nie zostanie wysłany przez kartę w ciągu kilku milisekund od startu karty (dokładna długość czasu na wysłanie ATR przez kartę zależy od typu tunera) to tuner uzna, że jej nie ma i odączy napięcie od slotu. Po podaniu przez kartę prawidłowego ATR tuner wie, że karta jest w slocie i wtedy może zacząć się z nią komunikować w opisany wcześniej sposób. ATR zawiera informacje o sposobie komunikowania się karty z dekoderem. Określa więc czy jest użyty normalny system przesyłu bitów czy też odwrócony (bit danych o wartości 0 ma wtedy wartość logiczną 1, a o wartości 1 ma wartość 0), prędkość transmisji, kierunek podawania bitów danych, itp. Karty systemu Seca mają ATR o długości 16 bajtów i jego budowa wygląda następująco:
- odczytany z karty v4.0: 3B F7 11 00 01 40 96 54 30 04 0E 6C B6 D6 90 00
- odczytany z karty v7.0: 3B F7 11 00 01 40 96 70 70 07 0E 6C B6 D6 90 00
Nie będziemy omawiać wartości poszczególnych bitów w odpowiednich bajtach, gdyż nie będzie to nam potrzebne. Wiadomo, że kart Seca porozumiewają się z prędkością 9600 bitów na sekundę, mają bity niezanegowane, bity danych podawane w kolejnościod najmniej do najbardziej znaczącego. Każda karta Seca pracuje przy takich parametrach. Jedynie trzeba zwrócić uwagę na 10-ty bajt w ATR. Oznacza on wersję karty w systemie Seca. Przy czym zamienione są miejscami 4 młodsze i starsze bity, więc w podanych przypadkach wartość 0x04 oznacza wersję 4.0, a 0x07 oznacza wersję 7.0. Karty v4.1 mają wartość tego bajtu równą 0x14, itd.

Bezerker 2004

Opis struktury PMT, CAT:
Cytat:
1. AllCam-em ogólnie określa się oprogramowanie, które umożliwia wybór ECM-PID'u z PMT dla innego systemu niż CAM znajdujący się w odbiorniku. MultiCam to w przypadku systemu Seca połączenie AllCam-a z odpowiednim patchem ECM managera.

Może przedstawmy to wszystko na przykładzie systemu SECA/MediaGuard, bo właściwie na dobrą sprawę te 2 określenia zawierają w sobie historię ewoluowania softów na przełomie kilku ostatnich lat.

W PMT CA_descriptory SECA mają taką strukturę:
09 11 01 00 PID PID ID ID xx xx PBM PBM PBM PBM PBM PBM PBM PBM ...
gdzie:
09 - tag dla CA_descriptora 11 - LEN
01 00 - CA_ID = SECA
PID PID - 14-bitowa wartość ECM-PID-u (16 bajtów, z czego 2 pierwsze bity zawsze = 1)
ID ID - ID providera
PBM... - wartość PBM z ustawionymi bitami dla pakietów, w których znajduje się dany kanał

Dekoder po wejściu na dany kanał odczytuje z PAT transpondera (czyli tablica lecąca zawsze na PID=0x0000) PID pod którym leci tablica PMT dla kanału, na który weszliśmy. Następnie skanuje PMT i znajduje pola z opisami streamów tego kanału. Oczywiście każdy stream ma przyporządkowany PID i niektóre streamy posiadają w swoich polach opisu tzw. descriptory. W polach opisu MPEG Audio i Video znajdują się właśnie CA_descriptory, dzięki którym odbiornik wie w jakich systemach kodowany jest kanał. CA_descriptory mogą być też w polu głównym PMT i wtedy dotyczą wszystkie następnych streamów A/V, dzięki czemu cała PMT jest krótsza. Odbiorniki Seca szukają CA_descriptorów z CA_ID = 0x0100 i jeśli takowy znajdą to zaczynają go przeszukiwać pod kątem zawartych w nich danych. Najpierw sprawdzany jest ident, w tabeli providerów pobranej z karty za pomocą ins 0x16, 0x12 oraz 0x34/0x32 oprogramowanie szuka ID znajdującego się w danych descriptorze. Jeśli go niej znajdzie to pomija te CA_descriptor i skanuje dalej. Jeśli znajdzie ID to dalej wykonuje sprawdzenia PBM. Wartość z CA_descriptora poddaje funkcji AND z wartością ciągu PBM odpowiedniego providera na karcie o określonym wcześniej ID i jeśli wynik jest niezerowy to znaczy, że dany kanał jest w jakimś pakiecie, który opłacamy (co najmniej jeden bit zapalony) i następnie ustawia dalej odpowiedni ECM_PID=PID PID i od tej pory procesor przetwarza każdy pakiet PES odebrany z tego PID-u i kieruje go do ECM managera gdzie poddawany jest operacjom mającym na celu zweryfikowanie go i późniejszym wysłaniu do karty. Jeśli PBM się nie zgadza to w przypadku Philips będziemy mieli info o braku uprawnień i brak ECM-ów w slocie, w przypadku MediSatów czarny ekran i brak ECM-ów w slocie. Softy AllCam polegają na tym, żeby zafałszować skaner PMT i umożliwić oprogramowaniu rozpoznanie danego CA_descriptora jako CA_descriptor Seca. Dzięki temu tuner ustawia sobie odpowiedni ECM-PID i od tej pory wszystkie ECM-y nie-Seca z tego ECM-PID będą przetwarzane przez ECM manager. Można też wogóle ominąć skanowanie przez oryginalną partię softu skanowanie PMT i na sztywno ustawić żądaną wartość ECM-PID. Rozwiązania mogą być dowolne, ale główne założenie jest takie, żeby po prostu tuner ustawił odpowiedni ECM-PID bez względu na system. W tym miejscu pozdrawiam @PJotr'a, bo to on stworzył piękny system skanowania PMT, wcześniej w softach multisystemowych Dynamita tuner zawsze łapał pierwszy ECM-PID dla zadanego systemu. MultiCam (w znaczeniu softu o takiej nazwie) to zmienił i każdy mógł sobie na ekranie skanować całą PMT podglądając systemy oraz ID (w wypadku Seca i Viaccess, bo tylko te 2 systemy mają ID providera w CA_descriptorze) wybierając dowolne PID według preferencji.

2. Teraz o ECM managerze

Po ustawieniu przez soft ECM-PID wszystkie pakiety PES odbierane ze streamu na danym transponderze (jak wiadomo stream składa się z elementarnych 188-bajtowych pakietów) będą kierowane do ECM managera, który sprawdzi je pod względem poprawności i sformatuje tak, żeby mogły być wysłane do karty. W przypadku systemu SECA nagłówek każdego ECM-a precam (czyli tak jak jest odbierany przed sformatowaniem) wygląda tak:
80/81 00 LEN ID ID 00 KEYINDEX P2 ...
gdzie:
80/81 - bajt nagłówka ECM wg standardu DVB
LEN - długość ciągu
ID ID - ID providera
KEYINDEX - przełącznik key primary/secondary
P2 - wartość P2, która będzie wysłana w nagłówku ECM-a idącego do karty (czyli jak wiadomo zawiera m.in. wartość klucza - młodsze nibble)

Po odebraniu pakietu ECM manager sprawdza pierwszy bajt czy jest to ECM. Jeśli tak to dalej sprawdzany jest ID providera. Musi istnieć takowy na karcie, żeby software wiedział, jaką ustawić wartość młodszego nibble P1, czyli nr tego providera na karcie. Przy czym nie jest wykonywane sprawdzanie czy ident w ECM-ie zgadza się z identem w PMT (mam na myśli soft Philipsów, Kenów i Pionków, reszta pewnie też, ale nie wypowiadam się bo nie analizowałem osobiście). Jeśli ident w nagłówku ECM-a jest na karcie to dalej już wszystko leci z górki i soft puszcza ECM od bajtów za P2 do karty. Ponieważ w sofcie AllCam ECM manager nie był patchowany to jak widać po umożliwieniu wyboru ECM-PID nie-Seca jedyne, co musimy zrobić to umieścić na karcie odpowiedniego fake providera, czyli po prostu ident i wartości takiej jak w ECM-ie nie-Seca będzie się znajdowała na odpowiedniej pozycji w nagłówku. Oczywiście to rozwiązanie ma dużo wad, bo zmuszeni jesteśmy umieszczać wiele takich fake identów i czasem nie mieszczą się na karcie. Np. w przypadku systemu Conax akurat na tym miejscu bajty w nagłówku ECM-ów bardzo często się zmieniają i czasem brakuje miejsca na wszystkie możliwe kombinacji. Przełomem był system MultiCam, czyli tzw. BEEF patch zwany potocznie właśnie MultiCam od nazwy softu, jaką MultiCam Team wypuścił jako pierwszy z tym rozwiązaniem. W przypadku MultiCama ECM manager był tak zmodyfikowany, że każdy ECM nie-Seca był odpowiednio formatowany i wysyłany do jednego fake providera o idencie BEEF. Czyli mając ECM w precam:
80/81 00 LENprecam ...
Który nie jest ECM-em Seca, po konwersji będzie miał format:
80/81 00 LENprecam+5 BE EF 00 00 P2=00
Także po wysłaniu do karty będziemy mieli:
C1 3C xx 00 LEN [wszystkie bajty ECM-a innego systemu]
Dzięki temu nie trzeba umieszczać już masy fake identów i otrzymujemy pełny, nieobcięty ECM innych systemów.
Soft EMU to już z punktu widzenia zmian w głównym kodzie tylko modyfikacja ECM managera polegająca na wstępnym przetwarzaniu ECM-ów przed wysłaniem ich do karty. Procedury dekodujące i przetwarzające ECM sprawdzają czy są go w stanie poprawnie zdekodować i wyliczyć DW. Jeśli tak to robią dismiss ECM-a, żeby nie szedł już do karty i podają bezpośrednio do descramblera wyliczone DW. Jeśli kod EMU uzna, że nie jest w stanie poprawnie zdekodować danego ECM-a, albo nie ma odpowiednich danych (nr providera, klucze) to wraca normalnie do ECM managera i po odpowiednim sformatowaniu jest wysyłany do karty.
3. To dla zakończenia dodajmy jeszcze o CAT.

Jest to tablica przesyłana zawsze na PID=0x0001 każdego transpondera i zawiera w swojej strukturze dane identyfikujące dane management dla różnych systemów kodowania. Nie są one potrzebne do oglądania kanałów jak to było w przypadku PMT. Tam obecność CA_descriptora przy opisie streamu mówiła, że program jest kodowany i musi zajść dekrypcja ECM-ów, aby oglądać. W CAT są same CA_descriptory i opisują PID-y, na których są wysyłane EMMs róznych systemów kodowania. Po wejściu na dany transponder, tuner odbiera CAT i szuka CA_descriptorów odpowiedniego systemu, a następnie po pomyślnym przeanalizowaniu ustawia odpowiednie filtry, na podstawie których będą odbierane pakiety PES zawierające EMM-y, które potem przekazane zostaną do EMM managera, który po odpowiednim przeanalizowaniu i przefiltrowaniu skieruje je do karty. CA_descriptor w CAT dla systemu SECA wygląda:
09 09 01 00 PID1 PID1 01 PID2 PID2 ID ID
gdzie:
09 - tag
09 - len
01 00 - CA_ID = SECA
PID1 PID1 - wartość EMM-PID dla EMM-ów na UA
PID2 PID2 - wartość EMM-PID dla EMM-ów na SA


4. I na koniec dokończenie o EMMs.

Teraz jak juz tuner przeskanował CAT i znalazł CA_descriptor dla SECA, który go interesuje, sprawdza czy istnieje dla niego provider o ID ID na karcie (w tabeli providerów w pamięci). Jeśli tak to ustawia odpowiednie filtry na odbiór pakietów z EMM-ami. Są to:
82 xx xx 00 00 UA UA UA UA ID ID ...
86 xx xx 00 00 UA UA UA UA ID ID ...
83 ...
84 xx xx ID ID SA SA SA ...
gdzie:
ID ID - ident providera
UA UA UA UA - serial karty
SA SA SA - grupa, do której należy PPUA danego providera

Następuje ustawienie filtrów, które powodują, że jedynie ciągi pasujące do powyższych masek będą odebrane i przetworzone przez EMM manager. Dodam, że filtr 84 dla EMM-ów SA jest tworzony dla każdego providera, więc w sumie mamy 1 filtr 82, 1 filtr 86 (identyczny jak 82), 1 filtr 83 (poza 83 na pierwszym bajcie nie ma innych kryteriów, więc taki EMM powędruje do wszystkich kart) oraz tyle filtrów 84 ilu mamy providerów na karcie. Ustawienie filtrów pozwala na łapanie tylko PES-ów dla odpowiedniej karty/grupy i nie zapycha pracy odbiornika masą informacji management, która leci non-stop.

Jeśli po ustawieniu filtrów dekoder trafi na pakiet odpowiadający którejś z masek, przekazywany jest on do EMM managera i tam następuje jego przetworzenie przed ewentualnym wysłaniem do karty. Na początku standardowo sprawdzany jest pierwszy bajt czy należy do przedziału 0x83-0x8F (EMM wg specyfikacji DVB). Jeśli tak to dalej przejmuje pałeczkę jedna z podprocedur, która odpowiada za typ tego EMM-a. Jeśli EMM nie jest kierowany do wszystkich kart (83) to musi jeszcze zostać sprawdzona obecność danego providera na karcie i ustalenie jego numeru, żeby stworzyć młodsze nibble P1 instrukcji, która zostanie wysłana do karty.

Bezerker 2004

jeszcze cos starszego, tym razem bardziej o technologii DVB piora kolegi Anubis1:
Cytat:
Od razu na wstępie zastrzegam, że wszystko to, co napisane jest poniżej, nie jest żadną wiedzą tajemną ani odkrywczą. Poszukiwacze sensacji, zwolennicy spiskowych teorii świata oraz uniwersalnych teorii wszystkiego na pewną znajdą gdzieś interesujące ich prawdy niepodważalne. Poniższa wiedza została skompletowana z ogólnie dostępnych (na ogół) źródeł, przede wszystkim były to oficjalne dokumenty organizacji powołanych do standaryzacji naszego codziennego życia (co w przypadku świata elektroniki zwykle ma sens), czyli ETSI i ISO. Część informacji pochodzi z niewyczerpanego źródła, jakim są kody i dokumentacje programów dla Linuxa. Jeżeli któryś z czytelników poczuje niedosyt po przeczytaniu tego dokumentu (a mówiąc szczerze, mam taką nadzieję), to z pewnością znajdzie w Sieci kolejne informacje. A teraz do rzeczy...
Digital Video Broadcasting to po prostu cyfrowa telewizja. A dlaczego jest (staje się) tak popularna i wypiera transmisje analogowe? Z powodu lepszej jakości obrazu? Każdemu na pewno zdarzyło się widzieć cyfrowy przekaz ledwie dający się oglądać i wspaniałej jakości audycje "łapane" na zwykłej antenie naziemnej. Jakość obrazu jest przede wszystkim chwytem reklamowym, choć oczywiście trzeba przyznać, że telewizja cyfrowa dzięki swej naturze, jest dużo mniej uzależniona od parametrów samego sygnału (odległości od stacji nadawczej, zakłóceń, dostrojenia itp.). Zazwyczaj albo mamy obraz o dokładnie takich parametrach, jak "spada" z nieba albo nie ma go w ogóle. Jakość sygnału przy jakiej obraz "cyfrowy" jest ciągle poprawny, nie pozwoliłaby na przesłanie dobrego obrazu analogowego. Ale przede wszystkim chodziło (i ciągle chodzi) o pieniądze. Nadawcy, którzy w tę technologię zainwestowali (przynajmniej na początku, zanim odzyskali z nawiązką "kaskę" od klientów), musieli widzieć perspektywy wymiernych korzyści w niebagatelnych wydatkach. A spodobały im się głównie dwie sprawy: dużo mniejsze zapotrzebowanie na pasmo przesyłowe i łatwość aplikowania dostępu warunkowego, czyli pozwolenia na oglądanie tylko płacącym abonentom. Mniejsze zapotrzebowanie na pasmo skutkuje w praktyce mniejszymi kosztami przekazu - zamiast jednego programu analogowego można nadawać osiem cyfrowych o takiej samej (lub lepszej) jakości (lub piętnaście "nieco" gorszych, jak udowadniają niektórzy, również rodzimi, providerzy). Najszybciej "przezbrojona" została telewizja satelitarna (DVB-S) - kolejne kanały analogowe, z których każdy zabierał jeden transponder (moduł satelity telekomunikacyjnego nadający sygnał o określonej częstotliwości i polaryzacji), znikają i są zastępowane przez paczki programów cyfrowych. Nieco wolniej pojawiają się cyfrowe kanały naziemne (DVB-T) i kablowe (DVB-C), ale i tu nie ma odwrotu od cyfryzacji.
W niniejszym "opracowaniu" przyjąłem, że czytelnik ma pewną podstawową wiedzę na temat telewizji satelitarnej i odróżnia od siebie elementy składowe zestawu odbiorczego. Ponieważ jednak pewne pytania powtarzają się na forach dyskusyjnych nagminnie, przytoczę kilka zasadniczych informacji. Przekaz satelitarny (niezależnie od tego, czy przesyłane są dane cyfrowe, czy też obraz i dźwięk analogowy), charakteryzuje się bardzo wysoką częstotliwością (pasmo Ku, popularne na satelitach "wiszących" nad Europą, to zakres ~10.7 GHz do ~12.7 GHz ) oraz spolaryzowaniem. Polaryzacja (rozróżniamy dwa jej rodzaje: "normalną", czyli pionową i poziomą oraz - rzadziej - kołową, czyli lewo- lub prawo-skrętną), pozwala na dodatkowe zwiększenie pojemności pasma przez umieszczenie na tej samej pozycji orbitalnej dwóch transponderów o tej samej (lub bardzo podobnej) częstotliwości, ale różnie spolaryzowanych. Ponieważ odstęp pomiędzy kolejnymi transponderami powinien wynosić ok. 40 MHz (aby uniknąć interferencji i zakłóceń), na jednej pozycji (nie piszę na jednym satelicie, bo jest ich zazwyczaj kilka i najstarsze są sukcesywnie zastępowane w miarę zużywania) można zmieścić ok. 100 transponderów. Oczywiście sytuacja zmienia się, kiedy wiązki tych transponderów nie zachodzą na siebie (są przeznaczone dla różnych obszarów Ziemi), ale nie będziemy tu przecież dzielić włosa na czworo. Każdy odbiornik satelitarny - również karta DVB do PC-ta - jest wyposażony w tuner, dość podobny do tego, jaki znajduje się w zwykłym telewizorze - poza kilkoma niuansami. Z naszego punktu widzenia najważniejsze różnice są następujące:
• tuner zasila urządzenia, które są do niego przyłączone przez przewód koncentryczny. W najprostszym przypadku jest to pojedynczy konwerter, częste są też instalacje z kilkoma konwereterami podłączonymi przez przełącznik DiSEqC, zdarzają się również siłowniki i pozycjonery. Każde takie urządzenie potrzebuje określoną ilość prądu, zazwyczaj tym większą im jest starsze (ma tu znaczenie zarówno wiek danego egzemplarza jak i jego konstrukcji i prądożerność użytych elementów). "Przeładowanie" magistrali zasilanej z pojedynczej karty bez żadnego wspomagania jest częstą przyczyną kłopotów, zwłaszcza jeśli zasilacz waszego PC-ta pracuje na granicy swoich faktycznych możliwości. Żeby sprawę wyjaśnić dogłębnie, potrzebny byłby dłuższy wykład, ale ja postaram się pokrótce: najwęższym gardłem jest zasilanie karty DVB przez magistralę PCI w komputerze. Bardzo dużo zależy od konstrukcji płyty głównej, ale specyfikacja przewiduje do 25W na kartę, przy czym na 12V maksymalnie 500 mA, reszta jest dostępna przy napięciu 5V. To napięcie tuner (a właściwie przetwornica w tunerze) musi przerobić na 13V lub 18V dla konwetera (od jakości tego układu zależy m.in. jak mocno karta się grzeje podczas pracy). Oczywiście na przetwornicy są pewne straty, część energii karta musi też "poświęcić" na zasilanie samej siebie. Dalej następują straty na kablu, tym większe im kabel dłuższy i starszy (gorszej jakości). Na końcu jest (przyjmijmy, że tylko jeden!) konwerter, wystawiony na bardzo różne warunki pracy. Jak widać łańcuch jest długi i składa się z samych słabych ogniw. Ale, żeby nie straszyć nadmiernie: trzeba wszystko samemu zmontować i sprawdzić "w boju", bo niekoniecznie najdroższe i markowe elementy muszą dawać najlepsze efekty (zwłaszcza, gdy i droższe i tańsze powstają w tych samych chińskich fabrykach). Najtrudniej mają użytkownicy siłowników, ale i takie instalacje się udają. Jeśli więc ktoś upadł na duchu po przeczytaniu powyższych słów, to teraz przynoszę pocieszenie: przynajmniej połowa DVB-maniaków to farciarze, którzy żadnych problemów sprzętowych nie mają.
• tuner generować musi dwa różne napięcia: ok. 13V i ok. 18V, a jest to związane ze wspominaną wcześniej polaryzacją sygnału z satelity. Ustawione przez tuner napięcie jest dla konwertera informacją, do jakiej polaryzacji ma się dostroić: 13V oznacza polaryzację poziomą, zaś 18V - pionową.
• zakres częstotliwości pracy tunera to 950 Mhz do 2150 Mhz. Jak to się ma do wspominanych wyżej gigaherców "spadających" z nieba? Do tego właśnie jest konwerter (z angielska nazywany też LNB - low noise block). On "odejmuje" od częstotliwości pewną wartość nazywaną LOF (znowu ten angielski: Local Oscillator Frequency), tak aby dopasować sygnał do możliwości tunera. W tym miejscu być może czujny czytelnik zauważy: zakres pasma Ku to ok. 2 Ghz (10.7 do 12.7), a tuner "łapie" częstotliwości o zakresie 1.2 Ghz. Jak to możliwe? Otóż konwerter (a przynajmniej ten stosowany w Europie, tzw. uniwersalny) ma dwie wartości LOF. Konwerter uniwersalny ma LOF1=9.75 Mhz i LOF2=10.6 Mhz. Wielkość obniżenia częstotliwości przez konwerter (czyli LOF1/LOF2 albo inaczej zakres: Lo/Hi) jest ustalana przez tuner, który dla zakresu Hi generuje sygnał o częstotliwości 22 kHz, który "nakładany" jest na napięcie zasilania. Częstotliwość satelitarna, przy której następuje zmiana zakresu (oznaczana jako LOFSwitch) to zwykle 11.7 Ghz, czyli połowa zakresu pasma Ku. Jak widać z powyższego wywodu, w zależności od wybranego zakresu i napięcia 13/18V, ta sama częstotliwość tunera może odpowiadać zupełnie różnym transponderom na satelicie.
Najlepiej wyjaśni to przykład:
Na tunerze wybieramy częstotliwość 970 Mhz. Dla zakresu Lo (brak sygnału 22 kHz) i przy napięciu 13V, daje to transponder oznaczany jako (970+9750=) 10720V. Dla naszego ulubionego HotBirda (13° East) oznacza to tp110 (10719V, Cyfra+). Po zmianie napięcia na 18V tuner dostroi się do transpondera tp111 (10723H, British Telecom). Po dodaniu sygnału 22 kHz, tuner najprawdopodbniej "złapie" tp153 (11566H, Trinity Broadcasting). Zwróćmy uwagę, że częstotliwość tego transpondera jest poniżej LOFSwitch! Wynika to z faktu, że część transponderów z środka zakresu (~11.55 Ghz do ~11.9 Ghz) daje się "złapać" na dwa sposoby: ustawiając zakres Lo na konwerterze i wysoką (powyżej 1950 Mhz) częstotliwość na tunerze, lub odwrotnie: zakres Hi i niską (poniżej 1150 Mhz) na tunerze. Tunery stacjonarne mają zwykle stosunkowo ograniczony zakres ustawień, oprogramowanie do kart DVB jest bardziej elastyczne, ale łatwiej "zrobić sobie krzywdę". Błędne wprowadzenie wartości LOF1, LOF2 i LOFSwitch jest częstą przyczyną niemożności dostrojenia się do niektórych transponderów - ustawienia tunera i konwertera rozsynchronizowują się i elementy układanki nie mogą dojść do porozumienia. Trzeba też pamiętać, że zdarzają się konwertery, które mają inne (nieco) wartości LOF, ale taką informację producent zawsze umieszcza na obudowie urządzenia. Natomiast częstotliwość przełączania (LOFswitch) może być w zasadzie wybrana dowolnie, jest to tylko informacja dla programu/sterownika, jaki zakres należy ustalić dla jakich transponderów. Naturalnie przyjęcie wartości spoza zakresu 11.55 do 11.9 Ghz spowoduje niemożność dostrojenia się do niektórych częstotliwości satelitarnych. Dlatego najlepiej trzymać się powszechnie stosowanej 11.7 Ghz.
Jeszcze jedna istotna cecha odróżnia odbiorniki satelitarne od odbiorników analogowego sygnału naziemnego: często oprócz wejścia antenowego (LNB in) mają również wyjście (LNB out), do którego można podłączyć kolejne urządzenie. Ważne przy takich instalacjach jest, żeby pamiętać, że konwerterem steruje pierwszy (tzn. najbliższy LNB) włączony odbiornik. Zatem jeżeli konwerter jest przypięty do dekodera cyfrowego a karta DVB jest podłączona za dekoderem, to tuner karty w PC może w pełni kontrolować konwerter (a tym samym wybierać polaryzację i zakres) tylko wtedy, gdy dekoder jest wyłączony (w trybie stand-by). Włączenie dekodera powoduje, że kartę DVB można dostroić tylko do transpondera o tej samej polaryzacji i z tego samego zakresu, co aktualnie wybrany program na dekoderze. To samo dotyczy instalacji z DiSEqC-ami - o wyborze LNB decyduje pierwszy włączony odbiornik.

A skoro mowa już o DiSEqC: jest to dosyć elastyczny i sensownie pomyślany system sterowania urządzeniami przypiętymi do tunera (tunerów) satelitarnych. Najczęściej spotykane są (również w świecie DVB-PC) przełączniki Mini-DiSEqC sterowane tzw. ToneBurst (karta generuje sygnał ciągły lub impulsowy, ciągle bazując na częstotliwości 22 kHz), pozwalające na wybór jednego z dwóch konwerterów. Bardziej skomplikowane są prawdziwe (sterowane komendami) przełączniki 4/1 (do 4 konwerterów) oraz siłowniki, pozwalające na nakierowanie anteny na dowolną ("widoczną") pozycję orbitalną. Na temat takich instalacji można pisać wiele, ale te informacje są do odnalezienia bez trudu w innych źródłach. Na koniec dodam tylko, że karty DVB są dosyć kapryśne, jeśli chodzi o współpracę z przełącznikami. Należy oczywiście zwrócić uwagę na wersję standardu obsługiwaną przez kartę i przełącznik. Zazwyczaj jest tak, że wersja 1.1 powinna wystarczyć do sterowania przełącznikiem 4/1, zaś dla siłownika karta musi obsługiwać 1.2. Standardy 2.x przewidują odczyt informacji z urządzeń DiSEqC i karty DVB raczej tego nie obsługują.

No dobrze, przyjmijmy, że mamy już wszystko zmontowane i podłączone, sterowniki do karty i filtry zainstalowane zaś aplikacja wystartowała i działa. Jeżeli, drogi Czytelniku, dobrnąłeś do tego miejsca, to znaczy, że nie wystarcza Ci samo oglądanie fascynujących audycji wybranych specjalnie dla Ciebie przez naszych drogich nadawców. Chciałbyś wiedzieć więcej? Co też tam leci z nieba i jak to się zamienia na ruchome obrazki z dźwiękiem? Mam nadzieję zaspokoić częściowo i może jeszcze rozbudzić Twoją ciekawość.

Standard DVB ma wiele wspólnego z DVD i przynajmniej częściowo był stymulowany przez rozwój tej technologii. Ważny element odbiornika DVB, jakim jest dekoder obrazu (układ zamieniający ciąg bitów na obraz telewizyjny) był już właściwie gotowy i zadomowiony na rynku. Technologia konwerterów i tunerów satelitarnych też była już na tyle rozkręcona, żeby stosunkowo niewielkim kosztem dało się to poskładać i wypuścić na rynek po atrakcyjnych cenach. Zresztą nadawcy płatnych pakietów cyfrowych "dofinansowywali" zestawy dla swoich klientów (żeby odebrać sobie później te inwestycje w ramach inkasowanego abonamentu). Potrzeba było naprawdę niewiele, żeby sprawa ruszyła, więc nie mogło się nie udać. Gotowe były też technologie skutecznego przesyłania sygnałów cyfrowych falami radiowymi - jako baza posłużyły techniki stosowane w telefonii komórkowej i opracowane do transmisji internetowych w sieciach kablowych. Dla DVB-S (czyli cyfrowej telewizji satelitarnej) wybrano modulację QPSK (Quaternary Phase Shift Keying). Pozwala ona na dobre wykorzystanie pasma dzięki czterowartościowemu kodowaniu (najmniejszy kwant informacji, tzw. symbol, zawiera dwa bity danych) i jest odporna na zakłócenia, co jest istotne przy przesyłaniu sygnału na odległość 30 tysięcy kilometrów. Naturalnie taka odporność nie jest wystarczająca w rozwiązaniach, które muszą poprawnie działać w milionach egzemplarzy - dane są więc dodatkowo zabezpieczone przez kontrolę parzystości (standard Reed Soloman) i korekcję błędów FEC (Forward Error Correction - standard Viterbi). Stosowanie korekcji zmniejsza efektywną szerokość pasma, ale poprawia odporność transmisji na zakłócenia, które objawiają się "pikselozą" lub zanikiem obrazu.
A jaka jest faktyczna przepustowość transmisji satelitarnej? Można to wyliczyć znając parametr Symbol Rate (określający całkowitą szerokość pasma), oraz współczynnik FEC, który informuje, jaka część pasma niesie użyteczne dane. "Najlepsza" korekcja FEC, wynosząca 1/2, oznacza, że połowa danych zawiera informację nadmiarową, przy wartości "najgorszej", czyli 7/8, tylko co 8 bit jest nadmiarowy (ale taką transmisję łatwiej zakłócić). Używane są jeszcze współczynniki FEC równe 2/3, 3/4 oraz 5/6. Ostatni parametr, który decyduje o faktycznej ilości użytecznych danych to kontrola parzystości - przeznaczone jest na nią 16 bajtów z każdych 204.

Mając te dane możemy się pokusić o obliczenia:
DR (data rate)=SR*m*FEC*CRv (m - współczynnik modulacji, równy 2 bity na symbol, zaś CRv=188/204 - współczynnik Reed Soloman).
Dla typowej transmisji o wartości SR=27500000 symboli/sekundę i FEC=3/4, mamy:
DR=27500000*2*3/4*188/204 -> 36.25 Mb/s -> 4.53 MB/s.
Wyliczenia te zmienią się, jeśli wartości SR i FEC będą inne (jest to cecha związana z konkretnym tranponderem i dla dobrego dostrojenia tunera są równie ważne jak częstotliwość i polaryzacja, chociaż wszystkie chyba karty wykrywają FEC automatycznie, niektóre również SR, zależy to od użytego tunera). Poza tym wyliczona wielkość określa maksymalną przepustowość danego transpondera - w praktyce nadawca musi pozostawić pewien margines, wypełniany nieznaczącymi danymi. Ponadto część (choć niewielka) jest wykorzystywana na dodatkowe informacje: nagłówki, CRC itd., ale o tym niżej.

Bardzo ważne dla zrozumienia istoty transmisji DVB jest pojęcie pakietyzacji. Otóż całe dostępne (użyteczne) pasmo jest podzielone na równej długości paczki (pakiety) o ustalonej wielkości 188 bajtów. Każdy pakiet ma swoją informacje kontrolną Reed Soloman (16 bajtów) co razem daje 204 bajty (stąd używany wyżej współczynnik Crv=188/204). Niektóre karty DVB (np. VP-1030), przesyłają do systemu kompletne pakiety po 204 bajty (chociaż 16 bajtowy nagłówek jest zazwyczaj po prostu ignorowany). Pakietyzacja danych DVB pozwala na łatwe odróżnianie danych należących do różnych elementów składowych strumienia danych (TS - transport stream). Każdy pakiet zaczyna się bowiem od 4-bajtowego nagłówka zawierającego istotne informacje. Jedną z nich jest 13-bitowy identyfikator pakietu (PID - packet ID). Sprawdzenie tej wartości pozwala aplikacji (tunerowi) na szybkie wybranie interesujących ją w danej chwili pakietów i odrzucenie pozostałych. Najniższe identyfikatory (poniżej 0x20 [zapis 0x... oznacza liczbę szesnastkową]) są zarezerwowane dla danych opisujących w ustandaryzowany sposób pozostałe pakiety. Te PID-y zawierają tzw. tabele PSI (program service information), zgodnie z poniższą tabelą:
PID Nazwa Opis
0x0000 PAT - program association table Tablice serwisów tworzących bieżący TS oraz informacje o PID-ach opisujących te serwisy.
0x0001 CAT - conditional access table Tabela wpisów dostępu warunkowego.
0x0002 TSDT - transport stream description Opisy TS - raczej nie używana.
0x0010 NIT - network information table Zestaw danych opisujących inne transpondery (i pozycje orbitalne), które zawierają TS-y tworzące wspólnie sieć (np. pozostałe transpondery danego nadawcy + programy FTA uznane przez niego za warte wpisania, dekodery stacjonarne używają tych danych do zbudowania listy programów).
0x0011 SDT - service description table Dodatkowe opisy składowych serwisów - więcej informacji w dalszej części.
0x0012 EIT - event information table Opisy bieżących i kolejnych audycji, podstawowa składnik informacji EPG (electronic program guide).
0x0013 RST - running status table W zasadzie to samo co EIT, przewidziana do szybkiej aktualizacji w przypadku zmian w programie (nie trafiłem na przypadek użycia tej tabeli przez jakiegokolwiek nadawcę).
0x0014 TDT - time and date table
TOT - time offset table Czas bieżący (wg nadawcy) oraz (opcjonalnie) jego przesunięcie względem czasu GMT.
0x0010 do 0x1ffe PMT - program map table Tabele, o których mowa przy opisie PAT - szczegółowe informacje nt. serwisów i ich składowych (więcej informacji w dalszej części).
0x0020 do 0x1ffe Pozostałe strumienie, składające się na serwisy: video, audio, AC-3, teletekst, napisy, specjalne EPG, DVB-IP (internet satalitarny), aktualizacja oprogramowania tunerów, itd.
0x1fff NULL packet Pakiet stosowany w celu dopełnienia pasma, jeśli istotne informacje nie wypełniają całości.

Niektóre PID-y mogą zawierać dane odnoszące się do różnych tabel - na przykład EIT może nieść nie tylko dane dotyczące bieżącego TS, ale również innych (tzn. nadawanych z innych transponderów). Podobnie tabele PMT mogą mieć każda osobny PID, albo zostać "upchnięte" w jednym. Na takie działania pozwala konstrukcja wszystkich tabel PSI, które składają się z tzw. sekcji. Każda sekcja ma swój identyfikator, determinujący jej zawartość i składnię, co pozwala na mieszanie różnych danych w ramach jednego PID-a (chociaż specyfikacja DVB określa, jakie sekcje mogą zdarzyć się w jakich PID-ach). Ponieważ sekcja może być dłuższa niż pojedynczy pakiet (maksymalna długość sekcji to 1023 bajty), niektóre z nich są podzielone i nadawane w kolejnych pakietach danego PID-a. Na wypadek zgubienia jakiegoś pakietu niosącego cząstkową informację, nagłówek pakietu zawiera 4-bitowy licznik kołowy, który zazwyczaj wystarcza do wykrycia błędu. Gdyby to zawiodło, sekcje mają jeszcze bardzo skuteczną sumę kontrolną (CRC32), jej sprawdzenie ostatecznie weryfikuje poprawność danych.

Jak może niektórzy zauważyli, pisałem już kilka razy o serwisach, a nie o programach TV czy radiowych. Otóż strumień TS zawierać może nie tylko programy audio/video, które są szczególnym rodzajem serwisu, ale również inne przekazy, będące częścią całego strumienia, ale składające się na swoistą całość. Takie niestandardowe zestawy PID-ów mogą zawierać rozszerzoną (specjalną) informację EPG, serwis pogodowy, dane abonenta, aktualizację oprogramowania dla dekoderów i co tam sobie jeszcze kto wymyśli. U niektórych nadawców zajmują one całkiem pokaźną część pasma (są tacy, którzy nadają np. zakodowane informacje giełdowe i do tego jakąś muzyczkę czy komentarze głosowe). Ale rzeczywiście najczęściej spotykanym przypadkiem serwisu jest program TV. Jego najprostszy opis zawiera nazwę programu (np. TVP1) i nadawcy (np. Cyfra+), unikalny identyfikator tego programu (używany np. do powiązania właściwej informacji EPG) oraz PID-y: video (czyli obrazu), audio (dźwięku) i PCR (Program Clock Reference - PID z danymi umożliwiającymi synchronizację wszystkich składowych serwisu, często tożsamy z PID-em video).
Dlaczego obraz nie jest zmiksowany z dźwiękiem, jak to ma miejsce w tradycyjnej (analogowej) telewizji? Rozdzielenie tych danych do osobnych PID-ów pozwala (podobnie jak to jest na płytach DVD) na ich dowolne mieszanie, np. jednego obrazu i kilku wersji językowych dźwięku. Zresztą przekazy dźwięku mogą się różnić nie wersją językową, ale standardem nadawania - typowy przypadek to możliwość wyboru między "normalnym" dźwiękiem stereofonicznym kodowanym jako MPEG-1 i dźwiękiem AC-3, o lepszej jakości. A bodajże we Francji niektóre mecze można oglądać wybierając komentarz "zaangażowany" po jednej ze stron lub neutralny. Poza tym jest to ułatwienie dla podsystemów dekodujących, których zadania są zupełnie różne (w świecie PC odpowiednikami sprzętowych dekoderów video i audio są zwykle filtry programowe, np. DirectShow w Windows) i każdy dostaje tylko te dane, które ma przetworzyć. PMT może i zwykle zawiera więcej informacji niż tylko PID-y audio i video. W skład jednego serwisu może wchodzić więcej strumieni danych (ES - elementary stream), typowe to: teletext, napisy (subtitles) i dźwięk w formacie AC-3. W przypadku programów kodowanych również PID(-y) CA, zawierające sekcje ECM (Entitlement Control Message), czyli informacje dla systemów dostępu warunkowego. Niektórzy nadawcy (np. nasz TVN) nadają kilka zestawów ECM (i EMM - Entitlement Management Message) dla różnych systemów dostępu warunkowego (taka technika jest nazywana simulcryptem). Różne strumienie mają różne atrybuty - np. dla dźwięku czy napisów będzie to język, w jakim są nadawane. Zresztą większość tych informacji jest opcjonalna: ich wykorzystanie lub zignorowanie zależy od oprogramowania (włączając w to oprogramowanie dekoderów) i nie ma bezpośredniego wpływu na "esencję" telewizji, czyli ruchomy obraz opatrzony dźwiękiem, aczkolwiek może - czasem w istotnym stopniu - podnieść komfort użytkowania systemu. Nadmienię, że standard DVB przewiduje możliwość rozsyłania danych, których żaden chyba (przynajmniej w Europie) nadawca nie używa - dla przykładu EPG może zawierać kod audycji (sport/film/wiadomości/muzyka itd.) oraz jej ograniczenie wiekowe. Mógłby to być znakomity sposób na utrudnienie dzieciom dostępu do niepożądanych programów pod nieobecność dorosłych. W zależności od wyboru nadawcy, opisy strumieni składających się na serwisy umieszczane są w odpowiednich PID-ach PMT lub też w SDT. To drugie rozwiązanie ma sens, gdy te same strumienie są składnikami różnych serwisów - wtedy informacja o nich byłaby niepotrzebnie powielana w różnych PMT. Używanie tego samego strumienia w różnych serwisach zdarza się przeważnie wtedy, gdy jeden przekaz obrazu ma wiele różnych ścieżek dźwiękowych - takie rozwiązanie stosuje np. Eurosport, definiując w swoim pakiecie bodajże dziewięć różnych programów o nazwie Eurosport Polish, Dutch, French itd., z których każdy ma ten sam PID video a różnią się PID-ami audio (co ciekawe, tylko "polski" Eurosport ma również ścieżkę z angielskim komentarzem). Inne podejście ma nadawca programu Euronews, który jest zdefiniowany jako jeden serwis, z jednym PID-em video i ośmioma PID-ami audio.

W poprzednich akapitach napomykałem już o dostępie warunkowym, przede wszystkim o tym, że jego łatwość stosowania i skuteczność dla przekazów cyfrowych była ważnym argumentem dla nadawców za wdrożeniem nowej technologii. Dzięki dużej "gęstości" satelitarnego sygnału cyfrowego, łatwo jest manipulować uprawnieniami nawet pojedynczego abonenta z dokładnością do grupy programów czy nawet pojedynczych audycji (technologia PPV - Pay Per View, czyli zapłać za jedną audycję). Nic tak nie mobilizuje "zapominalskich" do uregulowania rachunków, jak zniknięcie z ekranu ulubionej telenoweli.

Do szyfrowania (ang. scrambling) i deszyfrowania (descrambling) przekazu w standardzie DVB stosowany jest algorytm CSA (Common Scrambling Algorithm), jak nazwa wskazuje - wspólny dla wszystkich. Oczywiście nie znaczy to, że każdy odbiornik może zdekodować każdy program, tzn. może to zrobić, pod warunkiem, że zna bieżące klucze kodujące przekaz, tzw. CW (Control Words), które zmieniają się co ok. 10 s. CW mają nominalnie długość 64 bitów, ale poza USA ich "siła" jest ograniczana do 48 bitów. Mimo to, ponieważ nie znaleziono do tej pory żadnej metody "sprytnego" obejścia CSA, przeciętny komputer klasy PC potrzebuje tysiące lat, aby znaleźć CW metodą "brute force". Jest to ciągle znacząco więcej niż 10 s., więc sam algorytm jeszcze przez jakiś czas będzie bezpieczny. Najbardziej wrażliwym na atak elementem systemu dostępu warunkowego jest samo przekazanie bieżących CW do descramblera. (Descrambler można sobie wyobrazić jako czarną skrzynkę, do której wkłada się co jakiś czas nowe CW i na bieżąco zakodowany strumień danych, a wyjmuje dane rozkodowane. W tunerach stacjonarnych i kartach DVB "sprzętowych" descrambler to specjalizowany procesor (może być częścią układu scalonego lub w formie samodzielnej kości), karty "software'owe" posiłkują się odpowiednim oprogramowaniem, spełniającym tę samą funkcję). Systemy płatnej telewizji używają mikroprocesorowych kart kodowych, których funkcja jest dwojaka: decydują o uprawnieniach konkretnego abonenta do oglądania poszczególnych kanałów pakietu (informacja o tych uprawnieniach jest rozsyłana przez nadawcę jako strumień EMM) oraz generują (dla dostępnych kanałów) aktualne CW, bazując na danych ECM oraz EMM. Karta kodowa siedzi sobie w specjalnym gnieździe w dekoderze, który podrzuca jej odpowiednio przetworzone dane EMM i ECM i dostaje CW, których używa do zdekodowania wybranego przez abonenta programu. O ile strumień EMM jest zazwyczaj jeden (dla każdego systemu kodowania, jeśli nadawca stosuje simulcrypt) na transponder, o tyle każdy kanał (serwis) ma swój strumień ECM, który zawiera informacje pozwalające karcie na wygenerowanie CW właściwych dla tego (i tylko dla tego) kanału. Nie wnikając w szczegółowe opisy tego procesu (które zainteresowani na pewno znajdą w Sieci), dodam tylko, że różne systemy kodowania to właśnie algorytmy opisujące sposób generowania strumieni EMM i ECM i ich interpretowania przez właściwe dla nich karty. Dodatkowo, ponieważ karta nie dostaje do przetworzenia "surowych" danych z satelity - muszą one być wstępnie przygotowane, konkretny system często wymaga dedykowanych dekoderów, które te operacje przeprowadzają.
Szyfrowanie streamu MPEG2 w standardzie DVB:
Przesyłanie w standardzie DVB odbywa się w oparciu o 188-bajtowe pakiety, które są nadawane w streamie cały czas, jeden po drugim.
Zadaniem tunera jest dostrojenie się na odpowiednią częstotliwość transpondera i odbiór tych pakietów oraz oczywiście, co najważniejsze, ich interpretacja.
Każdy pakiet zawiera w swoim nagłówku tzw. PID (Packet ID), który go identyfikuje.
Są różne typy pakietów - video, audio, data. Gdy wchodzisz na jakiś kanał, dekoder dostraja się na odpowiednią częstotliwość transpondera i ustawia pozostałe parametry, aby zacząć odbierać dane z tego kanału.
Parametr APID i VPID każdego kanału odpowiada za wybór pakietów, które zawierają obraz i dźwięk.
I dlatego na jednym kanale może być np. kilka ścieżek dźwiękowych - ich przełączanie to po prostu wybór innego APID, do przerabiania dźwięku wykorzystywane są wtedy pakiety audio o danym ID. To co najbardziej nas interesuje to oczywiście sprawy związane z kodowaniem, więc przejdźmy dalej. Po wejściu na kanał pobierana jest tzw. tablica PMT, z której dekoder wie m.in. czy kanał jest kodowany, w jakich systemach i jakie PIDy mają pakiety niosące dane dla konkretnego providera w konkretnym systemie.
Możemy się więc dowiedzieć, że np. dany kanał jest w simulcrypcie z dwoma prov Seca o danych ID oraz w np. Viaccess z 3 providerami i ich ID.
Każdy z tych providerów ma przypisany parametr ECMPID, który wskazuje na pakiet danych z odpowiednimi informacjami potrzebnymi do odkodowania obrazu.
A są to tzw. ECMy, o których dokładniej za chwilę. ECM to ciąg danych wysyłanych do karty w regularnych odstępach czasu, który odpowiada za dekrypcję.
Są jeszcze tzw. EMMy z informacjami wysyłanymi przez operatora na konkretną kartę, wszystkie karty lub grupę kart, w celu wywołania określonych zmian, np. przesłania nowych kluczy, deaktywacji, zmiany pakietu, itp.
Będzie to dokładnie omówione przy okazji systemu Seca. Oczywiście pominęliśmy proces startowy karty. Gdy karta zostanie wsadzona do slotu lub gdy dekoder startuje z włożoną kartą, jest z niej pobierana mapa providerów wraz z datami uprawnień, informacjami o nr abo, nr seryjny karty itp. Omówię to dokładnie przy okazji opisywania samego protokołu Seca.
Następna sprawa to trochę teorii o kodowaniu. Ramki MPEG2 są zakodowane w algorytmie CSA używającym 46-bitowego klucza zmienianego co 10s.
Provider w swoim centrum nadawczym posiada kodery (scramblery) dla każdego kanału, które losują jakąś wartość klucza i za jego pomocą kodują ramki video i audio (chociaż tutaj istnieje rozgraniczenie - może być kodowany np. sam obraz, tak jak w przypadku FreeXTV). Następnym etapem jest stworzenie ECM-a, tzn. ciągu, który wysyłany jest na kartę w celu przetworzenia i podania klucza kodującego obraz.
Teraz dokładniej o tym. Klucz, który został wylosowany do zakodowania obrazu na dane kilkanaście sekund wędruje do kodera systemu używanego przez danego providera, gdzie tworzony zostaje ECM.
Zawiera on wiele informacji - główna to CW czyli zakodowane słowo, które musi zostać odkodowane przez kartę i wynik wysłany dekoderowi. Poza tym jest wiele innych informacji takich jak data uprawnień, ID providera, maska pakietu, itp. Bez odpowiednich wartości któregoś z nich CW nie zostanie odkodowane, ale dokładnie będzie to omówione podczas opisu systemu Seca. Wracając do wyniku wysyłanego dekoderowi przez kartę po przetworzeniu ECMa to jest to tzw. DW (decrypted word - odkodowane słowo), i jest to nic innego jak ten klucz, który został użyty podczas kodowania ramek i za pomocą którego nastąpi dekrypcja w descramblerze odbiornika, żeby można było oglądać.
Więcej o CW - dokładnie są 2 zakodowane słowa, każde po 64 bajty. Po odkodowaniu dostajemy 2 DW, również każde po 64 bajty, przy czym do odkodowania obrazu w descramblerze odbiornika przy pomocy algorytmu CSA używanych jest tylko 46 pierwszych bitów, ponieważ jest to właśnie ten 46-bitowy klucz, którym zakodowano ramki.
Teraz pytanie po co 2 CW oraz DW a nie jedno? Ano dlatego, żeby zapewnić płynność oglądania. Przypuśćmy, że aktualnie obraz kodowany jest przy użyciu klucza A. Koder CSA losując klucz zawsze losuje również drugi, który będzie użyty do kodowania po tym okresie 10-sekundowym ważności danego klucza. Czyli mamy 2 klucze, z których tworzone są 2 CW. Wchodzimy na kanał i karta dostaje ECM z danymi CW. Pakiety danych zawierające aktualny ECM lecą cały czas, więc możemy wejść na kanał w dowolnej chwili i zawsze tuner będzie w stanie wyciągnąć aktualny ECM ze streamu bez czekania na jego zmianę.
Po odkodowaniu tuner otrzymuje 2 DW. Pierwsze zostaje użyte od razu do dekodowania, a drugie wędruje do bufora. Gdy minie czas ważności danego klucza (max 10s gdy włączymy zaraz po zmianie klucza), kolejny jest pobierany z bufora, a do karty zostaje wysłany kolejny ECM ze streamu zawierający znów 2CW, z czego pierwsze jest takie samo jak to użyte aktuanie do odkodowywania. DW obliczone z drugiego CW wędruje do bufora i czeka 10s na swoją kolej. I tak w kółko. Czyli CW, a tym samym DW zmieniają się w kolejności: ECM1 - A B, ECM2 - B C, ECM3 - C D, itd.
Potrzebne jest buforowanie drugiego DW po to, aby dekoder był odporny na rwanie obrazu. Gdyby nie było następnego klucza, ECM musiałby zostać wysłany bardzo szybko do karty, a wiadomo, że mogą się zdarzyć różne przypadki, dekoder załapie jakieś opóźnienie, albo karta się nie wyrobi, itp. Wiemy już więc jak zachodzi samo dekodowanie obrazu.
Parametr ECMPID jest potrzebny, aby do karty dochodziły odpowiednie ECMy. Jeśli kanał nadawany jest w kilku systemach możemy więc zmieniając ten parametr wybrać danego providera w interesującym nas systemie.
Oczywiście jeśli chodzi jeszcze o możliwość odbioru ECMów przez tuner i wysyłanie ich do karty to muszą zajść również inne warunki niż tylko dobrze ustawiony ECMPID.
Podczas pobierania danych z karty podczas jej startu tworzona jest mapa providerów.
Na jej podstawie tuner wie czy na włożonej karcie jest provider, do którego są kierowane ECMy providera wybranego z tablicy PMT. Jeśli go nie ma to ECMy nie będą słane do slotu. Jeśli chodzi o oprogramowanie multisystemowe to tutaj sprawa się komplikuje, bo ECMy innych systemów teoretycznie wogóle nie powinny być słane do karty Seca. Jednak znaleziono na to sposoby i istnieją 2 rodzaje oprogramowań - AllCam i MultiCam. Oba różnią się sposobem kierowania ECMów systemów innych niż Seca do kart rozkodowywujących opartych o protokół Seca. Opowiem o tym dokładniej przy zagadnieniu multisystemu, bo nie jest to ściśle związane ze sprawą kodowania obrazu. Nas interesuje tylko w tej chwili, że dekoder musi puścić do karty odpowiedni ECM, karta musi go przetworzyć i dać DW do odkodowania obrazu w descramberze odbiornika. Należy więc z tego tekstu zapamiętać, że kodowanie obrazu jest zawsze takie samo (CSA) w przypadku dowolnego systemu kodowania. Zadaniem całości dekodowania w danym systemie jest tylko podanie przez kartę prawidłowych DW, żeby mogła zajść dekrypcja w descramblerze.
Dzięki temu każdy dekoder jednosystemowy można teoretycznie przekształcić w wielosystemowy. Jedyny warunek, które trzeba spełnić to umożliwienie dojścia odpowiednich ECMów do karty, a potem już normalnie odbiór DW i podanie ich do descramblera, co zachodzi w każdym odbiorniku standardu DVB. Oczywiście karta musi umieć rozkodowywać CW w danym systemie. Zamiast karty może być oczywiście EMU, ale jego zadanie jest dokładnie takie samo. W oprogramowaniu podpięta jest procedura przetwarzająca i dekodująca ECMy różnych systemów w miejsce wysyłania ECMów do karty oraz procedura zwracająca obliczone DW w miejscu ich odbioru z karty. Tak więc wszystko zachodzi jakby karty nie było, ale zasada jest dokładnie taka sama.

Alternatywnym rozwiązaniem jest używanie dekoderów z gniazdami CI (Common Interface), do których można włożyć moduły CI, do których dopiero wkłada się karty. Takie rozwiązania jest oczywiście droższe, ale bardziej uniwersalne, a odbiorniki z gniazdami CI mają często ciekawsze rozwiązania i funkcjonalność niż dekodery dedykowane, że wspomnę tu tylko o obsłudze dźwięku 6-kanałowego (AC-3), bardziej przejrzystych menu, szybszym przełączaniu kanałów czy lepszych filtrach obrazu. Niektórzy nadawcy bronią się przed używaniem odbiorników uniwersalnych, wymagając aby karta dostępowa sprawdzała również odbiornik i działała tylko z konkretnym egzemplarzem. Moduły CI są również popularne w świecie PC-tów - karty sprzętowe (i niektóre programowe) są standardowo wyposażane w gniazdo CI. Moduły takie są jednak raczej drogie i - jak zawsze, gdy producenci/sprzedawcy są zbyt pazerni - pojawiły się rozwiązania alternatywne, bazujące na bardzo prostych czytnikach Phoenix/Season.

Na zakończenie tego pobieżnego przeglądu haseł związanych z telewizją cyfrową, kilka słów na temat kart DVB. Jako pierwsze na rynku pojawiły się stosunkowo drogie karty sprzętowe, które były w zasadzie nieco okrojonymi dekoderami stacjonarnymi. Komputer potrzebny był takiej karcie do tego, żeby ustalić parametry pracy tunera (częstotliwość i polaryzacja), układu filtracji strumienia TS (ustalenie PID-ów wybranego kanału) no i zasilić całość. Taka karta oprócz tunera ma "na pokładzie" descrambler, dekoder MPEG-2 video i MPEG-1/AC-3 audio, a gniazdo CI pozwala na oglądanie programów kodowanych. Telewizor i głośniki podłącza się bezpośrednio do gniazd na śledziu karty. Wykorzystanie mocy procesora jest znikome, nieco większe przy nagrywaniu programu na dysk komputera. Największa zaleta tych kart - czyli niewielka interakcja z "macierzystym" komputerem - bywa też ich największą wadą. Nie można bowiem w żaden sposób przechwycić za pomocą takiej karty oryginalnego strumienia TS - zazwyczaj oprócz kanału A/V można ustalić maksymalnie 8 filtrów na dowolne PID-y, ale dostajemy wtedy 184-bajtowe pakiety bez nagłówków. Wady tej nie mają karty "programowe", które pojawiły się oryginalnie jako urządzenia do satelitarnego internetu. Miały służyć tylko do cyfrowej obróbki strumienia TS, tak aby wyciągnąć zeń strony w HTML-u czy ściągane "z nieba" pliki. Jedną z pierwszych takich kart była SkyStar2 (notabene karta częściowo sprzętowa, jej układ B2C2 potrafi filtrować PID-y odciążając procesor komputera i zmniejszając transfer przez magistralę PCI). Kolejnym popularnym modelem jest TwinHan VisionPlus-1020. Obie te karty zawierają w zasadzie tylko tuner i układ transferujący dane przez szynę PCI. Brak wyjścia TV, descramblera i dekodera MPEG-2 (ale niektóre miewają gniazdo CI). Na szczęście wraz ze wzrostem mocy obliczeniowej PC-tów okazało się, że brakujące elementy mogą być z powodzeniem zastąpione przez procesor i kartę graficzną. Na początek kanały FTA (Free To Air - niekodowane), do oglądania których wystarczały nieco przerobione programowe odtwarzacze DVD - w końcu sam przekaz audio/video jest bardzo podobny, a różnice w interpretowaniu formatu MPEG-2 są stosunkowo łatwe do opanowania. Programy kodowane jeszcze przez jakiś czas opierały się kartom programowym, a to dlatego, że zagadką pozostawały szczegóły implementacji CSA, która w kartach sprzętowych zaszyta była w układzie scalonym. Ale wraz z pojawieniem się programu FreeDec (JohnDec), przeznaczonego dla kart VisionPlus, pękła i ta bariera. Obecnie nie ma już właściwie istotnych powodów, które pozwoliłyby (w praktycznym użytkowaniu) orzec o wyższości kart sprzętowych nad programowymi (pomijając kwestię ceny, która wyższa była zawsze). Co więcej, karty programowe mają kilka istotnych przewag: najważniejszą jest chyba możliwość przechwytywania kompletnego (nieobrobionego) strumienia TS i zapisania go na dysk lub przesłania w czasie rzeczywistym przez sieć LAN tak, aby na kilku komputerach-klientach można było oglądać różne programy (pod warunkiem, że pochodzą z jednego transpondera). A już niedługo może okazać się, że sprzętowy dekoder MPEG-2 staje się nieprzydatny - nadawcy (fakt, że w Europie raczej ostrożnie) przechodzą na pozwalający na większą kompresję standard MPEG-4. Z drugiej strony słabszy komputer z kartą programową można dozbroić w niezależny dekoder MPEG-2, których sporo zostało z czasów, gdy PC-ty były za słabe aby odtwarzać filmy DVD. Renesans przeżywają zwłaszcza karty RealMagic Hollywood+ (i kompatybilne Creative Dxr3). A producenci takich kart nie zasypiają gruszek w popiele i mamy już rozwiązania dekodujące HDTV i MPEG-4 (DivX)
Anubis1

Ostatnio zmieniany przez Iskander : 31.07.2015 o godz. 16:53
Iskander jest offline   Odpowiedz cytując ten post
Stary 16.01.2016, 14:37   #18
konfidel
Zarejestrowany
 
Data rejestracji: 16.01.2016
Posty: 1
konfidel w tym momencie nie ma Reputacji dodatnich ani ujemnych <0  pkt>
Cytat:
Napisany przez GENERiC Podgląd Wiadomości
jak znajdę to mogę Ci udostępnić "kompendia wiedzy" dotyczące systemów SECA, Nagra i Cryptoworks,bo takie były popularne w Polsce. SECA już nie istnieje, została przejęta przez firmę Nagra i karty C+ to praktycznie jest Nagra 3/4 w środku. Cryptoworks został wykupiony przez Irdeto i od paru lat jest sukcesywnie wyłączany (telewizja austriacka, czeska, słowacka, swego czasu Wizja TV). Conax używany jest przez N-kę w wersji CAS7, system stary, dziurawy, można wyciągać klucze do parowania karty.

Generalnie systemy na płaszczyźnie komunikacji z tunerem różnią się detalami (klasą, instrukcjami, parametrami, itp.), bo wszystko jest standaryzowane z zasadami ISO 7816. Różnica leży w algorytmach wyliczania klucza DW, który jest potrzebny descramblerowi w tunerze do odkodowania sygnału audio i video. Często systemy są podobne w budowie instrukcji do systemów kodowania telewizji analogowej (np. SECA -> Eurocrypt). Nowe wersje systemów jak np. Nagra 3, SECA 2, Viaccess PC 4.0, róznią się od starych długościami kluczy, algorytmami szyfrującymi, mikroprocesorami, zabezpieczeniami pamięci, tak aby trudniej było wydobyć zawartość karty. Natomiast sam schemat dekodowania klucza DW (decrypted word) z CW (control word) nie zmienia się, tak samo jak i system zarządzania kartą ,uprawnieniami.

Jeżeli masz jakieś pytania, chętnie odpowiem na nie, mam nadzieję,że wyczerpująco i zrozumiale. Co do tych plików to poszukam wieczorem na dysku.
mnie interesuje co znajduje sie konkretnie w instrukcji c8 41 dla systemu cryptoworks... tam bylo 84 01 21 c8 41 xx xx siedze nad tym kilka lat
konfidel jest offline   Odpowiedz cytując ten post
Odpowiedz na post

Tagi
cyfrowy polsat, nc+, szyfrowanie, tv sat

Opcje związane z dyskusją
Tryby wyświetlania

Twoje uprawnienia:
Nie możesz rozpoczynać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz umieszczać załączników
Nie możesz edytować swoich postów

BB codeWłączone
EmotikonkiWłączone
Kody [IMG]Włączone
Kody HTML są Wyłączone

Teleport

Podobne dyskusje
Dyskusja Autor Forum Odpow. Ostatni Post
stacjonarna nagrywarka z HDD - jak to działa? panTOMas Domowy sprzęt Audio/Video (nagrywarki, odtwarzacze DVD, Blu-ray, odtwarzacze sieciowe, TV) 0 18.11.2008 10:53
UPC TV sat ? _bakupl_ Off topic 3 07.08.2008 05:53
Jak działa PayPal? roman01 Off topic 14 27.02.2006 10:41
DVD na TV 25" ale jak rozciągnąć filmik na cały ekran TV Pab Napędy optyczne DVD 1 26.03.2002 09:38


Wszystkie czasy w strefie CET. Aktualna godzina: 23:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.