Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Intrerupator cu N - doza doar cu ...

Incalzire casa fara gaz/lemne

Incalzire in pardoseala etapizata

Suprataxa card energie?!
 Cum era nivelul de trai cam din a...

probleme cu ochelarii

Impozite pe proprietati de anul v...

teava rezistenta panou apa calda
 Acces in Curte din Drum National

Sub mobila de bucatarie si sub fr...

Rezultat RMN

Numar circuite IPAT si prindere t...
 Pareri brgimportchina.ro - teapa ...

Lucruri inaintea vremurilor lor

Discuții despre TVR Sport HD.

Cost abonament clinica privata
 

GHID Tehnic I.P.TV.

- - - - -
  • Please log in to reply
385 replies to this topic

#37
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009

View Postshadowc, on 1st February 2010, 01:44, said:

daca detin deja un router wi-fi, il voi putea folosi pe acela?  Adica nu vor trebui folosiite 2 routere nu? Si in plus,avand in vedere ca va merge si internetul si tv-ul pe acelasi cablu, nu vor exista probleme de buffer, lag sau alte chestii cand vor fi folosite amandoua la viteza maxima? (download maxim + HD cu bitrate mare)
Routerul care se livreaza abonatului a fost certificat pentru a putea servi Set Top Box-uri al caror consum total de banda
nu depaseste 100 Mbps. Daca de exemplu ai 3 STB-uri si urmaresti de exemplu 3 posturi HD cu 12 Mbps bitrate fiecare
iti ramane download pe PC de pana la 60 Mbps. Ca sa ai Net over Wi-Fi ori pui al doilea router wi-fi ca bridge/ router pe
porturile de Net, ori, daca vrei IPTV over Wi-Fi il pui ca bridge intr-unul din porturile de IPTV (merge si ca router intrucat
IPTV-ul poate face NAT daca e nevoie. Pentru asta trebuie sa va intelegeti cu call-center-ul sa va dea instructiuni privind
configurarea router-ului/ STB-ului over Wi-Fi). La capatul spre STB e nevoie de alta cutie care sa-ti aduca streamul Wi-Fi.
Acelasi scenariu se aplica la case unde nu mai exista routerul RB-750 ci numai cutia Huawei cu intrate pe fibra si 4x Eth ...

Asa cum a subliniat un antevorbitor, va rog postati intrebarile legate de servciu /conectivitate la sectiunea corespunzatoare fiecarui operator

Edited by DoruPetrescu, 01 February 2010 - 11:25.


#38
blue-line

blue-line

    Active Member

  • Grup: Members
  • Posts: 1,634
  • Înscris: 13.01.2010

View PostDoruPetrescu, on 16th January 2010, 16:53, said:

Revin cu informatiile depre DISPLAY-uri si FORMATE

In afara de asta STB-ul trebuie cumva informat si de formatul streamului de la intrare care variaza in timp chiar
pe acelasi canal nu numai de la un canal la altul. Informatia de format se transmite in mai multe feluri (cateodata
chiar si redundant) si este asimilata WSS (wide screen signaling).

WSS a fost bun pentru analog, dar pentru HDMI devine irelevant. Flag-ul de Aspect Ratio e la putere.

View PostDoruPetrescu, on 16th January 2010, 16:53, said:

Automatizarea consta in
transmiterea in completarea WSS a unui descriptor numit AFD (active format descriptor) care pe langa proportie
ofera si o informatie pentru incadrarea optima a imaginii (ca un fel de "crop" din Photoshop pentru aria de interes).
Cu alte cuvinte, chiar daca benzile negre sunt puse din studio (pentru compatibilitatea cu 4:3) se mai transmite un
semnal care spune STB-ului ca acea zona nu este relevanta si poate face scalare (eventual format change) la ecran.
Nu toate posturile transmit AFD.

AFD nu merita folosit pentru schimbari 4:3<->16:9. Pentru asta, e de ajuns flag-ul de aspect ratio din stream.
E de preferat folosirea AFD doar daca doresc folosirea unui format 14:9, intermediar. Din cate stiu, generatorul de content
trebuie sa stie daca exista arii irelevante, astfel incat sa nu pierd informatia utila. In afara de UK, nu am vazut nicaieri
in Europa prezenta acestui semnal.

View PostDoruPetrescu, on 16th January 2010, 16:53, said:

La noi in tara lucrez impreuna cu ProTV pentru implementarea acestui "ptotocol" pe STB-ul IPTV de la RCS-RDS.
Aceasta deoarece foarte putine device-uri stiu WSS +AFD iar studioul de la Pro (jos palaria !) este compliant 100%.
Cum functioneaza?  pe langa proportie, in studio se transmite si informatia de incadrare optima a imaginii in SDI
La encodare (MPEG) aceasta informatie este pasata in elementary stream si ajunge la STB. Acesta ar trebui sa
comute automat incadrarea (chiar de la o emisiune la alta) pentru o satisfactie maxima a clientului (daca stie AFD).

Se poate si passthrough, prin cablul HDMI (protocolul HDMI stie de AFD), insa nu am vazut televizor care sa-l suporte.
Teoretic, televizorul ar trebui sa faca aceasta conversie.

View PostDoruPetrescu, on 16th January 2010, 16:53, said:

In concluzie, cat timp nici posturile TV nu transmit AFD (majoritatea transmit numai WSS) si device-urile nu stiu,
butonul manual va salveaza experienta privitului la TV indiferent daca aveti un display 4:3 sau 16:9.
(evident, daca a fost implementat in meniul Set Top Box-ului iar serviciul a fost proiectat cu subtitrari separat lucru
care nu este posibil intotdeauna la toarte canalele romanesti. Daca ati observat Pro-ul are grija de pozitia subtitrarilor
si a siglei in cazul in care ori prin AFD ori manual vrei zoom). Intrucat sursele de semnal variaza, semnalizarea nu se
face tot timpul, Set Top Box-urile au si ele limitari si in televizor exista setari care intra in conflict cu cele ale STB-ului
problema devine un pic confuza. Curand toti vor trece la transmisii 16:9 iar noi ne vom schimba televizoarele si
problema va disparea ...  :D

Ma rog, orice conflicte intre STB si TV se pot rezolva, prin HDMI se pot intelege mai bine.
In schimb, clientul va fi mai greu de multumit.

#39
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009
Observatii in general de bun simt, am un singur comentariu:
In cazul in care exista subtitrare separat in stream, STB-urile de ultima generatie stiu sa-i mentina pozitia
pe ecran in cazul in care AFD-ul actioneaza asupra planului video. De asemenea, un STB destept pastreaza
si locul meniurilor in ecran la schimbarea "layerului" video. Odata AFD-ul lasat in sarcina TV-ului prin HDMI
acesta nu are cum delimita cele trei elemente asadar este de preferat ca aceste operatiuni de incadrare si
pozitionare sa se faca in STB sau poti iesi cu meniurile si subtitrarile din ecran. Problema setarilor generale
sau chiar tentatia schimbarilor in cazul in care nu exista aceste semnalizari inclina balanta in favoarea STB-ului.
Nu mai socotesc faptul ca operatorului ii este mult mai usor de implementat facilitatea in STB decat sa spere
la "upgrade-uri software" ale televizoarelor. Iar de multe ori trebuie sa tii si telecomanda TV-ului la indemana,
destul de neplacut, insa asta e o alta discutie care odata cu aparitia STB-ului in casa n-o s-o epuizam usor ...

Edited by DoruPetrescu, 01 February 2010 - 23:05.


#40
blue-line

blue-line

    Active Member

  • Grup: Members
  • Posts: 1,634
  • Înscris: 13.01.2010

View PostDoruPetrescu, on 1st February 2010, 23:00, said:

Observatii in general de bun simt, am un singur comentariu:
In cazul in care exista subtitrare separat in stream, STB-urile de ultima generatie stiu sa-i mentina pozitia
pe ecran in cazul in care AFD-ul actioneaza asupra planului video. De asemenea, un STB destept pastreaza
si locul meniurilor in ecran la schimbarea "layerului" video. Odata AFD-ul lasat in sarcina TV-ului prin HDMI
acesta nu are cum delimita cele trei elemente asadar este de preferat ca aceste operatiuni de incadrare si
pozitionare sa se faca in STB sau poti iesi cu meniurile si subtitrarile din ecran. Problema setarilor generale
sau chiar tentatia schimbarilor in cazul in care nu exista aceste semnalizari inclina balanta in favoarea STB-ului.
Nu mai socotesc faptul ca operatorului ii este mult mai usor de implementat facilitatea in STB decat sa spere
la "upgrade-uri software" ale televizoarelor. Iar de multe ori trebuie sa tii si telecomanda TV-ului la indemana,
destul de neplacut, insa asta e o alta discutie care odata cu aparitia STB-ului in casa n-o s-o epuizam usor ...

Aici aveti perfecta dreptate. In cazul unui STB nici nu se poate pune problema de AFD passthrough, pentru ca planul grafic este alterat si el de zoom-ul automat. Cat despre AFD, cred ca va fi foarte greu sa se impuna ca standard, atata timp cat este faultat permanent de faptul ca mai toate televiziunile serioase isi anunta si transmit emisiunile in formatul nativ original al emisiunii, in timp ce televizoarele 4:3 incep sa dispara. Iar cei ce au CRT-uri 4:3, nu sunt asa de pretentiosi dupa AFD. Bineinteles, mai sunt si exceptii, dar rare. In general, AFD-ul este foarte util pentru a evita efectul de "timbru": cand o televiziune transmite doar in format 4:3 si are in program un film 16:9, televiziunea adauga barele negre jos si sus. Pe un televizor 16:9, ce tine sa pastreze proportiile originale, nestiind ce transmite televiziunea respectiva, mai adauga si el bare negre laterale. In felul acesta, filmul se va vedea in mijlocul ecranului, inconjurat de bare negre => "stamp effect". Un utilizator avizat ar trebui sa faca zoom pe durata filmului, dar deja este un stres pentru utilizator. Exemplul cel mai concludent se poate vedea pe Euronews, pentru cine stie. Format nativ 4:3, dar mereu cu bare negre jos si sus (cu exceptia publicitatii). Avand in vedere ca, cu mici exceptii, televiziunile ce isi permit sa integreze AFD in stream, isi permit sa foloseasca si format dinamic, AFD-ul devine redundant, de unde rezulta mai putina presiune pe producatorii de STB sa integreze acest standard.

#41
Theone

Theone

    Member

  • Grup: Members
  • Posts: 308
  • Înscris: 19.09.2003
Doru, pe o tehnologie de acces la reteaua IP, bazata pe dslam-uri si cupru, care ar fi diferentele notabile intre adsl si vdsl ce ar putea influenta pozitiv/negativ serviciul de iptv ? La provizionarea unui port in dslam cu serviciul iptv este posibil sa fie afectati parametrii liniei precum SNR- ul ? Exista diferente intre cerintele minime de banda pentru adsl (ppoe) si vdsl (dhcp) ? Accesul la platforma iptv, pe layer 2 cu inregistrarea prealabila a MAC-ului stb-ului este specifica unei anumite solutii sau e o chestie universala impusa de catre producatorii de programe pentru a se proteja de fraude ? Dslam-urile stiu toate sa faca multicast si igmp sau trebuiesc invatate ?

#42
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009

View PostTheone, on 7th February 2010, 20:49, said:

Doru, pe o tehnologie de acces la reteaua IP, bazata pe dslam-uri si cupru, care ar fi diferentele notabile intre adsl si vdsl ce ar putea influenta pozitiv/negativ serviciul de iptv ? La provizionarea unui port in dslam cu serviciul iptv este posibil sa fie afectati parametrii liniei precum SNR- ul ? Exista diferente intre cerintele minime de banda pentru adsl (ppoe) si vdsl (dhcp) ? Accesul la platforma iptv, pe layer 2 cu inregistrarea prealabila a MAC-ului stb-ului este specifica unei anumite solutii sau e o chestie universala impusa de catre producatorii de programe pentru a se proteja de fraude ? Dslam-urile stiu toate sa faca multicast si igmp sau trebuiesc invatate ?
Teoretic nu ar trebui sa existe diferente intre ADSL si VDSL. Practic diferenta ar trebui redusa strict la banda disponibila
pentru fiecare tehnologie. Nimeni nu stie cum se va comporta un tronson de perechi de cupru pana nu-l incarca complet.
Si chiar daca din 48 de perechi in cablu majoritatea nu pun probleme se poate intampla ca in casa unui abonat sa existe
o prelungire de cativa metri cu cablu de 220V care sa-i faca viata un cosmar si lui si operatorului. Problema nu este aici
ci in incarcarea exagerata a liniei. Din motive de marketing si nu numai, telecoamele au un obicei prost anume fortarea
sincronizarii modemurilor la viteze exagerate. Daca la TCP care are inclus prin definitie robustetea transportului se poate
forta o banda mai mare, la streamul UDP lucrurile se schimba: o linie pusa pe 8 Mbps poate permite un IPTV de calitate
pe cand aceeasi linie sincronizata la 14 Mbps ridica nivelul erorilor de transport la valoari inacceptabile pentru IPTV desi
downloadul merge fara probleme la viteza setata. Evident, bigger is better, asadar VDSL-ul este de preferat ADSL-ului.
In ceea ce priveste PPPoE versus DHCP iarasi este o problema de optiune a operatorului. De fapt, una e una, alta e alta ...
Oricum IPTV-ul este configurat in bridge si se foloseste de DHCP pe cand PPPoE este folosit la rate-shaping-ul accesului
la internet. Nici un IPTV nu poate evident trece prin BRAS (cu exceptia IPTV-ului CrossPoint, lucru demonstrat la testele
de anul trecut). Treaba cu inregistrarea MAC-ului este specifica implementarii Romtelecom, nu este o cerinta de securitate
a providerilor de content si dupa parerea mea este o prostie. Belelele Rtc vin si de la aceasta restrictionare total inutila ...
DSLAM-urile nu sunt totdeauna veriga cea mai slaba in lantul catre abonat. In fond, daca tu trimiti pe aceeasi linie ADSL
doua multicasturi la doua STB-uri sau doua unicasturi care e diferenta? multicastul numai iti complica viata. Odata ce ai
optat pentru multicast problemele se muta in switch-urile de agregare care transpira din greu sa faca snooping, cu alte
cuvinte sa filtreze streamurile catre abonati. Nu inseamna ca DSLAM-ul trebuie vazut ca un bridge, desi compatibilitatea
acestuia cu protocolul IGMP este de cele mai multe ori una pur comerciala (exista vendori care cer licenta IGMP per port).
Intrucat switch-urile existente in retea sunt de generatie mai veche, desi producatorul scrie in specificatii ca stie IGMP,
nimeni nu stie cat snooping face in layer2 pana nu crapa. Desi un switch poate face trafic TCP wire-speed pana la 1 Gbps,
pe UDP transpira pe la 600-700 Mbps iar daca il pui pe snooping poti sa ai surprize si la 150 Mbps. Manifestarea problemei
este clasica, daca nu mai poate canalele se schimba la 8-10 secunde. peste aceasta limita comportamentul este catastrofal.
Modele mai vechi au arhitectura non-blocking si se transforma in HUB, facand flood pe toate porturile (cu alte cuvinte zic:
fratilor, nu mai pot filtra, descurcati-va voi cu pachetele astea UDP ca sunt prea multe pentru mine, nu fac fata la trafic ...)
Eu nu sunt un dusman al multicastului insa tehnologia trebuie folosita acolo unde se preteaza, nu numai pentru ca e moda!
iNES de exemplu a investit in echipamente de ultima generatie (se vede si la pretul serviciilor) si a putut sa faca multicast.
Pentru un operator mare strategia e prea costisitoare, de aceea recomand unicastul. Cu atat mai mult cu cat viitorul nu mai
apartine programelor Live ci interactivitatea ne indreapta pe fiecare catre streamul lui (VOD, timeshifting, NPVR si altele ...)
Paradoxul retelelor mari, unde functioneaza matematica arata ca in core nici macar nu este nevoie de multicast ci broadcast,
intrucat numarul consumatorilor din nod fiind mai mare decat numarul canalelor, la setari uzuale de time-to-leave se observa
ca toate canalele trec prin noduri, multi dintre operatori comutand de pe modul sparse pe dense, flood-ind reteaua deliberat.
Avantajul este ca initial, la un numar mic de abonati zapping time-ul scadee. Oricum topologiile difera, fiecare cu otrava lui...
Revenind la avantajele unicastului, reteaua poate servi de 3-4 ori mai multi abonati cu switch-urile existente, CPE-urile isi
reduc costurile de 2-3 ori, poti implementa usor corectia de erori care pe zi ce trece devine tot mai necesara pe (V)ADSL etc.
IPTV-ul pe liniile ADSL mai are o problema: acolo unde banda e la limita si ai doua STB-uri in casa, schimband canalul la unul
poti "sufla" streamul la celalalt. De exemplu daca linia are 7 Mbps, teoria spune ca poti viziona doua streamuri SD cu 3 Mbps.
In realitate lucrurile nu stau tocmai asa. Setarile de leave pe tot lantul neomogen de echipamente poate face ca pentru zeci,
chiar sute de milisecunde catre STB-ul care schimba canalul sa vina doua streamuri. Pe ecranul negru nu te deranjeaza, insa
la al doilea STB care "vede" linistit un canal efectele de macroblocuri sunt suparatoare, si asta la fiecare schimbare de canal
a celuilalt STB. Poti incerca tuning la retea daca ai echipamente omogene dar e foarte greu. Sistemul CrossPoint de IPTV are
overflow protection, in sensul ca nu da voie canalului nou sa vina pana STB-ul nu si-a curatat bufferul de la canalul anterior.
Asta deoarece toata comunicatia (in afara de TCP care il folosim numai pentru "vizibilitate") este UDP de la layer4 in sus si este
agnostica de retea. In plus solutia patentata de transport si corectie de erori ne permite monitorizarea permanenta a STB-urilor
pana in dormitorul clientului. Multi operatori fac greseala sa creada ca reteaua lor se opreste la usa sau la CPE, mare prostie ...
Odata SLA-ul dat per serviciu, evaluarea QoE (quality of experience) se opreste la STB-ul din dormitorul sau sauna clientului.
La sistemul nostru operatorul stie din call-center daca patrateste IPTV-ul pana sa pui tu mana pe telefon, lucru care pentru un
sitem traditional cum are Romtelecom costa zeci de milioane de EUR sa-l implementezi, iar corectia de erori mai costa in plus.

Corectia de erori:
Deja nu mai este un secret pentru nimeni ca transportul IP mai rateaza ceva biti. Daca la alte servicii TCP-ul
poate retransmite pachete, la streaming-ul UDP nevoia de timp real face lucrurile mult mai complicate ...
De ce ar fi nevoie de corectia de erori? Pai in primul rand o linie (V)ADSL masurata riguros arata o medie a
erorilor de transport peste nivelul admis la o calitate video corespunzatoare. Odata cu instalarea abonatilor
suplimentari pe acelasi tronson de cupru cross-talk-ul (diafonia) inrautateste lucrurile. Perioadele de varf de
trafic genereaza congestii care genereaza freeze-uri de imagine. Chiar in retele optice de tip FTTH sau GPON
ecosistemul din casa clientului cauzeaza probleme (cablari defectuoase, convertoare la coaxial, Ethernet over
powerline, Wi-Fi etc). De obicei IPTV-ul nu merge peste routere Wi-Fi normale. Exista modele tip N fabricate
special (Ruckus de exemplu) care fac transportul posibil dar sunt foarte scumpe. Intrucat foarte putine case
sunt cablate UTP nevoia clientilor de a transporta IPTV prin coax, liniile de curent, chiar Wi-Fi este de inteles.
Chiar daca sunt momente cand transportul nu prezinta probleme, congestiile retelei si jitter-ul acumulat pana
in STB pot face placerea privitului la TV un cosmar. Exista mai multe metode de a corecta erorile si acestea se
baseaza pe doua strategii: una este transmiterea de informatie suplimentara redundanta cum este FEC-ul pe
satelit (de exemplu un FEC de 3/4 ocupa un canal de 10 Mbps ca sa transmita o informatie utila de 7.5 Mbps)
Din pacate in retelele reale banda este permanent o problema. Nimeni nu-si permite sa "arunce" 2.5 Mbps
ca sa corecteze "eventuale" rateuri ale transportului. Implementarea FEC-ului inrautateste cateodata lucrurile.
Mai mult, in situatia in care nu exista erori, banda suplimentara necesara asigurarii FEC-ului este irosita. Exista
si mecanisme tip PRO-FEC mai evoluate insa si aceste prezinta dezavantaje in ecositeme gen IPTV (schimbarea
dificila a canalelor prin nevoia de buffere suplimentare plus dificultatea monitorizarii eficiente a transportului).
De aceea "moda" in IPTV este acum transportul cu feedback ce functioneaza pe principiul repetarii pachetelor
gresite in urma verificarii integritatii lor la receptor (STB). Ideea nu e noua, este acoperita de cateva patente
in lume (Cisco, Qvidium etc) si se bazeaza pe "stampilarea" pachetelor IP care daca nu ajung de loc sau chiar
in ordinea normala, duplicate etc Set Top Box-ul cere unui echipament dedicat retransmiterea aceste pachete.
Abordarile pot acoperi atat transportul multicast (VQE-Cisco) si unicast (ARQ-Qvidium). De fapt, ideea este de
a combina avantajele TCP-ului cu cele ale UDP-ului, pastrand strategia de "real-time" si combinand-o cu cea
de retransmitere. Tehnica nici macar nu este rocket-science, insa in teren totdeauna lucrurile se complica.

De ce am ales Qvidium ARQ si nu Cisco VQE?
In primul rand deoarece convingerea noastra este ca viitorul serviciilor peste IP cere unicast. In al doilea rand,
daca luam in considerare banda (overheadul generat) necesara retransmisiei de pachete observam ca un server
centralizat cum este cel de la Cisco incarca reteaua cu toate greselile de transport si de multe ori acestea nu sunt
ale retelei insasi ci generate de problemele din casa abonatului. Ca sa scapi de ele alternativa este sa distribui
aceste servere de "retransmisie" in retea cat mai aproape de abonat. Paradoxal, pozitia ideala a acestor servere
este tocmai aceea de unde la fel de bine poti servi abonatul si pe unicast (scapand de belelele enuntate mai sus).
Solutia pe care am gasit-o a fost conceptul de "replicator" (am pus poze ale acestor servere care de fapt nu sunt
altceva decat niste routere video) care preiau streamul multicast si il transforma in unicast cu corectie de erori si
monitorizare a calitatii transportului spre client (QoE). Echipamentele pot sta in DataCenter ori cabinetul stradal
si se scaleaza odata cu numarul de abonati (pay-per-grow). Asta e motivul pentru care la RCS-RDS merge IPTV-ul,
demonstratiile noastre aratand HDTV cristal peste Netul public pana la Budapesta. Simplu, ieftin, future-proof ...
In plus, transportul poate face NAT permitand abonatului servicii OTT (over the top) din aceeasi cutie de IPTV.
Granularitatea replicatoarelor este flexibila si chiar reversibila in sensul ca doi abonati pot sa-si transfere video in
real-time. Sistemul este protejat mult mai bine decat multicastul la DOS (denial of service) si furtul de content.
Zapping time-ul devine aproape agnostic de retea, IPTV-ul reducandu-se la o simpla problema de banda disponibila.

Odata ales multicastul ca livrare, la Romtelecom vor fi curand presiuni sa se implementeze VQE-ul de la Cisco.
Insa pana se vor intelege Ericsson cu Cisco va curge multa apa pe girla. In plus, resursele necesare in Set Top Box
fiind critice, dupa cum gafaie Zyxel-urile sub clientul IPTV pe browserul Opera SVG adaugarea inca a unui proces
va face mai mult rau decat bine. Ma opresc aici, pentru o sedinta neplatita am dat si asa destula consultanta ...  :D

Edited by DoruPetrescu, 08 February 2010 - 10:59.


#43
jonex

jonex

    Member

  • Grup: Members
  • Posts: 262
  • Înscris: 16.03.2006
Interesante informatii. Acum intrebari pt dl Doru pentru ca nimeni din RTC nu va veni sa spuna ceva:

1. freezurile care au aparut in ultimele seri pe IPTV-ul RTC sunt cauza congestiei si a erorilor sau sursa poate fi direct in sistemul central al RTC? oricum, dumneavostra nefiind implicat acum in proiectul RTC banuiesc ca vorbim de "presupuneri" dar cu o probabilitate mare.
2. afirmai la un moment dat ca la RTC sunt posibile in acest moment (sau poate la momentul cand colaborai cu ei) pana in 80 sau 90 de canale maxim. Cineva spunea intr-un comunicat oficial ca intentioneaza sa ajunga la 100 de canale in acest an (cred ca atat IPTV cat si DTH) din care 10 HD. E asta chiar o limita pt RTC sau poate fi extinsa? Daca pe satelit costurile inseamna si inchirierea de TP-uri noi, la IPTV totul tine banuiesc de echipamentele lor centrale. La RDS unii spun ca vor fi 170 canale. La RTC la cat sa ne asteptam incepand cu 1 aprilie? Ce inseamna pt RTC sa mareasca numarul de canale?

Multumesc.

#44
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009
Assumption is the mother of all fuck-up's!   de aceea precizez ca partial imi dau cu parerea:

1. Desi initial Rtc a avut probleme cu streamurile chiar la iesirea din headend ma indoiesc
sa nu le fi rezolvat. Freeze-urile chiar nu conteaza din ce provin, exista, si odata cu incarcarea
retelei cu abonati de IPTV se vor accentua. La fel se va inrautati probabil si zapping time-ul.
2. Pai daca citesti mai sus, pe o infrastructura veche snooping-ul switch-urilor poate impune
si o limita de 150 Mbps. Daca imparti 150 la 2 Mbps obtii numarul maxim de canale in layer 2.
Problema se rezolva prin upgrade, Rtc tocmai asta va vrea sa faca sa mareasca grila de canale.
3. Cat timp serviciile ambilor operatori nu sunt disponibile foarte clar dpdv comercial, orice
discutie despre canale, numarul lor, calitatea, serviciile cu valoare adaugata, este prematura.
Nici nu e timp fizic sa se negocieze foarte curand un numar de 200 de canale, sa fim realisti ...
In ceea ce-l priveste pe Rtc este necesara transformarea headendului, poate unul suplimentar.

Edited by DoruPetrescu, 08 February 2010 - 10:56.


#45
frek menta

frek menta

    Junior Member

  • Grup: Members
  • Posts: 203
  • Înscris: 01.09.2005
Nu poate/vrea ceva mod sa schimbe titlul topicului din "Tenhic" in "Tehnic"? Ma cam "zgarie" pe ochi de fiecare data cand intru aici...

Multumesc

#46
bogdan_thirst

bogdan_thirst

    New Member

  • Grup: Members
  • Posts: 2
  • Înscris: 09.02.2010
Salutare, nu stiu exact care e problema generala....putini instructiuni la primirea stb-ului sau nepriceperea clientului....
Sunt abonat la o firma de internet (wind (italia)) ce imi ofera un pachet de telefonie , internet si televiziune (cu ajutorulu unui STB MOTOROLA VIP1616t)..vesnica poveste .Am urmat toti pasii pt a monta pachetul.... routerul merge perfect, lafel si telefonia.....in momentul in care comut televizorul pe Scart 1 (canalul pe care ar trebui sa emita stb-ul) mi se afiseaza un ''x" rosu....si gata...iar pe display-ul stb-ului imi scrie no connection, in ciuda faptului ca routerul imi afiseaza mac-adress-ul stb-ului....
deci ce e de facut ?
multumesc anticipat

#47
ole

ole

    Active Member

  • Grup: Members
  • Posts: 1,224
  • Înscris: 10.07.2003

View Postbogdan_thirst, on 9th February 2010, 01:34, said:

Salutare, nu stiu exact care e problema generala....putini instructiuni la primirea stb-ului sau nepriceperea clientului....
Sunt abonat la o firma de internet (wind (italia)) ce imi ofera un pachet de telefonie , internet si televiziune (cu ajutorulu unui STB MOTOROLA VIP1616t)..vesnica poveste .Am urmat toti pasii pt a monta pachetul.... routerul merge perfect, lafel si telefonia.....in momentul in care comut televizorul pe Scart 1 (canalul pe care ar trebui sa emita stb-ul) mi se afiseaza un ''x" rosu....si gata...iar pe display-ul stb-ului imi scrie no connection, in ciuda faptului ca routerul imi afiseaza mac-adress-ul stb-ului....
deci ce e de facut ?
multumesc anticipat
In primul rand cred ca este mai bine sa deschizi un alt topic pentru rezolvarea problemei tale pe aceasta arie. Sfaturile pe care eventual le vei primi ne pot ajuta si pe noi pe viitor.

#48
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009
In general STB-urile Motorola nu au firmware-ul intr-o memorie flash.
Acesta se incarca la secventa de power-up si trebuie sa fii cu petarda
intr-o retea in care poti incarca acest firmware (de obicei pe multicast).
Am mari indoieli ca STB-ul tau ar trebui sa mearga peste Netul public ...

#49
bogdan_thirst

bogdan_thirst

    New Member

  • Grup: Members
  • Posts: 2
  • Înscris: 09.02.2010
multumesc...

#50
alex321

alex321

    Senior Member

  • Grup: Senior Members
  • Posts: 5,968
  • Înscris: 25.12.2005
buna seara,

am ip tv rtc , modemuri zyxel...ma intereseaza comunicarea intre modem si stb..,pot folosi in configuratia actuala un powerlan pentru a evita patch-ul utp?

multumesc

#51
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009
Daca e sa facem o gluma, solutia la dorinta ta se traduce prin inlocuirea patch-ul lung UTP cu doua mai scurte ... :D
Asta deoarece vei avea un patch pana la master-ul PowerLan si unul de la slave la STB-ul aflat la distanta de router.

Acum despre conectivitate:
IPTV-ul aduce mare deranj la resedinta abonatului intrucat nimeni nu banuia la momentul cablarii casei ca-i trebuie
UTP pana la Televizor iar de obicei modemul (routerul) nu este pozitionat aproape de acesta. Solutiile sunt in ordine:

1. Ethernet over powerline
Sunt o multime de echipamente, unele mai bune, unele mai proaste. Scump nu inseamna neaparat mai bun!
Daca vorbim de un singur STB atunci cu un master si un slave te-ai rezolvat (presupunand ca echipamentele
nu introduc pierderi de pachete si surplusul de jitter introdus de cutiile PowerLan nu afecteaza transportul ...)
Mai trebuie de asemenea ca petardele sa fie imune la interferentele generate de aspiratoare /masini de gaurit.
Daca vorbim de doua Set Top Box-uri, intrucat cutiutele nu fac snooping (filtrarea streamurilor la nivel layer2)
ambele streamuri de la canalele vizionate vor bate la usa ambelor STB-uri. Nu stiu cum se comporta Zyxel-urile
in acest scenariu insa in mod normal ar trebui sa disocieze doua streamuri SD de ~3 Mbps (nu stiu din pacate
si daca doua streamuri HD de ~8 Mbps). Situatia este similara cu scenariul in care abonatul doreste sa instaleze
un switch normal (non IGMP) la iesirea unui port de IPTV (setat ca bridge in VLAN-ul de video) plecand dinspre
modemul (V)ADSL catre doua STB-uri. O alta problema cu ETH over Powerline este ca daca vecinul de bloc are
si el aceeasi configuratie si este pe aceeasi faza de 220V o sa faceti un bridge intre voi de toata frumusetea ...  :D
Reciproc, daca stai la casa si ai curent trifazic "slave-urile" de PowerLan n-o sa se vada toate cu master-ul, deci
este posibil sa ai nevoie de bridge-uri powerlan intre faze (scumpe), ori sa te multumesti sa servesti un singur STB.

2. Ethernet over Coax
Solutia recomandata, intrucat acolo unde ai TV-ul instalat de obicei ai tras si un cablu coaxial. Si aici sunt multi
producatori majoritatea dintre ei cu grija la snooping-ul multicast asadar scapi de problema cu toate streamurile
care tabara pe toate STB-urile. Unele cutii sunt mofturoase la adaptarea de impedanta asadar atentie la splittere
si de asemenea la prizele din perete cu cuplaj inductiv. Un alt element care trebuie avut in vedere este spectrul
de frecvente in care se face comunicatia: sunt echipamente care lucreaza la zeci de MHz (recomandate) dar unele
nu pot servi punct la multipunct (pentru mai multe STB-uri) cum la fel de bine sunt si echipamente care lucreaza
in banda utila de canale TV asadar odata luata optiunea de a folosi Coax-ul din casa pentru IPTV trebuie sa-l separi
de la reteaua CATV altfel ori nu-ti merge, ori afectezi si vecinii de pe scara, ori ambele. Mai exista si echipamente
care lucreaza la peste 900 MHz asadar nu influenteaza CATV-ul si pot co-exista in buna pace cu acesta. Ca regula
generala calitatea cablurilor instalate conteaza destul de mult in oricare dintre scenarii.

3. Ethernet over PhoneLine
Nu prea se folosesc uzual la IPTV. Recomandarea este "Try and Buy" only! Si aici trebuie sa separi segmentul de
linia de telefon a Operatorului insa nu-i o regula decat daca IPTV-ul vine pe A(V)DSL, caz foarte frecvent insa ...

4. Wi-Fi
In scenariile de IPTV pe multicast un exemplu bun este Ruckus Wireless care este un Router-N mai ingrijit construit
si care separa si streamurile. Nu lucreaza decat pe distante limitate (probleme la peretii din beton armat) si pana la
o banda agregata de cca 20 Mbps (suficienta in cele mai numeroase cazuri). Unii folosesc cu succes si routerul Apple
tip N (tinand cont cum am explicat mai sus de faptul ca nu filtreaza canalele catre STB-uri). In orice caz, IPTV-ul nu
merge nativ 100% bullet-proof peste Wi-Fi decat daca a fost conceput in acest sens asa cum este cel al RCS-RDS.
Sistemul lor (cu corectie de erori incorporata) este certificat Wi-Fi, Wi-Max si 3G cu handover de la o celula la alta.

Edited by DoruPetrescu, 26 February 2010 - 21:11.


#52
anicoara

anicoara

    Active Member

  • Grup: Members
  • Posts: 1,252
  • Înscris: 28.01.2005
In legatura cu sistemul IPTV peste 3G. Am retinut dintr-un post anterior ca aveti echipamente (servere) montabile la nivel de celula. Totusi, avand in vedere ca nu este multicast, cati clienti ar putea duce practic o celula ? Exista o urma de fezabilitate economica in ideea ca un operator 3G sa ofere aceste serviciu, poate chiar cu HD ? Sau trebuie sa steptam WiMax ?

#53
DoruPetrescu

DoruPetrescu

    Active Member

  • Grup: Senior Members
  • Posts: 1,938
  • Înscris: 18.11.2009
Nu are legatura cu multicastul in principal. Challenge-urile sunt mai complexe intrucat ridica diverse probleme.
Capacitatea celulei este prima insa reducerea acoperirii odata cu cresterea incarcarii este alta mult mai grava.
Wi-Max-ul nu este altceva decat stramosul LTE-ului. Un serviciu wireless pentru TV nu cred ca va tinti HD-ul,
ci mai degraba streamuri video intre 300k si 1 Mbps si chiar in acest scenariu nu vom putea vorbi curand decat
de un serviciu "complementar", folosit mai mult ocazional de catre abonati. In ceea ce priveste fezabilitatea e
mult de discutat si cand spun asta am in vedere si quasi-esecul financiar al DVB-H-ului. Privit in context tehnic
MediaFlo-ul lui Qualcomm promite mult, dar lupta din greu cu contextul politic. Asadar observam destui factori
externi ca sa consideram TV-ul mobil o oportunitate pentru operator. Tehnologia evolueaza foarte repede insa
deocamdata batranul concept de broadcast e imbatabil ca si costuri. Interactivitatea nu este un "must" pentru
majoritatea userilor. Nici incercarile folosirii cailor alternative pentru canalul de retur nu au dat rezultate foarte
concludente ca successful stories si nu este f. greu de inteles de ce. Increderea pe tot lantul: abonat-operator-
-integrator-producator genereaza un commitment dificil daca avem in vedere concentrarea diverselor tehnologii
in mana Telecoamelor. Daca legislatia ar fi impus ca operatorii sa nu dispuna de licente cross-technology atunci
cu siguranta unii ar fi apasat acceleratia sa poata face de toate cu licenta disponibila. Asa cum se prezinta piata
in zilele noastre cand fiecare mai mult "colectioneaza" licente si tehnologii decat le foloseste e putin probabil sa
vedem ceva concret. Nu este un secret ca si noi, Crosspoint, testam IPTV-ul atat peste 3G cat si peste Wi-Max.
Strategia consta insa in a beneficia de calitate ~300k in miscare si calitate full (pana la HD) odata ajuns acasa
in raza de actiune a Wi-Fi-ului conectat la reteaua Operatorului Fix. Terminalul, pe care putem sa-l numim usor
"Set Top Box la purtator" este in laborator si il vom face disponibil la teste pentru operatori undeva prin August.
Dispune de port HDMI pentru conectare la TV probabil printr-un docking station si va fi comandat prin Bluetooth.

Attached Files

  • Attached File  Poza.JPG   131.66K   158 downloads

Edited by DoruPetrescu, 02 March 2010 - 14:14.


#54
catalinman

catalinman

    RCS & RDS

  • Grup: Senior Members
  • Posts: 27,473
  • Înscris: 16.12.2006
misto :D

Anunturi

Bun venit pe Forumul Softpedia!

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate