УНИВЕРЗИТЕТ У ПРИШТИНИ

ФАКУЛТЕТ ТЕХНИЧКИХ НАУКА

ЗАВРШНИ РАД
ОСНОВНЕ АКАДЕМСКЕ СТУДИЈЕ

Тема: Технологија мултимедијалних сервиса у Интернет

мрежи
Предмет: Рачунарске основе интернета

Ментор: Студент:
Проф. др. Бранимир Јакшић Страхиња Бишевац 7/16

Косовска Митровица, новембар 2021.

 САДРЖАЈ

УВОД

1. ПРОТОКОЛИ ЗА STREAMING..............................................................................................................4
1.1. RTP (Real Time Protocol).............................................................................................................4
1.2. RTSP (Real Time Streaming Protocol)..........................................................................................6
1.3. RTMP (Real Time Messaging Protocol)........................................................................................8
1.4. HLS – HTTP Live Streaming.........................................................................................................12
2. IPTV...................................................................................................................................................16
2.1. Headend....................................................................................................................................17
2.2. IPTV Middleware платформа....................................................................................................20
2.3. Мрежна платформа за дистрибуцију IPTV сигнала...............................................................21
2.4. Транспортне мреже.................................................................................................................22
2.5. Кућна мрежа за пренос IPTV сигнала.....................................................................................23
2.6. Квалитет сервиса IPTV..............................................................................................................24
3. WEB TV..............................................................................................................................................29
3.1. Елементи Web TV-a..................................................................................................................32
4. OTT (Over-the-top)............................................................................................................................34
4.1. ОTТ - IPTV..................................................................................................................................38
5. АПЛИКАЦИЈЕ ЗА STREAMING...........................................................................................................40
5.1. Facebook...................................................................................................................................40
5.2. Instagram...................................................................................................................................44
5.3. WOWZA.....................................................................................................................................45
6. ЗАКЉУЧАК........................................................................................................................................49
ЛИТЕРАТУРА

2
 УВОД

Са развојем компјутерских мрежа и интернета јавила се потреба за преносом

мултимедијалних садржаја кроз компјутерске мреже у реалном времену, како би
мултимедијални садржаји могли да се преносе и приказују у реалном времену на
удаљеним компјутерима на интеренту или другим компјутерским мрежама. Ова потреба је
проузроковала појаву и убрзани развој технологија које су назване мултимедијалним
стреаминг технологијама (MMST). Основу ових технологија чини протокол за пренос
података у реалном времену (Real Time Protocol, RTP), који у уједно представља основни
стандард за пренос свих врста података који захтевају транспорт у реалном времену.
Такође, на овај протокол се надовезује и протокол за стреаминг у реалном времену (Real
Time Streaming Protocol) који представља допуну првом стандарду везано за стреаминг
мултимедијалних садржаја. Око ових стандарда су софтверске компаније развијале своје
технологије и неке нове стандарде за пренос мултимедијалних података у реалном
времену.

Најчешће мултимедијалне streaming технологије се примењују у областима VoIP

(Voice over Internet Protocol; телефонирање преко интернета, онлине chat системи), Video
on Demand (Видео емитовање на захтев), Internet Radio и TV stations (Интернет радио и ТВ
станице), Audio/Video Conferencing (Аудио/Видео конференције). Ове streaming
технологије су пронашле своју употребу у многим софтверским и хардверским уређајима.
Данас често нисмо ни свесни да користимо неки производ који користи неку од
мултимедија стреаминг технологија. Појам мултимедија односи се на такав садржај који
од нас захтева употребу више чула да би смо га схватили у потпуности. Напредак
технологије променио је начин на који користимо звук и слику. Раније смо слушали радио
и гледали програм преко телевизије, користили смо телефон за интерактивну
комуникацију, али времена су се променила.

3
 1. ПРОТОКОЛИ ЗА STREAMING

Стриминг (streaming) је термин који означава емитовање садржаја преко Интернета

крајњем кориснику. Материјали који су припремљени се стартују аутоматски и не
задржавају се на рачунару корисника. Снимак није потребно учитавати пре емитовања
зато што се учитавање врши у реалном времену за време трајања снимка. Квалитет
емитованог дигиталног програма зависи од квалитета Интернет конекције корисника.
Емитовани програм може бити само аудио, само видео или аудио/видео запис.

Постоје две врсте емитовања дигиталног програма путем стрима:

 Уживо (Live) – директан пренос преко Интернета (други назив овог преноса је и
webcast)
 На захтев (On-demand) – емитовање унапред припремљеног снимка на захтев
корисника

Да би се пренос реализовао користе се различити протоколи, што зависи од начина

жељеног преноса и опреме која се користи. У наставку ће бити опширније описано само о
неколико најбитнијих протокола.

1.1. RTP (Real Time Protocol)

RTP је протокол за транспорт медија у реалном времену преко unicast или multicast
мрежних сервиса, а у већини случајева H264 и MPEG4 видеа и аудија. RTP је дизајниран
од стране IFTF’s радне групе за аудио и видео транспорт како би подржао видео
конференције са више географски раздвојених учесника. Овај протокол је сам по себи
push протокол, то значи да ако енкодер жели да пошаље стрим (stream) видео декодеру
помоћу RTP протокола, он мора да зна IP адресу декодера и „гура“ податке на декодер. По
правилу RTP протокол примарно ради на UDP (User Datagram Protocol) протоколу, мада

4
може користити и друге транспортне протоколе. Овај протокол има задатак да шаље
податке у реалном времену. Такође он може ефикасно решити проблем кашњења у мрежи
на штету квалитета и може решити синхронизацију података различитих стримова.

Енкодовање података (аудио и видео) енкапсулирано је у RTP пакете, заглавље

преко пакета пружа информације о редном броју пакета, али, RTP не може пружати
поуздан механизам за пренос пакета у секвенцу, нити пружа контролу протока. Контрола
протока се ослања на RTCP (Real Time Control Protocol) протокола.

Заглавље RTP пакета садржи: број секвенце (Sequence Number) – користи се за

детектовање изгубљених пакета; идентификацију корисних података (Payload type) -
описује тип медија, као и њихов енкодинг како би прималац знао како да их декодује, овај
податак је променљив и зависи од варијација у пропусности; индикацију фрејмова (frame)
(M) - означава почетак и крај сваког фрејма; унутармедијску синхронизацију (Timestamp) –
ово је најбитнији део механизма овог протокола. Користи временске ознаке за откривање
различитих кашњења унутар једног тока и врши надокнаду истог. Помоћу овог механизма
прималац репродукује садржај у правилном редоследу; Извор синхронизације
(Synchronization source (SSRC) ID) – идентификује извор мултиме-дијалног садржаја,
уколико подаци долазе са истог извора имаће исти SSRC ID; Идентификација извора
(Contributing Source (CSRC) ID) – идентификује извор (на пример све учеснике аудио
конференције) и везија (V) – ово поље идентификује верзију RTP-a.

Слика 1: Заглавље RTP пакета

5
 За ефикасан рад протокола број тачака за мултиплексирање требао би да буде што
мањи. RTP пружа мултиплексирање одредишне адресе (мрежна адреса и број порта) који
се разликују за сваку RTP сесију. На пример у телеконференцији састављеној од аудио и
видео медија кодираних одвојено, сваки медиј мора бити пренешен у засебној RTP сесији
са сопственим одредиштем адреса. Преплитање пакета са различитим врстама RTP медија
али истим SSRC-a произвело би доста проблема. С друге стране, мултиплексирање
вишеструко повезаних извора у једној сесији користећи различите SSRC вредности не би
изазвало проблеме. Као још једно погодно решење намеће се и мултиплексирање токова
истог медија користећи различите SSRC вредности што елиминише доста грешака.

RTP пријемници пружају повратне информације о квалитету пријема користећи

RTCP извештаје. Пакети могу имати један од два облика, зависно од тога да ли је
пријемник у исто време и пошиљаоц, или није. Једина разлика између форми извештаја
пошиљаоца (SR) и извештаја примаоца (PP), поред типа пакета, је та да извештај
пошиљаоца садржи секцију информација о пошиљаоцу од 20 бајта. Извештај пошиљаоца
се „издаје“ уколико он шаље било који током интервала од „издавања“ последња два
извештаја примаоца. Оба обрасца садрже нула или више извештаја о пријему блокова, по
један за сваки од извора синхронизације из којих је пријемник примио последње RTP
пакете података.

1.2. RTSP (Real Time Streaming Protocol)

RTSP је такође један од протокола за стримовање у реалном времену који се

користи за успостављање и контролу медија између клијентског уређаја и сервера са ког
се врши стриминг. Успостављен је 1997. године од стране Anup Rao of Netscape
Communications и Rob Lanphier of Progressive Networks. Ово је pull протокол, што значи да
се декодeр повезује са енкодером користећи RTSP протокол, а затим енкодер шаље
декодеру видео коришћењем RTP протокола. Више декодера се може повезати са једним
RTSP сервером и ово се назива multi-unicast, а RTSP подржава прави multicast. Поставља
се питање да ли је овај протокол базиран на UDP или TCP протоколу. Он заправо користи

6
TCP али пошто се никад не користи сам већ у комбинацији са RTP протоколом који је
базиран на UDP-у , често се долази до података да је он базиран на оба протокола. Овај
протокол ради скоро на свим декодерима.

Овај протокол има неколико пратећих карактеристика:

 Проширив је – могу се лако додати нове методе и параметри,

 Лак за превођење – може се преводити стандардним HTTP или MIME
преводиоцима,
 Сигурност – користи веб механизме за сигурност. Такође може искористити и
сигурносне сегменте транспортног или мрежног слоја,
 Независност од преносних протокола – може се базирати на различитим
протоколима за пренос само уколико они подржавају апликацијски ниво,
 Више серверна архитектура – сваки део медија може да се презентује са различитог
сервера,
 Способност контролисања уређаја за снимање – овај протокол може контролисати
уређаје за снимање и плејбек,
 Одвајање контроле тока и покретање конференције – контрола система је одвојена
од позивања медијског сервера за конференцију,
 Погодан за професионалне апликације – подржава промене на нивоу фрејмова што
даље омогућава дигиталне промене на медију...

Како RTSP протокол ради?

Када корисници апликације покушавају да стимују видео са удаљених извора,

клијентски уређаји шаљу RTSP захтеве серверу за доступност опција попут репродукци-је,
паузе и снимања. Затим сервер враћа листу захтева који могу бити реализовани преко
RTSP протокола. Једном када клијент пошаље захтев, он се преноси до стриминг сервера,
а сервер одговара описом медија. У следећем захтеву клијент шаље захтев за подешавања,
а сервер одговара информацијама о транспортном механизму. Када се подешавања
комплетиирају, клијент иницијализује стриминг процес тако што шаље захтев за битстрим
– бинарну секвенцу – користећи транспортни механизам из претходног захтева.

7
 Овај пртокол настао је из потребе да се корисницима омогући репродукција аудио
и видео садржаја без потребе да исти сачувају физички на својим машинама. RTSP
протокол је нашао широку прмену у раду онлајн радија, видео позива преко Интернета,
онлајн едукацијa... Он користи исте концепте као HTTP протокол, што га и чини лако
упаривим са постојећом HTTP мрежом.

RTSP има бројне кључне компоненте, укључујући:

 Опциони захтев – шаље се серверу да одреди тип података које он подржава,

 Захтев за описом – садржи URL и описује поновно репродуковање података,
 Сетап захтев – описује како ће се преносити битстрим,
 Teardown захтев – овим захтевом се завршава стриминг сесија,
 Редирекциони захтев – обавештава клијента да се конекује на други медиа сервер,
 Репродукциони захтев – овим захтевом се започиње репродукција медија,
 Захтев за паузу – привремено стопира (замрзава) стримиг док корисник поново не
пошаље репродукциони захтев,
 Захтев за снимање садржаја – омогућава клијенту да сними стримовани саджај на
својој физичкој машини и
 Захтев за подешавања – омогућава тестирање са клијентске и серверске стране у
смислу да ли је супротна активна.

1.3. RTMP (Real Time Messaging Protocol)

Протокол за размену порука у реалном времену или RTMP углавном служи за бзи
аудио, видео пренос података између Flash player-a и сервера. Првобитно развијем од
стране Макромедија сада је у власништву ADOBE-а, а сертификације о њему су
делимично пуштене у јавну употребу. Према тим спецификацијама RTMP протокол има
више варијација, тј. „Обични RTMP“ протокол и RTMPЅ који је RTMP преко TLS/SSL везе,
RTMPЕ који је RTMP шифрован помоћу ADOBE-овог сопственог сигурносног механизма,
и RTMPТ који је енкапсулиран унутар HTTP захтева за прелазак кроз firewall-a.

8
 RTMP се употребљава да би се избегла кашњења у комуникацији, углавном, глатко
испоручује аудио или видео токове, и њиховим дељењем у фрагменте, чини их
преплетеним и мултиплексираним у једној вези. Такође, штеди пропусни опсег.

Само преплитање и мултиплексирање се врши на нивоу пакета, при чему се RTMP

пакети преплићу на више различитих канала на тај начин што се осигурава да сваки канал
испуњава своје пропусне ширине, латенције и остале захтеве за квалитетом услуге. RTMP
дефинише неколико виртуелних канала на којима се пакети могу слати и примати и који
функционишу независно један од другог. Током редовне RTMP сесије, неколико канала
може бити активно истовремено у било ком тренутку. Као резултат тога, RTMP
инкапсулира MP3 или AAC аудио и FLV1 видео мултимеди-јске токове и може упућивати
на даљинске позиве са процедурама или RPC-ове.

Овај протокол се такодје сматра оригиналним за стриминг Flash-ом који је равила

Макромедија, затим ADOBE за стриминг аудио, видео и података између  Flash media
Server-а и Flash player-а. Успоставља се двосмерна комникација између Flash media
Server-а и Flash player-а која омогућава комуникацију у реалном времену напред и назад.
Пример података који се могу пренети је:

 унапред снимљени подаци,

 видео подаци уживо,
 аудио подаци уживо,
 текстуални подаци у реалном времену (ћаскање),
 координате X и Y, на пример код игара са више играча,
 и остало...

Пакети протокола садрже заглавље и тело које се у случају наредби заповезивање и

управљање кодирају коришћењем акционог формата поруке (AMF).

9
 Слика 2: Структура заглавља RTMP пакета

Слика 3: Структура заглавља RTMP пакета – извор слике

Основно заглавље је једини константан део пакета, састављен од једног бајта, а

остали део пакеа је стрим ID. Основно заглавље може бити продужено са још 2 или 3
додатна бајта. У наставку ће бити описана неопходна поља која садржи свако заглавље
RTMP пакета:

 Временска ознака поруке (Timestamp) – ово поље може преносити 4 бајта података.
 Дужина поруке – ово поље може бити дужине 3 бајта.
 ID типа – ово поље резервисано је за контролу порука протокола. Овим порукама
које садрже информације се оврађују и протокол RTMP Chunk Stream и протокол
вишег нивоа. Сви други типови су доступни за употребу од стране протокола
вишег нивоа и третирају се као непрозирне вредности од стране RTMP Chunk
Stream-а.
 ID стрима поруке – ово може бити произвољна вредност. Различити стримови
порука мултиплексирани у исти део заглаља, демултиплексирају се на основу
њихових ID-ева.

10
 RTMP веза почиње тзв. „руковањем“. Руковање је мало другачије него код остатка
протокола. Састоји се од три дела статичке величине док је код осталих променљиве
величине са заглављима. Клијент (крајња тачка која је иницирала везу) и сервер - сваки од
њих пошаљу иста три дела. Ови делови ће бити означени са C0, C1 и C2 када их сервер
пошаље.

Руковање почње када клијент пошаље C0 и C1 део.

Клијент мора да сачека док Ѕ1 стигне пре слања C2. Он такође мора да сачека
сигнал Ѕ2 пре слања било којих других података.

Сервер мора да сачека сигнал C0 пре него пошаље Ѕ0 и Ѕ1, а такође може да сачека
и C1 сигнал. Он такође мора да сачека док не стигне сигнал C1 пре слања Ѕ2, као и да
сачека сигнал C2 пре слања било којих других података.

Слика 4: Дијаграм „руковања“

На слици је графички приказ „руковања“ код RTMP протокола. Након „руковања“

конекција мултиплексира један или више делова Сваки део носи поруку о једном делу

11
једног стрима поруке. Такође сваки од њих има уникатну ознаку (ID) припојену за
заглавље. Током преноса сваки део мора да буде омлтно послат пре слања следећег дела.
Када сви делови пристигну они се преводе у поруку на основу ознака које носе у својим
заглављима. Дељење омогућава да велике поруке са високог нивоа буду подељене на мале
поруке, на пример због превенције у смислу да велике ниско приоритетне поруке (као што
је видео) блокирају мале високо приоритетне поруке (као што су аудио и контрола).
Величина делова је променљива.

1.4. HLS – HTTP Live Streaming

HTTP (такође познат и као HLS) је базиран на HTTP-у, са адаптивном брзином

преноса, стиминг комуникациони протокол креиран од стране Apple компаније 2009.
године. Подршка овог протокола је распростањена на медија плејере, веб претраживаче,
игрице, мобилне телефоне, таблете и стриминг медија сервер. Вишегодишње истраживање
видео индустрије је открило да је овај протокол постао најпопуларнији формат стриминга.

Apple је креирао овај протокол како би дозволио проајдерима да шаљу садржај у

реалном времену или садржај раније снимљен на серверу ка корисницима са Apple
производима користећи обични веб сервер.

Слика 5: Архитектура система HLS протокола

12
 Када је садржај енкодован, сегментира се кроз стрим сегментер. Стрим сегментер
дели медијске податке што је условљено фиксираним временским интервалима, генерише
сегменти документ и документ о редоследу сегмената мета података на основу чега ће
сегментирани документ бити реконструисан на клијентској страни. Стриминг уживо
захтева похрану података у реалном времену али сегментирање података није обавезно.
Уместо тога сегментирани подаци за стрим се могу произвести на основу унапред
одређеног трајања медија сегмената који се затим чувају.

Слика 6: Мастер play листа са више енкодованих фајлова

HTTP је протокол који не дефинише стање конекције (енг. stateless). То у пракси

значи да сервер не чува информације о клијенту након обраде клијентског захтева, тј. да
се за сваки нови захтев (од стране истог клијента ка истом серверу, чак и истом ресурсу)
остварује потпуно нова веза. Проблем је делимично решен увођењем тзв. „колачића“ (енг.
cookie) а постоје и алтернативни начини решавања код динамичких страница. Други
главни проблем код HTTP протокола је не поседавање никаквих система заштите података
који се њиме преносе. Овај проблем је решен увођењем HTTPS протокола (Secured HTTP).

13
 Клијент Сервер

Ово је захтев
(REQUEST)

Ово је одговор
(RESPONSE)

Слика 7: HTTP интеракција

HTTP се користи при раду са World Wide Web-ом (WWW). HTTP протокол је
имплементиран као протокол по принципу захтев/одговор. Клијент шаље захтев за
трансфером стране са WEB сервера на његов рачунар. WEB сервер на тај захтев одговара
слањем тражене странице.
Протокол ради у апликационом слоју. Клијент шаље захтев HTTP серверу (обично
на TCP порт 80). HTTP интерпретира захтев и шаље одговарајући одговор клијенту.
Комуникација је заправо не-конекционог типа без постојања стања. Након одговора HTTP
сервера на захтев клијента, конекција се прекида све до следећег захетева.

Неке од новијих опција овог протокола су:

 HTTP дозвољава да се опслужује више конекција у исто време.

 Pipelining. Опција која омогућује слање додатних захтева WEB серверу пре него што
одговор на иницијални захтев стигне назад. Овим се добија на великом повећању
перформанси.
 Директиве за кеширање. Имплементација ових директива омогућава алгоритмима за
кеширање и код клијената и серверу да буду замењени и опитимизовани.
 Заглавље хостова. HTTP опција дозвољава да се више имена хостова придружи
једној IP адреси. Овим се елеминише потреба за одвајањем IP адреса за сваки
виртуелни сервер. Host заглавље се користи за утврђивање ком виртуелном серверу
захтев треба да се упути.

14
  PUT и DELETE опције. Ове команде омогућавају администратору да пошаље или
уклони садржај са WEB сервера користећи стандардни WEB претраживач (browser).
 HTTP редирекције. Ова опција омогућује администратору да изврши редирекцију
корисника на алтернативну страну или WEB презентацију уколико је оригинална
страна недоступна или је уклоњена.

Пренос медијског садржаја путем HTTP-а технлогија има следеће предности:

 Садржај се преноси путем HTTP-а. Ово је помоћни интернет протокол. У овом

случају ово решење делује на било ком месту са доступним интернетом.
 HTTP не захтева неко компликовано прилагођавање портова упоређујући, на
пример, са прилагођавањем RTSP-a или RTMP-a.
 Подаци примљени преко HTTP-а лако се преносе преко firewall-a спољних
компанија
 HTTP подржава адаптивне брзине и за видео уживо и за видео на захтев (VOD). Због
тога сваки гледалав може у било ком тренутку добити најквалитетнији стрим за
своју интернет везу.
 HTTP подржава шифрирање медија и проверу аутентичности корисника
 Има свеприсутну подршку на различитим прегледачима, мобилним телефонима и
оперативним системима.
 Бесплатни Apache или NGINK могу се користити као веб серверу. HTTP не захтева
куповину ADOBE Flash Media Server-а или Wowza Server-а.
 HTTP је прилагодљива технологија стримина за комуникацију са iOS и Apple
уређајима.
 Омогућава поуздано, економично средство за споруку континуираног и другог
формата видеа путем интернета.

15
 Слика 8: Пример прилагођавања брзини протока

2. IPTV

IPTV (Internet Protocol Television) представља мултимедијални сервис који

подразумева пренос дигиталног сигнала (аудио, видео, подаци, текст, графика) преко
затвореног мрежног окружења помоћу IP (Internet Protocol) пакета. Има задовољавајући
висок ниво квалитета, поузданост и сигурности током преноса, а омогућује и увођење
нових персонализованијих сервиса. То је нова генерација телевизије која за пренос
користи постојећу телефонску линију и преко ње преноси дигитални TV сигнал у форми IP
пакета. Технички гледано, IPTV представља испоруку видео садржаја, коришћењем
интернет протокола преко широкопојасних мрежа до крајњег корисника (претплатника).

16
 Овај вид емитовања се први пут појавио 1994. године, а 1995. је употребљен
термин IPTV. Користећи постојећу телефонску линију, до корисника долази дигитални TV
сигнал високог квалитета, имун на атмосферске сметње и спреман на двосмерну
комуникацију пуну интерактивних мултимедијалних садржаја. Тако је развијен и ADSL
(Asymmetric Digital Subscriber Line), који је искоришћен као IP структура ѕа пренос IPTV-а.
Тако добијамо могућност преноса дигиталног TV сигнала до великог броја домаћинстава
преко телефонске парице, што раније није било могуће. Осим ADSL-а, IPTV се касније због
својих предности (двосмерна комуникација) почео користити и на другим местима, свуда
тамо где је развијена IP структура, независно да ли је у питању ADSL, кабловски интернет,
бежични, 3G, 4G, и др.

Пре него што се видео сигнал пропусти кроз систем, потребно је извршити његову
компресију. Најчешће примењиван поступак за компресију у ове сврхе је H.264. Затим се
врши прикупљање великог броја TV канала, и њихово прослеђивање до система сервера,
одакле преко DSLAM-a (Digital Subscriber Line Access Multiplexer), долази до
домаћинстава. Да би примили овакав сигнал у домаћинству се поред модема мора
инсталирати и тзв. STB (Set-Top-Box) уређаји, односно дигитални пријемник који декодује
видео сигнал и репродукује га.

Разлика између IPTV и кабловске телевизије у томе је што су код кабловске

телевизије сви канали присутни на STB уређају, без обзира да ли се приказују или не, а код
IPTV-а присутан је само онај канал који се приказује. Због тога постоји разлика у брзини
промене канала. Време потребно за промену канала код кабловске телевизије готово је
тренутно, а код IPTV-а може да износи и до неколико секунди. Код кабловске телевизије
инфраструктура је наменски пројектована тако да може да задовољи највише захтеве када
је у питању било који сервис, а IPTV то не може. Код IPTV-а може да наступи кашњење
пакета (delay jitter), што се манифестује треперењем слике на екрану TV пријемника.

Архитектура IPTV мреже се може представити као на cлици 9:

17
 Слика 9: Општа атхитектура IPTV мреже
Типична мрежна архитектура IPTV структура може се поделити на четири целине:
• Headend,
• Middleware,
• Транспортна мрежа,
• Кућна мрежа корисника.

2.1. Headend

Headend платформа (слика 10) је кључни елемент сваког IPTV система и

представља улазну тачку за садржај у мрежи сваког провајдера IPTV сервиса. Састоји се
од различитих уређаја који су дизајнирани да приме видео и аудио садржај, уколико је
потребно промене му формат и припреме га за пренос преко IP мреже. Конфигурација
опреме за обраду аудио и видео садржаја зависи од тога у ком формату је могуће добити
улазни сигнал. Аудио и видео садржај може да се обрађује у реалном времену (live TV
multicasting) или се садржај чува на локалним серверима у одговарајућем формату (VOD -
Video-on-Demand, PVR - Personal Video Recording). У Headend-у сакупљају се сви сигнали
с различитих извора, преслажу се и шаљу преко мреже до крајњег корисника. Функција
Headenda може се уопштено поделити на три дела.

Први део Headendа је антенски пријемни део, који укључује сателитске антене,
терестријалне антене, кабловске разводе који дистрибуирају сигнале до мрежног
чворишта.

18
 Други део Headendа је пријемно - декодерски и он представља скуп интегрисаних
пријемних декодера. Њихов задатак је да сигнале који дођу са сателита, са земаљских
антена, оптичким или жичним путем, „распакују“, декодују, ако је потребно промене
формат и стављају на располагање следећем делу мрежног чворишта.

Трећи део Headendа је енкодерски део. Он на излазу даје дигитални садржај у

форми пакета, који може да буде у различитим резолуцијама (SD или HD). За сваки
садржај (TV програм) додељује се посебна IP адреса (по једна за сваки канал).

Број Headend чворишта зависи и од тога да ли се дистрибуција садржаја организује

на државном, регионалном или локалном нивоу. Код мањих мрежа с мањим бројем
корисника, функције више Headend чворишта сконцентрисане су у једно Headend
чвориште.

Слика 10: Headend платформа

Headend платформа обавља следеће функције у IPTV систему:

 Пријем садржаја: Овај функционални блок састоји се од компонената за пријем

аудио и видео садржаја који долазе кроз оптичке линкове великих брзина или
сателитске системе.

19
 Припрема сигнала: Овај функционални блок састоји се од опреме дизајниране да
унапреде видео сигнал који долази од опреме за пријем. Овај функционални блок
обично обухвата декодере, опрему за смањење шума и опрему за дигиталну обраду
видео сигнала.
 Енкодовање: Енкодери припремају аудио и видео садржај у формат подесан за
пренос преко IP мреже и пријем на IP STB-у. Енкодовање у овом случају
подразумева или дигитализацију и енкодовање аналогног аудио и видео садржаја
или транскодовање дигиталног аудио и видео садржаја у одговарајући формат што
је најчешће MPEG-2 или MPEG-4 AVC. Капацитет потребан за енкодирани аудио и
видео садржај у MPEG-2/MPEG-4 формату је око 3.5/2.5 mbps.
 Rate Shaping: Подешавање променљивог протока различитих TC канала на
константан проток.
 Енкапсулација: Енкодери форматирају видео стрим у облик који је подесан за
пренос преко IP мреже. Енкапсулацијом видео садржај се дели на одговарајуће
пакете за транспорт. Пошиљалац енкапсулира мултимедијални садржај у RTP (Rea
Time Protocol) пакете а она те пакете енкапсулира у UDP (User Data Protocol)
сегменте и затим те сегменте укључује у IP пакете. Енкапсулација је приказана на
слици 11.
 Енкрипција: Криптује садржај како би се спречила неауторизована употреба
садржаја. Енкрипција садржаја подразумева како ливе броадцаст садржај тако и
садржај који се чува. Садржај остаје криптован током целог животног циклуса и
могуће га је декриптовати само на IP STB који су ауторизовани за то. Подржани су
различити алгоритми за енкрипцију и механизам је независтан од процеса и
формата енкодирања (MPEG-2/MPEG-4).

2.2. IPTV Middleware платформа

20
 Middleware софтвер опслужује цео IPTV систем. То је скуп софтверских
апликација који обједињују све компоненте IPTV система. Задужен је за опслуживање
корисника, одређује изглед интерфејса према крајњим корисницима, контролише приступ
корисника (аутентификација), обрађује захтеве пристигле од корисника, рецимо захтев за
промену канала или захтев за неки сервис, као што је видео на захтев и неки други.
Middleware је задужен да прима све захтеве од корисника и да управља деловима система
како би се ти захтеви адекватно реализовали. Он се брине о испоруци траженог IPTV
садржаја кориснику преко IP мреже и STB-a. Када неки корисник, преко даљинског
управљача и STB-a, изабере неки канал, middleware најпре, коришћењем уређаја за
заштиту телевизијског садржаја, утврђује да ли је датом кориснику дозвољено да га
прима, и ако јесте, генерише адекватна права приступа и криптографске кључеве за
енкрипцију садржаја.

У језгру middleware налазе се три основне врсте апликација:

 базе података, у којима се смештају подаци о расположивим садржајима, подаци о

ресурсима IPTV система и ниховом тренутном стању, подаци о корисницима и
њиховим техничким и комерцијалним карактеристикама и други подаци од
важности за исправан рад IPTV система;
 апликације којима се реализују услуге IPTV система, као што су наџор и
управљање његовим радним окружењем;
 комуникационе апликације, преко којих се остварује и одржава веза између IPTV
система и његових корисника.

Зависно од типа садржаја, Middleware одређује којом врстом протокола (unicast или
multicast) одређени садржај ће се преко транспортне мреже преносити до крајњег
корисника.

21
 2.3. Мрежна платформа за дистрибуцију IPTV сигнала

Пренос IPTV канала од хеаденд платформе до крајњег корисника може да се

реализује multicast и unicast технологијама. Multicast технологија подразумева да се
одређени садржај током преноса копира и шаље истовремено већем броју корисника, а
unicast технологија да се одређени садржај шаље дирекно до одређеног корисника (слика
11). IP адресе за ове технологије могу да се додељују на два начина: статички и
динамички. Статичке адресе се додељују тако што се сваком уређају ручно, од стране
оператера који га конфигурише, унесе IP адреса, којих може да буде једна или више.
Динамичке IP адресе додељује посебан уређај у мрежи уз употребу DHCP (Dinamic Host
Configuration Protocol) протокола.

Unicast пренос је достављање канала и података само једном кориснику у оквиру

мреже корисника. IP пакети се шаљу према једном одредишту (један сервер, један
корисник). Сваки корисник добија исту адресу за повезивање када жели да приступи
садржају, као сто је IPTV канал. Употреба unicast преноса није ефикасна у случају када
више корисника добија исте информације у исто време јер је тада потребан велики
пропусни опсег.

Mulicast пренос је процес слања канала или података истовремено корисницима на

више места (пријемника). После кодовања у headendu сваки канал се смешта у IP пакете и
шаље према већем броју одредишта (сервера, корисника). Сваки канал добија multicast
адресу, током транспорта она се копира и копије шаљу свим адресираним корисницима.
Сви корисници добијају исти сигнал у исто време, баш као и код традиционалног
телевизијског емитовања. У multicast-u један канал се истовремено доставља на адресе
више корисника. Употребом посебних протокола, мрежа је усмерена да прави копије
канала за сваког примаоца. Овај процес копирања се дешава у оквиру мреже. Копије се
праве у сваком чвору (рутеру) мреже ради даљег прослеђивања осталим чворовима мреже.
Multicast систем представља форму стабла доставе информација где чворови (рутери)
умножавају информације у облику грана.

22
 Слика 11. Unicast и multicast преноси

Употребом multicast преноса постиже се велика уштеда у потребном пропусном

опсегу у односу на уницаст пренос. Иако multicast технологија решава проблем испоруке
истог садржаја великом броју корисника у исто време, она не може да се користи код
одређених сервиса који изискује једнозначни видео стрим према једном кориснику, као
што су: видео на захтев VoD (Video on Demand), плаћање по гледању садржаја PPV (Pay
Per View), услуге преноса телевизијске слике високе резолуције HDTV и услугу
сопственог видео-рикордера PVR (Personal Video Recorder). За овакве услуге користи се
unicast технологија преноса.

2.4. Транспортне мреже

Транспортна мрежа преноси видео садржај у формату прилагођеном за пренос од

headend-а до приступне мреже. Транспортна мрежа има могућност да на ефикасан начин и
у одговарајућем квалитету пренесе следећа два типа садржаја: multicast и unicast. То је
мрежа са великом брзином преноса података у којима се користе следеће технологије:

 SONET/SDH (Synchronous Optical Networking / Synchronous Digital Hierarchy),

 IP/MPLS (Internet Protocol / Multi Protocol Label Switching),
 Metro Ethernet.

23
 2.5. Кућна мрежа за пренос IPTV сигнала

Кућна мрежа (слика 12), може да се реализује као локална етернет (ethernet) мрежа,
или бежично (стандард IEEE 802.11). Крајњи корисник се повезује на зидну телефонску
утичницу, а гледање IP програма могуће је на специјализованим телевизорима, без
употребе STB уређаја, као и на стандардним телевизорима помоћу STB уређаја, а могуће је
и на рачунарима, за шта је потребна инсталација неког једноставнијег софтвера, као што је
Real Player или Windows Media Player. У основи, оперативни систем је нека варијанта
Linuxa која подржава Java апликације.

Слика 12: Кућна мрежа

Пошто је IP оријентисана терминална опрема, своју мрежну конфигурацију STB добија од

DHCP сервера. На себи STB садржи конфигурацију за иницијализацију апликација док
оперативну конфигурацију (апликациони слој) добија од Edge Server-а комуникацијом
преко HTTP (Hyper Text Transfer Protocol) или неког другог протокола. На страни
корисника може да се инсталира већи број STB уређаја уз употребу опреме за
мултипликацију портова (хаб, свич и др.), а све зависно од расположивог опсега у access-
у.

Интерфејси на STB уређајима могу да буду мрежни 10/100 eternet, skart, S-video,
композитни, HDMI, стерео и 5.1 дигитал SP/DIF, дигитални/оптички, USB 2.0 и слот за
паметне картице (Smart Card).

24
 2.6. Квалитет сервиса IPTV

Технички захтеви IPTV middleware платформе за квалитетну реализацију сервиса

пре свега се односе на пропусни опсег приступног (access) линка. Који пропусни опсег је
потребно обезбедити зависи од тога да ли се емитује садржај у SD (Standard Definition)
или HD (High Definition) формату. За емитовање SD садржаја односно за SDTV потребно је
4 mb/s по каналу, док је за HDTV тј. емитовање HD садржаја потребно до 10 mb/s по
каналу.

Грубо посматрано квалитет пренетог сигнала је дефинисан вредношћу delay, jitter и

packet loss параметара. Самом проблематиком квалитета IPTV сервиса баве се многе
организације, као и лабораторије у којима се развијају тест модели за мерење квалитета
сервиса. Quality of Experience за IPTV сервисе (QoE IPTV) се дефинише на различите
начине. То је субјективни доживљај апликације/сервиса, односно укупна прихватљивост
апликације од стране крајњих корисника. За оцену QоЕ IPTV одговорне су карактеристике
везане за видео слој (layer 7) комуникационог (референтног) модела. QоЕ IPTV као
субјективни концепт је практично немогуће мерити. Субјективни фактори IPTV сервиса се
разликује од корисника до корисника и зависе од претходних искустава корисника са
сличним апликацијама, посебних погодности (комфорност, интерактивност, заштита
приватности,...), цене, мотивације, тренутног емоционалног стања корисника, културе,
образовања и других фактора, који се свеобухватно могу описати прихватљивошћу
сервиса. Прихватљивост IPTV сервиса се најчешће посматра кроз брзину промене канала
(channel zapping time) и квалитет медиа (укупног квалитета видео, аудио и дата). За
успешност IPTV сервиса неопходно је да видео, аудио и подаци буду одговарајућег
квалитета. Није дозвољен прекид у испоруци програма, блокирање, замагљеност,
дисторзија ивица, ехо и друге врсте сметњи. Ипак, објективно се могу мерити само
параметари везани за перформансе мреже. Модел за дијагностику и адресирање проблема
објективно мерљивих параметара је основа за одређивање QоЕ IPTV, иако се не може
извршити корелација између свих измерених параметара са субјективном оценом

25
квалитета. За извођење корелације између појединих параметара измерених на мрежи и
QоЕ IPTV сервиса, квалитет се може организовати у неколико сегмената:

• квалитет садржаја (аудио и видео информације),

• квалитет видео стрима,

• квалитет транспорта (на транспортној и мрежи за приступ, као и кућној мрежи) и

• квалитет трансакције (интеракција између корисника и сервиса).

Квалитет садржаја обухвата аудио-визуелни квалитет, укључујући одсуство

замагљене слике, дисторзије ивица, пикселизације, подрхтавање слике, замрзнуте слике, и
др. Квалитет садржаја је полазна основа квалитета која се описује индикатором грешке и
V-MOS фактором (Video Mean Opinion Score - средња субјективна оцена квалитета
видео садржаја). Индикатор грешке служи да открије изворе садржаја који су са
смањеним квалитетом и не зависи од карактеристика дистрибутивне мреже. Уколико се на
излазу енкодера детектује грешка, постоји могућност њеног отклањања. V-MOS омогућује
процену QоЕ аудио-визуелног садржаја програма на основу објективно измерених
величина. Обједињује ометајуће параметре мреже са параметрима садржаја. Изражава се
вредностима на скали од 1 до 5 (1 - неприхватљив квалитет, 5 - неприметно оштећење).

Квалитет видео стрима се описује континуалном грешком и RTP (Real Time

Protocol) jitter-ом. Континуална грешка потиче од типа видео компресије (MPEG-2,
MPEG-4, VC-1/WM9). На квалитет видео стрима, под истим условима пропусног опсега,
приказ релативно статичног догађаја изгледа лепо, а код брзих промена садржаја
(покретни кадрови), често долази до настајања блокова у слици, који се манифестују
замагљеношћу. За то је одговоран начин кодирања.

Квалитет транспорта се односи на пренос пакета видео материјала, односно

програма кроз мрежу. Језгро мреже се карактерише високим протоком и мањом
вероватноћом настајања грешке. Оно по чему се IPTV системи међусобно највише
разликују, су управо технолошке разлике и могућности мрежа за приступ. Описује се
губитком пакета и jitter-ом. Ове величине директно зависе од перформанси мреже и

26
саобраћаја на њој. За транспортни стрим се везује индекс испоруке видео садржаја MDI
(Media Delivery Index). То је индустријски стандард за тестирање IPTV QоЕ, који узима у
обзир елементе мрежне инфраструктуре за пренос IP видеа. Дефинисан је у RFC 4445 и
усвојен је од стране IP Video Quality Alliance. MDI се састоји од две компоненте DF (Delay
Factor) и MLR (Media Loss Rate). За одређивање ових параметара значајни су губитак
пакета и jitter. MLR броји изгубљене пакете или пакете ван секвенце током одређеног
времена. MDI повезује неправилности на мрежи са видео квалитетом. Висок DF директно
указује на кашњење које може деградирати видео квалитет. Такође, упозорава на
могућност губитка пакета. Слично, MLR компонента јасно наглашава да губитак пакета
осиромашује квалитет видеа. Вредности MDI одређују квалитет мреже.

Трансакциони квалитет утиче на прихватљивост (доступност и брзину) сервиса код

корисника. Обухвата: брзину промене канала (Channel Zapping Time), брзину испоруке
видеа на захтев, функције оџива за команде плаy/паусе, расположивост програмског
материјала, одговор (одзив) електронског програмског водича EPG (Electronic Program
Guide) итд. Channel Zapping је величина која дефинише колико брзо корисник може
променити канал и примити видео стрим одабраног канала. Сматра се да је прихватљиво
укупно време од 1 секунде (оно је сада између 2 с и 4 с), али корисници траже да то буде
тренутно, реда 100 до 200 мс. За брзину промене канала су осим мрежне инфраструктуре
одговорни и multicast протоколи. IGMP (Internet Group Menagment Protocol) или MLD
(Multicast Listener Discovery) одјава/придруживање директно утичу на дужину Channel
Zapping времена. Да би укупно време промене канала било 1 с, циљ multicast
одјава/придруживање на свакој мрежној компоненти треба да буде између 10 мс и 200 мс.
Слика 13 приказује типично време кашњења при промени IPTV канала који се преносе
multicast-ом.

27
 Слика 13: Кашњење при промени TV канала.

Ако се претпостави да је време потребно за приказивање корисничког интерфејса

на екрану TV пријемника 0 с. У STB се налази програмска шема и STB стримује канале ка
TV пријемнику. Испод је дат опис процеса који се догађа при промени TV канала:

 т0 је тренутак у времену када корисник притиском на дугме даљинског управљача

иницира промену TV канала.
 т1 је временски интервал током ког клијент обавести мрежу и сервере да зауставе
слање аудио и видео стрима тј. током ког клијент пошаље IGMP поруку и који се
завршава када се заустави слање аудио и видео стрима према кориснику. Просечно
вредност интервала т1 је 150 мс.
 т2: Када је заустављен multicast стрим првог канала клијент се придружује multicast
групи другог TV канала тј. шаље IGMP захтев. Време потребно за овај корак је
релативно мало.
 т3 је време потребно да садржај траженог канала стигне до корисника. Како је
IP/MPLS мрежа способна да садржај изрутира до корисника великом брзином ово
време је занемарљиво мало.
 т4 је интервал који је клијентској апликацији у STB потребан да прихвати пакете
стрима са етернет порта и рашчлањава их како би утврдио неопходне системске
податке као што су информације о каналу и опис формату у ком стиже садржај.
Ове информације се користе током декодирања.
 т5 је интервал током ког клијентска апликација на STB добија кључеве за
декрипцију садржаја система са условним приступом CA (Coditional Access).
 т6 је релативно дуг и служи за попуњавање бафера садржајем. Како садржај долази
до STB преко IP мреже он не стиже континулано већ у налетима. Бафер спречава
деградацију квалитета слике. Величина бафера разликује се од система до система.
За овај систем величина бафера је дефинисана на 300 мс.
 т7 се односи на почетак декодирања, зависи од много фактора ипак најважнији је
време потребно да се појави први следећи MPEG Intra frame (I-frame). I-frame је
једини фрејм који садржи довољно информација на основу којих декодер може
креирати комплетну слику погодну за приказивање на TV пријемнику.

28
Размак између два суседна I-frame-a зависи од изабраног формата и подешавања на
енкодеру на ком је садржај припреман за пренос преко IP мреже. У зависности од тога
у ком тренутку је корисник иницирао промену канала време до следећег I-frame-a је од
0 мс до 500 мс. У просеку овај интервал трајаће 250 мс.

 т8 је време потребно да клијентска апликација декодира I-frame-a и оно је изузетно

мало. Највећи део овог времена користи се на припрему слике за TV пријемник.

29
 3. WEB TV

WEB TV (или on-line телевизија) је дигитална дистрибуција телевизијског садржаја

путем јавног Internet-а (који такође носи и друге врсте података), наспрам земаљској
телевизији, кабловској телевизији и сателитској телевизији система који само носе видео.
WEB TV представља платформу (оквир) са отвореним развојем, у којој учествује
велики број видео издавача малих и средњих величина. Такав сервис омогућује високо
иновативни садржај, који учесницима/корисницима пружа велику угодност и комфор,
услед могућности отварања различитих класичних канала који су или за малопродају или
широку потрошњу.
WEB TV је први успешан пример конвергенције дигиталне телевизије,
телекомуникација и рачунара. Еволуција обухвата дигиталну телевизију, мултимедијалне
ТК и РС (Personal Computer) рачунаре повезане на Internet. Технолошки изазови WEB TV
су инфраструктура и процеси стандардизације, промена структуре индустрија, глобални
утицај на моделе пословања и стратегију, као и регулатива.
WEB TV појављује се под различитим именима, као што су Internet TV, EnhancedTV,
у широком опсегу сложености система. Најједноставнији системи су појединачни
двосмерни канали у Internet стилу, који су повезани (али не и потпуно синхронизовани) са
стандардним TВ програмима. Internet канал служи за пренос додатних информација (као
што су, на пример, детаљи вести или спортског програма), које омогућавају активности у
току преноса и при интерактивном оглашавању. Наредни корак сложености система је
комбинација Internet канала за бирање видео програма на захтев корисника (VoD).
Најсложенији систем је потпуно асинхрона двосмерна телевизија, у којој корисници
примају и емитују појединачне TВ програме, а пружаоци услуга (издавачи) имају директан
дистрибуциони канал до корисника, тј. потрошача.
Најсложенији систем је потпуно асинхрона двосмерна телевизија, у којој
корисници примају и емитују појединачне TВ програме, а пружаоци услуга (издавачи)
имају директан дистрибуциони канал до корисника, тј. потрошача.

30
 Хибриднo eмитовање широкопојасне ТВ (HBBTV) конзорцијум индустријских
предузећа (као што су SES, Humax, Philips и ANT софтвер) тренутно промовишу и
успостављају отворен европски стандард (тзв. HBBTV) за хибридни STB за пријем
емитовања широкопојасне дигиталне телевизије и мултимедијалних апликација са једног
корисничког интерфејса. Текући оператери WEB TV користе различите технологије за
пружање услуга као што су Peer-to-peer (P2P) технологије, VoD система, и стриминг
уживо. DRM софтвер (Digital Rights Management) је такође укључена у многе услуге WEB
TV.

Квалитет протока одоноси се на квалитет слике и звука прелазећи из

дистрибуционих сервера на почетни екран корисника. Квалитетнији видео као што је
видео у високој резолуцији (720p) захтева већи пропусни опсег и велику брзину везе.

Осврнимо се, најпре, на чињенице које чине WEB телевизију различитом од IP

телевизије, пошто је тешко направити разлику између поменута два модела телевизије.

Због великог интересовања за испоруку ТВ услуга преко IP мрежа, услуге ТВ

дифузије постају дигитални и интерактивни, тако да технолошки захтеви постају све
сложенији. Напредне технике дигиталне обраде и компримовања видео/аудио сигнала, као
и дистрибуције, омогућавају пројектовање економичних система. Велики број оператера и
произвођача опреме ради на стандардизацији IPTV система (ATIS/IIF, ITU-T FG IPTV ),
како би услуге IPTV система постале широко прихваћене, доступне и поуздане.

Основне технологије пакетизованог дигиталног видео сигнала, тј. IPTV услуга, су

расположиве већ неколико година уназад, али нису биле комерцијално пуштене у рад због
постојања бројних проблема пројектовања и развоја самих IPTV услуга, као што су:
стандардизација појединих елемената архитектуре, заштита садржаја, као и аспекти услуга
(скалабилност, интероперабилност, перформансе и наплаћивање).

Видео Портал - Video Portal - YouTube видео портал омогућава корисницима

објављивање, прегледање и међусобну размену видео садржаја као што је приказано на
слици Портал користи Adobe Flash технологију за приказивање различитих видео

31
садржаја које су корисници направили (снимили или објавили), као што су филмски
инсерти, ТВ исечци и музички спотови, аматерски снимци, итд.

Слика 14: Пример емитовања/објављивања видео/аудио садржаја на WEB TV порталу

https://www.youtube.com/

Нерегистровани корисници могу да прегледају већину садржаја на порталу, док

регистровани могу да постављају неограничену количину видео/аудио садржаја. WEB
странице приказују сродне, повезане видео/аудио садржаје на основу наслова и ознака.

Емитовање уживо - YouTube Live један је од видео портала који омогућава

корисницима емитовање видео садржаја у реалном времену. Корисник ствара канал,
ауторизује WEB камеру и започиње јавно емитовање. Гледаоци прате видео садржај, а
постоји могућност да се у програм укључе видео/аудио путем или текстуално. Корисник
поставља профил и прати број гледалаца, број емитовања и временско трајање емитовања.
Емитовани видео материјал се не архивира, па не постоји могућност емитовања претходно
снимљеног видео материјала.

Телевизија на захтев (TV on demand) - Joost TV портал дистрибуира видео

садржај технологијом тачка-тачка Р2Р (Peer-To-Peer). Само мањи број корисника је
директно повезан са видео сервером, а они који су повезани прослеђују видео стримове
(Stream) до суседних корисника, који даље понављају исти поступак (Слика 7.2). P2P
Joltid технологија је економична и преноси трошкове дистрибуције са власника мреже на
кориснике. Joost се финансира на сличан начин као и ТВ дифузне компаније
(интерактивно оглашавање).

32
 Joost систем претвара РС рачунаре у ТВ пријемнике са садржајем на захтев (on-
demand), тако да додатни STB уређај (декодер) није потребан. Видео је приближно
стандардног TV квалитета (SDTV, Standard Video TV), и користи H.264/Core AVC кодек за
компресију сигнала.

Мени за избор ТВ програма је полупровидан, доступно је око 480 канала (податак из

2007.године), а постоје још многе могућности, као што су читање новости, форум,
процене гледаности, и тренутне поруке IM (Instant Messaging) сесије више гледалаца.

Сервер Сервер Сервер

Клијент
Клијент
Клијент
Клијент
Клијент

Клијент Клијент Клијент

Клијент
Клијент
Клијент

Клијент Клијент

Клијент
Клијент

Слика 15: Дијаграм P2P дистрибуције TV програма

3.1. Елементи Web TV-a

WEB до TV-а обезбеђује начин да прикаже WEB TV-у или друге садржаје са
Internet-а на телевизору. Разне технологије укључују PC (персоналне рачунаре), дигиталне
медија пријемнике и „паметне“ телевизоре (Smart TV).
RSS (Rich Site Summary) користи скуп стандардних формата извора WEB-а да објави
често ажуриране информације: блог уносе, вести, аудио, видео. RSS документ укључује
потпуни или сажети текст, као и издавачке датуме и имена аутора. Извор RSS омогућава
издавачима аутоматку дистрибуцију података. Стандардни формат XML обезбеђује
компатибилност са различитим машинама/програмима. RSS такође има користи од

33
корисника који желе да добију благовремена ажурирања од омиљених сајтова или збирне
податке из многих сајтова. Претплате на сајту RSS отклањају употребу за корисника да
ручно проверава сајт за новим садржајем. Уместо тога, њихов претраживач стално прати
сајт и обавештава корисника о било каквим ажурирањима. Претраживач може бити под
командом да аутоматски преузима нове податке за корисника. Софтвер назван „RSS
читач“ или „агрегатор“ који може бити базиран на WEB-у или заснован на мобилном
уређају, може приказивати податке RSS корисницима. RSS кућишта су начин качења
мултимедијаних садржаја на извор RSS-a обезбеђујући URL датотеке повезане са уписом,
као што је Mp3 датотека у музичку препоруку или фотографија у дневнику. Подршка и
имплементација међу агрегаторима варира: ако софтвер разуме одређени формат, може
аутоматски преузети и приказати садржај или на други начин обезбеђује везу за њега или
га тихо игнорише.
WTVML (Worldwide TV Mark-up Language) je базиран на XML-у и добијен од стране
WML-а који садржи формат дизајниран да омогући оператерима WEB сајта да лако развију
и примене интерактивне ТВ услуге, обично то смањује време потребно за оператера WEB
сајта да створи ТВ сајт, а резултати у сајту могу се распоредити на већем броју уређаја.
WTVML услуге могу бити аутоматски и динамички траснформисане у различите облике
HTML/JS/CSS што их чини компатибилним са традиционалним WEB претраживачима и
омогућавајући мрежног оператера да управља посебним функцијама платформама
независно од стандарда које користе аутори WEB сајтова. Неки новији set-box уређаји
(посебно IPTV уређаји) користе различите верзије HTML претраживача.
Dirac (видео компресија формата) је отворен и бесплатан формат видео компресије,
развијен од стране BBC истраживања. Schrodinger и Dirac истраживања су отворени и
бесплатни софтвери имплементације. Dirac-ов формат има за циљ да обезбеди квалитетну
видео компресију за Ultra HDTV и као такав такмичи се са постојећим форматима као што
су H.264 и VC-1. Dirac подржава резолуције HDTV-а (1920x1080) као и веће, и обезбеђује
значајне уштеде у брзини преноса података и побољшања у квалитету преко видео
формата за компресију као што су MPEG-2 Part2, MPEG-4 Part 2. Dirac подржава
константну брзину битова као и рад са променљивим бројем битова. Dirac подржава
моделе компресија са губицима и без губитака.

34
 SMIL (Synchronized Multimedia Integration Language) је конзорцијум World Wide
Web-a препоручен од стране ЕML (Extensible Markup Language), програмски језик за
описивање мултимедијалне презентације. Он дефинише ознаке за време, распоред,
анимације, визуелне транзиције и медија уграђивања. SMIL омогућава представљање
медијских објеката као што су текст, слике, видео, аудио, линкове за друге SMIL
презентације, као и датотеке са више WEB сервера. SMIL означавање је написано у XML-у,
али има сличности са HTML-ом.

4. OTT (Over-the-top)

ОТТ је термин који се користи за испоруку видеа до корисника посредством мреже

на коју провајдер нема никаквог утицаја, већ само емитује садржај преко ње (Over-Тhe-
Тop). Видео се стримује преко јавног Интернета, нема загарантованог квалитета, али се
користе протоколи за адаптивни HTTP стриминг који прилагођавају брзину стрима
условима на мрежи. Саобраћај је IP unicast, па сваки корисник мора да има сопствени
стрим, али су протоци нешто мањи него код IPTV, а видео садржају су доступни на свим
уређајима са фиксним или мобилним broadband приступом као што су рачунари, таблети,
мобилни телефони, итд.

ОТТ провајдер може се дефинисати као провајдер ICT (Information Communication

Tehnology) услуга, који нити управља мрежом нити закупљује мрежни капацитет
телекомуникацијског провајдера. Уместо тога, ОТТ провајдери се ослањају на Интернет и
приступне брзине мреже )које се крећу од 256 kbp/s за слање порука, до распона у Мbp/s
(од 0.5 до 3) за видео стриминг) како би дошли до крајњих корисника, заобилазећи мрежу
провајдера телекомуникационих услуга.

ОТТ провајдери могу приступити купцима или крајњим корисницима на два начина.
Као што је приказано на слици , ОТТ услуге користе већ успостављену фиксну или
мобилну мрежу на коју су спојени корисници. У овом случају, телекомуникациони
провајдер Интернет услуга (ISP – Internet Service Provider) обезбеђује конекцију и
пропусни опсег.

35
 Слика 16: ОТТ преко TSPs (Telecommunications Service Providers)

Други начин је приказан на слици где ОТТ услуге користе пропусни опсег WiFi
оператора или кабловких оператора. Задња тачка конекције у овом сучају је WiFi hot spot
или конекција кабловског оператера са крајњим корисником. Појава паметних телефона са
мултимедијалним и напредним комуникационим функцијама револуционирала је
тржиште ОТТ услуга. Већим процесорским снагама и лаганим прилагодљивим
интерфејсом уз подршку великих конекцијских брзина, омогућено је лакше иновирање и
прихватање ОТТ апликација.

36
 Слика 17: ОТТ преко WiFi и Cable TV (Other Service Providers)

Веза између пробијања тржишта за паметне телефоне и развоја ОТТ услуга

предтавља тачку преокрета у сложеном стратешком осносу између телекомуникационих
провајдера и ОТТ провајдера, због тога што одређују тржишне цене, награде и даје
подстрек новим инвестицијама како за телекомуникацијске провајдере тако и за ОТТ
играче.

Још један од разлога брзог развоја ОТТ услуга и њихове независности од

провајдера, била је компјутеризација банкарских система и пораст броја банкарских
трансакција. Раније, када корисник купи апликацију или одређени садржај, провајдер
садржаја је морао чекати телекомуникационог провајдера да наплати услуге па тек онда да
са њим подели прикупљени приход. Међутим са интернет банкарством то је потпуно
другачије, провајдер садржаја може независно наплаћивати и директно добијати новац од
корисника.

На основу услуга које нуде, разликујемо три типа ОТТ апликација:

 слање порука и говорне услуге (комуникационе услуге)

 апликацијски екосистеми, повезани са друштвеним мрежама и e-commerce и

 видео/аудио садржај

37
 Минимална Изазови за Импикације за
брзина за мрежне мрежне оператере
ОТТ Примери добар оператере
квалитет
услуге
Слање порука и VoIP, Skype, Chat са Замена за фиксну Конкуренција,
говорне услуге и без видеа, Gmail, телефонију, замена губитак традицио-
(комуникационе WhatsApp, <1 Mbs за смс налних услуга
услуге) Wechat,Line, Viber

Facebook, Linkedin, Још један начин

Twiter, Instagram, комуникације (у
Wechat, разне e- слuчају e-
Апликациони commerce апликациј commerce Конкуренција,
екосистеми као што су онлине апликација,још губитак прихода од
плаћање, онлине <1 MBs једно тржиште. традициона-лних
новчаник (Amazon, услуга
Filipkart, Snaodeal,
Alibaba)

OТТ-Тв, ОТТ видео, Није директна

Стриминг и видео на конкуренција/пад
Аудио/видео ѕахтев, Нетфликс, замена класичној гледаности (мање
садржаји Netmovies, Hulu, телевизији оглашаваља) за
4-10 MBs
Cuevana TV, традиционалне ТВ
YouTube сервисе

Табела 1: Приказ типова апликација ОТТ услуга

OTT ће у будућости представљати модел услуга за комуникацију и медије, као и за

читав низ других апликација, попут е-трговине, м-плаћање, е-здравство, е-образовање,
паметне мреже као и дигиталну економију у целини.

Иако је успон ОТТ услуга створио озбиљну забринутост код традиционалних

телекомуникационих оператера, створено је и окружење за иновацију и развој
алтернативних услуга. Они најекстремнији сматрају да се оператери требају искључиво
фокусирати на улогу „носиоца бита“ (услуге преноса података), а не да остану
интегрисане компаније које нуде и инфраструтуру и услуге као IPTV.

Доступност брзог интернета отворила је бројне могућности за ове апликације. ОТТ

ТВ/видео дистрибуцију видео и телевизијских садржаја преко Интернета, на бројне
уређаје (мобилни телефони, рачунари, таблети...) које користи корисник.

38
 Овај видео садржај омогућен је бесплатно путем интернета (нпр. YouTube видео
садржај као и друге странице које нуде видео стриминг).

Када су у питању говорне услуге (аудио стриминг) ситуација је другачија јер се

неуправљане говорне услуге као што су Skype, WeChat или Gmail video chat могу
користити при нижим приступним брзинама.

Веб странице као што је YouTube постају све популарније. Процењује се да око 150
кориснички креираног садржаја сваке минуте буде учитано на YouTubе-у. Слично томе
Нетфликс, Spotify, па чак и видео записи који се преносе преко Facebook-a и Instagrama
(IGTV, IG Live) све више оптерећују мрежу.

4.1. ОTТ - IPTV

Главна предност OTT услуге у односу на IPTV је та што су ове услуге доступне на
било којем уређају који има могућност повезивања на широкопојасни Интернет,
независно од типа мреже, користећи HTTP протокол. Овај пренос се обавља преко
слободног Интернета (Open Internet) користећи интелигентну технологију на крајњим
тачкама да би се добио најбољи могући квалитет применом IР best effort pristupa.

Комбинација и интеграција OTT и IPTV ће створити нову понуду услуга, која ће

омогућити IPTV оператерима да прошире постојећи сет са новим услугама за ширу и
разноврснију публику. Такође се отвара и простор за могуће повећање прихода од
оглашавања и профилирања куаца. Комбинацијом обе архитектуре, телевизијски емитери
ће бити у могућности пружити мношво нових услуга, брзо проширити постојећу
географску распростањеност, без значајних капиталних улагања. Кључ спајања две
технологије је да крајњи корисници виде услугу само са једним знаком. ОТТ интегрисана
са хибридним корисничким set – top – box-oм ће се омогућити даваоцима садржаја да
комбинују постојеће линеарне телевизијске услуге са новим услугама на захтев, као и да
промовишу садржај користећи јединствен електронски прогрмски водич (EPG – Electronic
Program Guide). Услугена захтев могу бити комбинација садржаја који се емитује и
сачуваног садржаја.

39
 Телевизија је углавном састављена од емитовања унапред снимљеног садржаја, са
врло мало садржаја који се емитује уживо. Постоји велики број телевизијских станица које
су ништа друго до емитери постојећег садржаја.

У контексту овог уједињења предложено је раздвајање архитектуре у 3 подслоја

који имају одговорност за различите аспекте корисничког искуства:

 како корисник замишља да се услуга пружа?

 како заправо садржај стигне до корисника?
 и на крају како је садржај приказан кориснику?

Ова три слоја су :

 Презентација услуге - овај слој је одговоран за начин пружања услуге коју

корисник представља.
 Достава – се односи на методе које се корсте за дистрибуцију садржаја од извора до
корисника.
 Playout – карактерише га кодирање садржаја унапред без обзира на доставу или
презентацију услуге.

40
 5. АПЛИКАЦИЈЕ ЗА STREAMING

Нове друштвене мреже се свакодневно појављују на тржишту, док са друге стране

као парадокс имамо гашење оних старих, мање популарних или мање развијених.
Различите су области у којима се развијају и правци којим плове. Како би опстале на
тржишту (што значи биле све више или у истој мери коришћене од стране корисника)
многе друштвене мреже улажу велике напоре у унапређењу својих услуга. Неке од данас
најпопуларнијих и најсвеобухватнијих су Facebook и Instagram. Ако погледамо натраг
кроз историју друштвених мрежа, сам развој друштвених мрежа напредовао је врло брзо, а
под утицајем напредовања мулимедијалних технологија. У почетку су биле оптимизоване
само за рачунаре да би се са појавом паметних телефона и лед екрана појавиле и оне
оптимизоване само за телефоне. Све ове апликације теже једном циљу а то је потпуно
задовољавање корисникових потреба. Као што је већ горе напоменуто, развојем
мултимедија појавиле су се и многе могућности у апликацијама друштвених мрежа за
обраду и стриминг мултимедијалног сигнала. Тако се 2015. године на тржишту први пут
појављује LIVE стриминг видеа на Facebook-у, a недуго затим ову опцију уводи и
Instagram.

5.1. Facebook

Facebook најраспростањенија друствена мрежа у свету. Тренутно коришћена од

стране 2500 милиона корисника месечно према статистици од новембра текуће године.
Корисници свакодневно постављају фоторафије, видее или repost-ују већ постављене
фотографије. Наравно, што је више доступних могућности то је и „глад“ за новим
могућностима већа. Зато се Facebook и одлучио на корак увођења live видео стриминга.
Према тадашњим проценама корисници су више времена проводили гледајући видео
преносе уживо него користећи друге опције апликација.

41
 Тестирање Facebook live-а почело је са малом групом корисника у Сједињеним
Америчким Државама на паметним телефонима марке Apple тзв. Iphone телефонима. Ова
могућност је првобитно било намењена славним личностима, како би могли да се обраћају
својим обожаваоцима преко live видеа. Због тога су у имплементацију кренули од
чињенице да преко милион људи у једном тренутку може да гледа тај видео што је за
највећи изазов девелопера на изради овог дела апликације наметнуло решавање протока
сигнала од емитера до много корисника. Како би то омоућили смањили су време кашњења
на неколико секунди омогућавањем репроукције RTMP-а.

Уместо да се клијенти директно повезују са сервером са којег се емитује live стрим,

постоји мрежа ручних кеш дистрибутера широм света. Видео узиво је подељен на HLS
сегменте од 3 секунде у имплементацији. Те сегменте узастопно захтева видео player који
приказује емитовање. Захтевом за сегменте управља један од HTTP прокција у крајњем
центру података који проверава да ли је сегмент већ у делу предмеморије. Aко је сегмент
у кешу враћа се директно одатле, ако није proxy издаје HTTP захтев изворној
предмеморији што је други слој кеша са истом архитектуром. Ако сегмент није у
предмеморији изворног кода онда га треба затражити на серверу који обрађује тај
одређени ток. Тада сервер враћа HTTP сегмент са одговором који је кеширан у сваком
слоју, тако да га следећи клијенти брже добијају.

Помоћу ове шеме више од 98% сегмената је већ на делу предмеморије, близу
корисника, а матични сервер прма само делић захтева. Решење је деловало добро али је на
једном делу дошло до „цурења“, 1,8 % захтева је прошло кроз део кеша и отишло
директно на сервер. Када је live видео у питању велики број корисника шаље захтев за
истим пакетом у исто време са потенцијалним не регистровањем захтева због
пренатрпаности, што би за последицу имало то да сервер прими ороман број
нерегистрованих захтева кеша. Да би се то спречило крајњи кеш враћа грешку за први
пристигли захтев, а у редовима чекања има следеће захтеве. Једном када HTTP одгвор
дође до сервера сегмент се чува у делу кеша, а на захтев из реда одговара кеш са већ
спремним пакетима. На овај начин се ефикасно управља са великим бројем захтева
смањујући оптерећење сервера. Кеш сервера за узврат покреће исти механизам за обраду

42
захтева из више крајева предмеморије - исти објекат се може затражити из више
различитих кеш меморија.

Слика 18: Распоређивање захтева код facebook live стрима на почетку

Касније, да би се смањила латенција у преносу података код корсника који нису

јавне личности долази до употребе RTMP-а. У RTMP-у емитовање је раздељено у два тока:
видео стрим и аудио стрим. Стрим је подељен у сегменте од 4Kb које се могу
мултиплексирати у TCP конекцију тј видео и аудио делови су преплетени. При брзини
видео бита од 50Kb/s сваки комад дугачак је само 64ms што у поређењу са HLS
сегментима од 3 секунде производи глаткији проток кроз све компоненте. Емитер може
послати податке чим је кодирао 64ms видео податка, сервер за кодирање може обрадити
тај део и произвести више излазних битова. Пакет се затим прослеђује подсредством кроз
proxy све до player-a. Већина live видеа користи HLS јер је заснована на HTTP-у и лако се
интегрише са свим постојећим CDNS. Како би пружили корисницима најбољи live
стриминг девелопери из фејсбука су се одлучили на примену модификованог RTMP-а тзв.
nginx-rtmp модул и развој RTMP проксија.

43
Слика 19: Распоређивање пакета у HLS/HTTP-у, прва верзија решавања нагомилавања захтева

Слика 20: Распоређивање пакета у RTMP-у коначна верзија решавања нагомилавања захтева са
коришћењем nginxs-rtmp модула

44
 5.2. Instagram

Кључ успеха Instagram live-а су функције и перформансе. Често се додају нови

филтери за лица како би се људи више забавили, видео снимци уживо се могу објавити у
online часописима Stories тако да их они који су пропустили пренос уживо могу да их
гледају у року од 24 сата, а LiveWith додаје сасвим нови ниво интерактивности.

За перформансе је изазов омогућити висок квалитет, ниску латенцију, глатку

репродукцију у огромним размерама. Ови циљеви су у сукобу једни са другима. Испод је
поједностављени концептуални дијаграм live инфраструктуре (слика 21):

Слика 21: Поједностављен концептуални дијаграм live инфраструктуре

Емитер уживо преноси видео уживо путем RTMP-а на Facebook Live Server (FBLS),
који затим користи слојеве кеша и PoP-а за скалирање и перформансе. Овде је дата
предност глаткој репродукцији (мереној стопи застоја) преко латенције, динамички
прилагођена квалитету видео записа. Међуспремник за пренос на страни емитера,
транскодирање на FBLS-у, слојеви предмеморије и међуспремник репродукције на страни
прегледача додају секунде кашњења, тако да целокупна латенција може постати прилично
велика. Испод су истакнути:

45
 Одмах након покретања Instagram Live-a примећено и сугерисано од стране
корисника је да су неки стримови уживо имали врло низак квалитет видео записа, посебно
на iOS-у за који је првобитно и била намењена апликација Instagram. Упркос недостатку
добре евиденције и аналитике, девелопери су добили јасну слику о проблему: и
емпиријски и збирни подаци показали су да не може само претпоставити лоша мрежа.
Брзо је откривен проблем и исправљена грешка због које је процена пропусне ширине
пала и никада се није опоравила под одређеним условима. Та исправка удвостручила је
проценат висококвалитетних видео записа уживо и преполовила проценат видео снимака
уживо са ниским квалитетом на iOS-у.

Главни напори су као и код Facebook Live-а били оптимизација распореда пакета и
смањење оптерећења сервера. LiveWith има много строжије захтеве од кашњења од Live-
а, па је на крају имплементиран хибридни модел RTMP тока за гледаоце.

Instagram live је био огроман успех по свим показатељима. Live је лансиран у

одабраним земљама крајем новембра 2016. Тада је live показао огроман ефекат новитета:
ангажман је пао континуирано и значајно након лансирања. LiveWith је показао мали
ефект новитета након покретања, прегледи live-а су се непрестано повећавали. Instagram
све више придобија наклоност корисника увођењем многих опција у току live стрима.
Поред LiveWith омогућени су коментари чиме live стрим поставља стандарде у
интерактивности у реалном времену. Поред тога, емитерима су омогућени многи филтери
које могу да користе у току преноса (директна обрада видеа у реалном времену). Ово
представља другу опцију по популарности у стримовима на Instagram-у.

5.3. WOWZA

Wowza Streaming Engine је софтвер за медијске сервере који омогућава струјање на

било који уређај, било где.

Wowza Media Systems смањује сложеност испоруке медија који се емитира уживо и
на захтјев. Wowza Streaming Engine је робустан, прилагодљив и скалабилан серверски
софтвер који омогућава купцима да граде, примене и управљају поузданим стримингом
висококвалитетног видео и аудио записа на било који уређај, било где.

46
 И последње, али не најмање битно, нове технологије попут WOWZ, WebRTC и SRT
дизајниране су са закашњењем. Слично CMAF-у са ниским латенцијама за DASH и Apple
Low Latency са ниским латенцијама, ови протоколи се и даље развијају.

WOWZ је власнички протокол који постиже муњевиту брзу испоруку видео записа,
резолуцију квалитета емитовања и интерактивност путем двосмерног протока података.
Wowza Streaming Cloud service услугу са Ultra Low Latency и софтвер Wowza Streaming
Engine за комуникацију између сервера и сервера. Такође је уграђен у Wowza player и
Wowza GoCoder SDK, омогућава бешавне радне токове од снимања до репродукције.

Пошто се WOWZ испоручује преко WebSocket протокола, он омогућава двосмерну

текућу конверзацију између корисника и емитера. Омогућујући серверу да шаље податке,
а да клијент не захтева да га прво затражи, WebSocketѕ одржавају везу отвореном тако што
се поруке прослеђују напред и назад.
 Аудио кодеци: AAC
 Видео кодеци: H.264
 Компатибилност са репродукцијом: ограничена (мора се користити са Wowza
производима као што су Wowza player или GoCoder)
 Предности: Скалабилан, стреловит и омогућава двосмерни проток података
 Недостаци: Мора се користити заједно са производима компаније Wowza
 Латенција: 3 секунде или мање

Wowza nDVR (мрежни дигитални видео снимач) омогућава функцијe као што су
пауза, репродукција и премотавање уназад у живом преносу. Мрежна функционалност
уклања захтев за снимање са хардвера крајњег корисника и поставља га на медијски
сервер. У поређењу са имплементацијама специфичним за клијента, Wowza nDVR значајно
смањује трошкове смањујући захтеве за мрежном меморијом и поједностављујући радни
ток испоруке.

47
Wowza Streaming Engine на Azure:

 Унапред изграђене Wowza VM слике које могу да се покрену у било ком Microsoft
Azure оперативном региону
 Више опција имплементације, укључујући BYOL (месечно, трајно) и Microsoft Paid
(по сату)
 Идеално за преношење догађаја уживо, концерте, црквене услуге, вебинаре и
састанке компанија
 Неограничена употреба Wowza Transcoder -а, nDVR-а и DRM-а
 Wowza Streaming Engine омогућава да се сигурно и поуздано прилагоде токови
протока за стреаминг током уживања у флексибилности и скалабилности Microsoft
Azure.
 Премиум подршка - планови подршке нуде различите нивое услуге тако да је
могуће добити помоћ која је потребна и када је потребна.
 GoCoder SDK може убрзати развој апликација за live стриминг користећи ручне
мобилне уређаје који су интегрисани у Wowza Streaming Engine.

Слика 22: Ток рада стриминга видеа Wowza апликације

Wowza Media Server подржава многе видео протоколе за стриминг. Омогућује

просљеђивање протока примљеног са VoIP уређаја на мноштво уређаја које подржава
Wowza Media Server користећи различите протоколе за стриминг као што су:
 Adobe Flash RTMP (RTMPE, RTMPT, RTMPTE, RTMPS)

48
  Adobe Flash HTTP Streaming (HDS),
 Apple HTTP Live Streaming (HLS),
 Microsoft Smooth Streaming,
 RTSP/RTP,
 MPEG2 Transport Protocol (MPEG-TS).

Интеграција између Wowza Media Server-a и Flashphoner RTMP SIP Gateway-а може
бити потребна када је потребно да се преузме аудио и видео ток са VoIP уређаја и
испоручи ток корисницима, користећи више протокола Wowza Media Server-a.
У овом случају, ако је потребнан и пренос аудио и видео тока са веб претраживача и
Аdobe Flash Player-а до Wowza користећи RTMP протокол и даље на VoIP уређај путем
RTP протокола, претходно претварајући овај ток у формат који подржава VoIP уређаји.

Ако већ постоји видео chat, видео конференција или нека друга апликација
заснована на Wowza Media Server-у, постоји могућност додавања функције одлазних аудио
и видео позива мобилним GSM и PSTN телефонима и SIP уређајима. Поред тога, уз
употребу Flashphoner RTMP SIP Gateway -а, Wowza апликација ће моћи примати долазне
позиве са SIP уређаја и PSTN телефона путем посредног VoIP gateway -а.
На основу Flashphoner RTMP SIP Gateway -а могуће је креирати SIP телефоне
претраживача и Click2Call апликације који ће се заснивати на RTMP, RTMPT, RTMPE,
RTMS протоколима имплементираним у Wowza Media Server-у.
На слици је приказано : Adobe Flash Player - Wowza Media Server + Flashphoner RTMP SIP
Gateway – VoIP.

49
 Слика 23: Adobe Flash Player - Wowza Media Server + Flashphoner RTMP SIP Gateway – VoIP

6. ЗАКЉУЧАК

У овом раду је показан значај примене мултимедијалних сервиса у

широкопојасном окружењу, као и предности које пружају ти сервиси. Анализа до сада
спроведених активности недвосмислено указује на даљу потребу развоја широкопојасних
мрежа, без којих ће трипле-плаy сервиси, а пре свега интернет протокол телевизија
(IPTV), бити тешко остварљиви.

Један од важних елемената овог развоја је повећање протока. Упоредо са

техничким питањима преноса, морају да се размотре и питања везана за развој приступних
мрежа. Треба истаћи, међутим, да развој мрежа сам за себе не значи много, односно да је
неопходна синергија између самих мрежа и понуђених мултимедијалних сервиса на њима.
То заједно указује и на неопходност либерализације тржишта у којем би се створила
клима за свеопшти напредак широкопојасних мрежа и сервиса. Услуге на интернету у
данашње време су нешто без чега готово нити један човек који се налази у радној околини
не може нормално функционисати. Оне су корисне свима. Услуге омогућавају брзо
претраживање и налажење потребних информација, обраду и пренос података од
текстуалних, графичких, сликовних, видео записа...

Неопходно су потребне у пословном свету јер придоносе на уштеди времена,

брзини и квалитету посла, и у данашњици не постоји подузеће које послује без интернета
тј. услуга које оно пружа. Највећа предност је то што су готово свима у свету доступне.

50
 ЛИТЕРАТУРА

1. Data Communications and Networking, fourth edition (Copyright © The McGraw-Hill

Companies, Inc.)
2. Wikipedia (www.wikipedia.com)
3. Интернет страница - http://www.google.com ; Основне услуге интернет мреже
4. A.Banerjee et al: „Wavelength-division-multiplexed passive optical network (WDM-
PON) technologies for broadband access: a review“, Journal of Optical Networking,
Vol.4, No.11, pp 737-758, November 2005.

51