GHID Tehnic I.P.TV.

GHID de CONECTIVITATE cu scuzele anticipate celor care le stiu deja:

Calitatea video este influentata si de tipul de interfata cu TV-ul (display-ul). In ordine:
HDMI-DVI, YUV-RGB, SVideo-Composite. Avand in vedere tranzitia de la display-urile
cu intrari analogice la digitale si format 4:3 la 16:9 se pun urmatoarele probleme:

In general pentru instalarea initiala este recomandat sa folositi iesirile analogice
standard definition. (Composite, S-Video, SCART daca exista). Abia apoi puteti comuta
pe cele digitale sau de rezolutie sporita. Cele mai multe probleme apar de la acest lucru.
Un STB bine proiectat n-ar trebui sa te lase cu ochii in soare orice buton ai apasa.
In acest sens e bine sa cititi manualul unde pot fi definite butoane speciale pentru
activarea /comutarea diverselor tipuri de iesiri. Cea mai buna strategie este sa existe
un buton /combinatie de butoane (care sa nu poata fi accesate intamplator) si de ce nu
si butoane pe panoul frontal al STB, care sa faca trecerea de la un mod /rzolutie video
la alta(ul) chiar daca pe ecran nu apare nimic (STB-ul poate functiona). De asemenea,
trecerea de la o setare la alta sa se faca cu confirmare (ca la Windows) de asa natura incat
sa poti vedea pe ecran ca trebuie apasat OK numai daca display-ul poate lucra in acel mod
altfel sa revina la setarea initiala dupa 5-10 secunde. Avand in vedere ca display-urile de
ultima generatie au (unele) un timp mare de comutare, acest interval este de dorit sa fie
cat mai mare (cu riscul de a enerva clientul).
In functie de cat de bine este implementat softul si ce poate STB-ul ca hardware, aceste
comutari de rezolutie se pot face on-the-fly sau necesita restart. Sunt cazuri in care si simpla
schimbare a raportului display-ului necesita restart (la STB-urile de generatie mai veche).

1. Daca TV-ul nu are HDMI fiind de generatie mai veche, are ori DVI caz in care se poate
folosi adaptor DVI la HDMI si sunet separat de pe iesirile analogice ale STB-ului
(sau cablu optic /coaxial SPDIF catre un decoder 5.1)
Exista situatii in care acel DVI nu stie 1080i caz in care STB-ul trebuie sa poata fi trecut
usor in 720p (chiar blind cu un buton usor accesibil, daca nu ai nimic pe ecran).
2. Daca TV-ul nu are HDMI nici DVI si stie HD ar trebui folosite iesirile analogice YUV ale
STB-ului. Acestea pot fi comutate (tot blind de preferinta) intre 1080i, 720p, 576i,
ultima situatie daca display-ul nu stie HD dar are totusi intrari analogice YUV.
Aceasta iesire YUV ar trebui comutata si in RGB pentru o calitate superioara in cazul in care
televizorul are numai SCART, nu si YUV. In aceasta situatie problema se rezolva cu un cablu
3xRCA video + 2xRCA audio la SCART si comutarea corespunzatoare din meniu.
3. Daca televizorul are SCART dar nu stie RGB (de obicei au SCART dar numai cu Composite)
un cablu de la iesirea RCA Composite + 2xRCA audio la SCART rezolva problema.
Televizoarele cu mai multe SCART-uri au pini diferiti la mufe. In general cea cu RGB este prima
(marcata cu trei puncte  (...) sau RGB) iar cea de-a doua este S-video (uzual a treia este
Composite only, daca exista). Toate aceste 2-3 mufe SCART stiu si Composite.
Atentie, dupa cum am zis, nu toate mufele SCART ofera aceeasi calitate.
4. Un cablu simplu de la 3xRCA la 3xRCA rezolva problema conectivitatii in cazul in care
STB-ul nu are SCART. De obicei acestea au si S-video (nu obligatoriu) caz in care este recomandat
sa se foloseasca un cablu S-video +2xRCA audio pentru o calitate mai buna ca pe Composite.

Ca regula generala, toate iesirile modulate PAL (Composite, S-video) scot tot timpul semnalul
video in Standard Definition si 576i. Cand STB-ul primeste HD, pe aceste iesiri se face downscaling.
Iesirile analogice YUV se pot comuta si 576i, si 720p si 1080i, dupa nevoie. Trecerea acestor iesiri
in spatiul de culoare RGB se face din software si necesita un cablu cum s-a explicat mai sus.

Din cauza ca ne aflam in perioada de tranzitie operatorii au de ales intre 3xRCA YUV si SCART
pe spatele STB-ului. Daca ar opta la SCART i-ar incurca pe cei care vor HD dar avand televizoare
de generatie mai veche au nevoie de YUV. Daca aleg YUV (si asta fac majoritatea) este nevoie
de un adaptor de la 3xRCA la SCART daca se vrea calitate maxima (multi il livreaza in cutie)
sau se pot folosi celelalte iesiri: S-video si composite.
O dezbatere pe tema iesirii de sunet digital genereaza aceeasi dilema: unii si-au ingropat cabluri
coaxiale prin podea si vor SPDIF-ul electric, altii au intrari optice la receivere si-l vor optic.
Exista si STB-uri care le au pe amandoua cum la fel de bine exista si adaptoare potrivite.

Indiferent care este resolutia display-ului procesorul din TV interpoleaza pixelii ca sa poata afisa
formatul semnalului de la intrare. Dtancu a incercat sa explice cum functioneaza, daca n-a reusit
el sa va lamureasca, n-o sa reusesc nici eu. A punctat bine faptul ca in general TV-urile reusesc
mult mai bine sa interpoleze decat STB-urile. Mai mult, si de-interlacing-ul il fac mai bine.
Asadar, ca regula, daca aveti de ales in a oferi TV-ului vostru 576p din setarile STB-ului e bine s-o
faceti (daca stie 576p). La fel, daca semanlul vine 720p, e recomandat sa lasati STB-ul pe 720p
de asa natura incat televizorul sa-si faca upscalingul (sau downscaling-ul la plasme care au
1024x720 sau mai putin) la rezolutia nativa a panelului. Nu fortati STB-ul in 1080i daca sursa
nu stie mai mult ca n-o sa se vada mai bine. In cazul softului implementat pe browser nu faceti
altceva decat sa-i dati STB-ului de lucru inutil. La middleware-urile si STB-urile performante
nu are nici o relevanta pentru incarcarea STB-ului ce rezolutie alegeti (intrucat scalarea se face in
hardware poate doar STB-ul sa se incalzeasca mai tare).
Nu uitati ca pot exista diferente de aliniere de sunet daca folositi iesiri diferite. Operatiile din
TV-urile digitale moderne au nevoie de ceva timp de procesare. Stiindu-se acest lucru inauntru
lor exista corespunzator o aliniere intre sunet si imagine. Daca folositi de exemplu iesirea HDMI
pe video si cea analogica pe audio se poate ca sa existe diferente intre imagine si sunet care nu
sunt din vina operatorului. De asemenea daca folositi iesirile digitale de sunet (receiverele 5.1
au majoritatea setari de intarziere la sunet si alinieri in cazul cand functioneaza ca si comutatoare
de surse HDMI /analogice utile cand nu aveti destule intrari la televizor.

Topicul urmator:   16:9 sau 4:3?
Mostenirea display-urilor existente deja in teren ii incurca pe operatori. Toti si-ar dori ca abonatii
sa aiba 16:9 cu HDMI si sa uite de cele 4:3 cu intrari analogice. De aceea si meniurile trebuie tratate
in ambele scenarii ca si posibilitatea de a comuta pe o incadrare optima a imaginii pe ecran.

Ma opresc aici, poate sunt intrebari. Rog sa ma ajute si cei care sunt mai familiarizati cu problema.

Edited by DoruPetrescu, 18 January 2010 - 09:45.

Am sa las aici doar partea on topic postata de @strain

@strain:
''In alta ordin de idei,lasati-o draq (tu si alalalt) cu interpolarea in contextul pomenit. Interpolarea, sau compensarea miscarii, are treaba cu rata de cadre, nu cu upscalingul (rezolutia).''

Edited by rz, 15 January 2010 - 23:38.

"interpolarea" in cazul citat nu se referea la cadre. Pentru cadre e mai bun "intretesere" IMHO
Sensul era, ca sa inteleaga userii, similar cu Photoshopu'
Cu alte cuvinte daca trebuie sa inghesui 7 pixeli ai semnalului de la intrare intr-o suprafata de 3 pixeli
fizici ai panelului sau invers daca ai de scalat 3 pixeli dintr-o rezolutie inferioara pe un panel de o densitate
mai mare este nevoie sa construiesti o "corespondenta" intre cei de la intrare si cei de la iesire bazata pe
ponderi (nu e cazul sa intram in formule matematice, stie Photoshoupu' si televizoru' mai bine).
De aceea si eu si Dtancu am simtit nevoia sa precizam ca e de preferat sa lasi treaba asta in grija TV-ului.

@strain: Eu si "alalalt" suntem oameni de bun simt. Ne limitam la topic evitand calificativele ...

Edited by DoruPetrescu, 15 January 2010 - 23:16.

Cand l-am citat pe dtancu, paradoxal, era intr-un context in care aveam pareri diferite despre un subiect.
Asta nu inseamna ca ne-am apelat cu "tu si alalalt". Daca ai argumente vis a vis de subiect, be my guest!
M-as fi asteptat sa continui ghidul cu informatii utile pentru useri, daca ai alte pareri sa le explici asa cum
incerc sa fac eu. Avem amandoi acelasi statut pe forum si dupa cum ai observat nu eu te-am atentionat ci
moderatorul. Si eu pot sa gresesc sau sa nu aleg terminologia cea mai potrivita, Intr-un spatiu public nu
stii niciodata cui sa te adresezi. Sa vii cu termeni foarte tehnici ori nu intelege nimeni nimic, ori pari ca te
dai destept. Daca vorbesti pe intelesul gospodinei, sar ceilalti pe tine impunandu-ti o rigurozitate necesara.
Eu zic totusi ca nivelul la care am prezentat subiectul este pe media cunostintelor generale ale membrilor.
Daca tu reusesti s-o spui mai bine, do it, dar la modul politicos, nu ca in PM-urile pe care le-am primit eu.
Pe vremea cand editam revista Hi-Fi si Multimedia si faceam review-uri la Sony, Panasonic si alte branduri
chiar daca nu erau totdeauna favorabile nu i-am vazut pe specialistii de acolo decat cu respect pentru ce
scriam in revista. Desi am un forum cu 10.000 de membri si as putea sa-mi exercit dreptul de veto acolo
am preferat sa postez pe Softpedia unde sunt egal cu toata lumea. Tocmai in interesul dialogului, lucru pe
care vad ca tu incerci sa-l duci in derizoriu. Sa fie buna o atitudine ostila numai ca avem pareri diferite ?

Edited by DoruPetrescu, 15 January 2010 - 23:48.

Multumim frumos pentru informatiile utile postate. Foarte buna ideia deschiderii acestui topic.

As avea 2 intrebari......
1. In general pentru IPTV va exista permanent problema lag-ului pentru STB-uri la schimbarea canalelor ? Adica exista sansa ca in viitor sa apara un STB care sa asigure o viteza de reactie "in timp real"?

2. Legat de explicatiile de mai sus privind rezolutia din STB...........De unde stim care este rezolutia la care "vine" semnalul atat timp cat in STB exista toate cele 3 optiuni setabile: 576p, 720p si 1080i?

Multumesc.

Explic cat pot de simplu: factorii care influenteaza zapping-ul sunt: latenta retelei (CPE, switch-uri, routere), bufferele
(network dejittering, eventuale buffere suplimentare in STB), viteza aplicatiei care interpreteaza tipul si elementele din
stream si decoderul audio video. Daca bufferele sunt de cele mai multe ori neglijabile in raport cu restul, operatiunea de
play din STB se face destul de greu in primul rand datorita felului in care este construita compresia (MPEG2 sau H264).

La MPEG2 structura GOP (grup of pictures) are cca doua I-frame-uri pe secunda (un I-frame este un cadru complet din
cele 25 pe secunda, ca un fel de poza JPEG) completata de P si B (informatii gen diferenta intre cadre succesive, unele
chiar intre cadre anterioare si ulterioare). Decoderul din STB nu poate face play pana nu primeste o referinta (I-frame)
urmand apoi sa inceapa redarea prin reconstructia imaginii folosindu-se de P-uri si B-uri. Asadar trebuie sa astepte cca
jumatate de secunda. La H264 compresia este si mai eficienta insa se bazeaza preponderent pe rarirea cadrelor de tip I
care ocupa cea mai mare parte din informatie (P-ul si B-ul fiind diferente, ocupa mult mai putin). GOP-ul implicit H264
permite cca un I-frame pe secunda. Se vede cu ochiul liber ca la MPEG2 zapping-ul este mai bun ca la H264. Si la H264
Se poate altera GOP-ul pentru a accelera zappingul in detrimentul bitrate-ului. Mai sunt insa intarzieri ale aplicatiei care
interpreteaza codecul, sincronizeaza audio cu video, descopera subelementele componenete ale streamului (audio, video
teletext, subtitrari etc) care in functie de cat de bine este scrisa "mananca" pana la 2 secunde. In viata reala un IPTV pe
MPEG2 zappeaza la 1-1.5 secunde iar unul pe H264 zappeaza la 2.5-3 sec. Pana acum am explicat partea din decoder.

In partea de networking, ca sa chemam un stream catre STB cand schmbam canalul se face o cerere in retea. Daca in
primul echipament de networking mai consuma cineva canalul respectiv, acesta este automat trimis si catre noi. Daca
nu, este cerut in amonte la echipamentul urmator (explicatia este valabila la operatorii care folosesc multicast la IPTV).
Timpul pana cand ajunge streamul la noi influenteaza zappingul. Intr-un nod sarac in abonati, schimbarea canalelor se
poate face greu, pe masura ce abonatii se inmultesc probabilitatea ca acel canal sa fie vizionat de alt abonat creste deci
si experianta noastra privind zappingul ar trebui sa se imbunatateasca. Lucrurile nu stau tocmai asa, intrucat pentru a
filtra streamurile (canalele) echipamentele de networking incep sa transpire (IGMP snooping) si transporta pachetele
din ce in ce mai greu. Cand echipamentele de retea sunt ori la limita, ori prost configurate zappingul poate ajunge si la
7-8 secunde. CPE-ul (routerul) din casa abonatului (care trebuie sa fie ieftin contribuie) si el decisiv la intarzieri.

In timp clientul se obisnuieste chiar daca zappingul e lent. Mai rau este cand vine dinspre cablul analogic unde canalele
se schimba relativ repede. La zapping performantele IPTV-urilor de la noi sunt: iNES 0.5-1 sec, RCS-RDS 1-1.5 secunde,
Romtelecom (codec H264) 2.5-3 secunde. De mentionat ca RCS-RDS desi are MPEG2 ca iNES in STB mai exista un buffer
suplimentar pentru corectia de erori (ca sa nu patrateasca si sa mearga si pe Wi-Fi). In plus distributia este unicast.
Si la iNES si la Romtelecom distributia este multicast.

Rezolutia la care vin canalele este de obicei 576i (pana la 720 orizontal cu 576 vertical) pentru SD si 720p (1280x720) si
1080i (pana la 1920 orizontal cu 1080 vertical) pentru HD. Nu ai de unde sti daca Set Top Box-ul nu-ti afiseaza informatii
despre stream. Oricum poti sa te increzi in informatiile de pe forum, majoritatea membrilor stiu sau au de unde sa afle ...
iNES transmite bitrate si resolutie nativa (cum vine din satelit), RCS-RDS transmite nativ pana la 13-14 Mbps dupa care
transcodeaza semnalul, Romtelecom transcodeaza la <8 Mbps cu 720p in vederea penetrarii serviciului si pe liniile ADSL.

Tehnologia de azi permite si zapping accelerat insa sistemul este foarte scump. Microsoft de exemplu se bazeaza la fast
zapping pe faptul ca la schimbarea canalului ochiul nu percepe detaliile. Trimite un stream de joasa rezolutie initial care
dupa 1-1.5 secunde este inlocuit de cel full. Aparent schimbarea este instantanee. Alti furnizori care folosesc unicast fac
schimbarea din echipamentul care trimite pachetele catre STB lipind pe I-frame (sa nu apara intreruperi) canalele similar
cu add-insertion. STB-ul nu-si mai schimba parametri, doar trimite o comanda echipamentului care-l deserveste. Alte
metode se folosesc de PiP (picture in picture) pentru a imbunatati zappingul cum face RCS-RDS. Desi are zapping rapid
(MPEG2) se poate naviga si mai rapid cu PiP-ul (se pot schimba si 5-6 canale pe secunda intrucat codecul este intraframe)
iar cand te-ai hotarat la canal apesi OK si imaginea apare pe tot ecranul. Solutia este unicat in lume, marca CrossPoint ...

Edited by DoruPetrescu, 16 January 2010 - 11:58.

Asta o sa fie un thread foarte interesant ! Intrebare legata de format:

Atunci cand sursele unui canal difera ca format astazi din studio se fac transformari prin introducerea de benzi negre (sau mult mai grav prin deformarea imaginii cum face DigiSport HD). Este posibil la IPTV ca imaginea sa vina nativ iar in STB fiecare abonat sa-si seteze propria politica de preferinte in privinta adaptarii la ecranul lui ? Evident , asta inseamna o semnalizare perfecta a tipului de imagine (ce azi la DVB_C RCS nu exista) si probabil o variatie a bitrateului. Sau daca nu o face STB-ul macar sa o faca TV-ul ...

Daca ai observat in primul meu post incepusem subiectul dar am renuntat din cauza orei inaintate.
In plus, mai aparuse si un "strain" pe-aici si mi-a luat si mie si moderatorului rz vreo ora sa-l linistim.
O sa raspund in cursul zilei de azi, imi ia ceva timp sa vad cum fac sa nu va confuzez mai rau ...

Edited by DoruPetrescu, 16 January 2010 - 12:40.

DoruPetrescu, on 16th January 2010, 11:46, said:

1. Intr-un topic pe rdi sustineai ca la canalele HD care transmit la un bitrate mare, ca Discovery Hd si History HD rds va face transcodare de semnal. La acea data "sfetnic"sustinea ca se va lasa streamul la bitrate-ul nativ. Acum vad ca sustii acelasi lucru: ca se va face transcodare pe la 13-14 mbps unde este cazul. Este solutia finala?
2. Cand vorbesti despre echipamente si te referi la CPE (Consumer Premise Equipment) este vorba despre STB, router sau ONT-HG865. ONT-ul am vazut ca in Oradea, la case se instaleaza chai in casa. La blocuri am inteles ca este unul la 20 de apartamente. Corect? Nu cuva router-ul despre care spui ca vine pe 25 ian in Oradea este chiar HG865 si se va monta in absolut toate apartamentele ce vor IPTV?

Nu are nici un rost sa livrezi Discovery la 22 Mbps in MPEG2, 12-14 Mbps in H264 este mai mult decat suficient.

La GPON, echipamentul din scara de bloc este diferit (Gigabit) iar cel de la casa este de 100M. Exista deocamdata
si scari de bloc cu ONT comun de 100 Mbps dar se vor inlocui pe masura se se incarca scara respectiva cu abonati.
Tot din ONT-ul comun porneste si coaxialul care prin splittere ajunge in apartamente sa serveasca analog si DVB-C.
Cel de la casa serveste direct Set Top Box-urile si computerele prin porturile Ethernet (optional are coaxial pentru
analog si DVB-C). In spatele echipamentului de bloc este un switch care ofera 100M UTP la fiecare apartament si
un MGCP gateway (comun in scara de bloc) care trimite telefonie pe doua din cele 4 perechi de cupru ale cablului
UTP care ajunge in fiecare apartament. Acolo vine un router care imparte cei 100M la STB-urile IPTV si calculatoare.
Modelul din apartament ales pentru testele din Oradea este un Microtik RouterBoard, nu stiu pe deasupra ce model.


Rugamintea este sa discutam aspectele specifice RCS-RDS pe topicul existent, si sa lasam aici loc de tutorial. OK?

Edited by DoruPetrescu, 16 January 2010 - 16:04.

Revin cu informatiile depre DISPLAY-uri si FORMATE
In casa abonatului exista si display-uri 4:3 si 16:9. In STB exista un meniu pentru alegerea tipului de display.
(la unele modele de STB-uri este nevoie de un restart pentru a modifica tipul de display, motivul principal fiind
re-initializarea browserului daca meniurile sunt pe browser. Nu este deranjant intrucat nu schimbi display-ul
din 5 in 5 minute). Odata cu aceasta setare STB-ul stie cum sa ofere informatia video la iesire catre display.

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). Ea poate fi oferita si displayului TV ori prin liniile
de stingere (la PAL) ori in cazul in care exista SCART pe un pin special care ofera o tensiune de 4-7V in vederea
acestei semnalizari (tensiunea este 0 daca STB-ul e oprit si 12V daca e activ iar formatul este 4:3,  lucru care face
ca televizorul sa si comute automat pe intrarea respectiva). In cazul SCART, la SD, Intre STB si TV abonatul trebuie
sa decida cine anume sa faca incadrarea. Desi  multe ori informatia, desi transmisa pe doua cai nu este suficienta...

Exemplu: abonatul vede un canal care este definit (semnalizat) ca 4:3 insa provine dintr-un format wide si are doua
dungi negre sus-jos. Situatia este frustranta pe un display 16:9 care ofera o imagine corecta ca raport insa in centrul
ecranului. Se simte nevoia de zoom si acest lucru poate fi facut ori manual, ori automat. 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. Pentru cei curiosi, un link util este: http://www.pjdaniel....k/afd/index.asp
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).
In cazul in care nu stie ramane varianta manuala din STB: ori ca preferinte generale, utila in cazul in care canalul
nu schimba tipul de incadrare, ori, in situatia reala se simte nevoia de un buton usor accesibil de unde abonatul
sa-si optimizeze afisarea (pan-scan, letterbox, wide, nonlinear). Chiar daca incadrarea poate fi imbunatatita manual
sunt situatii in care din motiv ca subtitrarile nu sunt separat in stream ci sunt arse in imagine, acestea ies din format
si trebuie facut un compromis alegand o incadrare "la pace". Mai sunt situatii in care STB-ul nu pastreaza pozitia
subtitrarilor (de multe ori nici a meniurilor, proportia si formatul imaginii modificandu-se odata cu meniul, neplacut)

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 ...  

In legatura cu Digi Sport se lucreaza la aceasta semnalizare pentru depasirea limitarilor encoderului intrucat deocamdata
problema raportului deranjeaza la HD 16:9 mai mult decat la SD 4:3 (unde incadrarea corecta doar alungeste sigla postului)

Edited by DoruPetrescu, 16 January 2010 - 17:20.

@Doru
Sarutmana.Este intr-adevar un ghid profesionist de semnale video, pe care il faci probono, in pofida injuriilor si amenintarilor nervoase si voalate pe care le primesti pe diferite canale de la managementul RTC. Este o consultanta gratuita pe care ar trebui sa o citeasca toti tehnicii DOLCE interactiv, cei din call center , cei din NOC sau din head-end. Pentru a vea accest knowledge based on experience and expertise la acest  s-au platit multi bani la consultanti pana acum ...si se vor mai plati si de acum inainte! Cei din Ericsson ar trebui sa iti multumeasca de o mie de ori mai mai mult...Daca as fi CEO Romtelecom , te-as chema maine la cafea si ti-as multumi public ,in fata la tot boardul, cerandu-ti scuze pentru neplacerile si daunele provocate de anularea unilaterala a contractului. Ti-as oferi pe loc, un alt contract la de 2 ori banii pe care ii plateste ROmtelecom lui Ericsson, numai ca sa nu semnezi cu RDS! Din fericire (pt dl Teszari) nu sunt CEO Romtelecom si nici nu lucrez sau nu am prieteni in aceasta companie.Sunt doar un viitor fost client de IPTV RTC, caruia nu ii functioneaza , dar care este facturat abuziv cu multe milioane pentru un serviciu de care nu poate beneficia, din vina exclusiva Romtelecom!
O sugestie pentru cei de la IPTV RTC: dati un semnal de test din STB catre TV , macar pe iesirea analoaga, ca eu am 5 intrari AV in TV si nu stiu pe care e IPTV-ul. Macar sa stiu ca intre STB si TV semnalul curge. Acum 15-20 ani, pe modulatoarele RF de antena , pe canalul 39 era mira generata automat si stiam unde e semnalul de la video, cand cautam pe selectorul UIF din televizorul NEI/Samsung sau Goldstar...E doar o sugestie, sper sa aprecieze baietii si sa nu primesc si eu injurii pe privat!

Multumesc Ovidiubox,
Mai zicea cineva zilele trecute ca ar fi trebuit procedat ca la fotbal cand scoti 2 jucatori la incalzire prin minutul '70 ...
N-apuca sa intre in teren dar ii tii ocupati ... Intradevar Rtc ma putea tine legat, din pacate pentru ei unii chiar s-au
bucurat ca au scapat de mine. Dar asa-i in sport. Cine rade la urma rade mai bine si acela nu poate fi decat Teszari.
Am mai primit un mesaj azi noapte pe PM in care eram avertizat ca n-o sa-mi plateasca RCS ... ha, ha, platesc ceas
si daca ma supar nu trebuie sa intreb pe nimeni sa-i fac gratis IPTV lui RCS-RDS ...  


Cu riscul de a te supara, vreau sa tin topicul asta curat. Intreaba-ma ce vrei pe RCS-RDS, aici e doar tutorial.

Edited by DoruPetrescu, 16 January 2010 - 17:41.

Multumesc pentru raspuns. Ati putea aborda in prezentarile dvs si o alta latura ? M-ar interesa cum se regasesc azi cele prezentate. De exemplu AFD este un standard general raspandit, e ceva ce va sa vie ? Cate dintre posturile curente in RO pot sau cand vor putea sa adere la acesta? (Bine-nteles, nu-mi permit sa intreb pe acest thread dar de prim interes este situatia celor transmise de RDS).

O alta intrebare: uzual TV-urile tin minte o setare de zoom/pan/etc pentru o anumita categorie de transmisie, de exemplu Samsungul pastreaza setari diferite pentru HD si SD. Este uzual in lumea IPTV ca STB-ul sa stocheze preferintele la nivel de canal individual ? Cred ca ar avea sens sa ai o setare generala pentru HD de exemplu apoi pt fiecare canal sa ai "prefered" sau o setare proprie (cum este azi la limba subtitrari)

Multumesc pentru explicatii.....O sa continui sa pun intrebari.

Dupa atatea informatii legate de imagine cred ca multi au intrebari si legate de sunet. Una din asteptarile mari ale clinetilor de IPTV este sa poata sa receptioneze sunet de calitate, daca se poate  in acelasi format livrat de canalul sursa. Ce-ar insemna asta in general dpdvd al tehnologiei folosite? Sunt limitari legate de banda de transmisie? De ce de ex. RTC nu poate sa furnizeze acum decat stereo la canalele HD? La RDS-RDS cum va fi?

anicoara, on 16th January 2010, 21:47, said:

AFD-ul nu este raspandit, e un standard pe cale de implementare. Majoritatea au WSS. RCS-RDS retransmite canalele asa cum
vin de la studiouri sau din satelit. Cand acestia vor avea AFD, va ajunge si in STB-ul vostru fara ca RCS-RDS sa faca nimic.

In lumea IPTV-ului se poate teoretic orice.
Setarile se stocheaza de obicei in preferintele generale ale userului. Nu este imposibil sa le salvezi per canal.
Nu are sens, intrucat cum am explicat chiar pe acelasi canal vrei sa modifici din cand in cand. Este suficient
sa poti schimba usor asa cum faci cu sunetul, subtitrarile (acestea din urma este recomandat sa se salveze,
desi nu cred ca abonatul va dori sa aiba la un canal sunetul in limba romana, la altul in ceha sau in maghiara).

abogdan, on 17th January 2010, 00:40, said:

Prevad ca asta va fi un raspuns luuung si in care iar voi fi acuzat ca am ceva cu Rtc ...  
Am explicat sumar la sectiunea Rtc care sunt optiunile din punct de vedere al sunetului, incerc s-o lamuresc mai pe larg.

Pentru a "prepara" canalele la IPTV exista mai multe optiuni. Acestea au in vedere in primul rand posibilitatile retelei, in special partea de acces.
Un operator cu ADSL (telecom) doreste sa acopere cat mai multi abonati cu serviciul, si pe cei cu sarma de 500m si pe cei cu sarma de 2 km.
Aceasta constrangere il obliga sa faca unele compromisuri. La capitolul banda nu are incotro, trebuie sa reduca bitrate-ul in detrimentul calitatii.
La sunet si restul optiunile se bifurca, nu au treaba cu banda decat partial. Spun partial intrucat un sunet multicanal ocupa 400K, unul stereo
pana in 250k (de multe ori e nevoie de ambele) un teletext si o subtitrare zeci de K asadar exista un impact si la banda ocupata, n-ai incotro.

1. varianta re-encodarii:
Receptoarele profesionale de satelit ofera doua tipuri de iesiri: ASI unde sunt prezente toate canalele din transponder (criptate sau nu) si SDI
unde este prezent canalul selectat decodat din MPEG in formatul de studio. Operatorii mari isi mai iau si canalele pe fibra direct de la posturile
de televiziune, asdar au canalul (necomprimat in MPEG) direct in curte (se elimina intarzierile de satelit, caderile de vreme rea si se obtine o calitate
mai buna). Daca preiei semnalul SDI din receptor asa cum face Rtc, pe langa video trebuie sa tratezi si restul de elemente: audio, teletext,
subtitrari. Acest semnal se aplica la intrarea unui encoder care la iesire ofera streamul generat din canalul de la intrare reprocesat: de obicei se reduce
bitrate-ul prin folosirea eventuala a unui codec mai bun cum este H264, subtitratea dispare ca stream separat (se arde in imagine), sunetul se
reproceseaza (in detrimentul calitatii). Nu este imposibil ca folosind forta bruta (costuri aberante) sa construiesti o a doua cale de semnal preluand
din ASI componentele de subtitrare si audio care insumate si resincronizate la iesire cu semnalul video procesat din SDI sa genereze streamul final.
De obicei, si subliniez de obicei, telecoamele nu-si bat capul cu a doua cale, prefera sa reproceseze si audio iar subtitrarea s-o arda in imagine.
Cablistii in general, si in particular RCS-RDS au mai multa experienta in contruirea unui sistem TV cu acoperire nationala. Stiu ca exista zone unde
abonatii prefera limba maghiara, turca, sarba etc. La fel, abonatii au pretentia sa poata sa-si schimbe subtitrarea asadar ea trebuie separata in stream.
Avand mostenirea cablului analog si experienta pe DVB-C unde banda nu este asa critica Operatorii de cablu prefera varianta 2:

2. varianta transrate-ing:
Uzual folosita la cablu digital. Iesirea ASI a receptoarelor este pasata unui remultiplexor care selecteaza canalele utile si le grupeaza pe MPTS-uri.
(multi program transport stream) adica mai multe canale al caror bitrate agregat (exemplu 6 canale x 6 Mbps medie = 36 Mbps total) se aplica la
intrarea modulatoarelor de DVB-C care ori in 64 QAM ori in 256 QAM trimit semnalul la STB-urile de DVB-C din casele abonatilor. Este de subliniat
ca aceste canale nu au totdeauna un bitrate constant si din motive ca la intrarea unui modulator (fie el QAM la DVB-C, QPSK la satelit, COFDM la
DVB-T) este nevoie de un bitrate constant (altfel spectrul s-ar intinde cat China iesind din canalul alocat) este necesar ca suma canalelor sa fie
pastrata. Intrucat canalele variaza ca bitrate instantaneu, suma lor poate avea cand 25 Mbps cand 36 Mbps. Daca alegem 64 QAM pentru DVB-C
diferenta pana la cca 38 Mbps trebuie umpluta cu asa zisele "null-packets" care nu sunt informatie utila si se introduc cat este nevoie pentru a pastra
bitrate-ul constant la iesire. De multe ori aceasta solutie este neeconomica iar cablistii prefera sa re-proceseze canalele prin metoda transrating.
In ce consta? procesoarele taie in mod dinamic din vectorii de miscare (am explicat mai sus cu frame-urile I,P si B la MPEG) cat este nevoie ca suma
celor 6 canale sa fie constanta, inghesuind inca unul doua canale pe purtatoare. Metoda asta se foloseste si la uplink-ul de satelit si se numeste
multiplexare statistica, functioneaza insa prin re-encodare intrucat este mai eficient (o sa explic si de ce in continuare). Asadar cand bitrate-ul
celor 8 canale este mai mic de 38 Mbps se baga pachete de null, cand este mai mare se "tunde" din fiecare (exista un stack de prioritati de asa
natura incat unele canale sa se vada mai bine) ca sa obtii cei 38Mbps constant la iesirea catre modulator.
Toata aceasta strategie se bazeaza pe matematica, statistic intelegand ca cele 8 canale adunate variaza independent si de capul lor caci daca ai de
adunat 8 canale cu acelasi continut strategia asta nu mai este eficienta (exista si aici alifii, nu e cazul sa le divulg pe toate gratuit pe forum ...).
Avcest transrating de DVB-C mai are un dezavantaj, anume ca nu poti reduce bitrate-ul mai mult de 15-20% intrucat la miscarile bruste pe ecran
imaginea apare sacadat si deranjeaza clientii. Nu insist mai mult ca topicul nu era pentru DVB-C ...

3. Varianta transcoding (cea recomandata pentru Telecom)
La iesirea receptoarelor de satelit ori prin ASI ori prin streaming in IP semnalul se aplica unor transcodere care proceseaza NUMAI semnalul video,
reducandu-i bitrate-ul la cat se poate livra in retea (se schimba eventual si din MPEG2 in H264) iar toate celelealte semanle: audio (toate pistele),
teletext-ul, subtitrarile, alte metadata se fac passthrough la iesire prin intarzierea necesara alinierii cu semnalul video reprocesat (reprocesarea nu se
poate face fara intarzieri). Metoda este ieftina, elimina toate neajunsurile (arderea subtitrarii in imagine, costul ridicat al encoderelor cand ai nevoie
de mai multe piste de sunet - EuroNews, de exemplu, problemele aferente teletextului etc), nu afecteaza calitatea originala care vine de la postul de
televiziune la sunet si ai si sunet 5.1 la iesire fara bataie de cap si cu costuri zero. Paradoxal, fata de reencodarea din SDI solutia pe langa faptul ca
are aceste avantaje majore (calitate, multiple languages, subtitling, 5.1, teletext) este si de doua ori mai ieftina fara sa tinem socoteala de matricile
SDI necesare comutarii si asigurarii redundantei in headend (foarte scumpe) intrucat redundanta in IP se asigura mult mai usor, va dati seama ...
Sincronizarea sunetului (fie stereo, fie 5.1) este facuta de unul si acelasi echipament care "cunoaste" in mod dinamic cat timp are nevoie pentru
reprocesarea video (reducerea bitrate-ului). De aceea daca se alege re-encodare (varianta 1) cu a doua cale de adaugare a celorlalte componente
sumarea facandu-se in echipamente separate si de obicei neomogene ca vendor exista decalaje intre imagine si celelalte. Daca la teletext chiar nu
conteaza, la subtitrari conteaza destul de putin (numeni nu moare ca apar mai devreme sau mai tarziu cu o secunda), la audio este cam frustrant.
Echipamentele de pe "a doua cale" au de obicei o intarziere medie prestabilita iar daca encoderul are o informatie mai complexa de procesat intarzie
si se desincronizeaza audio. Problema apare si mai grav in cazul in care se alege CBR (constant bit rate) cum banuiesc ca are Rtc la streamul de iesire
intrucat atunci cand pachetele se inghesuie aleator trebuie obligatoriu preluate de un buffer (care intarzie cu alte 1-2 secunde) si care functioneaza
similar cu toarcerea lanii cand o pui pe fus cu o grosime constanta: daca vine mai multa trebuie subtiata, daca vine prea putina trebuie adunata.
Este foarte greu de sincronizat audio cu video in aceasta configuratie. Problema se agraveaza in Set Top Box, intrucat pachetele sunt greu de "stampilat"
de asa natura incat STB-ul sa-si faca treaba corespunzator. Orice sincronizare mai precisa implica un zapping time lent, in defavoarea abonatului.

4. Varianta passthrough (in general folosita de cablisti sau cand ai banda la dispozitie cum este si RCS-RDS, sau iNES)
La iesirea ASI se instaleaza streamere care convertesc in IP semnalul ce ajunge la abonat fara nici o procesare suplimentara (calitate maxima).
Costa doi lei, are tot ce trebuie (subtitrari separate, toate sunetele originale si 5.1 la calitatea transmisa de postul de televiziune, teletext etc).
Intr-un STB cu soft bine facut poti sa-ti selectezi ce subtitrare vrei, ce sunet stereo sau 5.1 vrei, nu ai pierderi de calitate nici la video nici la audio.
Este tot ce-si poate dori un abonat intrucat livrarea nu depinde de operator, poti cel mult sa dai vina pe postul de televiziune. Metoda este eficienta
intrucat exista posturi ca RTL, Pro7, Sat1 care pe langa stereo transmit si AC3, deci ai doua piste de sunet pe care le poti selecta. Recent, o gramada
de posturi si-au imbunatatit calitatea, de exemplu TVR-ul a urcat bitrate-ul pe satelit la 8 Mbps la mai toate canalele. ProTv transmitea deja la 7-8,
Antena 1 si Realitatea la 5-7 Mbps etc. HD-urile pot fi oferite nativ (10-14 Mbps) fara pierdere de calitate si intarzieri etc. Exista si exceptii: si iNES si
RCS-RDS au in vedere coborarea bitrate-ului canalelor de 18-22 Mbps pana la un 12-14 Mbps suficient pentru abonat (Discovery, History HD).

Si Romtelecom lucreaza la 5.1 si subtitrari separate. Intre dorinta de a oferi cat mai multor abonati HDTV prin reducerea bitrate-ului pe de o parte
si calitate de cealalta parte trebuie sa faca un compromis. Sunetul multicanal mananca destul bitrate ca sa influenteze si mai mult calitatea video
asadar trebuie o compresie si mai mare pe video sau renuntarea la procente de penetrare al serviciului cu HD. Si ei sunt fortati sa-si regandeasca
reteaua in special in acces. Din motive de teritorialitate si disponibilitate cei ce vor dori IPTV nu vor avea optiuni. Sunt convins ca vor face eforturi
pentru un serviciu de calitate iar de acum incolo vor intelege ca nu toti cei care te critica iti vor raul si nu toti care te lauda iti vor binele. Sper !

Si mai sper ca n-am fost prea tehnic (am incercat pe cat se poate sa explic pe intelesul tururor) sau prea putin riguros pentru cei care
au bagajul de cunostinte necesar. Ca pe abonati nu-i intereseaza detaliile si scuzele, e foarte adevarat. Pana la coada toate se rezolva ...

Edited by DoruPetrescu, 18 January 2010 - 00:41.

Va rog nu-mi mai dati mesaje pe PM! Nu am nimic de ascuns si cred ca nici voi nu aveti.
Pe de o parte problemele voastre sunt de interes general si e bine sa le tratez o data pentru toti
si in al doilea rand n-am timp sa raspund individual, fac si asa eforturi, si nu vreu sa par nepoliticos.
In plus, am si fost ridicat la grad de moderator si am destula treaba. Multumesc de intelegere!

Edited by DoruPetrescu, 17 January 2010 - 17:01.