GHID Tehnic I.P.TV.
#37
Posted 01 February 2010 - 11:17
shadowc, 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) 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
Posted 01 February 2010 - 15:56
DoruPetrescu, 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. DoruPetrescu, 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. DoruPetrescu, 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. DoruPetrescu, 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 ... 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
Posted 01 February 2010 - 23:00
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
Posted 02 February 2010 - 09:54
DoruPetrescu, 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
Posted 07 February 2010 - 20:49
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
Posted 07 February 2010 - 22:18
Theone, 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 ? 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 ... Edited by DoruPetrescu, 08 February 2010 - 10:59. |
#43
Posted 07 February 2010 - 23:23
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
Posted 07 February 2010 - 23:34
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
Posted 08 February 2010 - 16:25
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
Posted 09 February 2010 - 01:34
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
Posted 09 February 2010 - 08:31
bogdan_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 |
#48
Posted 09 February 2010 - 10:37
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 ... |
#50
Posted 22 February 2010 - 22:20
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
Posted 26 February 2010 - 11:41
Daca e sa facem o gluma, solutia la dorinta ta se traduce prin inlocuirea patch-ul lung UTP cu doua mai scurte ...
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 ... 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
Posted 28 February 2010 - 14:30
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
Posted 28 February 2010 - 18:54
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 FilesEdited by DoruPetrescu, 02 March 2010 - 14:14. |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users