Clock Synchronization in Satellite, Terrestrial and IP Set-top Box for Digital Television

Transcription

1 Clock Synchronzaton n Satellte, Terrestral and IP Set-top Box for Dgtal Televson THESIS Submtted n partal fulflment of the requrements for the degree of DOCTOR OF PHILOSOPHY by MONIKA JAIN Under the Supervson of Prof. P.C. Jan BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE PILANI (RAJASTHAN) INDIA 010

2 BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE PILANI (RAJASTHAN) CERTIFICATE Ths s to certfy that the thess enttled Clock Synchronzaton n Satellte, Terrestral and IP Set-top Box for Dgtal Televson submtted by Mrs. Monka Jan, ID. No. 006PHXF47 for award of Ph.D. Degree of the Insttute, embodes orgnal work done by her under my supervson. Date: 9 March 010 PROF.PREM CHAND JAIN HEAD & Professor- School of Electroncs. CDAC- Noda(U.P)

3 ACKNOWLEDGEMENTS Ths thess could have been completed by grace of GOD and wth the support, help and encouragement of many people that have been by my sde durng ths experence. I am mmensely thankful to Prof. L. K. Maheshwar, Vce-Chencellor, BITS, Plan for provdng me ths opportunty to pursue the off-campus PhD of the Insttute. I express my grattude to Prof. Rav Prakash, Dean, Research and Consultancy Dvson (RCD), BITS, Plan for hs constant offcal support, encouragement and makng the organzaton of my research work through the past few years easy. I thank Dr. Hemanth Jadav, Mr. Dnesh Kumar, Ms. Monca Sharma, Mr. Sharad Shrvastava, Mr. Gunjan Son, Mr. Amt Kumar and Ms. Sunta Bansal, nucleus members of RCD, BITS, Plan, wthout whose cooperaton and gudance t would not have been possble for me to pursue such goal orented research durng each of the past few semesters. I also express my grattude to the offce staff of RCD whose secretaral assstance helped me n submttng the varous evaluaton documents n tme and gve presubmsson semnar smoothly. I thank my Doctoral Advsory Commttee (DAC) members, Dr. Anu Gupta and Dr. S.K. sahoo, who spared ther valuable tme to go through my draft thess and were audence to my pre-submsson semnar n order to provde several valuable suggestons that mmensely helped n mprovng the qualty of my PhD thess report. I wsh to express my deep sense of grattude and sncere thanks to my thess supervsor, Dr. P.C. Jan, Professor & Head, School of Electroncs, CDAC, Noda, for havng hosted me n hs group, for hs able gudance, encouragement and suggestons n my thess. It has been a prvlege for me to work under hs gudance. I am mmensely ndebted to Dr. Jan for the enthusasm he transmtted, for hs competence, as well as for the rchness of hs gudelnes and hs nvaluable suggestons. The tme he spent throughout my research perod wth me n dscussng and revewng my work was extremely precous. I am hghly grateful to Dr. Jan for hs consent to become my supervsor. Grattude s also accorded to STMcroelectroncs Pvt. Ltd. Gr. Noda for provdng all the necessary support to complete the research work. I am ndebted to Mr. Vvek Sharma, Drector, STMcroelectroncs and Mr. Vvek Khaneja, Department Manager, HVD R&D IP Development, STMcroelectroncs, Gr. Noda, to enhance knowledge n Set-top box doman, for Jont Authorshp of IP wth ST and approvng the student sponsorshp for my Ph.D work.

4 I would be mmensely pleased to thank Mr. John Mark Benamount, Archtect n STMcroelectroncs, Brstol, U.K. and Mr. Vncent Capony, Archtect n STMcroelectroncs n Grenoble, France for beng the gudng force durng the work for helpng me to get famlarzed wth varous standards and drvers of the set-top box. Hs nvaluable suggestons and contnuous check on the progress of the project proved to be ndspensable. I would lke to express my sncere grattude towards Mr. Sharad Jan, Secton Manager, STMcroelectroncs, for hs nvaluable gudance, nteracton and untrng efforts throughout the research work. Ths has helped me from tme to tme at varous stages of the research work, and showng me the way out whenever I got stuck. I am extremely thankful to Dr. Ashok K. Chauhan, Founder Presdent Rtnand Balved Educaton Foundaton (RBEF), Maj. Gen. K. Ja Sngh, Vce-Chencellor, Amty Unversty, UttarPradesh, Noda for encouragng me for the Research work. I cannot forget the mmense help and support provded by Dr. Balvnder Shukla, Pro-VC, Amty Unversty and Drector-General-ASET, Noda for gvng me drectons whch ultmately proved to be very mportant and for nsprng me to complete the work. Her ndefatgable efforts were a bg motvaton to perform effcently. I am grateful to Prof. Dnesh Chandra, HOD - ECE at JSSATE, Mr. K.M Son, HOD at ASET, Noda for ther neffaceable contrbuton and regular help. I am also ndebted to my frends and relatves that have shared wth me ths experence from the begnnng: Mr. K.P. Sngh, Mr. Akshat Jan, Mr. Ankt Jan, Mr. Avdesh Kumar, Dr. Arun Sngh, Ms. Anjula, Ms. Dmpy, Ms Kshama Jan who have contrbuted n many ways to complete my research work. Specal thanks are due to lbrary staff at JSSATE and at AMITY Unversty for makng tmely avalablty of varous books, on-lne journals. The support extended by lbraran of IIT, New Delh for lterature survey s also gratefully acknowledged. My famly deserves a specal grattude for the patence and the attenton that I enjoyed: t was a precous assstance throughout ths perod. Fnally a very specal expresson of apprecaton s extended to my parents Mr. Vnod Kumar Jan and Mrs. Sheela Jan wthout ther encouragement, patence, and understandng ths endeavor would not have been possble. I would lke to record my specal affecton to my son and my daughter and very specal thanks to my husband Sharad Jan, and my sster Ms. Sona Jan whose constant persuason and moral support has been a source of nspraton to me. [Monka Jan]

5 TITLE OF THE THESIS: ABSTRACT: Clock Synchronzaton n Satellte, Terrestral and IP Set-top Box for Dgtal Televson Wth the ncreasng trend and demand of dgtal televson n today s dgtal world, set-top box (STB) s becomng more and more popular due to broadcast qualty pctures and lot more flexblty. STB follows the MPEG- dgtal-compresson standard, whch s the bass of both the Dgtal Vdeo Broadcast standard (DVB) and the Advanced Televson Systems Commttee (ATSC) standard. MPEG- allows the delvery of any nformaton that can be dgtzed, ncludng audo, vdeo and text. MPEG- stream can be easly dsplayed on Hgh Defnton televson sets (HDTV) n analog NTSC, PAL or SECAM formats wth help of set-top box. Thus MPEG streams n a real-tme software manner are ganng more and more mportance. Clock synchronzaton s always an mportant part of a MPEG system. It s even desrable to extract the tmng nformaton where the decoder obtans ts nput from a controllable dgtal medum such as a CD-ROM. However t s not always necessary n such applcatons. But clock synchronzaton becomes very crtcal n desgns where the compressed nput to the decoder arrves from an uncontrollable real-tme channel such as satellte transmsson, cable transmsson, terrestral transmsson, IP transmsson. The Clock- Synchronzaton has two concepts : Clock Recovery, and A/V sync (Audo-Vdeo Sync). Clock recovery s a method to recover the encoder clock n order to buld a local clock runnng at the same frequency (+/-offset). Ths module also provdes local STC (reference clock) for vdeo & audo drver use. Due to accurate clock recovery vdeo and audo streams are played at the same pace as they are processed at encoder sde. Both clocks (encoder & decoder) are synchronzed. Vdeo and audo bt buffers stay correctly flled hence no under- or overflow.

6 However, AV sync s a method to synchronze audo and vdeo mutually e.g. the sound heard by the vewer matches the pctures seen (e.g. character speakng, door bangng closed, etc.) Correct clock synchronzaton at Set-Top Box (STB) recever sde s mandatory for smooth operaton of MPEG decoder and correct user experence because loss of synchronzaton between the receved and the transmtted clocks can lead to degradaton n system performance lke color loss, jerky vdeo, audo dropouts etc. There are several factors, whch lead to degradaton n clock recovery process. Some of these are lke frequency drft between the transmtter and the recever clock, network nduced jtter, nner nterleavng and de-nterleavng blocks n the transmtter and recever sde, packetzaton jtter etc. Many tmes worse channel condtons (such as ¼ guard nterval, channel fadng, low carrer-tonose rato etc.), the tuner front-end takes much more tme to detect and demodulate the sgnal and ths can delay the arrval of Program Clock Reference (PCR) packets. The jtter n DVB Broadcastng s hgh and t vary domnantly dependng upon transmsson meda. It has been analyzed that jtter s less n satellte transmsson, hgh value n terrestral and very hgh n IP transmsson.. Our thess s addressng the soluton for problem of clock recovery and AV sync both. The core contrbuton s to present sutable clock recovery modules to be mplemented n dgtal set-top box for three dfferent transmsson medums such as DVB-S, DVB-T and DVB-IP. Three dfferent schemes for AV synchronzaton and some enhancements n exstng approaches has also been proposed. The frst contrbuton of ths thess s to acheve clock recovery for drect satellte broadcast or Drect-to-Home (DTH) televson to receve dgtal TV sgnal. In ths we proposed an economcal and very smple, real tme software approach to solve the clock synchronzaton problem. A basc movng wndow averagng flter approach has been v

7 descrbed. Our methodology s evaluated by both analyss and extensve smulaton experments n a satellte broadcastng envronment. Computer smulatons verfy the desgn approach llustrated. The second contrbuton of our research work s presentng a low cost, low complexty and effcent clock recovery module to solve the color loss problem n Dgtal Set-top Box used for terrestral televson. In Dgtal Vdeo Broadcastng for terrestral envronment (DVB-T) there s large jtter due to multpath reflectons and other stochastc losses. In dgtal s et-top box most of the CPU bandwdth s consumed n audo & vdeo data decodng so clock synchronzaton algorthms get very less CPU tme to execute. Exstng Set-Top Boxes experences very large jtter n terrestral envronment due to mult-path reflectons. Our man am s addressng the effects of jtter on MPEG- Transport streams for DVB-T. Movng wndow weghng FIR flter approach has been used n our module. Our enhanced FIR flter approach solves the color loss problem due to clock de-synchronzaton. It ams to be stable wth jttery Program Clock Reference (PCR) and acheves synchronzaton quckly. Its performance has been compared wth Lnear Regresson based algorthm and shows dstnct advantages. Ths methodology s evaluated by both analyss and extensve smulaton experments for satellte and terrestral broadcastng envronment. Smulatons results also verfy the desgn approach. Proposed module was also mplemented on a set-top box SOC (system-on-chp) and t demonstrated hgh performance. The thrd core contrbuton s to present a new technque for Clock Recovery n MPEG- Transport Streams n DVB-IP envronment. Wth the ncreasng penetraton of packet-swtchng network technologes that provde asynchronous network servces, and the smultaneous necessty of accommodatng synchronzaton-senstve data types (.e., voce, audo and vdeo), the problem of keepng end-systems mutually synchronzed s becomng crtcal and more complex than n tradtonal crcut-swtchng networks. Ths complexty s v

8 due to the fact that stochastc packet transmsson delay jtter may lead to sgnfcant varaton n packet arrval tme. Eventually ths makes clock synchronzaton much more dffcult. The amount of jtter n ths envronment s very hgh compared to DVB-S and DVB-T. Researchers n the smlar feld suggest use of lnear Regresson algorthm for Clock synchronzaton over packet swtched networks. However, the stablty of such a flter n Real Tme set-top box applcaton posed a problem. A newly devsed approach of Contnuous adaptve feedback loop used wth the Lnear Regresson Algorthm provdes accurate clock synchronzaton even when subjected to jtter of half a second. Ths robustness s needed for IP envronment because of the ncreasng network traffc. The algorthm was smulated and found to requre low computaton tme, hgh jtter attenuaton and fast response as needed for the IP network. It s auto-adaptve for both low and hgh jtter envronments by analyzng the jtter present n the stream. The algorthm was mplemented for Real tme applcaton n IPTV set-top box and tested to be stable n the RTOS envronment. The fourth man contrbuton s presentng certan enhancements for AV Sync (Audo Vdeo synchronzaton) n dgtal STB (Set-Top Box). Audo Vdeo synchronzaton has always proved dffcult to mplement n STB. The man reason of AV Sync problem s dfference n processng path of audo and vdeo. Smultaneous synchronzaton of audo wth HD (Hgh Defnton) and SD (Standard Defnton) output mpose very tght constrants. Researchers n the smlar feld have suggested varous models for Correct AV Sync mplementaton. However, none of them addresses the AV Sync problem of dual vdeo (HD & SD smultaneously) wth audo. Set-top box (STB) has not been consdered as possble applcaton for ther mplementaton so such models are not sutable for Real Tme Systems. Detaled analyss of varous STB applcatons scenaros and ther tght constrants has been carred out. The current AV Sync mplementatons of STB have been analyzed and v

9 certan enhancements n current software mplementatons have been proposed. In ths thess we have also proposed few novel synchronzaton models that offer better synchronzaton accuracy. These models have been mplemented n Real tme applcaton n set top box. Testng of proposed mplementaton n the RTOS envronment meets STB AV sync constrants. v

10 TABLE OF CONTENTS Page No Acknowledgements Abstract Lst of Fgures Lst of Tables Lst of Symbols and Abbrevatons xv xx xx Chapter 1 Introducton 1.1 Background of the Clock Recovery Problem 1 1. Background of the A/V sync Problem Objectves of the Thess Methodology adopted for the Research Work Scope of the Thess Organzaton of the Thess 11 Chapter Lterature Revew.1 Lterature revew of Clock recovery for Satellte and Terrestral Broadcastng 14. Lterature revew of Clock recovery for IPSTB Broadcastng 18.3 Lterature revew of Audo Vdeo Synchronzaton 30.4 Research gap dentfed n exstng clock recovery algorthms 31.5 Research gap dentfed n exstng AV sync Implementatons 33 Chapter 3 MPEG Standard 3.1 Introducton MPEG Standard Overvew Part of MPEG Standard 39 v

11 TABLE OF CONTENTS (Contd...) 3.4 MPEG System Layer Elementary Stream (ES) Packetzed Elementary Stream (ES) MPEG Multplexng Layer MPEG Transport Stream 49 Chapter 4 Set-Top Box System 4.1 Introducton Set-Top Box components The Network Interface The Decoder The Buffer Synchronzaton hardware Set-Top Box functon Functonng of STX7109 HDTV Set-Top Box decoder chp 64 Chapter 5 Clock recovery for Satellte TV 5.1 Introducton to Clock synchronzaton Voltage controlled Oscllator based clock recovery module FS based clock recovery module Analyss of Jtter n DVB-S Envronment Movng wndow Basc Averagng algorthm FOR DVB-S Broadcastng Flter parameters PCR_DRIFT_THRESHOLD MIN_SAMPLE_NUM 77 x

12 TABLE OF CONTENTS (Contd...) MAX_WINDOW_SIZE Error calculaton and applyng correctons Performance of Movng wndow Basc Averagng algorthm Concluson 83 Chapter 6 Clock recovery for Terrestral TV 6.1 Analyss of Jtter n DVB-Terrestral Envronment Lmtaton of DVB Terrestral Broadcastng Movng wndow Weghtng FIR flter algorthm for DVB-T Broadcastng Low Pass Flter Movng wndow Weghtng FIR flter algorthm Applyng Correctons Closed loop analyss of proposed algorthm Performance of proposed algorthm for Terrestral Broadcastng Concluson 99 Chapter 7 IP Streamng: Detaled Analyss n IP Envronment TV 7.1 IP Network Interface Networkng Technologes IP Protocols sute Uncast and Multcast IP Protocols Byte and Bt Representaton Transport Protocols Protocols stacks 108 x

13 TABLE OF CONTENTS (Contd...) Stack Representaton Data Encapsulaton Protocol Stack Implementaton AV Content Transport format MPEG Transport Stream based format IP streamng recever software Server Push or Clent Pull MPEG TS based Recever Software Stack RTP Elementary Stream based Recever Software Stack IP streamng recever clock synchronzaton Clock Synchronzaton for TS based Transport 119 Chapter 8 Clock recovery for IP TV 8.1 Analyss of Jtter and color loss n IP envronment New proposed Algorthm for clock recovery n IP Set-top box Proposed algorthm Algorthm enhancements Pece-wse Lnear Adapton Over-lapped Pece-wse Lnear Adapton Contnuous Adapton technque Exponental Weghtng X Co-ordnate Shft Parameter Scalng Proposed feedback loop System response 135 x

14 TABLE OF CONTENTS (Contd...) Over-Dampng Matlab smulaton of Proposed algorthm for IP envronment Performance analyss of new proposed LR algorthm n real tme IP envornment System Matlab smulaton wth real tme data Matlab Smulaton of Real tme data for 0 ms jtter Matlab Smulaton of Real tme data for 0 ms jtter Matlab Smulaton of Real tme data for 100 ms jtter Results of Real tme IP streams for varyng jtter Results of Real tme IP streams for 0 ms jtter Results of Real tme IP streams for 0 ms jtter Results of Real tme IP streams for 50 ms jtter Results of Real tme IP streams for 80 ms jtter Results of Real tme IP streams for 100 ms jtter Performance Comparson of new proposed LR algorthm wth old LR algorthm Concluson 16 Chapter 9 Audo Vdeo Synchronzaton 9.1 Introducton to Audo Vdeo synchronzaton (AV sync) Audo Vdeo synchronzaton defnton Proposed enhancement n exstng schemes Improvng tmng accuracy Tmng mprovements by local clock tck quantzaton 170 x

15 TABLE OF CONTENTS (Contd...) Tmng mprovements by correct nterrupt 171 handlng Tmng mprovements by software schedulng Optmzaton Improvng quantzaton accuracy PTS Quantzaton Arthmetc Quantzaton Audo Quantzaton Vdeo Quantzaton Proposed AV sync desgn varaton Mnmze Control Complexty Mnmze Hgh Qualty Error Mnmze Memory Requrements Test setup for AV sync problem Concluson 180 Chapter 10 Results and Conclusons 10.1 Summary of results Conclusons Specfc Contrbutons Further Scope of Work 189 References 191 Appendces I. Applcaton of Set-Top Box decoder chp A-1 II. Clock recovery algorthm smulaton n matlab A-7 x

16 III. Sgnalng and management protocols for IP streams A-14 III. Sgnalng and management protocols for IP streams A-3 Lst of Publcatons A-1 Bref Bography of the Canddate A-1 Bref Bography of the Supervsor A-1 xv

17 LIST OF FIGURES Fgure No Ttle Page No 1.1 Methodology Adopted for Present Work 9.1 Block dagram of a PLL used n MPEG decoder 0. LLR based Clock Recovery Method Evoluton of MPEG Summary of MPEG Compresson Capablty Formaton of MPEG stream PES Packet Schematc Detaled structure of PES Packet Functonal Block dagram of Standard MPEG MPEG Transport Stream Detaled Syntax of Transport stream Three types of TS Packets Example of PSI Tables PSI Table Structures Schematc of Dgtal Set-Top Box block dagram PCR mechansm PCR mechansm n Transport Stream Tmng Dagram n a Typcal Set-top Box VCXO based clock recovery 74 xv

18 Fgure No Ttle Page No 5.5 Generalzed Desgn of PLL based Clock Recovery Concept of Movng Wndow Behavor of algorthm as smulated n Matlab for Satellte data wth P=50, S=10, M= Input PCR Count vs Decoder Frequency graph demonstrate behavor of Proposed Algorthm n Satellte Envronment Hardware Setup PCR samples Arrval tme n Terrestral Envronment Frequency Error Samples n Terrestral Envronment Feedback Loop expressed as Z transform Behavor of smulated algorthm n MATALAB for terrestral data wth P=1000, S=50, M= Behavor under G.I. = 1/8, 64 QAM, FEC=3/4 terrestral envronment(jtter = 0.4 ms) 6.7 Behavour under G.I. = 1/4, 64 QAM, FEC= 7/8 terrestral envronment(jtter = 1. ms) IP Network Stack Representaton IP Data Encapsulaton Protocol Stack Implementaton MPEG TS based Recever Software Stack RTP ES based Recever Software Stack PCR vs STC Jtter dstrbuton 1 8. Jtter and Latency n IP envronment 14 xv

19 Fgure No 8.3 Ttle Prncple of Enhanced LLR algorthm for Clock Recovery n IP envornment Page No Clock Recovery module usng Enhanced Lnear Regresson Quantzed Frequences n Response To 0ms Jtter Lnear Comparson of Dfferent order of Jtter dstrbuton Model 8.7 Performance of new LR algorthm n Matlab envronment (Pareto- for jtter 18 ms wth FS=3 OD= 4.83) 8.8 Performance of new LR algorthm n Matlab envronment (Pareto- for maxmum delay of 35 ms wth FS=3, OD= 9.38) 8.9 Performance of new LR algorthm n Matlab envronment (Pareto- for jtter 5 ms wth FS=3 OD= 18.73) 8.10 Performance of new LR algorthm n Matlab envronment (Pareto- for jtter 70 ms wth FS=5 OD= 18.73) IP-STB clock recovery test setup Plot of quantzed decoder frequency for real tme data havng 0 ms jtter 8.13 Plot of quantzed decoder frequency n matlab for real tme data havng maxmum jtter=0 ms 8.14 Plot of quantzed decoder frequency n matlab for real data havng maxmum jtter=100ms 8.15 Plot of PCR count and quantzed decoder frequency for 0 ms jtter n real tme IP stream 8.16 Plot of PCR count and quantzed decoder frequency for 0 ms jtter n real tme IP stream 8.17 Plot of PCR count and quantzed decoder frequency for 50 ms jtter n real tme IP stream 8.18 Plot of PCR count and quantzed decoder frequency for 80 ms jtter n real tme IP envronment xv

20 Fgure No Ttle Page No 8.19 Plot of Decoder Frequency vs tme elapsed n a VBR stream -nd order pareto 100 ms jttery envronment (FS =9). 8.0 Performance comparsons of old LR algorthm wth new enhanced LR algorthm for VBR (max 33.7 Mbps) -nd order pareto jtter dstrbuton. 9.1 Standard MPEG system: Full clock recovery s mandatory wth PCR, Lp Sync wth PTS/STC 9. One program n Full screen+pip (Pcture n Pcture) Full clock recovery+ Lp Sync wth PTS/STC for full screen program, PIP s ether free runnng or vdeo synced. 9.3 Vdeo only (Mosac): clock recovery s mandatory, but Lp sync s not needed 9.4 Audo only: Full clock recovery s mandatory, but Lp sync s not needed 9.5 DVR(recorded system) : clock recovery s mandatory, but Lp sync s not needed Audo errors wth respect to slower vdeo rate General Dsplay Tmng Mnmze control complexty Mnmze FR Error Mnmzng memory requrement Audo Vdeo synchronzaton testng setup 180 A 1.1 Low cost satellte HD Set- Top Box A- A 1. Low cost dual satellte & terrestral HD Set- Top Box wth A-3 HDD & DVD A 1.3 Low cost cable HD Set- Top Box wth return channel A-4 A 1.4 Low cost HD IPTV Set- Top Box A-6 xv

21 LIST OF TABLES Table No Descrpton Page No 3.1 PES Scramblng control PSI Table Example of PAT for Three Program Multplex Example PMT for Program Example CAT for Program Effect of Terrestral Parameters on Jtter Test1- SportsVBR3.8 - NoShunra Test- AllVBR38 No Shunra Test3- SportsCBR0 No Shunra Test4-SportsCBR40-NoShunra Real Tme PCR- STC data set (0 ms jtter) Real Tme PCR- STC data set (0 ms max jtter) Real Tme PCR- STC data set (100 ms max jtter) Performance Comparson of OLD LLR and enhanced LLR STB customer s Audo Vdeo Sync requrement 165 xx

22 LIST OF SYMBOLS AND ABBREVIATIONS Symbol/Abbrevaton AAC AAL AEPS ARMA ATM ATSC CAT CBR CRC CVBS/YC DCXO DDR DHCP DOCSIS DSL DSM-CC DTS Descrpton Advanced Audo Codng ATM Adaptaton Layer Average Error Per Sample Auto Regressve Movng Average Asynchronous Transfer Mode Advanced Televsons Systems Commttee Condtonal Access Table Constant Bt Rate Cyclc Redundancy Check Color, Vdeo, Blank, Sync/Y-separate lumnance (Y), Chromnance(C) Dgtally Compensated Crystal Oscllator Double Data Dynamc RAM Dynamc Host Confguraton Protocol Data Over Cable Servce Interface Specfcaton Dgtal Subscrber Lne Dgtal Storage Meda Command & control Decode Tme Stamp xx

23 LIST OF SYMBOLS AND ABBREVIATIONS Symbol/Abbrevaton DVB-CI DVB-S DVB-T DVB-IP DVI EIT EMM EMI EPG ESCR ES FEC GCF HD HDD HDMI HTTP IGMP JTS Descrpton Dgtal Vdeo Broadcastng-Common Interface Dgtal Vdeo Broadcastng - Satellte Dgtal Vdeo Broadcastng -Terrestral Dgtal Vdeo Broadcastng Internet Protocol Dgtal Vdeo Interface Event Informaton Table Event Management Module External Memory Interface Electronc Program Gude Elementary Stream Clock reference Elementary Stream Forward Error Correcton Gradual Correcton Factor Hgh Defnton Hard Dsk Drve Hgh Defnton Memory Interface Hyper Text Transfer Protocol Internet Group Management Protocol Jtter Tme Stamp xx

24 LIST OF SYMBOLS AND ABBREVIATIONS Symbol/Abbrevaton LLR LMI MAFE MPLS MII NIT NTSC PAL PAT PCR PES PID PLL Descrpton Least Square Lnear Regresson Local Memory Interface Modem Analog Front End Interface Multprotocol Label Swtchng Meda Independent Interface Network Informaton Table Natonal Advanced Televsons Systems Comttee Phase Alternate Lne Program Assocaton Table Program Clock Reference Packetsed Elementary Stream Packet Identfer Phase Locked Loop PMT PSIP PSTN PTS Program Map TAble Program Specfc Informaton Protocol Publc Swtched Telephone Network Presentaton Tme Stamp xx

25 LIST OF SYMBOLS AND ABBREVIATIONS Symbol/Abbrevaton RMII SATA SD SDRAM SECAM SOC S/PDIF STB TCP TS VBR VCXO Descrpton Reduced Meda Independent Interface Seral Advanced Technology Attachment Standard Defnton Synchronous Dynamc RAM Sequental Color wth Memory System On Chp Sony-Phlps Dgtal Interconnect Format Set Top Box Transmsson Control Protocol Transport Stream Varable Bt rate Voltage Controlled Crystal Oscllator LIST OF SYMBOLS AND ABBREVIATIONS Symbol/Abbrevaton Descrpton a, b Exponental Weghtng Parameters α, β Dampng Weghts xx

26 α β FS L M N P S Delay n current decode frame from prevous FR frame Audo delay w.r.t FR vdeo Flter Strength PCR_ dffr. Max. Wndow Sze No. of data ponts PCR drft threshold Mn. sample number. S a Scalng parameters σ y Standard Devaton λ γ Maxmum Slow Vdeo Delay w.r.t. audo Maxmum Audo Delay w.r.t. slow vdeo T F Tme Interval for faster frame rate T S Tme Interval for slow frame rate T M Maxmum Specfed AV sync. Delay T E AV sync. Error wndow specfcaton xxv

27 Chapter 1: Introducton 1.1 BACKGROUND OF THE CLOCK RECOVERY PROBLEM In the late 19th century the research to represent mages wth electrcal sgnals began. In 1897 the cathode ray tube was nvented, whch stll s the most wdely used technque n TV sets and computer montors to dsplay the mage. The possblty of transmttng audo-vsual nformaton became possble only wth arrval of televson n the early thrtes. The frst televson broadcast took place both n Berln and Pars n 1935 and the frst publc televson servce was started n New York n In the fortes, televson servces started n more and more countres n Europe, but each country developed ts own standard. It was not untl 195 that a sngle standard was proposed and progressvely adopted for use n Europe. Apart from gradually mprovng qualty of sender and recever equpment, three major nnovatons have characterzed for the development of televson n the fftes: The ntroducton of color televson began n the md-fftes, hgh defnton televson n the late seventes, and dgtal televson n the nnetes. One major problem wth analogue televson s ts hgh demand of bandwdth. Thanks to the dgtal representaton of mages, advanced mage codng, and data compresson technques, ths helped to reduce the bandwdth sgnfcantly. Typcally, about sx dgtal TV channels can ft nto the bandwdth of a sngle analogue TV channel. One major advantage of dgtal televson over analogue, apart from the bandwdth reducton, s the possblty of nteracton between the TV recever and the vewer. Due to many more other advantages, demand for new audovsual servces and applcatons, such as Dgtal TV (Marsch, 1999), Dgtal Versatle Dsc (Taylor, 1997) and vdeoconference contnuously ncreased n the recent years. The ntroducton of these 1

28 servces, and n partcular those that have a dstrbuted nature lke vdeoconference and DTV, has been facltated by three key factors: avalablty of codng/compresson technques of audovsual data, hgh-capacty transport networks, and hgh-speed access technologes to network facltes. Today dgtal televson s delvered over dedcated broadcast networks (Fscher, 004) such as satellte, cable, and terrestral transmsson. The most wdely used vdeo codng standard used n these networks s MPEG- (Moton Pcture Expert Group-) (MPEG-System). It s part of the DVB (Dgtal Vdeo Broadcastng) standard for broadcastng of dgtal televson, whch s most wdely used standards n Europe. Ths s also used n storage of dgtal vdeo for example on DVD. To enable some sort of nteractvty, the networks have to provde support for an nformaton flow from the recever to the vewer. Therefore, there s large nterest n provdng new, nteractve TV servces over data communcatons networks, lke IP networks. In order to provde nteractve TV servces over data communcatons networks, a lot of work has been done durng the nnetes. Especally, ATM (Asynchronous Transfer Mode) networks have been studed n ths respect. An overvew of the ssues of asynchronous transfer of vdeo over packet swtched networks s gven n (Karlsson, 1996). Snce the Internet has grown and developed enormously n the last few years, t was expected that n a near future more servces, lke hgh qualty dgtal televson, wll be offered beyond the usual data transmsson that the Internet was frst desgned for. An Internet provder can provde both broadband connectons to the Internet.e. dgtal televson and IP-telephony on the same cable. The transmsson of dgtal televson over IP-based network provdes opportuntes of nteractve servces for the vewers, e.g. VoD (vdeo on demand) (Mlenkovc, 1998) (where the vewer decdes when to watch a certan move or TV program).

29 There are some problems wth real tme transmsson of audo-vsual nformaton over IP based networks because these types of networks were not desgned for such applcatons. Tradtonally IP-based networks behave as classcal packet swtched networks, provdng no guarantee regardng delvery of the nformaton on a "network level". When the network s heavly loaded,.e. congested, some data may be lost or sgnfcantly delayed durng the transmsson. Audo-vsual data are generally vulnerable to data loss because of the codng technques used n real tme, for example the most commonly used subsets of MPEG-, generate bt streams wth lmted reslence to packet losses. Another major problem s that end-to-end delay s varable, whch depends on the load of the network. In order to delver MPEG- audo and vdeo streams n real tme wth hgh qualty, these delay varatons have to be reduced at the recevng end, otherwse the decoder wll not operate correctly. Thus, most of the multmeda applcatons need tme-senstve nformaton n voce, audo, and movng pctures. Mostly applcatons requre strct synchronzaton propertes. One can dvde real-tme streamng applcatons nto dfferent categores, dependng on the servce t provdes and ts tolerance to delay: Informaton Retreval Servces: These types of servces nclude vdeo-on-demand, where the vewer decdes when to watch a specfc TV program or move. Usually these servces are not very delay senstve. The vewer can accept to wat maybe a second from the moment that he/she presses "play" and the vdeo sequence s dsplayed. These servces are usually only suted for uncast. Communcatve Servces: These types of servce nclude vdeoconferencng and vdeo telephony. Communcatve servces are senstve to delay and response tme. For vdeoconferencng, the end-to-end delay should not be more than 150 ms, see (Wolf 1997). Actually dfferent authors suggest dfferent delay lmts. (The one suggested by 3

30 Wolf can be regarded as a qute strngent requrement.) These servces can be ether of type uncast or multcast. Dstrbutve Servces: These types of servces nclude broadcastng/multcastng of e.g. real tme audo, vdeo and text to Televson. Dstrbutve servces are also delay senstve. An example of ths s a TV program where vewers can call n lve to the program and take part n e.g. a quz show or other compettons. Move channels are less delay senstve. However t should be noted that excessve bufferng at the recever mght ntroduce a too long channel change tme. Regardng synchronzaton ssues, an mportant dstncton s that not all the mplementatons of MPEG- servces requre strct synchronzaton e.g. VoD (vdeo on demand), RealPlayer (RealPlayer, 009), MPEGplayer (MPEG TV, 009) or ARTeMeD (Noro, 1997) and frame-based mplementatons do not requre very strct synchronzaton. However, n dgtal TV, the recevng system.e. STB decoder must be able to reproduce the nformaton wth strct tmng as when t was produced by the sender. All the concerns related to tmng are encompassed by the term synchronzaton. Any synchronzaton error causes serous dsrupton of the qualty perceved by the vewer, not only loss of nformaton and excessve delay, but also loss of nter-stream synchronzaton between audo and vdeo streams. Another ssue n Dgtal TV (DTV) s due to the fact that set-top box decoder should provde accurate colour sub-carrer frequency synchronzaton as decoder provdes a output of colour vsual sgnal compatble wth TV set (e.g., PAL and NTSC). A need s felt for a clock synchronzaton system that overcomes the clock synchronzaton problems n the presence of jtter n dgtal vdeo broadcastng typcally DVB-S, DVB-T and DVB-IP. 4

31 1. BACKGROUND OF THE A/V SYNC PROBLEM Wth the ntroducton of advanced dgtal delvery systems for audo and vdeo, there s an ncreased awareness of the tmng relatonshp between audo and vdeo. Owng to advanced data compresson technologes such as Dolby Dgtal (AC-3) for audo and MPEG- for vdeo, sound s clearer and pctures are sharper. Technologes such as Dgtal Televson (DTV), DVD, Drect Broadcast Satellte (DBS), and Dgtal Cable use above compresson technques to delver extremely hgh qualty to consumers. However, performance can degrade sgnfcantly due to occurrence of audo/vdeo synchronzaton problems. Reports on (Lnear acoustc, 004) have ndcated that most flm edtors are able to detect A/V Sync errors as short as ± ½ flm frames. As flm s projected at 4fps n the US and 5fps n Europe, ths equates to approxmately ±0msec. It s clamed that some edtors can detect even smaller errors, but ths mght be more accurately attrbuted to ther famlarty wth the materal beng vewed. Dolby Laboratores has specfed that any Dolby Dgtal decoder must be wthn the range of +5msec audo leadng vdeo to 15 msec audo laggng vdeo. Ths s because human percepton of A/V Sync s weghted more n one drecton than the other. The fact s that human bran s accustomed to hear thngs slghtly after seeng them happen because lght travels much faster than sound. We are all used to seeng ths proven, although as t s such a common stuaton many tmes we do not notce. For example, a basketball httng the court n a large sports venue would appear relatvely correct to the frst few rows, but the further back a vewer gets, the more the sound lags behnd the sght of the ball httng the floor. The further back you get, the more the sound lags, but t stll seems OK. 5

32 Now, magne f the A/V tmng was reversed. You are watchng a basketball game, and the sound of the ball httng the court arrves before the ball looks lke t makes contact. Ths would be a very unnatural sght and would seem ncorrect even f you were n the frst few rows where there was just a small amount of A/V Sync error (lp-sync error). The pont s that the error s n the wrong drecton. To summarze, human percepton s much more forgvng for sound laggng behnd sght as ths s what we are used to seeng n everyday occurrences, so t s better for the audo to be slghtly late rather than early. Accordng to (ITU-R, 1998), the thresholds of tmng delectablty are about +45 ms to -15ms, and the thresholds of acceptablty are about +90ms to -185ms. However, ths range s probably far too wde for truly acceptable performance, and much tghter tolerances need to be obeyed. The ATSC recommends (ATSC, 003) that the sound program never leads the vdeo program by more than 15ms and does not lag the vdeo program by more than 45ms. In today s consumer electroncs market, STB customers even ask to have a maxmum delay of half a vdeo frame (hence ±0 ms or ±17 ms). In addton to these tght requrements of end user, case of smultaneous synchronzaton of SD and HD vdeo wth audo becomes more crtcal. In ths evolvng stuaton, we have taken-up the problem of AV sync for our research work. 1.3 OBJECTIVES OF THE THESIS In vew of above, the man objectves of the research work are. Desgn a clock recovery mechansm to adjust the locally generated clocks wth the encoder clock for DVB-S (DVB- Satellte) broadcastng n dgtal satellte set-top box (STB). 6

33 . Analyss of jtter n terrestral envronment and developng clock recovery algorthm for DVB-T (DVB-Terrestral) n dgtal terrestral set-top box.. Detaled analyss of IP envronment and dentfy lmtatons mposed by IP broadcastng for sutable clock recovery algorthm n IP dgtal set-top box. v. Detaled analyss of complete IP data flow. Desgn a new effcent clock recovery algorthm that can handle jtter up to several hundred ml seconds n IP envronment. v. Desgn a new novel audo-vdeo synchronzaton (AV Sync) module for dgtal set-top box based on drawbacks n exstng audo-vdeo synchronzaton mplementaton. 1.4 METHODOLOGY ADOPTED FOR THE RESEARCH WORK The methodology adopted for the research work s shown n Fgure 1.1. Followng tasks were completed to acheve the objectves of the study. Phase 1: Extensve lterature survey has been done. Ths nvolves n-depth study of exstng research work done for achevng clock recovery mechansm and audovdeo synchronzaton (lp-synchronzaton) n set-top box for satellte, terrestral, and IP envronment as shown n Fgure 1.1. Phase : Detaled study of MPEG- (Systems) standards, Set-top box subsystem, ST40 toolset. Phase 3: A new algorthm named Basc Averagng algorthm has been proposed. It has been smulated and tested n satellte envronment for set-top box applcaton. 7

34 Phase 4: Another algorthm Movng Wndow Weghng Flterng algorthm has been proposed. It has been smulated and tested for satellte and terrestral envronment for set-top box applcaton. Phase 5: Study of IP set-top box functonalty, detaled analyss of IP envronment and ssues n clock recovery for IP Set-top box has been done. Phase 6: Proposng a new algorthm for IP envronment. It has been smulated and tested for IP-set-top box. Comparatve study of performance of newly developed algorthm wth exstng algorthm has also been done. Phase7: Certan mprovements have been proposed n exstng audo-vdeo synchronzaton desgn. Three new desgn schemes have also been proposed for dual vdeo (HD & SD smultaneously) for AV Sync n dgtal set-top box. Phase 9: Results have been compled wth the help of the output obtaned throughout the research work n ths thess. 8

35 Study of research work done so far for achevng clock recovery mechansm n satellte, terrestral, and IP Set-top box. Survey and study of exstng lterature for AVsync problem Study Regon Study of MPEG- System standard, functonalty of dgtal set-top box, ST Toolset ST40 used for testng and smulaton Desgn and mplementaton of new algorthms for Satellte broadcastng n dgtal set-top box. Analysng Jtter n terrestral broadcastng and desgnng and mplementaton of new algorthms for Terrestral broadcastng n dgtal set-top box. Study of IP set-top box functonalty and detaled analyss of IP set-top box clock recovery requrement Newly desgned LLR based IP clock recovery algorthm mplementaton and performance evaluaton Proposng new schemes for AVsync for dual vdeo (HD & SD smultaneously).certan mprovements n exstng schemes are also presented. Results complaton Fgure 1.1 Methodology Adopted for the Present Work 1.5 SCOPE OF THE THESIS The scope of thess s manly focused on achevng clock recovery for low jttery satellte broadcastng and moderate to hgh jttery Terrestral broadcastng for dgtal settop box. Major scope s to acheve clock recovery n STB for very hgh jttery IP broadcastng. A/V sync problem n dgtal set-top box for dual vdeo (SD, HD) STB s another sgnfcant scope of our work. 9

36 We amed for developng and mplementng effcent clock recovery mechansm for satellte and terrestral set-top boxes. In dgtal set-top boxes, decoder-clock has to be strctly synchronzed wth encoder by tmng nformaton (Program clock reference.e. PCR tmestamps embedded n transport stream). MPEG data s broadcasted over varous transmssons medum. Satellte and Terrestral are jttery medum where PCR packets get delayed and we get large +/- errors proportonal to the delay and very frequent gltches. It leads to ncorrect synchronzaton and color loss. The clock recovery problem n satellte and terrestral envronment has been analyzed. Exstng algorthms appled n ths area have certan lmtatons. Sometmes color loss has been observed n very hgh jttery envronments. Our proposed approaches provde an effcent, economcal, and a smple real tme software solutons meetng all constrants posed by set-top boxes for satellte and terrestral envronment. Further major work has been done for IP set-top box. The amount of jtter n IP envronment s drastcally hgh (may be shoot up to hundred of ms) compared to DVB-S or DVB-T. The detaled study has been done towards development of a Least-square Lnear Regresson (LLR) synchronzaton algorthm. The LLR algorthm s nearly two tmes faster than a PLL of equvalent synchronzaton accuracy. Wth contnuous adapton enhancement n LLR, we mnmze the end-to-end delay and hence the loss caused by synchronzaton errors. The optmal performance of LLR enables the deployment of methodology adopted n the present thess n dgtal TV applcatons based on the MPEG- standard over a wder range of jtter nducng networks, where the conventonal secondorder PLLs generally fal. We have desgned a new synchronzaton algorthm to perform effcent synchronzaton of two dspersed clocks for IPTV envronment. Another challengng scope of the thess s n area of AV sync error. Audo-vdeo Synchronzaton (AV sync) s very mportant to consumer and the dsplay ndustry snce 10

37 newer technologes have created a notceable delay between the processng of vdeo sgnals and the processng of audo sgnals. Lp sync correcton algorthms take nto account processng delays, so that both sgnals can be synchronzed and presented to the vewer together. Correct A/V sync greatly mproves the entertanment for the vewer. In a typcal set-top box A/V sync (lp-sync) has always proved to be dffcult. The man reason of AV Sync problem s dfference n processng path of audo and vdeo. Smultaneous synchronzaton of audo wth HD (Hgh Defnton) and SD (Standard Defnton) output mpose even much tghter constrants. In ths thess detaled analyss of varous Set-top box applcatons scenaros and ther lmtatons has been explored. The current AV Sync mplementatons of Set-top box have been analyzed and certan enhancements n exstng approaches have been suggested. We have also proposed some new schemes for AV sync for dgtal STB n ths thess. 1.6 ORGANIZATION OF THE THESIS The research work s presented n ten chapters as follows: Chapter 1: In ths chapter, ratonale and structure of the thess s presented. Need of development of clock recovery algorthms and audo-vdeo synchronzaton n set-top box applcaton s hghlghted. Ths chapter also states the objectves of the research followed by the methodology adopted and organzaton of the thess. Chapter : In ths chapter, lterature survey on varous ssues and technques nvolved n achevng clock recovery for Satellte, Terrestral and IP broadcastng has been presented. Dffcultes and shortcomngs of already exstng approaches of clock recovery for set-top box applcaton has been dentfed and understood. A revew of lterature on 11

38 exstng audo-vdeo synchronzaton (lp-sync) problem s presented and research gaps are hghlghted. Chapter 3: In ths chapter, popular MPEG standard s beng explaned. In-depth understandng of ths standard s very much essental for software mplementatons of clock recovery algorthms. Major techncal detals of MPEG-System have been descrbed n detal n ths chapter. Chapter 4: In ths chapter, state-of-the-art of set-top box subsystem has been dscussed. As we may lke to develop clock recovery algorthms for set-top box applcatons, so understandng the functonalty of set-top box and dentfyng constrants posed by STB was mmensely requred. Clock recovery s beng handled by decoder chp n STB system, SoC (system-on-chp) of STB decoder chp has also been explaned n ths chapter. Chapter 5: In ths chapter, a new desgned algorthm Movng Wndow Basc Averagng clock recovery algorthm for Satellte Set-top box has been dscussed. The methodology adopted for clock synchronzaton n set-top box s descrbed. The algorthm has been smulated and tested n real tme envronment. Chapter 6: In ths chapter, nature of jtter n terrestral broadcastng has been analyzed. Another sutable algorthm Movng Wndow Weghng Flter for terrestral Set-top box has been proposed. The results of newly developed algorthms n terrestral envronment are beng presented. 1

39 Chapter 7: An overvew of varous protocols and how MPEG- s to be transmtted over IP-based networks s presented. Chapter 8: Ths chapter wll frstly descrbe the problems that occur when real tme audo-vsual nformaton s streamed over IP networks. After that newly desgned Contnuous Adapton Enhancement n LLR algorthm for IP-STB has been dscussed. The performance of proposed algorthm s smulated and tested n real envronment. Superorty over other exstng algorthms has been llustrated. Chapter 9: In ths chapter the problem of AV synchronzaton (lp-synchronzaton) has been analyzed. Certan enhancements n exstng approaches are suggested. Three dfferent proposals for dual vdeo (HD & SD smultaneously) wth audo synchronzaton has been presented. The results are used to select optmal scenaro for mplementaton. Chapter 10: Ths chapter presents the summary of results, conclusons, and recommendatons of the future research work. Further scope of work and specfc contrbutons n the thess are also presented. 13

40 Chapter : Lterature Revew In ths chapter, survey of lterature regardng clock synchronzaton for dgtal settop box s presented. A revew of lterature on major ssues nvolved n varous ssues and technques nvolved n achevng clock recovery for Satellte broadcastng, Terrestral broadcastng and IP broadcastng s dscussed. Manly followng major ssues are presented n ths chapter: Revew of Clock Recovery algorthm for Satellte broadcastng n set-top box. Revew of Clock Recovery algorthms for Terrestral broadcastng n set-top box. Revew of Clock Recovery algorthms for IP set-top box. Revew of exstng Audo-Vdeo synchronzaton technques for set-top box.1 LITERATURE SURVEY OF CLOCK RECOVERY FOR SATELLITE AND TERRESTRIAL BROADCASTING The growng demand for dgtal satellte & terrestral broadcastng servces has dentfed the need of sutable clock recovery algorthm for Satellte and Terrestral envronment. Clock synchronzaton plays a key role n correct workng of the STB system for real tme audo and vdeo transmsson. MPEG encoder s a varable bt rate devce. To transport a varable bt rate stream through a constant rate channel or medum, buffers are requred both at the encoder and the decoder. Snce buffers are placed at the encoder and the decoder sdes, these buffers have to be managed so that they nether overflow nor underflow. Buffer management n turn requres clock synchronzaton between the encoder system clock and the decoder system clock. 14

41 In DVB-Satellte (DVB-S) and DVB-Terrestral (DVB-T) communcaton, uncertan arrval of PCR packets at the recever end causes serous problems n synchronzaton of recever system clock wth that of the transmtter. The conventonal methods avalable to overcome ths aspect cannot reduce all the problems, specfcally n worst case channel condtons of terrestral set-top box. Problems such as color loss, jttery vdeo, and audo dropouts stll persst. Apart from ths, exstng methods have hgh computatonal overhead and hgh cost. Audo and vdeo have separate frame sze defntons and samplng rates and have entrely separate encodng strateges. To synchronze audo and vdeo streams, t s convenent to have a common clock between the encoder system and the decoder system. Ths common clock between the encoder and the decoder systems can easly provde the tme reference needed for nter-stream synchronzaton. Ths common clock s acheved by the process of clock recovery. Clock recovery between transmtter and recever n exstng set-top boxes s acheved by confgurng clock recovery hardware regsters.e. software approach n STB decoder chp for adjustment of decoder clock. In a purely hardware based decoder system, buldng a synchronzaton subsystem s not dffcult. Large body of lteratures (Edward and Davd, 1988; Harry and Van, 1971; Holborow, 1994) are avalable on the subject of frequency and phase locked loops. Varous hardware mplementaton modules for clock adjustment s acheved by ether DCXO chp (Lmng, 008), or by VCXO chp (Watanabe et al., 006), or by onchp VCXO/DCXO (Voltage controlled Crystal Oscllator/Dgtally-Compensated Crystal Oscllator) module (Ln J., 005; Mujca et al., 003; Lee and Bulzacchell, 199). 15

42 A real tme software soluton for resynchronzng fltered MPEG transport stream has been proposed by Bn and Klara (00). Author dscussed the scenaro of streamng of HD vdeo n MPEG- Transport Layer syntax wth software streamng/processng and hardware decodng. Several approaches to solve synchronzaton problem has been suggested. In one approach, paddng wth NULL packets s done n MPEG stream. In other approach some of the flterng ntellgence s exported to the end hosts, for example, nstead of nsertng NULL packets, nsertng only a specal packet sayng that the next N packets should be NULL packets. Note that ths paddng s mportant to mantan correct tmng, especally f the clent s usng some standard hardware decodng board. Ths way, the bandwdth s ndeed saved, but ths ntroduces non-standard protocol outsde MPEG. Soluton proposed (Bn and Klara, 00) has some drawbacks. It can only handle bt rate adaptaton operaton. We only try to fx the header of each frame to ts orgnal poston on the lne, whch means the changed frame should not occupy more bts larger than dstance between the current frame header and next header. Ths property does not always hold, snce some flterng operatons lke nformaton embeddng and watermarkng may ncrease the frame sze n bts. The saved bts are padded wth NULL packets to mantan the orgnal constant bt rate and the startng pont of each frame and ths roncally runs to counter our ntal goal of bt rate reducton for some operatons lke low pass flterng and color frame droppng. The resultng stream contans the same number of packets as the orgnal one. The only dfference s that the number of bts representng each frame has been shrunk; yet ths savng s spent mmedately by paddng null packets at the end of each frame. Flterng ntellgence approach wll ntroduce problem assocated wth non-standardzed solutons such as dffcultes n software mantenance and upgradng, so t can only be consdered as secondary choce not as a major soluton. 16

43 Kaser (1993) has gven a technque to mnmze the effects of jtter n the clock recovery process s by countng the tme dfference between successve tmestamps n the packet stream. Although the jtter ntroduced by the network may be computed on per packet-bass n ths scheme, t requres constant spacng between tmestamps n the packet stream, an assumpton that may not hold n MPEG- Transport Streams. Antono et al.(001) has proposed effcent non-data-aded carrer and clock recovery for satellte DVB at very low sgnal-to nose ratos. Analyss of clock and carrer (frequency/phase) synchronzaton algorthm ntended for use dgtal vdeo broadcastng systems s presented. However clock recovery needed for audo and vdeo streams n MPEG decoder n set-top box has not been explored. In ths research work, lot more lterature s revewed but we found that there s not much research work done regardng the synchronzaton problems of MPEG over satellte and terrestral set-top box. A large body of lterature (Monka et.al., June 009; Shen et.al.,004; Osak, 00; Wellan and Akyldz, 001; Tryfonas and Verma,1999; Ramamoorthy,1997; Rangan,1996; and Andreott et.al.,1995) suggested clock recovery for ATM and packet swtched networks but the drawback n these systems s that the computaton nvolved for clock recovery requres a complex algorthm and hgh cost apparatus. The complexty of algorthm s an ssue n set-top box applcaton. Ths ssue s due to the fact that real tme audo and vdeo processng consumes most of the processng space of set-top box decoder chp, so algorthm for clock recovery must be smple so that CPU of decoder chp s not loaded. Another drawback of hgh cost s well known fact n consumer market of set-top box. 17

44 It has been realzed that jtter n Satellte and Terrestral envronments s much lesser as compared to IP envronment hence a lght weghted, cost effectve algorthm can be deployed for handlng jtter n such a transmsson. To date, to our knowledge, no exstng clock recovery scheme s meetng constrants of STB for satellte and terrestral transmsson.. LITERATURE SURVEY OF CLOCK RECOVERY FOR IP STB BROADCASTING Several researchers (Markopoulo et al.,003; Gardner et al.,003; Lang et al., 001; Sanneck et al.,001; Cole and Rosenbluth,001; Vleeschauwer et al.,000; Kostas et al.,1998; Moon et al.,1998 ; Bolot et al.,1995) have worked on VoIP but t s a real challenge to acheve clock synchronzaton whle real-tme audo and real-tme vdeo both are broadcasted on IP networks and ths real tme data has to be dsplayed on dgtal televson. Due to stochastc nature of IP network, the clock recovery for MPEG stream n IP-STB s a bg ssue. IP networks were orgnally desgned to optmze bandwdth utlzaton by resource sharng, but they are unable to optmally meet the needs of real tme traffc that requres tmely clock synchronzaton. Ths lmtaton s due to the fact that stochastc packet transmsson delay jtter may lead to sgnfcant varaton n packet arrval tme. Accordng to DVB-IP (005), secton , the amount of jtter on an IP network s typcally 0 mllseconds (ms). However, maxmum jtter may be more than ths specfcaton to the tune of 100 ms, eventually ths makes clock synchronzaton more dffcult. In IP envronment, there s no lmt on how late a packet may arrve. Theoretcally ths delay could be nfntely long so we have to dscard packets reachng 18

45 after a certan tme otherwse all the subsequent packets get delayed. Ths maxmum delay should nclude 99% of the packets whle 1% of the packets may be dscarded. Color loss s the other problem that has serous mpact on the pcture qualty of IP Dgtal Set- Top Box. As per (MPEG- System) to prevent color loss, local frequency overshoot should be less than 1350 Hz. The TV montor connected to set- top box has to locate a color burst sgnal n order to decode the color sgnal. Accordng to Robn and Pouln (000), the frequency of the color burst must be accurate to 50 ppm. If the decoder clock has a large error, then the color burst sgnal wll not be found and ths wll result n color loss. When the color burst s successfully found, a PLL (Phase Locked Loop) n the montor s used to track subsequent changes n the color burst frequency. After samplng the small color burst sgnal at the start of each lne, the PLL then generates the color reference for the duraton of each lne. If the STB frequency changes too rapdly, then a color shft s observed as the PLL momentarly losses track. Although ths s a known problem, at present no specfcaton for the maxmum acceptable rate of frequency change was found n any standard. Ths maxmum drft rate was approxmated under the assumpton that typcal tme constant for a PLL n TV s 15 ms and set top box drft rate and tolerance should be 1000 tmes faster than ths tme constant. Thus drft rate come out to be 67 KHz per second. Poor accuracy of clock synchronzaton results n audo dstorton or vdeo flckerng. Long response tme results n the buffer overloadng, causng loss and excessve delays. The MPEG- standard does not formally constrant the network jtter: nstead, t requres that all TS decoders must be capable to absorb a network jtter of 4 ms, unfortunately, ths threshold s qute often exceeded n actual packet-swtchng networks, causng several malfunctons of the MPEG- systems decoder (Grnger et al., 1998). Thus there s a strong need to fnd a robust technque of clock recovery n emergng IPTV envronment that can handle all the above lmtatons. 19

46 The standard technque of synchronzaton between the transmtted and receved clock, as dscussed n the MPEG standard uses a dscrete tme Phase locked Loop (PLL). A typcal phase-locked loop (PLL), used n the MPEG decoder to synchronze the clock of the decoder to the STC of the encoder (Best, 1993), s shown n Fgure.1. It works as follows: Intally, the PLL wats for the frst PCR to arrve. When the frst PCR arrves t s loaded to the PCR counter. Now the PLL starts to operate n a close loop fashon. Each tme as a PCR arrves t s compared to the current value n the PCR counter. The dfference gves an error term e. Ths error term s sent to a low pass flter (LPF). The output of ths stage s a control sgnal f whch controls the frequency of the voltagecontrolled oscllator (VCXO) whose output provdes the system clock frequency of the decoder. The output of the VCXO s sent to the PCR counter. The nomnal frequency of the VCXO s approxmately 7 MHz. After a whle the error term e converges to zero whch means that the PLL has been locked to the ncomng tme base. The requrements on stablty and frequency accuracy of the recovered STC clock depend on the applcaton. In our DTV applcatons, the output from the decoder wll be fed to an analogue TV set. The colour sub-carrer and all synchronzaton pulses wll be derved from ths STC clock. In our case the STC must have suffcent accuracy and stablty so that a TV set can synchronze correctly to the vdeo sgnal. Fgure.1 Block dagram of a PLL used n MPEG decoder 0

47 The clock synchronzaton of the recever and the transmtter clock wth the PLL requres a loop flter for jtter absorpton. The loop flter s usually a Proportonal- Integratve (PI) (Gardner, 1979) flter of extremely narrow bandwdth (typcally, less than 0.1Hz), whch elmnates most of the hgh-frequency components of the jtter. Unfortunately, the response tme of the flter s dependent on the bandwdth of the flter, a narrow flter bandwdth has the nconvenence of a very slow convergence of the local sgnal to the reference sgnal (typcally, n the order of mnutes). As the jtter to be removed ncreases, the only possble strategy wth PLLs s to further reduce the bandwdth: n ths way, the response tme becomes even longer (Noro, 000). In (Andreott et.al.,1995) ordnary PLLs are used to dejtter MPEG- stream, whch uses the PCR tmestamps n the MPEG- Systems layer. In ths smulatons t s assumed that the MPEG- stream s delvered over a network wth small delay varatons, and therefore uses a peak-to-peak jtter (delay varaton) ampltude of up to 1 ms. Thus author smulates hs algorthm usng jtter models (lke Gaussan dstrbutons), however ampltudes of delay varatons n these regons are regarded as very low n IP-based networks. Ths scheme s therefore not suted for IP networks. Monka et.al.,(dec 008) has proposed an approach based on PLL desgn. Movng Wndow Averagng Flter for Clock Recovery n Set-Top Box has been presented. Approach s low cost and smple but t s performng well only for satellte broadcastng where jtter s very less. Monka et.al., Jan 009; Monka et.al., Oct 009; has presented another approach based on PLL desgn. Rather smple averagng, some more enhancements lke weghng s also applyng for handlng more jtter. Author has proposed an enhanced FIR 1

48 Flter based Module for Clock Synchronzaton n MPEG Transport Stream s effcent and low cost. Its performance s also evaluated (Monka et.al., March 009) and to be found stable. Algorthm s able to handle jtters of Terrestral broadcastng but t fals n hghly jttery envronment of IP. In summary, conventonal PLL synchronzaton algorthms fal n recoverng an accurate clock sgnal n the presence of hgh amounts of network jtter, that can be to the order of dozens of mllseconds on Internet lnks. We can conclude that a PLL lke desgn for hghly jttery envronment such as IP STB applcatons has to face several ssues: The large jtter experenced on IP networks complcates the flterng, the relatve clock drft s a slowly movng value hdden behnd a large whte nose. Effcent flters wll have a slower response tme, lettng the relatve clock frequences drft further apart. Dgtal flters are based on the assumpton that the nput varable has a fxed samplng rate however for MPEG transport streams there s no fxed frequency requrements for PCR tme stamps, other than sendng PCR at least every 100 ms. Thus PLL desgns are not sutable for IP networks due to above mentoned reasons. A number of possble alternatves to PLLs are proposed n the lterature (Moon et.al., 1999; Roppel, 1995; Crstan, 1989) prncpally derved from the statstcal sgnal processng feld. One such technque (Lau and Flescher, 199) proposes a new mplementaton that suggests that packet swtched networks nclude the synchronzaton of the transmtter clock and the recever clock usng tmestamps. The transmtter sends a seres of explct

49 tme references as tme stamps n sequence of packets and the tme stamps are used by recever to synchronze ts clock wth the transmtter, snce no common network clock s used, the recever rely on lockng ts clock to the arrval of tme stamps. Ths technque s analogues to the common method of perodc nserton of synchronzng pattern nto bt stream at the transmtter whereby recever s adapted to detect these synchronzng patterns and use them to generate a reference clock sgnal for PLL at the recever. Technques have been developed for clock synchronzaton usng a lnear modelng of error between transmtter clock and recever clock. Usng a lnear regresson analyss, the frequency offset between transmtter clock and recever clock for a gven tme perod or tme nstance s estmated or predcted and recever clock then s adjusted by ths estmated error. However, major dsadvantage n use of lnear regresson analyss as an estmaton technque s that the large number of consecutve clock samples generates accurate tmng sgnals and s needed to accurately estmate the model coeffcents. However, the storage capacty for storng a large number of tme seres samples and the assocated calculatons would be prohbtve. Another such technque s based on the Least Square lnear Regresson (LLR) (Noro, 000) prncple. Ths prncple wll take N samples of (STC,PCR) data ponts as shown n Fgure. and generate the best fttng lne such as the sum of the squares of the dstance between each (STC,PCR) data pont and the lne s mnmal (hence, leastsquare name). At the tme of arrval of the PCR packet, N consecutve samples of the transmtted clock (PCR) and the local clock (STC) values are beng collected. These (STC,PCR) data ponts are represented on a b-dmensonal space and ftted wth a straght lne. The slope of the straght lne represents the correcton factor to be used for 3

50 Fgure. LLR based Clock Recovery Method synchronzng the frequency of the recever clock wth the frequency of the transmtter clock. The LLR offers three sgnfcant advantages over other algorthms: It shows superor performance of jtter removal. It s not affected by the varable PCR samplng nterval and more robust than PLL based desgns n the presence of jtter. It provdes a better response tme than PLL based desgns. Inspte of above advantages, the man ssue of LLR wth respect to PLL based desgns s the relatvely heavy computatonal load on the CPU (Central Processng Unt). LLR uses several multplcatons and dvsons, often usng floatng pont arthmetc, due to the large ampltude values so t s better suted to systems wth hgh performance CPU. We can summarze that although ths technque and others based on least squares lnear regresson analyss generally perform consderably more effcent than conventonal 4

51 second-order PLLs, these technques have drawbacks of requrng large number of samples (thus a large storage requrement) n order to generate accurate tmng sgnals. Several other technques such as dejtterng buffer and tme stamp approach have been proposed n lterature for systems wth larger jtter. In frst technque a de-jtterng buffer s used at the recever to absorb the network ntroduced jtter. A dsadvantage of ths approach s that t requres a pror knowledge of the maxmum jtter n the network to avod an overflow or the underflow of the de-jtterng buffer. Also ths approach wastes memory by usng two separate buffers one system decoder buffer and the other the dejtterng buffer. Major ssue of sutable clock recovery n set-top box s due to the fact that n real tme sgnal processng audo/vdeo drvers consume most of processng space. If clock recovery nvolves more computaton tme, audo/vdeo decodng suffers. Hence, latency.e. tme taken by clock recovery algorthm to apply correcton n the decoder clock, acts as a bottleneck for the CPU to provde adequate tme for audo-vdeo decoder. Rangan et.al.(1996) proposed the dea of provdng a constant de-jtterng space n MPEG system decoder by combnng the two buffers. These technques use de-jtterng buffer to acheve clock recovery. Ths ntroduces more latency to ths process. Sngh et.al.(1994) proposed a scheme based on frst one, often denoted adaptve buffer, montors the fullness of the nput buffer and determnes the playout rate accordng to some low pass algorthm. If the buffer flls faster, local clock speed s ncreased and vce versa. The logc s benefcal n preventng any A/V gltches. However, f the local clock frequency s changed too frequently or above the maxmum frequency, due to overshoot lmted by the TV montor, color loss s obvous. 5

52 Parekh (1997) montor buffer level to mantan the A/V buffers towards 50% occupancy effectvely. But the jtter attenuaton n ths algorthm s not very hgh. The resdual jtter ampltude volates the (MPEG- RTI) specfcatons. Moreover, ths scheme s also possble to be used only n CBR vdeo traffc.e. f the stream runs at a constant bt rate. If the stream run at varable bt rate the buffer occupancy method would fal drastcally. Shen et.al.(004) proposed a new buffer measurement based packet network clock recovery algorthm for fast and accurate synchronzaton. Ths algorthm has the ablty to flter out buffer level fluctuaton effcently and removes the negatve contrbuton of delay jtter n clock recovery. Smulatons are performed for jtter dstrbuton based on a geometrc dstrbuton model developed by Bolot (Bolot, 1993). However ths jtter model practcally does not exst n today s real tme IP network. More real tme jtter dstrbuton models lke Pareto (Wessten-Pareto, 1999), Webull (Wessten-Webull, 1999) needs to be used for testng algorthm s capablty to handle real tme jttery envronment n IP transmsson. Based on second approach, Wellan and Akyldz (001), ntroduces a new source rate recovery scheme, called the jtter tme-stamp (JTS) approach. Each packet from the source carres ths tme stamp nformaton. Here n PCR-unaware approach, the sender does not check whether PCR values are contaned wthn a transport packet and may therefore ntroduce sgnfcant jtter to PCR values durng the encapsulaton, whch n turn may affect the perceved qualty of the vdeo sgnal. The scheme s provdng synchronzaton at asynchronous transfer mode (ATM) adapton layer (AAL). However t s not able to meet constrants of STB as possble applcaton. 6

53 Tryfonas and Verma, 1999 have suggested a desgn methodology n whch a constant amount of de-jtterng space s provded n the system decoder buffer by subtractng an offset from the ncomng PCR values. The jtter estmator performs restampng on all the ncomng packets contanng clock values s used n conjuncton wth standard PLL. The approach mnmzes the effect of the jtter on clock recovery by usng a jtter estmator to calculate the jtter on a per packet bass and re-stamp the ncomng packets based on the estmated jtter. Ths scheme can be used to correct both the source nduced and the network nduced jtter. The estmaton of jtter s the real challenge n ths technque. Further, jtter ntroduced due to the set-top box front-end s not taken nto account by ths algorthm. Probably approach used was desgned to work n ATM networks and was therefore not desgned to handle very hgh jtter ampltudes n IP- STB. Ramamoorthy, 1997 uses tmestamp nformaton for correcton to the decoder clock. Ths method s feasble for both VBR (Varable bt rate) and CBR (Constant bt rate) streams. However, there s a possblty of A/V gltches f effcent jtter reducton s not acheved due to buffer underflow or overflow. The smulaton technque dscussed here provdes clock synchronzaton usng sub-samplng. The algorthm was not tested by the author under actual set-top box envronment constrants. Author has dentfed the settop box as the possble applcaton but not practcally tested n ths envronment. The system constrants for the RTOS (Real-tme OS) nclude CPU tme usage and memory usage. Comparng wth above algorthms, t was found that complexty caused a bottleneck for mplementaton n RTOS envronment under the constrants dscussed above. The smulaton technque dscussed by (Ramamoorthy, 1997) lacks suffcent testng n real-tme DVB-IPTV envronment. 7

54 For handlng both CBR and VBR streams,varma(1996) dscusses that f maxmum jtter s known for the VBR stream, then analyss lke CBR stream may be carred out. But the stochastc nature of jtter n IPTV suggests fallacy n ths argument. Bjorn (000) deals effcently wth the problem of handlng delay varatons of MPEG- audo-vsual streams delvered over IP-based networks. Here, the focus s also on hgh qualty dgtal televson applcatons. A scheme to handle delay varatons (jtter) has been desgned and evaluated by smulatons. The results have been compared to the expected requrements of an MPEG- decoder and an ordnary consumer TV set. A smple channel model has been used to smulate the IP-based network, where the jtter process s unformly dstrbuted wth a peak-to-peak delay varaton of 100 ms. From smulatons t has been shown that t s possble to desgn a dejtterng scheme capable of flterng 100 ms of peak-to-peak IP-packet delay varaton, producng a resdual jtter ampltude n the order of a mcrosecond. Such a low jtter ampltude s obvously well below the MPEG- RTI specfcaton of ±5 µs. The scheme also matches the performance requrements that can be expected of a consumer TV set. It has also been shown that t s possble to combne an extreme low-pass flterng wth a suffcently small addtonal delay added by the dejtterng scheme. But proposed dejtterng scheme has only been tested n smulatons and some aspects have therefore been neglected, whch could cause problems n a real mplementaton. If the scheme s to be mplemented n a real system some further nvestgatons need to be made, especally concernng ssues around real tme support of common operatng systems. Mathur and Saha (007) proposed scalable nteger based error estmaton technque for clock recovery n packet swtchng networks. The proposed scheme requres only nteger level precson as compared to conventonal floatng pont precson. The 8

55 system shows stable clock recovery, however, the response tme for ths algorthm was too hgh for hgh jtter streams. The Broadcom patent (Fsher et. al.,007) dscusses the hardware module 7140 used to acheve clock recovery. No algorthm whch uses PCR tmestamps to modfy the system clock s explaned or clamed. Aweya et.al.,(007) uses a dfferental clock recovery algorthm for packet swtched network n general. It suggests good recovery n IP, MPLS and Ethernet. We use RTP protocol for STB. For our applcaton of IP-STB, the LLR algorthm s dfferent and much robust from above technques. Perkns and Lookabaugh (1998) smulatons for reducton of tmng jtter n audovdeo transport streams ndcate that for a total network jtter of msec peak-to-peak, the output steady-state peak-to-peak jtter can be reduced below a threshold amount. However n IP-STB jtter s much hgh. Baker (003) nventon provdes a method of measurng MPEG PCR jtter, frequency offset and drft rate wth a selectable, constant measurement bandwdth over non-unform PCR arrval tmes and a varable PCR rate. Su et.al.,(1999) also clam a apparatus for measurng program clock reference (PCR) jtter n a data stream, such as an MPEG- transport stream. The PCR jtter value may be dsplayed on a dsplay unt, preferably n a hstogram. Jtter s measured effectvely, however, n both nventons, handlng of jtter n IP network s not clamed. Osak (00) nventon clams an apparatus for reducng a jtter of a program clock reference of an MPEG sgnal transmtted over ATM (Asynchronous Transfer Mode) system. In our STB applcaton, due to major constrant of CPU bandwdth n Real 9

56 tme operatng system, a separate apparatus for reducng jtter can not be an approprate choce..3 LITERATURE SURVEY OF AUDIO-VIDEO SYNCHRONIZATION A/V sync ssues wthn the TV plant are not new to dgtal televson, they are perhaps more notceable. Dfferent amounts of delay n the sgnal processng n both the audo and vdeo channels mght occur ndependently from each other, whch requre the sgnals from the two channels to be re-algned. Lp-sync error occurs when the sound s heard earler than the movement of lps s seen. Lp-sync error has been observed and dscussed ntensvely n the lterature (Cooper, 008) and s the most common type of A/V sync error. Very tght AV sync requrements have been demanded by varous key customers n STB applcatons. Therefore the present secton focuses on survey of lterature for A/V sync. Younkn and Corrveau,(008) tres to determne the absolute detecton threshold of lp sync error. Ths specfc work s amed at lp-sync detecton n context of a sngle speaker. Much tghter constrants posed n applcaton of handlng dual vdeo (HD & SD) synchronzaton wth audo, are not handled here. Chanwoo et. al.,006; Km et. al.,005; Km and Seo,006; devsed algorthm qute sutable for consumer cellular phone wth lmted computatonal resources. Proposed algorthm s sutable for Vdeo-Telephony applcatons but ths can not handle constrants posed by dgtal TV. Bhattarcharya (006), explores four system-level desgn optons for PTS-based AV-synchronzaton mechansms where the AV playback chan spans more than one 30

57 processor. The frst of these extends a sngle clock doman over multple processors through hardware support. The second realzes PTS translaton across clock domans usng explct clock modelng. The thrd bundles AV effects processng nto an extended logcal renderer wth fxed delay and forces logcal presentaton at the decoder output. The fourth scheme constrans the streamng playback chan onto a sngle processor to elmnate cross-processor synchronzaton ssues. However, out of above four, no partcular desgn paradgm fts nto overall system desgn of SoC of set-top box decoder chp. Chen et.al.(1995) has proposed a novel audo/vdeo synchronzaton model. Based on t, a powerful multmeda authorng system was mplemented. Ths system provdes a frendly and functonally complete envronment for users to conduct ther A/V edtng operatons. In our applcaton, rather edtng, dual vdeo sync wth audo s much more mportant. Yuong and Ouhyoung(1993) have proposed an A/V Synchronzaton scheme based on the dea of algnng the physcal locaton of A/V data storage. However, the above method suffers from naccurate estmaton of meda loadng tme n Real Tme Operatng System (RTOS) envronment n STB..4 RESEARCH GAPS IDENTIFIED IN EXISTING CLOCK RECOVERY ALGORITHMS In provdng the smooth audo-vdeo vewng usng Satellte, Terrestral and IP Set-Top Box, the effcent handlng of jtter n above envronments s very much essental and crtcal. Detaled analyss of the exstng algorthms mplementatons for clock 31

58 recovery and Audo-vdeo synchronzaton n varous envronments has been carred out. In vew of the lterature survey above, followng research gaps are dentfed: A lght weght, low cost, fast algorthm s needed for low jttery Satellte and medum jttery Terrestral envronment whch can handle all constrants of real tme STB wthout consumng much CPU bandwdth. The PLL based desgns are not sutable for IP clock recovery as large jtter experenced n IP networks. Effcent flters wll have a slower response tme, results n the relatve clock frequences drft further apart. Dgtal flters are based on the assumpton that the nput varable has a fxed samplng rate, whch s not true for MPEG TS streams. Although LLR based clock synchronzaton method has several advantages and provdes better response tme compared to PLL based desgn but due to relatvely heavy computatonal load placed on the CPU (Central Processng Unt), t s better suted to systems wth hgh performance CPU. De-jtterng buffer technque suggested by varous researchers ntroduces more latency to the clock recovery process. Ths s not acceptable for Real tme STB where tme needed by audo-vdeo decoder for smooth operaton s very much crtcal. In vew of the above, t would be desrable to provde a technque for synchronzng a recever clock wth a transmtter clock that overcomes the above descrbed nadequaces and shortcomngs. The present research work ams at applyng PLL based desgn for Satellte and Terrestral envronment where jtter s less. For IP 3

59 applcatons certan practcal problems n exstng mplementaton of the LLR algorthm have been dentfed. In most of exstng approaches addtonal de-jtterng buffer s needed to store the sample set of ncomng PCR, STC values whch s beng elmnated n ths thess. The major contrbuton n ths thess s to apply enhancements n old LLR algorthm mplementaton so that LLR performance n IP applcaton can be mproved sgnfcantly..5 RESEARCH GAPS IDENTIFIED IN EXISTING AV SYNC IMPLEMENTATIONS Advance data compresson technologes such as Dolby Dgtal (AC3) for audo and MPEG- for vdeo provde vewers hgh qualty multmeda experence wth the help of STB. Lp-sync problem can be observed f AV synchronzaton specfcatons are not properly met. Smultaneous synchronzaton of audo wth HD (Hgh Defnton) and SD (Standard Defnton) output mpose very tght constrants. In vew of the lterature survey above, followng man research gaps are dentfed. Varous models for correct AV Sync mplementaton has been suggested by researchers n the smlar feld. However, none of them addresses the AV Sync problem of dual vdeo (HD & SD smultaneously) wth audo. Research work done so far have not consdered set-top box as possble applcaton for ther mplementaton so such models are not sutable for Real Tme set top box applcaton. In ths chapter, the varous technques and methodologes for clock recovery and AV synchronzaton have been explored rgorously. Most of the exstng algorthms for 33

60 clock synchronzaton n Satellte, Terrestral and IP network have been dscussed. Varous AV sync approaches suggested by varous researchers n the smlar felds have been dscussed. Ths chapter has provded a sold background and good summary of work done n ths feld. 34

61 Chapter 3: MPEG Standard The lst of systems use MPEG standard s extensve and contnuously growng. Some of them are dgtal TV (cable, satellte and terrestral broadcast), Vdeo on Demand (VOD), Dgtal Versatle Dsc (DVD), personal computng, MPEG test and measurement, nteractve TV, etc. In ths chapter popular MPEG standard has been presented. 3.1 INTRODUCTION MPEG (Moton Pctures Expert Group) s an encodng and compresson system whch defnes a seres of standards for compresson of movng pcture nformaton. The MPEG was establshed n January 1988 wth the mandate to develop standards for coded representaton of movng pctures, audo, and ther combnaton. Fgure 3.1, shows how MPEG systems have evolved over tme. Ths dagram shows that MPEG-1 standard developed n 1991 offered VHS qualty at 1. Mbps, prmarly used to record audo vdeo n CD ROMs. Ths standard was updated n 1995 and became MPEG- whch was used for satellte, terrestral, and cable dgtal televson along wth DVD dstrbuton. The MPEG specfcaton then evolved nto MPEG-4 n 1999 to permt multmeda dstrbuton Fgure 3.1 Evoluton of MPEG 35

62 through the Internet. The work contnues wth MPEG-7 for object based multmeda and MPEG-1 for dgtal rghts management. Dfferent types of MPEG Standards are mentoned below: MPEG-1, A standard for storage and retreval of movng pctures and audo on storage meda e.g. CDROM. It s for medum bandwdth (upto 1.5 Mbts/sec) MPEG-, A standard for dgtal televson. It s for hgher bandwdth. It can deal wth wder range of frame szes (ncludng HDTV) MPEG-3, A standard was developed for HDTV applcaton wth dmensons up to 190 x 1080 x 30 Hz, however MPEG- and MPEG- syntax worked very well for HDTV rate vdeo so MPEG-3 was dscarded. MPEG-4, a standard for multmeda applcatons. It s for very low bandwdth (64Kbts/sec). It s optmzed for vdeophones. MPEG-7, a content representaton standard for nformaton search. MPEG-1, a standard for Dgtal Rghts Management. MPEG-1, MPEG- and MPEG-4 have been standardzed, whereas MPEG-7 and MPEG-1 are currently beng developed. The MPEG- standard has been extended by varous groups ncludng: MPEG-1, a standard for Dgtal Rghts Management. Dgtal Vdeo Broadcastng (European) The UK Dgtal TV Group U.S. Advanced Televsons Systems Commttee (ATSC) Dgtal Audo Vsual Councl (DAVIC) 36

63 Dgtal Versatle Dsk (DVD) The synchronzaton aspects that are found at the applcaton level are mostly related to audo-vsual servces. In ths area, the applcatons based on the Movng Pcture Expert Group standards MPEG- play a major role (MPEG, ; MPEG,13818-; MPEG, ).The famly of MPEG- standards defnes the rules for codng, storng, multplexng and transmttng dgtal audo and vdeo sgnals. In the case of streamed audo and vdeo, MPEG- s ntentonally made ndependent from the network technology that s employed to provde the communcaton faclty. The synchronzaton schemes defned for other audovsual applcatons, such as MPEG-1, MPEG-4, H.61- and H.63-based vdeoconference systems (MPEG ; MPEG ; MPEG ; H.61,1993; H.63,1998) have n general smlar features than those defned for MPEG-. In ths chapter we restrct our attenton to the case of MPEG-. 3. MPEG STANDARD OVERVIEW MPEG- s wdely used as the format of dgtal televson sgnals that are broadcasted by terrestral (over-the-ar), cable, and drect broadcast satellte TV systems. As such, TV statons, TV recevers, DVD players, and other equpment are often desgned to ths standard. MPEG- was the second of several standards developed by the MPEG and s an nternatonal standard ISO/IEC Parts 1 and of MPEG- were developed n a jont collaboratve team wth ITU-T, and they have a respectve catalog number n the ITU-T Recommendaton Seres. The MPEG- standard s dvded nto two man layers: Compresson layer (ncludes audo and vdeo streams) 37

64 Systems layer (ncludng tmng nformaton to synchronze vdeo and audo as well as multplexng mechansms) Thus MPEG- extends the basc MPEG system to provde compresson support for TV qualty transmsson of dgtal vdeo. To understand why vdeo compresson s so mportant, one has to consder the vast bandwdth requred to transmt uncompressed dgtal TV pctures. Phase Alternate Lne (PAL) s the analogue color TV transmsson standard used n the Europe, and throughout many parts of the world. An uncompressed dgtal PAL TV pcture requres a massve 16 Mbps data rate, far beyond the capacty of most rado frequency lnks. The U.S. uses an analogue TV system based on NTSC standard. Ths system provdes less precse color nformaton, and a dfferent frame rate. An uncompressed dgtal NTSC TV sgnal requres slghtly less data rate at 168 Mbps. The stuaton becomes much more acute, when one realzes the hgh defnton TV (HDTV) whch s around the corner. Now-a-days a Hgh Defnton TV pcture requres data rate exceedng 1 Gbps (1000 Mbps). MPEG- provdes a way to compress ths dgtal vdeo sgnal to a manageable bt rate. The compresson capablty of MPEG- vdeo compresson s shown n the Fgure 3.. Snce MPEG- standard exhbts good compresson usng standard algorthms, t has become the standard for dgtal TV. It has the followng features: MPEG- Vdeo compresson s backwards compatble wth MPEG-1 Full-screen nterlaced and/or progressve vdeo (for TV and Computer dsplays) Enhanced audo codng (hgh qualty, mono, stereo, and other audo features) Transport multplexng (combnng dfferent MPEG streams n a sngle transmsson stream) 38

65 Fgure 3. Summary of MPEG Compresson Capablty 3.3 PARTS OF MPEG STANDARD MPEG- s a standard currently n 9 parts. The frst three parts of MPEG- have reached Internatonal Standard status; other parts are at dfferent levels of completon. One has been wthdrawn. ISO/IEC :000 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton: Systems (avalable n Englsh only) Part 1: Systems specfes the system codng layer of the MPEG-. It defnes a multplexed structure for combnng audo and vdeo data and means of representaton the tmng nformaton needed to replay synchronzed sequences n real tme of MPEG-. Ths s specfed n two forms: the Program Stream and the Transport Stream. Each s optmzed for a dfferent set of applcatons. ISO/IEC :000 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton: Part : Vdeo (avalable n Englsh only) Part specfes set of rules for encodng and compresson of vdeo. 39

66 ISO/IEC :1998 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 3: Audo (avalable n Englsh only) Part 3 specfes set of rules for encodng and compresson of audo. ISO/IEC :1998 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 4: Conformance testng (avalable n Englsh only) ISO/IEC TR :1997 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 5: Software smulaton (avalable n Englsh only) ISO/IEC :1998 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 6: Extensons for DSM-CC (Dgtal Storage Meda Command and Control). It s the specfcaton of a set of protocols whch provdes the control functons and operatons specfc to managng MPEG-1 and MPEG- btstreams. ISO/IEC :1997 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 7: Advanced Audo Codng (AAC) (avalable n Englsh only) Part 8 of MPEG- was orgnally planned for codng of vdeo when nput samples are 10 bts. Work on ths part was dscontnued when t became apparent that there was nsuffcent nterest from ndustry for such a standard. ISO/IEC :1996 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 9: Extenson for real tme nterface for systems decoders (avalable n Englsh only) 40

67 ISO/IEC :1999 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 10: Conformance extensons for Dgtal Storage Meda Command and Control (DSM-CC) (avalable n Englsh only) MPEG-System s formally known as ISO/IEC and as ITU-T Rec. H..0. The vdeo and audo data s encoded as descrbed n ITU-T Rec. H.6 ISO/IEC and ISO/IEC MPEG- System layer (Part-1) contans tmng and synchronzaton nformaton to allow the MPEG player to multplex the audo and vdeo portons of the meda fle so that they are synchronzed durng playback. Because our man objectve n ths thess s to acheve clock synchronzaton for dgtal set-top box hence MPEG- System layer has been understood and descrbed n further secton n detal. 3.4 MPEG SYSTEM LAYER It s a communcaton layer encapsulatng compressed vdeo, audo and data streams n packets. It multplexes elements of a sngle program: vdeo, audo, program related data. Ths layer deals wth multplexng of multple programs. It synchronzes all elements of a program and provdes flexblty by allowng dynamc mx of content. A program perhaps most easly thought of as a televson program, or a Dgtal Versatle Dsk (DVD) track contans a combnaton of elementary streams (typcally one for vdeo, one or more for audo, control data, subttles, etc). To understand how the component parts of the bt stream are multplexed, we need to frst look at each component part. The most basc component s known as an 41

68 Elementary Stream (ES). The Fgure 3.3 shows that multple types of sgnals are dgtzed and converted nto ES sutable for the MPEG packetzers.e. a MPEG channel that ncludes vdeo, audo, and user data for a televson message. It also shows that each meda source s packetzed and sent to a multplexer that combnes the channels nto a sngle Transport/Program stream. The multplexer also combnes Program Specfc Informaton (PSI) that descrbes the content and format of the meda channels. The multplexer uses a clock to tme stamp the MPEG nformaton to allow t to be separated and recreated n the correct tme sequence at recever sde. In next subsectons all components of MPEG- System layer s descrbed. Fgure 3.3 Formaton of MPEG Stream 4

69 3.4.1 Elementary Stream (ES) ES s an MPEG audo, vdeo and data encoder output. ES contans a sngle type of (usually compressed) sgnal. There are varous forms of ES ncludng: Dgtal Control Data Dgtal Audo (sampled and compressed) Dgtal Vdeo (sampled and compressed) Dgtal Data (synchronous, or asynchronous) For vdeo and audo, the data s organzed nto access unts, each representng a fundamental unt of encodng. For example, n vdeo, an access unt wll usually be a complete encoded vdeo frame Packetzed Elementary Stream (PES) Each endless Elementary Stream (ES) s nput to an MPEG- packetzer whch dvdes the ES nto streams of convenent sze packets (64 Kbytes). Ths stream s known as Packetzed Elementary Stream (PES). A PES packet may be a fxed (or varable) szed block, wth up to bytes per block whch ncludes a 6 byte protocol header also. A PES s usually organzed to contan an ntegral number of ES access unts. PES packet schematc s shown n Fgure 3.4. Fgure 3.4 PES Packet Schematc 43

70 It s shown n Fgure 3.4, that PES header starts wth a 3 byte start code, followed by a one byte stream ID and a byte length feld. Varous bts of PES header are dscussed below: () The packet_start_code_prefx s a 4-bt code. Together wth the stream_d t consttutes a packet start code that dentfes the begnnng of a packet. The packet_start_code_prefx s the bt strng ' ' (0x000001). The followng well-known stream IDs are defned n the MPEG standard: x xxxx - MPEG- audo stream number x xxxx yyyy - MPEG- vdeo stream number yyyy MPEG- DSM-CC control packets. () The next feld contans the PES Indcators. These provde addtonal nformaton about the stream to assst the decoder at the recever. These ndcators are defned as: PES_Scramblng_Control, PES_Prorty, Data_Algnment_Indcators, Copyrght Informaton, Orgnal_or_Copy, Presentaton Tme Stamp (PTS), Decode Tme Stamp(DTS), Elementary Stream Clock Reference (ESCR), Elementary Stream Rate, Trck Mode, CRC, PES Extenson Informaton 44

71 Fgure 3.5 Detaled structure of PES Packet PES_Scramblng_Control - Defnes whether scramblng s used, and the chosen scramblng method. The bt PES Scramblng Control feld ndcates the scramblng mode of the PES packet payload. When scramblng s performed at the PES level, the PES packet header shall not be scrambled. Table 3.1 PES Scramblng Control Value Descrpton 00 Not scrambled 01 User defned 10 User defned 11 User defned 45

72 PES_Prorty It s 1-bt feld. A 1 ndcates a hgher prorty of the current PES payload. A multpler can use PES_Prorty bt to prortze ts data wthn an ES. Ths feld shall not be changed by TS mechansm. Data_algnment_ndcator - f set to 1 ndcates that the PES packet header s mmedately followed by the vdeo or audo start code Copyrght nformaton If t s =1, ndcates that the payload s copyrght protected. Orgnal_or_copy - If t s =1, ndcates ths s the orgnal ES. If t =0,.e. contents of assocated PES payload s a copy. A one byte flag feld completes the PES header. Ths defnes the followng optonal felds, whch f present, are nserted before the start of the PES payload. Tme Stamps Presentaton Tme Stamp (PTS) and Decode Tme Stamp (DTS) ndcate exact tme to decode or present audo or vdeo.e. these tme stamps are used to synchronze a set of elementary streams and control the rate at whch they are replayed by the recever. Elementary Stream Clock Reference (ESCR) It provdes elementary stream clock reference. Elementary Stream rate - If t s =1, ESCR base and extenson feld are present n PES packet header. Trck Mode It s 3-bt feld. It ndcates the vdeo/audo s not the normal ES. Copyrght Informaton - set to 1 to ndcate a copyrght protected ES. CRC The Cyclc Redundany Check to verfy the correctness of data 46

73 PES Extenson Flag A 1 -bt flag. If t s 1, ndcates that an extenson feld exst n PES packet header. It may be used to support MPEG-1 streams. The PES packet payload ncludes the ES data. The nformaton n the PES header s, n general, ndependent of the transmsson method used. Two optons are possble for nsertng PES data nto the TS packet payload: 1. The smplest opton, from both the encoder and decoder vewponts, s to send only one PES (or a part of sngle PES) n a TS packet. Ths allows the TS packet header to ndcate the start of the PES, but snce a PES packet may have an arbtrary length, also requres the remander of the TS packet to be padded, ensurng correct algnment of the next PES to the start of a TS packet. In MPEG- the paddng value s the hexadecmal byte 0xFF.. In general a gven PES packet spans several TS packets so that the majorty of TS packets contan contnuaton data n ther payloads. When a PES packet starts, the payload_unt_start_ndcator bt s set to 1 whch means the frst byte of the TS payload contans the frst byte of the PES packet header. Only one PES packet can start n any sngle TS packet. The TS header also contans the PID so that the recever can accept or reject PES packets at a hgh level wthout burdenng the recever wth too much processng. Ths has an mpact on short PES packets. 3.5 MPEG- MULTIPLEXING The MPEG- standard allows two forms of multplexng: MPEG Program Stream (PS) A group of tghtly coupled PES packets referenced to the same tme base. Such streams are suted for transmsson n a 47

74 relatvely error-free envronment and enable easy software processng of the receved data. The PS s wdely used n dgtal vdeo storage devces, and also where the vdeo s relably transmtted over a network (e.g. vdeo-clp down load). Thus PS has followng characterstcs: o o o o combne one or more PES wth a common tme base nto a sngle stream desgned for error free envronments packets of varable length works well on a sngle program wth varable bt-rate n recordng envronment (used n DVD) MPEG Transport Stream (TS) Each PES packet s broken nto fxed-szed transport packets formng a general purpose way of combnng one or more streams. TS format s desgned to carry dgtal vdeo and audo over possbly lossy meda, such as broadcastng, examples of whch nclude ATSC and DVB. Ths s suted for transmsson n whch there may be potental packet loss or corrupton by nose, or/and where there s a need to send more than one program at a tme. Dgtal Vdeo Broadcast (DVB) uses the MPEG- Transport Stream over a wde varety of under-lyng networks. Thus TS has followng characterstcs: o combne one or more PES wth one or more ndependent tme bases nto a sngle stream (sometmes called multplex) Frst byte of the PES packet must be the frst byte of the Transport packet Each transport packet must contan data from only one PES packet o desgned for envronments where errors are lkely to occur 48

75 o packets are 188 bytes n length o works well on multple programs n a fxed bt-rate transmsson envronment Fgure 3.6 Functonal Block dagram of Standard MPEG Note: Snce both the Program Stream and Transport Stream multplex a set of PES nputs, nteroperablty between the two formats may be acheved at the PES level. Snce n Settop box, TS format s used hence TS syntax has been provded n detal n secton MPEG Transport Stream The Transport Stream s a stream defnton whch s talored for communcatng or storng one or more programs of coded data accordng to ITU-T Rec. H.6 ISO/IEC and ISO/IEC and other data n envronments n whch sgnfcant errors may occur. Such errors may be manfested as bt value errors or loss of packets. The format of the transport stream s descrbed usng the Fgure 3.7. Ths Fgure shows two elementary streams sent n the same MPEG- transport stream. Each packet s assocated 49

76 wth a PES through the settng of the PID value n the packet header (the values of 64 and 51 n the fgure). The audo packets have been assgned PID 64, and the vdeo packets PID 51 (these are arbtrary, but dfferent values). As s usual, there are more vdeo packets than audo packets, but t can be observed that two types of packets are not evenly spaced n tme. The MPEG-TS s not a tme dvson multplex, packets wth any PID may be nserted nto the TS at any tme by the TS multplexer. If no packets are avalable at the multplexer, t nserts null packets (denoted by a PID value of 0x1FFF) to retan the specfed TS bt rate. The multplexer also does not synchronze the two PESs, ndeed the encodng and decodng delay for each PES may be dfferent. A separate process s therefore requres to synchronze the two streams (see below). Fgure 3.7 MPEG Transport Stream The syntax of transport stream s shown n Fgure 3.8. It conssts of a sequence of fxed szed transport packet of 188 bytes. Each packet comprses 184 byte payload and 4 byte header. One bt n ths 4 byte header s 13 bt Packet Identfer (PID) whch plays a key role n the operaton of the TS. The header (4 Byte) has the followng felds: The header starts wth a well-known Synchronzaton Byte (8 bts). Ths has the bt pattern 0x47 ( ). A set of three flag bts are used to ndcate how the payload should be processed. 1. The frst flag ndcates a transport error. 50

77 . The second flag ndcates the start of a payload (payload_unt_start_ndcator) 3. The thrd flag ndcates transport prorty bt. The flags are followed by a 13 bt Packet Identfer (PID).Ths s used to unquely dentfy the stream to whch the packet belongs (e.g. PES packets correspondng to an ES) generated by the multplexer. The PID allows the recever to dfferentate the stream to whch each receved packet belongs. Some PID values are predefned and are used to ndcate varous streams of control nformaton. A packet wth an unknown PID, or one wth a PID whch s not requred by the recever, s slently dscarded. The partcular PID value of 0x1FFF s reserved to ndcate that the packet s a null packet (and s to be gnored by the recever). The two scramblng control bts are used by condtonal access procedures to encrypt the payload of some TS packets. Two adapton feld control bts whch may take four values: a) 01 no adaptaton feld, payload only b) 10 adaptaton feld only, no payload c) 11 adaptaton feld followed by payload d) 00 - RESERVED for future use there s a half byte Contnuty_counter (4 bts) : ncrements wth each TS packet wth same PID : a) Wraps to 0 after max value b) Not ncremented when adaptaton_feld_control s 00 or 01 c) Used to fnd packet loss 51

78 There may be Optonal Transport Packet Adapton Feld. The presence of an adaptaton feld s ndcated by the adapton feld control bts n a transport stream packet. If present, the adapton feld drectly follows the 4 byte packet header before any user payload data. It may contan a varety of data used for tmng and control. Fgure 3.8 Detaled Syntax of Transport stream One mportant tem n most adapton packets s the Program Clock Reference (PCR) feld. Ths carres the Encoder clock tme stamps. Another mportant tem s splce_countdown feld. Ths feld s used to ndcate the end of a seres of ES access unts. It allows the MPEG- TS multplexer to determne approprate places n a stream where the vdeo may be splced to another vdeo source wthout ntroducng undesrable dsrupton to the vdeo replayed by the recever. Snce MPEG- vdeo uses nter-frame codng a seamless swtch-over between sources can only occur on an I-frame boundary (ndcated by a splce count of 0). Ths feature may, for nstance be used to nsert a news flash n a scheduled TV transmsson. 5

79 One other bt of nterest here s the transport_prvate_data_flag whch s set to 1 when the adaptaton feld contans prvate data bytes. Another s the transport_prvate_data_length feld whch specfes how many prvate data bytes wll follow the feld. Prvate data s not allowed to ncrease the adaptaton feld beyond the TS payload sze of 184 bytes. Dfferent payload types n a TS packet are shown n Fgure 3.9. Fgure 3.9 Three types of TS Packets Transport stream has a concept of programs, whch are groups of one or more PIDs that are related to each other. For nstance, a transport stream used n dgtal televson mght contan three programs, to represent three televson channels. Suppose each channel conssts of one vdeo stream, one or two audo streams, and any necessary metadata. A recever wshng to tune to a partcular "channel" merely has to decode the payload of the PID s assocated wth ts program. It can dscard the contents of all other PID s after the adaptaton feld, n the TS packet. The payload can be ether PES or secton feld contanng PSI (Program specfc Informaton) tables. Secton feld contan nformaton about program number, scramblng control, network parameters etc. In TS each transport packet s tagged wth an approprate Packet ID (PID) value ndcatng to whch ES ts payload belongs. There can be many ES comprsng many dfferent programs. Addtonal nformaton requred for decoder s called PSI and s present n every TS. The PSI tables n MPEG- consst of a descrpton of the elementary streams 53

80 whch need to be combned to buld programs, and a descrpton of the programs. Fgure 3.10 and Fgure 3.11 shows structure of PSI tables. Each PSI table s carred n a sequence of PSI Sectons, whch may be of varable length (but are usually small). Each secton s protected by a CRC (checksum) to verfy the ntegrty of the table beng carred. The length of a secton allows a decoder to dentfy the next secton n a packet. A PSI secton may also be used for down-loadng data to a remote ste. Tables are sent perodcally by ncludng them n the transmtted transport multplex Table 3. PSI Tables Table Name PID # Descrpton Program Assocaton 0 Assocate Program number wth PMT able (PAT) Program Map Table(PMT) Assgned Assocate PID s wth Programs Network Informaton Table(NIT) Assgned Contans physcal network parameters Condtonal Access 1 Assocate PID s wth prvate stream Table(CAT) Program Assocaton Table: The PAT lsts the PIDs of tables descrbng each program. The PAT s sent wth the well-known PID = 0. It provdes the correspondence between a program_number and the PID value of the transport stream packets whch carry the program defnton. The program_number s the numerc label assocated wth a program. 54

81 Table 3.3 Example of PAT for Three Program Multplex Program PMT PID Meanng 3 PID 3 contans map for program 3 48 PID 48 contans map for program PID 64 contans map for program 4 PAT provdes correspondence between a Program number and the PMT PID that carres program defnton. Program # s smlar to Channel # n broadcast TV. PAT always assgned as PID 0 Program Map Table: The PMT provdes the mappngs between program numbers and the program elements that comprse them.e. defnes the set of PIDs assocated wth a programe, e.g. audo, vdeo, auxlary data and PCR etc. Table 3.4 Example PMT for Program PID Stream Type 3 PMT 33 Vdeo & PCR 36 Audo 4 Data 55

82 PMT provdes correspondence between a Program number and the elementary streams that comprse t. Descrptors may be sent to provde more nformaton about the program and/or program elements. PMT stream type descrbes the elementary stream e.g. MPEG-1 Vdeo, MPEG- Vdeo, MPEG-1 Audo, MPEG- Audo, Prvate Sectons, PES Prvate Data, DSM-CC, User Prvate data (e.g., AC-3 Audo)etc. Network Informaton Table: NIT s optonal and ts contents are prvate. If t s present, t s represented by Program 0 n PAT. It contans physcal network parameters such as RF frequences, Satellte Transponder Numbers, etc. Condtonal access Table: The CAT s sent wth the well-known PID = 1 and must be present f a stream s scrambled. Ths table defnes type of scramblng used and PID values of transport streams whch contan the condtonal access management (ECM) and enttlement management nformaton (EMM)). Table 3.5 Example CAT of Program CA System CA PID CAT provdes correspondence between CA systems and ther Enttlement Management Message (EMM) streams. EMM s are system-wde prvate streams that specfy authorzaton levels of specfc decoders. Prvate Tables: These are provded for transmsson of prvate data. It can be used for sendng non-mpeg data, such as stock quotes, downloadable software modules, etc. 56

83 Fgure 3.10 Example of PSI Tables Event Informaton Table (EIT): Contans nformaton about present, followng and future events. Fgure 3.11 PSI Table Structures 57

84 To dentfy the requred PID to de-multplex a partcular PES, the user searches for a descrpton n a partcular table, the Program Assocaton Table (PAT). Ths lsts all programs n the multplex. Each program s assocated wth a set of PIDs (one for each PES) whch correspond to a Program Map Table (PMT) carred as a separate PSI secton. There s one PMT per program. PAT/PMT form a Mn Program Gude and certan nformaton n those tables and n PSIP (Program specfc nformaton protocol) must be consstent. As MPEG s bass n dealng wth dgtal set-top box. Thus n ths chapter, MPEG standard has been presented n detal. Ths chapter has provded a sold background to work on clock recovery. In next chapter, Set-top box system s presented. 58

85 Chapter 4: Set-Top Box Subsystem The research work n ths thess s manly amed at clock recovery and clock synchronzaton for varous broadcastng envronments for dgtal set-top box, hence settop box (STB) system and varous components assocated wth t has been descrbed n ths chapter. Bref descrpton and functonng of a latest STB decoder chp has been explaned to understand the capablty of STB. 4.1 INTRODUCTION A set-top box s a devce that connects to a televson and an external source of RF sgnal, turnng the sgnal nto content whch s dsplayed on the televson screen. Today, t offers more than the basc defnton of set-top box lke nteractve vewng, subttles n varous languages, cable modem etc. Set-top box s equvalent to a computer that process dgtal nformaton. These typcally have on-screen user nterfaces that can be seen on the TV screen and nteracted wth through the use of an hand-held nteractve keypad, whch s lttle more than an advanced remote control. Set-Top Box also has facltes for upgradng software such as browsers and Electronc Program Gudes (EPGs). Some have huge hard-drves and smart card slots to put your smart card nto t for purchases and dentfyng yourself to your cable, satellte TV provder. Many set-top boxes are able to communcate n real tme wth devces such as camcorders, DVDs, CD players, musc keyboards, vdeo-conferencng, sendng e-mal and cable telephony etc. Set-top Boxes act as a gateway between televson or PC or PC-TV and telephone, satellte or cable feed (ncomng sgnal.) In terms of ITV, the STB receves encoded and/or compressed dgtal sgnals from the sgnal source (satellte, TV staton, cable 59

86 network, etc.) and decodes (and/or decompresses) those sgnals, convertng them nto analog sgnals dsplayable on your televson. Thus a set-top box, or STB, refers to any devce nserted between the cable or satellte feed and the user's televson set. These devces have the capablty to select and dsplay ndvdual channels. Satellte televson today follows the MPEG- dgtal-compresson standard, whch s the bass of both the Dgtal Vdeo Broadcast standard (DVB) and the Advanced Televson Systems Commttee (ATSC) standard. Most U.S. cable provders have ether adopted the MPEG- standard or are n the process of upgradng ther servces from analog to dgtal n order to do so. MPEG- allows the delvery of any nformaton that can be dgtzed, ncludng audo, vdeo and text. MPEG- stream can be easly dsplayed on dgtal Hgh Defnton televson sets, or n analog NTSC, PAL or SECAM formats wth help of set-top box. Thus t s possble to get dgtal qualty pctures and lots of flexblty due to powerful settop box. The STB s a combnaton of hardware and software modules for audo-vdeo decodng, tunng, encrypton etc. as dscussed n further sectons. 4. SET-TOP BOX COMPONENTS To provde nteractve servces, the Set-top Box, from the standpont of ts hardware, needs four mportant components: a network, an nterface, a buffer, as well as decoder/synchronzaton hardware The Network Interface Allows the user to receve data from the server and send data back to the server, n a manner that the server can understand t. 60

87 4.. The Decoder In order to save storage space, dsk bandwdth, and network bandwdth, moves are usually encoded (compressed) before they are sent over the network. Thus, the endusers need a decoder to decode (decompress) the ncomng stream's data before t's vewable The Buffer Due to delay jtters n the network, the arrval tme of a vdeo stream cannot be determned exactly. In order to guarantee contnuous consstent playback for the vewer (end-user/subscrber) the stream s often receved one or even a few seconds before t's actually seen by the end-user. Ths way f there are fluctuatons (even those measured n mllseconds) n the transport tme of the vdeo stream to that recever, the vewer won't know the dfference as ther buffer has a bt of tme to spare Synchronzaton Hardware Dgtal TV sgnal conssts of both vdeo and audo streams. They must be synchronzed wth each other before beng vewed. In smple words t s a knd of a computer that translates dgtal sgnals nto a format that can be vewed on a televson screen. Today dgtal TV usually requres a STB, whch s used to decode and tune dgtal sgnals and converts them to a format that s understood by analog TV. In a STB, the tuner receves a RF sgnal from a cable, satellte or terrestral network and tunes to a partcular channel. Set-top Boxes are beng desgned to be ntegrated wth game consoles, DVDs, vdeophones, telephones and televsons. Ideally Set-top Boxes should have as much 61

88 nteroperablty as possble. Interoperablty refers to the characterstcs of a Set-top Box that allow t to operate on equpment made by dfferent manufacturers. 4.3 SET-TOP BOX FUNCTION Majorty of the functons are as below- Decodes the ncomng dgtal sgnal Verfes access rghts and securty levels Dsplays studo-qualty pctures on TV set The STB s comprsed of front-end and back-end modules as shown n Fgure 4.1. The vertcal lne demarcates the front-end and back-end. Front-end comprses of a tuner, FEC and dgtal demodulator, Back-end comprses of transport stream (TS) demultplexer, A/V decoder, dgtal vdeo encoder, audo DAC and CPU along wth onste memory. Major blocks functons are as below- Tuner receves a RF sgnal from a cable/satellte or terrestral network. The dgtal demodulator demodulates nto the dgtal format, checks for errors & forwards t to the de-multplexer. De-multplexer extracts the audo, vdeo and data from the dgtal stream and sends t to the approprate decodng blocks. Thus front-end s responsble of translatng RF sgnal nto a dgtally demodulated error corrected TS (Transport Stream). 6

89 Fgure 4.1 Schematc of Dgtal Set-Top Box The demodulaton technques used for dfferent broadcast meda are: QPSK for satellte transmsson OFDM for Terrestral transmsson QAM for Cable transmsson Dgtal demodulator along wth tuner s called Network Interface Module (NIM). NIM s controlled usng I C bus to select requred channel, convert nto ntermedate frequency and fed to demodulator. After demodulaton, the back-end module demultplexes, descrambles and processes the raw TS data comng from the front-end to be used by audo-vdeo decoders. TS demultplexer extracts audo, vdeo and clock and sends to A/V decoder and smart card. Smart card determnes access rghts to varous dgtal servces. A/V decoder decompresses audo, vdeo data whch are fed to DAC and vdeo encoder to dsplay on TV recever. Thus dgtal A/V sgnal s converted to analog format for SD vewng or to sutable dgtal stream for HD vewng, dependng on the SoC used and features supported by t. 63

90 4.4 FUNCTIONING OF STX7109 HDTV SET-TOP BOX DECODER CHIP The STx7109 s desgned around the well-proven Omega (STBus) nterconnect and presents a new generaton of HD vdeo decoders for VC1 Mcrosoft vdeo (ncludng Wndows Meda vdeo 9, WMV-9) as well as H.64 (MPEG-4 part 10) and MPEG- hgh-defnton (HD) decodng. Ths SoC(system-on-chp) (STB-7109) s a full back-end processor for dgtal terrestral, satellte, cable, DSL (Dgtal Subscrber Lne) and IP clent hgh-defnton set-top boxes. It also ncludes all processng for DVD applcatons. Dfferent applcatons by usng ths chp are presented n appendx-i. The STx7109 ntegrates a Wn CE compatble 66 MHz ST40-0 processor core that features a 3-bt superscalar RISC CPU and IEEE-754 complant floatng pont unt (FPU). The ST40-0 ncludes -way set-assocatve caches, 16 Kbytes of nstructon cache and 3 Kbytes of data cache, as well as core support perpherals such as a real-tme clock and nterrupt controller. The STx7109 demultplexes decrypts and decodes HD or SD (Standard Defnton) vdeo streams wth assocated mult channel audo. Vdeo s output to two ndependently formatted dsplays: a full resoluton dsplay ntended for a TV montor, and a down sampled dsplay ntended for a VCR or DVD-R. Connecton to a TV or dsplay panel can be analog through the DACs, or dgtal through a copy protected DVI/HDMI (Dgtal Vdeo Interface/Hgh Defnton Memory Interface). Composte outputs are provded for connecton to the VCR wth macro vson protecton. Audo s output wth optonal PCM mxng to an S/PDIF nterface, PCM nterface, or through ntegrated stereo audo DACs. Dgtzed analog programs can also be nput to the STx7109 for reformattng and dsplay. The STx7109 ncludes a graphcs renderng and dsplay 64

91 capablty wth a D graphcs accelerator, two graphcs planes and a cursor plane. A dual dsplay compostor provdes mxng of graphcs and vdeo wth ndependent composton for each of the TV and VCR/ SD TV outputs. The STx7109 ncludes a stream merger to allow three dfferent transport streams from dfferent sources to be merged and processed concurrently. Applcatons nclude DVR tme-shfted vewng of a terrestral program, whle acqurng an EPG/data stream from a satellte or cable front end. The STx7109 embeds a 66 MHz ST40-0 CPU for applcatons and devce control. A dual DDR1 SDRAM memory nterface s used for hgher performance, to allow the vdeo decoder the requred memory bandwdth for HD VC1/H.64 and suffcent bandwdth for the CPU and the rest of the system. A second memory bus s also provded for flash memory, storng resdent software, and for connecton of perpherals. Ths bus also has a hgh speed synchronous mode that can be used to exchange data between two STx7109 devces. Ths can be used to connect a second STx7109 as a co-decoder for a dual TV STB applcaton. A hard-dsk drve (HDD) can be connected ether to the SATA nterface, or as an expanson drve through the USB.0 port. The USB or Ethernet nterfaces can also be used to connect to a DOCSIS.0 CM gateways for nteractve cable applcatons. 65

92 Fgure block dagram Set-top box (STB) transport streams are receved and processed by the TS subsystem. DVD streams are receved through the seral ATA (SATA) nterface, processed by the decrypton cell and then demultplexed. The resultng PES streams and secton data are stored n memory buffers n DDR1 SDRAM attached to the local memory nterface (LMI). A flexble DMA controller (FDMA) performs PES parsng and starts code detecton and routes elementary streams to audo and vdeo bt buffers n DDR1 SDRAM. A vdeo decoder decodes HD or SD vdeo streams. Audo decodng and PCM mxng s performed by the audo decoder and output through S/PDIF and PCM nterfaces. Audo can also be output through an ntegrated 4-bt stereo DACs system. After vdeo 66

93 decodng, two ndependently formatted vdeo dsplays (man and auxlary) can be generated, and each mxed ndependently wth graphcs to create man and auxlary dsplay compostons. The man dsplay composton (HD or SD) can be suppled as analog RGB or YPbPr outputs and, through a copy protected DVI/HDMI, as dgtal outputs. The auxlary dsplay composton (SD only) can be output as YPbPr analog component or composte vdeo on a separate nterface for connecton to a VCR. A dgtal vdeo nput nterface allows the STx7109 to receve SD non compressed dgtal vdeo and to output ths through the man and auxlary dsplays n place of decoded vdeo. A separate PCM nput allows any assocated audo to be receved, mxed and output n place of decoded audo. The graphcs subsystem comprses a separate D bltter, two graphcs planes, a cursor plane and dual dsplay compostor. Graphcs buffers are created, stored n and dsplayed from buffers n DDR1 SDRAM. The STx7109 embeds an ST40-0 CPU core for applcatons and data processng, and devce control. The CPU boots from flash/sflash on the external memory nterface (EMI) and can execute n place, or transfer the man executable to the DDR1 SDRAM and execute from there. CPU data s held n DDR1 SDRAM where cacheable and non-cacheable regons can be programmed. The 16-bt EMI s also used for connectng to external perpherals. System performance s enhanced wth the multchannel FDMA, whch can be used for D block and stream data transfers wth mnmal CPU nterventon. DVR applcatons are supported usng a hard-dsk drve (HDD) connected ether to the seral ATA nterface, or to the USB.0 nterface. IP-TV and home networkng applcatons are also supported by the ntegraton of an Ethernet controller wth ntegrated MAC (Meda access control). The STx7109 also ntegrates a range of 67

94 perpherals, system servces, and a clock generator module wth embedded VCXO (voltage controlled oscllator), to sgnfcantly reduce external component cost. In ths chapter, basc concepts of Set-top box have been presented. In secton 4.5 functonng of a typcal low cost set-top box decoder chp has been explaned. Varous blocks of Set-top box decoder SoC, and how a set-top box s able to perform mportant functons for dgtal TV has been explored. Ths chapter has provded a background for understandng and analyzng clock recovery problem n varous broadcastng envronments for set-top box. 68

95 Chapter 5: Clock Recovery for Satellte TV In ths chapter, frst concept of clock synchronzaton has been explaned, and then n next secton jtter n satellte envronment has been analyzed. Further a newly desgned Clock Recovery algorthm for Satellte broadcastng for STB has been presented. In the last secton smulaton results and performance n real envronment has been llustrated. 5.1 INTRODUCTION TO CLOCK SYNCHRONIZATION Clock synchronzaton s an essental feature of modern dgtal network and dgtal system. Synchronzaton s of fundamental mportance at both the applcaton level (voce, audo, vdeo and graphcs), and at transmsson level (packet, cell, symbol and bt). In a Set-top box subsystem, synchronzaton of decoder clock wth the encodersde clock s one of the most mportant parts of MPEG standard snce t s absolutely crtcal to extract the tmng nformaton accurately n order to play the audo/vdeo smoothly at the decoder end. A typcal block dagram of the clock synchronzaton prncple n set-top box s shown n Fgure 5.1. As audo and vdeo have dfferent samplng rates and dfferent frame szes, t s convenent to have a common sngle clock at the encoder provdng the tmng nformaton of audo as well as of the vdeo. The clock nformaton s then used by the decoder sde as a reference to retreve the stream tmng nformaton to decode the audo/vdeo data accurately and then to synchronze audo wth the vdeo. At the encoder, the clock reference s encoded n the form of tmestamps termed as Program Clock Reference (PCR). The decoder sde uses clock nformaton comng n the stream as a reference (PCR) to retreve the stream-tmng 69

96 nformaton to decode the audo-vdeo data accurately. The tmestamps from the local decoder clock are termed as System Tme Clock (STC). The encoder contans a 7 MHz master oscllator runnng at worst case tolerance (MPEG-System) of +/- 810 Hz. The encoder samples the 33bt counter perodcally to provde PCR base value. Encoder also provdes the 9-bt remander value as a PCR extenson. These two values (PCR Base Value and 9 bt extenson) are then multplexed wth the audo-vdeo data and transmtted n the transport stream. PCR tme stamps are requred to occur at maxmum 100ms ntervals. DVB recommends PCR nserton rate at 40ms. VCXO runs the counter to derve the System Tme Clock as shown n Fgure 5.1. Fgure 5.1 PCR mechansm Decoder system s drven by a separate ndependent 7 MHz clock provdng local clock tme stamps also called System Tme Clock (STC). The STC frst dvdes the 7MHz by 300, gvng a 90 khz clock that s counted by a 33-bt counter gvng the base STC value. The remander s taken as a 9-bt value, used as STC extenson. The 33-bt counter at decoder sde wraps around to zero after a perod of ~95443 seconds (6.51 hours).snce the encoder clock can run anywhere n between 7MHz+/-810Hz, decoder does not know the exact frequency of the encoder sde clock. It only knows the mnmum and maxmum values of the encoder clock. So there s a need to fnd out the exact 70

97 frequency of the encoder sde to run the decoder system at the correct frequency for any transport stream. Now let us consder the worst case. Suppose an encoder sde, clock s runnng at 7MHz-810Hz whle the decoder sde s runnng at 7 MHz KHz. Total error n the system s KHz = 610 Hz whch we need to correct. Such large error wll result n vdeo sync loss or n the worst case audo/vdeo data loss. Data loss may occur because f we are not playng the data at the correct rate, t wll lead to accumulaton of the data f we are slow compared to the encoder clock and eventually data buffer overflows resultng n data loss. On the other hand, f we are runnng fast, we may dsspate the data all too soon resultng n no more data to play. In both these cases, fnal result s bad audo wth gltches, no vdeo on the TV sometmes and/or color loss of the vdeo. Therefore, t s very essental to recover the encoder sde clock at the decoder end for smooth vewng on TV. Ths s known as clock recovery. As shown n Fgure 5., f the encoder transmts N PCR values, n a gven absolute tme perod T, then the local recever must receve N PCR values n the same absolute tme perod T. The PCR tme stamp s the encoder s relatve measure of the tme when a PCR value was transmtted. Smlarly, the STC tme stamp s the local recever s relatve measure of the tme when a PCR value was receved. Fgure 5. PCR mechansm n Transport Stream 71

98 After N PCR receved by the decoder, the dfference between the tme elapsed as measured by the encoder, and the tme elapsed as measured by the local recever s the clock dfference. Ths dscrepancy can be used to correct the local recever clock. Fgure 5.3 Tmng Dagram n a Typcal Set-top Box A typcal tmng block dagram of Set-top box subsystem s shown n Fgure 5.3. It has two parts- Encoder and Decoder. The MPEG audo vdeo encoded and output data s formatted nto elementary Stream (ES). At the encoder sde, an endless ES s broken nto number of packets of convenent sze (64 Kbyte) called as packetzed elementary stream (PES). Header s also added n ths PES that contans PTS (Presentaton Tme Stamp) and DTS (Decodng tme stamp). Tme stamps n each PES ensure lpsynchronzaton between the vdeo and audo. The PES s then further subdvded nto transport stream (TS) 188 byte packet sze that contans 4 byte Header and 184 Byte Payload. Thus PES packets are beng broken nto short fxed-sze packets and multple programs encoded wth dfferent clocks can be carred out. Ths s possble because the stream has program clock references (PCR s) mechansm whch allows transmsson of 7

99 multple clocks, one of whch s selected and regenerated at the decoder. At decoder sde, TS s demultplexed by demultplexer block and converted nto PES. The PCR nformaton s extracted from TS and fed to frequency control block for encoder and decoder clock synchronzaton. The PES parser n demultplexer block converts PES nto ES. Ths ES s then fed to audo and vdeo-decoder. PTS and DTS are extracted from PES and used by audo and vdeo decoder drvers for ther synchronzaton. Clock recovery s a process of synchronzng set-top box decoder system clock wth encoder system clock. It s a mechansm to adjust the locally generated clock wth the encoder sde clock referenced n the Program Clock Reference (PCR) located n the adaptaton feld of the ncomng transport stream. In a typcal Set-Top Box decoder, System Tme Clock s derved from an adjustable 7MHz clock source (wth a tolerance of 5.4 KHz). Decoder latches local STC counter value as soon as PCR packet arrves at decoder. Output frequency s adjusted at the decoder sde accordngly. The multplexed bt stream from the encoder s made avalable to set-top box decoder system through a broadcastng channel (satellte, cable, terrestral or IP) or storage medum (CD etc). Thus specfc contrbuton of our research work s to develop clock-recovery algorthms at decoder sde for extractng the transmtted PCRs n transport stream and accordngly adjustment of the decoder clock. sde. In a set-top box typcally there are two ways of frequency adjustment at decoder 5.1. VOLTAGE CONTROLLED OSCILLATOR (VCXO) BASED CLOCK RECOVERY MODULE In a VCXO type devce as shown n fgure 5.4, there s a sngle clock source (voltage controlled oscllator) used for both audo and vdeo. A sngle 7 MHz clock s 73

100 modfed, usng a PWM pulse tran, and as a consequence all other clocks derved from ths clock are modfed. Frequency change affected by varyng the Mark/Space rato lnear over a sub-range of avalable PWM Mark values, from 40 to 16. Over ths range a change n frequency s of approxmately 61 tcks per second per PWM Mark change Fgure 5.4 VCXO based clock recovery 5.1. FS BASED CLOCK RECOVERY MODULE In Frequency Syntheszer (FS) based system, a sngle fxed frequency crystal acts as the source to multple ndependently controllable clocks by programmng FS regsters. Frequency generated by the frequency syntheszer s controlled by programmng varous FS regsters. 5. ANALYSIS OF JITTER IN DVB-S ENVIRONMENT For detaled analyss of satellte envronment, n STB decoder, Event Manager (EVT s used to receve events from one software drver to other software drver) and 74

101 Programmable Transport Interface (PTI for demultplexng the transport stream and extract the PCR) software modules are used. These modules help n provdng PCR & STC to clock recovery module. When PCR packet reaches the PTI, PCR event occurs and then PTI call-back functon wll be nvoked and nform the clock recovery module. In one of the parameters of PTI call-back functon, we get the PCR value and correspondng STC value. Fve hundred samples of raw PCR value (PCR packet value receved by the backend), raw STC value (STC value correspondng to the PCR packet receved) are collected. The dfference between two successve PCR packet values (PCRdff) and the dfference between two successve STC values (STCdff). Msmatch (deltas) between correspondng PCR dfferences and STC dfferences (STCdff PCRdff) s calculated. Ths (STCdff - PCRdff) gves us the jtter value. We also noted that PCRdff and STCdff values are n mllseconds along wth the system tme when the PCR packet s gathered by the PTI. In case of satellte transmssons, the STC follows the PCR almost always and s n sync. Ths ndcates that jtter effect s not very hgh n satellte transmsson. 5.3 MOVING WINDOW BASIC AVERAGING ALGORITHM FOR DVB-S BROADCASTING A classcal PLL based clock recovery approach has been explaned n Fgure 5.6. In ths clock recovery system error sgnal PCR (Program Clock Reference)-STC (System Tme Clock)) s fltered to elmnate the effects of the network jtter, resultng n a correcton value to be appled to the local clock generator. The newly corrected clock wll be the base for the subsequent STC value read upon the arrval of the next PCR tme stamp. 75

102 Fgure 5.5 Generalzed Desgn of PLL based Clock Recovery The algorthm developed n ths chapter for low jttery envronment s based on PLL based desgn. The frst step nvolves fndng the frequency error between the headend and the local-end by samplng the PCR and STC by the SD (Standard Defnton) clock. The tck error s calculated by takng the dfference of successve STC and PCR values. Tck error = (S1 - S0) - (P1 - P0) (1) Where S0, S1... denotes successve STC values and P0, P1... denotes successve PCR values. Ths tck error s then converted n to frequency error usng Frequency Error = [ / (P1 - P0)] * Tck Error () For two successve PCR samples, error s beng calculated and fed to our newly desgned Movng Wndow Basc Averagng flter. Ths secton s dvded nto two parts. In frst part we wll explan the three most mportant parameters of ths algorthm and later, how these parameters are beng used n the algorthm Flter Parameters Here we wll dscuss three man parameters as per below- 76

103 PCR_DRIFT_THRESHOLD (P) It defnes the maxmum number of tcks n an error sample beyond whch the correspondng frequency error sample wll be gnored. Ths maxmum lmt depends upon the transmsson jtter n the envronment. If maxmum frequency error s 5.4KHz + 810Hz = 610 Hz. Assumng a PCR rate of 40 ms, maxmum tck error should be 610/5 ~ 50. And all error samples above 50 tcks wll be gnored. Thus PCR_DRIFT_THRESHOLD characterzes a Low Pass Flter n whch all the frequency error samples above a partcular frequency defned by PCR_DRIFT_THRESHOLD are gnored. In applcatons lke change of a channel n TV and 33-bt counter wraparound case, a very large jtter error may occur n the system. For example, takng 33 bt counter wraparound, from eq.(1) dfference between two consecutve PCR values wll be too large.(max. 33 bt value - ~mnmum 33 bt value) resultng n a very large frequency error. However, actually t s not an error and the problem occurs because of wraparound. Smlarly, when we change a TV channel, PCR data may change entrely snce tmng nformaton of two dfferent channels s dfferent. There may be stuaton where we are subtractng the last PCR value of the last channel wth the frst PCR value of the current channel agan results n a very large error sample. We need to gnore such spurous error samples. After passng the frequency error samples through a low pass flter, error samples are accumulated untl a pre-defned number of samples are reached as explaned further MIN_SAMPLE_NUM (S) MIN_SAMPLE_NUM s the mnmum number of error samples after whch frequency correctons can be appled. MIN_SAMPLE_NUM s just to fasten the clock recovery so that as soon as we have some mnmum number of error samples defned by 77

104 MIN_SAMPLE_NUM, we wll apply a correcton to the clock. The value should be taken n such a manner so that correcton s nether appled very late nor too early because we need to take an average of error samples to cancel out the jtter error. In satellte envronment we can start applyng correcton very early snce there s less or no jtter and even by averagng very few error samples we can calculate the actual error. So MIN_SAMPLE_NUM s set to a small value of 10 or MAX_WINDOW_SIZE (M). MAX_WINDOW_SIZE s the maxmum number of error samples to be consdered n a wndow to calculate the actual error and the correspondng correcton value. After recevng ths maxmum number of error samples and on the arrval of next PCR value, we wll remove the oldest sample from the sample wndow and nclude the latest PCR sample n ts place. Thus n a way, our error sample wndow wll start movng Thus there wll always be MAX_WINDOW_SIZE number of error samples n the wndow. In case of satellte ths can be set to a small value(100 or 150) as there s very less jtter and error n the decoder clock can be smply corrected by accumulatng the error of a very few number of samples Error Calculaton and Applyng Correcton Frst of all, the error samples are passed to low pass flter. All error samples beyond PCR_DRIFT_THRESHOLD are gnored. Now from second sample onwards error s beng calculated for every two successve PCR samples. But correcton s appled only when MIN_SAMPLE_NUM of samples have been receved. To calculate the correcton to be appled, an average of all error samples (less than or equal to MAX_WINDOW_SIZE) need to be taken. To keep wndow sze fxed most recent sample s ncluded n wndow and oldest sample of wndow s beng excluded from 78

105 wndow as shown n Fgure 5.6. Ths s how a wndow has moved hence named Movng Wndow and Averagng Flter. Fgure 5.6 Concept of Movng Wndow After calculatng error, correcton need to be appled n an approprate manner. Here one mportant thng to consder s the settlng tme of the decoder clock. If we take an average of a very large number of error samples, the error calculated wll be more accurate but t wll take a large tme for the decoder clock to settle to the encoder clock value. So larger the value of MAX_WINDOW_SIZE larger s the settlng tme but more s the accuracy. Smlarly a small wndow sze s also napproprate as t can destablze the sum of whole wndow and STC clock wll not be stable. In a small wndow, f we receve a very large error sample t may happen that the negatve counterpart of ths error sample s not ncluded n the wndow because of ts small sze. So after averagng, jtter error wll not reduce to zero resultng n a correcton beng appled to the frequency when t s not requred. Now, when we receve the counterpart of such an error sample later on, t wll shft the sum of the wndow hugely n the opposte drecton resultng n another 79

106 naccurate correcton beng appled to the frequency. Thus n a nutshell, we wll have an unstable frequency at the decoder. Keepng n vew above facts, we wll be calculatng the actual error by applyng Basc Average flter, and then a correcton s appled to the runnng STC clock. But the correcton correspondng to the actual error passed by the flter n a sngle step can make the clock recovery unstable. If PWM correcton s appled too fast, clock recovery became unstable because of the averagng of current error sample wth prevous errors, for example, f there s a ntal error of 000 Hz then Average_error = ( )/4 On the thrd sample, Average_error of 000 Hz s corrected n one go then fourth error sample (0 Hz) s arrved. At the arrval of fourth sample there s no error n the system, but due to the averagng of all error samples, error now comes out to be 1500 Hz. Because of ths fact clock recovery appled further correcton n opposte drecton and flter ends up n togglng between low PWM mark and the hgh PWM mark. Soluton to ths problem was to apply PWM correcton gradually so that togglng of the flter can be really slowed down. An Average_error should not be corrected n one step, t should be appled gradually. Average_error s dvded by a multple number of samples (Store_count) n the wndow and a constant multple called GCF(GRADUAL_CORRECTION_FACTOR), whch gves Average_error Per Sample (AEPS). AEPS= Average_error/ (GCF * Store_count) Above Average_error per sample gves the correcton to be appled to the local decoder clock as New_freq = Old_freq+ AEPS 80

107 For satellte envronment, normally GCF has been chosen as 50. Frequency change effected by varyng the Mark/Space rato s lnear only over a sub-range of avalable PWM Mark values, from 40 to 16. By one PWM Mark change, approxmately 61 tcks per second change s observed n frequency. Correcton (n terms of PWM mark value) = (AEPS + Outstandng error)/ PWM _TICK_MARK, where PWM _TICK_MARK= 61 AEPS could be too small to be corrected for one sample so t s carred forward for next PWM correcton. Ths carry forward error s called Outstandng Error. AEPS comes out to be a small value and Outstandng Error ncreases wth every PCR receved. Whenever the sum of AEPS and Out Standng Error s hgher, than one step of VCXO (appx 61 tcks per second), correcton s made and outstandng error s adjusted. After applyng ths Correcton, the flter behaved n a stable manner. In jtter less envronment t s locked to correct frequency and t also takes care of any resdual error whch s too less to correct (means less than one PWM step). In the smulaton on the Satellte, we can see that the flter s stablzed to +/- 1 PWM step around the lock frequency and then toggles n such a way so that the long term average approaches encoder frequency. 5.4 PERFORMANCE OF NEW DESIGNED ALGORITHM The algorthm was smulated on MATLAB for testng the response to the satellte envronments. Appendx- II provdes the necessary nformaton about MATLAB code. The PCR data s extracted from lve satellte streams and correspondng STC data s captured from the decoder clock. The plot of decoder frequency change wth PCR count after runnng the smulaton for satellte envronment s shown n Fgure

108 Fgure 5.7 Behavour of algorthm as smulated n Matalab for Satellte data wth P=300, S=10, M = 50 Test results usng real tme set-top box n satellte envronment and s shown n Fgure 5.8. In satellte transmsson, error n the encoder sde clock s tracked very accurately. Assumng PCR arrval rate of 40 ms the decoder sde clock s synchronzed wth the encoder sde clock n 40 * 500 = 0 seconds. Ths has been acheved wth parameters MIN_SAMPLE_NUM =10, MAX_WINDOW_SIZE = 50 and PCR_DRIFT_THRESHOLD =

109 Fgure 5.8 Input PCR Count vs Decoder Frequency graph demonstrate behavour of Proposed Algorthm n Satellte Envornment wth P=300, S=10, M= CONCLUSION Thus our desgned algorthm shows good response as t s meetng all constrants of real tme STB and achevng clock recovery effcently. A lght weghted, smple, low cost and stable software approach to recover the encoder clock n a satellte transmsson envronment has been proposed n ths chapter. 83

110 Chapter 6: Clock Recovery for Terrestral TV Dgtal Vdeo Broadcastng (DVB) transmsson over terrestral medum ntroduces hgh jtter n the stream (max jtter upto the order of 1ms). In DVB-T, loss of synchronzaton between the receved and the transmtted clocks can lead to degradaton n system performance lke color loss, jerky vdeo, audo drop outs etc. There are several factors, whch lead to degradaton n clock recovery process. In ths chapter, analyss of varous factors that consttutes jtter n recever clock durng acquston of PCR packets n terrestral envronment has been done. It has been tested and smulated wth already exstng algorthms, whch are not able to handle jttery envronment of terrestral broadcastng. Lmtatons of Movng Wndow Basc Averagng algorthm for terrestral envronment have been removed by modfyng the algorthm. A new Movng Wndow Weghtng flter algorthm, whch offers low computatonal complexty, low cost and stable clock recovery has been presented for terrestral transmsson n set-top boxes. 6.1 ANALYSIS OF JITTER IN DVB-TERRESTRIAL Jtter s a term that refers to the varance n the arrval rate of packets from the same data flow, and abnormal jtter values can negatvely mpact real tme applcatons (Davs, 008). For terrestral envronment hardware setup shown n Fgure 6.1 has been used. It has been observed n case of terrestral transmsson that sometmes the STC does not follow the PCR properly.e. jtter exst. Jtter may arse due to the sources namely- There may exst a frequency drft between the transmtter and the recever clock. 84

111 Fgure 6.1 Hardware Setup The communcaton channel ntroduces a sgnfcant amount of jtter called the network jtter. In terrestral envronment, the maxmum network jtter of 500 µs s beng analyzed. The hgh jtter s due to mult-path reflectons of transmtted waves by buldng, trees etc. before t s fnally receved. At the set-top box front-end, more jtter s ntroduced because of the denterleavng and other varable delays before provdng data to the audo/vdeo drvers. The nner nterleavng and de-nterleavng blocks n the transmtter and recever sde, partcularly n Dgtal Vdeo Broadcast-terrestral (DVB-T) transmsson, ntroduce a sgnfcant amount of jtter (ETS , 1999). Packetzaton at source may result n dsplacng the tmestamp values n the stream. Ths s called packetzaton jtter. In worst case channel condtons (such as ¼ guard nterval, channel fadng, low carrer-to-nose rato etc.), arrval of Program Clock Reference (PCR) packets 85

112 beng delayed as the STB tuner front-end takes too much tme to detect and demodulate the sgnal. Hgh amount of jtter causes color loss and audo/vdeo data loss. Data loss may also occur f the decoder clock s slower than the encoder clock. In ths case, the data nput to the dsplay buffer memory s more than the output, whch would lead to accumulaton of the data n t, eventually causng buffer overflow. Smlarly, f the decoder clock s faster than the encoder clock and eventually the buffer emptes, the result s no more data to dsplay. In both the cases, mproper clock synchronzaton results n bad audo wth gltches, no vdeo dsplay, and some tmes vdeo color loss. 6. LIMITATIONS FOR DVB TERRESTRIAL BROADCASTING Lot many terrestral streams have been analyzed to dentfy the lmtatons n terrestral streams. Ths analyss has helped us to propose a sutable algorthm for clock recovery for terrestral set-top box. Analyss-1: In Fgure 6., PCR sample arrval tme for terrestral condtons s shown. As per DVB standards, PCR nserton-rate s 40ms, however, maxmum allowable PCR tme stampng s 100 ms. Ths tme nterval vares a lot n the terrestral channels. It has been observed that a few PCR samples n some terrestral streams were stamped even at duraton of less than 5 ms as shown n the nset of Fgure 6.. Ths varyng rate needs to be consdered for desgnng the algorthm to prevent any false correcton n frequency of the decoder clock. 86

113 Fgure 6. PCR samples Arrval tme n Terrestral Envornment Analyss-: The frequency error wth respect to PCR count s beng shown n Fgure 6.3. In a typcal terrestral envronment these error samples complement each other and all the error samples may be averaged. By averagng, the postve and negatve error cancel out and only the actual drft between the decoder and encoder clock remans. As shown n Fgure 6.3 nset, the complement of error samples s not necessarly n ts Fgure 6.3 Frequency Error Samples n Terrestral Envornment 87

114 vcnty but may arrve after some tme (a large spke n the downward drecton s complemented after about 10 samples), so we need to consder some mnmum prevous values whle averagng and fnd out the actual correcton n the decoder clock. Above analyss are the startng pont of developng new algorthm sutable for terrestral envronment. The clock frequency on the decoder sde n the fnal stable state should be at 7MHz wth a tolerance of 30ppm. It s observed that f the jtter error s not effectvely removed, ths may result n a faulty correcton appled to the decoder clock. Ths correcton can cause the decoder clock to operate above the tolerance lmts, whch may cause color loss n the televson sets. 6.3 MOVING WINDOW WEIGHTING FIR FILTER ALGORITHM FOR DVB-T BROADCASTING When a new PCR value arrves at the decoder, the prevous value s subtracted from the present one to get PCR_Dff. The STC tmestamp s smlarly processed to get STC_Dff. Neglectng any jtter for the moment, the error dfference, called the Tck_Dff, s then calculated as n (1) Tck _ Dff = ( PCR _ dff ) ( STC _ Dff ) (1) The true error estmate s the error per cycle, or percentage error s found out- Tck _ Dff Percentage _ err = () PCR _ Dff The frequency error s then calculated as n (3) Freq _ err = Percenage _ err Encoder _ frequency (3) 88

115 The Freq_err s calculated usng the assumpton that there s no jtter n the stream and the encoder s transmttng at the frequency exact 7MHz. Hence, Encoder_frequency = 7MHz. Ths error samples should deally be zero f there s no jtter and the decoder and encoder clocks are at same frequency. The non-zero frequency error samples are then sent to a Low Pass Flter for rejectng the samples, whch arrve too fast LOW PASS FILTER The error samples need to be checked to be vald or nvald. Ths s done usng a smple low pass flter to reject all the values above a parameter termed as PCR_DRIFT_THRESHOLD (P). All the error samples beyond P are gnored. There are two cases when error sample can be very large. PCR samples are further checked f ts arrval tme s lesser than 0 ms to reject all the samples comng too fast. The PCR and STC data arrvng before 0 ms s gnored otherwse t would have caused a false correcton on the decoder clock. In ths manner, bad PCR and STC data s handled effectvely. Ths vald data s stored nto a Movng wndow buffer for average calculatons MOVING WINDOW WEIGHTING FIR FILTER ALGORITHM The sample values are stored nto a wndow of sze defned by a parameter MAX_WINDOW_SIZE (M). Ths parameter s of prncpal mportance as t defnes the amount of prevous samples to be used for effcent averagng. It also determnes the settlng tme for ths algorthm. If the flter s appled over a large error sample sze, the error calculated s more accurate but t takes a larger tme for clock synchronzaton. 89

116 However, a small wndow sze s napproprate as a sngle large sample can destablze the sum of whole wndow and STC clock wll not be stable. So, optmzed value of M s found out for dfferent jtter stuatons. Another consderaton whle desgnng s that the error s beng calculated from second sample onwards but correcton s not appled at the same tme. We have desgned our algorthm n such a manner that correcton n the frequency of the decoder clock should be appled only when mnmum numbers of samples are collected, defned by the parameter MIN_SAMPLE_NUM (S). Ths approach s adopted to prevent the ntal spkes due to average over a small sample set. The strategy and modfcaton over here as compared to our earler developed algorthm as dscussed n chapter-5, for calculaton of average error s to assgn a weght to each of the frequency error samples dependng on some parameters. The Fnte Impulse Response (FIR) flter s made usng the taps equal to the sze of the wndow. The weghts are proportonal to the poston of the element n the movng wndow n a pyramdal manner (the central tap beng the hghest and the edge taps beng lowest). The output of the flter s the average error calculated as n (4) Freq _ error * wegh MAX _ WINDOW _ SIZE Average _ err = (4) wegh MAX _ WINDOW _ SIZE A trangular flter s chosen compared to the exponental flters or any other flters used by researchers n the smlar feld. The reason for ths s to develop a smpler flter to be mplemented n an RTOS envronment. The maxmum weght n the centre of the wndow s desgned under the assumpton that the complment of error samples n the 90

117 centre exst n the wndow, however the samples at the edges may not have ther complments n t APPLYING CORRECTION After calculatng the Average_error by mantanng the movng wndow and applyng the FIR flter, ths correcton should be appled to the decoder clock. But ths correcton should not be appled n a sngle step as t can force the decoder clock outsde tolerance lmts. It must be appled n a gradual manner by dampng ths correcton value. If no dampng s done, the frequency change may be so much that ths sharp change n frequency may not be sensed by the Televson montor s PLL(Phased Lock Loop) and may cause colour shft of the vdeo sgnal. To acheve above, Average_error was dvded by the number of samples n the wndow (Store_count) and a constant dampng factor called Gradual Correcton Factor (GCF). Ths gves Average Error Per Sample (AEPS) as shown n equaton (5) Average _ err AEPS = (5) GCF Store _ count The value of the dampng factor was chosen such as to optmze the settlng tme wth respect to the stablty of the decoder. Ths average error per sample gves the correcton to be appled to the local decoder clock as n (6) New _ freq = Old _ freq + AEPS (6) The parameters for the movng wndow were found out by analyzng the amount of jtter present n the stream. The STC dfference between consecutve STC samples was found out after arrval of two consecutve PCRs. The standard devaton of the STC dfferences 91

118 gves the approxmate jtter. Extensve smulatons were conducted to fnd out the value of the flter parameters M, S and P n jtter condtons varyng from 0.1 ms to 1.ms. A lookup table was made regardng the parameters to be adapted for the Clock Recovery module accordng to the amount of jtter n the stream. Accordng to the jtter n the stream, the algorthm tested n the set top box auto-adapts the parameters requred. 6.4 CLOSED LOOP ANALYSIS OF PROPOSED ALGORITHM In ths secton, the man clock recovery feedback loop s descrbed as a flter that transforms the nput PCR and STC tme stamps nto an output frequency correcton value. The flter transfer functon wll be expressed as a Z transforms. Z transform analyss assumes that the nput samples are perodc. In clock recovery, the error dfference samples En are not perodc. However, f the error dfference s dvded by the PCR dfference Pn to obtan a percentage error measurement, and assumng small PCR tmng error at the encoder, we can obtan samples wth close approxmaton of perodcty. Therefore, for rest of ths analyss nput samples wll be assumed as perodc data. Let us consder an absolute tme nterval T, between two successve PCR tme stamps (P n and P n-1 ). The head-end clock at the encoder, runnng at frequency H, wll measure ths as- (P n P n-1 ) = H. T = L (7) A smlar equaton relates the STC tme stamps at the decoder - (S n S n 1 ) = F n.(t + j n ) (8) 9

119 where F n s the composte decoder frequency, and j n s the jtter due to the varablty n the delvery tme of the PCR packet. F n has two components, the programmed output frequency of the FS, and crystal frequency drvng the FS. These are related as follows - F n = (H + C n 1 ).(X+X n ) / X (9) where the programmed output frequency of the FS s represented as the encoder frequency (H) plus a prevous programmed correcton (C n-1 ), and the crystal frequency s represented as a nomnal value (X) plus the drft error (X n ). We are tryng to correct crystal drft error here. Assumng both (C n /H) and (X n / X) are small, the followng approxmaton can be made - F n H + C n 1 + H. X n / X (10) The dfference error (E n ) s evaluated as - E n = (P n P n 1 ) (S n S n 1 ) (11) Substtutng values from (7) and (8) nto (11) gves - E n = H.T F n. (T + j n ) = (H F n ).T F n. j n (1) Substtutng for the frst F n from (10) gves - E n = ( H- (H + C n-1 + H. X n / X)) T F n. j n = (C n 1.T) (H.T. X n / X) (F n. j n ) (13) Ths can be re-expressed as- E n = Programmed Correcton DrftError RandomError (14) The random error s a nose term that averages to zero, so t can be elmnated from ths part of the analyss. The system stablzes when the programmed correcton s equal to (mnus) the drft error. If we express the drft as - D n = H. X n / X (15) 93

120 Then neglectng the nose term, equaton (13) becomes- E n = (C n 1. T) (D n. T)= T(C n 1 + D n ) (16) Ths equaton s represented at the left hand sde of the system dagram shown n Fgure 6.4. Fgure 6.4 Feedback Loop expressed as Z transform The Z-transform representaton of the feedback loop s shown n above Fgure 6.4. The error dfference s fltered to form the mean error n. By dvdng the mean error by the tme perod (T), we get a new ncrement to the frequency correcton. Ths s added to the prevous estmate of the frequency correcton to form the new estmate of the frequency correcton. When the system stablzes - C n 1 = Dn = n, En = n= 0, Cn C 1, For Fgure 6.4, the followng tme seres equatons are gven wth ther Z transform equvalents - E n = ( T. D n ) ( T. C n n n = 1 1) <=> E( Z) = ( T. D( Z)) ( T. Z. C( Z)) = F( E ) <=> ( Z) F( Z). E( Z) (17) (18) C n n ( ) ( ) ( ( Z)) 1 = + Cn 1 <=> C Z <=> + Z C( Z) (19) T T (17), (18), (19) can be used to elmnate E(Z) and (Z) The resultng equaton can be re-arranged to the followng form- 94

121 C( Z) F( Z) Z = = (0) 1 1 D( Z) 1 Z + Z. F( Z) ( Z 1) + 1 F( Z) The rght hand sde of (0) s the overall transfer functon of the feedback loop. Coeffcents of Z -n n the numerator represent coeffcents of a movng average (FIR) flter. Coeffcents of Z -n n the denomnator represent coeffcents of an auto-regressve flter (IIR). The smplest system s when there s no n-loop flter. In ths case F(Z) = 1, C( Z) and (0) reduces to = 1 D( Z).e. frequency correcton C(Z) s set to mnus drft error D(Z). For example, f the local crystal s 1% fast at 7.7 MHz, the frequency syntheszer wll programmed to be 1% slow at 6.73 MHz. The most smple n-loop flter averages the current nput and the prevous nput. Ths s represented by F( Z) = (1 + Z 1 ) In ths case (0) reduces to C( Z) D( Z) 1 ( + = 1 1 Z Z 1 1 Z ) (1) Ths equaton has coeffcents of n Z n both the numerator and the denomnator. Therefore the total transfer functon of the feedback loop forms an ARMA flter. In general, any attempt to use n-loop flterng wll produce a total system flter wth the complexty of an ARMA flter. 95

122 6.5 PERFORMANCE OF PROPOSED ALGORITHM FOR TERRESTRIAL BROADCASTING The algorthm was smulated on MATLAB for testng the response to the terrestral envronments. The PCR data s extracted from lve terrestral streams and correspondng STC data s captured from the decoder clock. Ths dataset s then appled to the nput to the MATLAB scrpt. Snce the STC data s captured when the decoder clock s runnng constantly at 7 MHz, ths data s not the same as the STC value f the decoder clock frequency s changed by the clock recovery module. The MATLAB scrpt calculates the smulated actual STC and then apples the algorthm dscussed above to fnd out the correcton at the decoder end. The terrestral plot usng Guard Interval 1/8, 64 QAM, FFT 8K, FEC ¾ (the parameters are explaned later) s shown n Fgure 6.5. The clock settles n 40*000/1000 = 80 sec (for Jtter = 0.4 ms). The behavor of the algorthm s stable wth the parameters of P=10,000, S=50 and M=150. Note that the varaton n the frequency s well wthn the tolerance lmts of 30ppm. Fgure 6.5 Behavour of smulated algorthm n MATALAB for terrestral data wth P=10000, S=50, M=

123 The set-up for testng of the algorthm n terrestral envronment has already been shown n Fgure 6.1. The lve DVB stream s fed to DVB-T front-end whch generates Transport Stream packets for the set top box drvers. The Clock Recovery module provdes the tmestamps to the vdeo and audo drvers, whch provde a decoded audovdeo sgnal to vew on televson for testng of color loss or audo-vdeo data loss. Usng ths test setup the amount of jtter s measured for varous streams usng dfferent values of parameters lke Guard Interval, FFT, FEC, and modulaton technque s descrbed n the Table 6.1. Table 6.1 Effect of Terrestral Parameters on Jtter The jtter vared from 0.1 ms to 1.ms under these test condtons. The behavour for 0.4 ms jtter, usng the condtons Guard Interval (G.I.) = 1/8, FEC = ¾ and modulaton technque = 64 QAM s shown n Fgure 6.6. The clock stablses n about 80 sec. The varaton n the clock frequency after stablsng s 1 step only and t shows good stablty over a long tme. The plot confrms wth the MATLAB smulatons too. The stablty of the module follows from these results. The algorthm has adapted to M=150, S = 50 and P = under condtons wth Guard nterval = 1/8, Modulaton=64-QAM, FEC=3/4. Guard Interval FFT FEC Modulaton 1/3 K 1/ 16 QAM 1/16 K 3/4 16 QAM 1/8 8K 3/4 64 QAM 1/4 8K 7/8 64 QAM 97

124 Fgure 6.6 Behavour under G.I. = 1/8, 64 QAM, FEC=3/4 terrestral envronment(jtter = 0.4 ms) The worst case jtter (1.ms) was found usng ¼ Guard Interval, FEC 7/8, and 64QAM. The algorthm was tested wth dfferent values of Guard Interval and FEC. The behavour of our module under ths stressed jttery condton s shown n Fgure 6.7. The clock settles n about 150 sec wth reasonable stablty. The jump n frequency of the module s only of steps after settlng. Furthermore, no data buffer overflow or underflow was observed and the televson vewng went smoothly. It may seems that the settlng tme of the decoder clock s large, however, t s not so. If the correcton to the decoder sde s appled n a sngle step, the settlng tme may reduce, but the sharp frequency change n the decoder clock may cause colour loss. The Algorthm has adapted to M = 300, S = 100 and P= for the worst-case terrestral condtons wth Guard nterval = 1/4, 64 -QAM, FEC=7/8. 98

125 Fgure 6.7 Behavour under G.I. = 1/4, 64 QAM, FEC= 7/8 terrestral envronment(jtter = 1. ms) 6.6 CONCLUSION In ths chapter a newly desgned effcent, cost- effectve, smple and smart algorthm named Movng Wndow Weghtng Flter algorthm for terrestral transmsson for dgtal set-top box has been presented. The performance of new proposed algorthm has been smulated n MATLAB. Results are llustrated for real tme envronment n STBs. Wth our proposed algorthm, decoder clock s synchronzed wth encoder clock n 80 seconds for 0.4 ms jtter and for 1. ms jtter, decoder clock s synchronzed wth encoder clock n 150 seconds so proposed weghtng algorthm shows cost effectve and smple clock recovery wthout sgnfcant overshoots, n low as well as n hgh jtter envronment. 99

126 Chapter 7: IP Streamng: Detaled Analyss n IP Envronment Proper clock synchronzaton s very crtcal for ensurng good performance of IPTV. Analyss and understandng of varous component assocated wth IP envronment s essental for developng clock recovery algorthms for IPTV. Fundamental concepts of IP networkng technologes, TCP/IP protocol, varous AV contents transport formats, IP protocol stack, and dfferent IP streamng recever software have been explored n ths chapter. However, sgnalng and management protocols related to above have been presented n Appendx-III. IP streamng s a generc term for transmttng dgtal audo and vdeo contents over an IP (Internet Protocol) network. Insde the home, AV contents can be transferred from two consumer applances (e.g. two set-top boxes) va a network connecton, usng IP streamng over an n-home network. Smlarly, an Internet Servce Provder (ISP) can provde dgtal AV contents, such as lve TV programs or vdeo on demand, to ts customers va a broadband Internet connecton, just lke cable or satellte operators. Such a servce s often called IPTV or even Telco-TV (because t s mostly offered by telecom operators). IPTV (Internet Protocol Televson) s a system where a Dgtal Televson servce s delvered usng Internet Protocol over a network nfrastructure, whch may nclude delvery by a broadband connecton. A general defnton of IPTV s that televson content, nstead of beng delvered through tradtonal broadcast and cable formats, s receved by the vewer through the technologes used for computer networks. The set-top box recevng and decodng AV contents over an IP network s called an IP set-top box or IP STB. 100

127 When AV content s streamed over an IP network rather than broadcasted from a satellte, terrestral, or over cable, there are some addtonal constrants put on the recevng devce. These constrants are: Format: Many IPTV systems use a famlar MPEG Transport Stream, but some use entrely dfferent formats. Network jtter: Due to the asynchronous nature of IP networks, network nduced jtter values are much larger than what can be found on broadcast networks: several mllseconds and sometmes hgher (up to 500 ms). The hgh jtter value requres extra bufferng to compensate and also complcates the recevng devce local clock synchronzaton wth the sender s clock. In fact, clock recovery n IP network s really challengng and crtcal. Lost packets: IP packets can be dscarded due to bt errors on a nosy transmsson lne (e.g. ADSL). No FEC scheme s avalable for the moment, although organzaton lke DVB, are workng on such a mechansm. IP packets generally contan more AV contents than MPEG TS packets, so the loss of an entre IP packet s more dffcult to compensate for. Out of sequence packets: Although very unlkely on a home network or carefully engneered telecom provders networks, IP packets could arrve at destnaton n a dfferent order than when they were sent out. 7.1 IP NETWORK INTERFACES Networkng Technologes Ethernet Networks: IP packets can be transported over dfferent knd of networks, encapsulatons and formats. One common feature of all the dfferent networks used for IP 101

128 Streamng, ether n-home or from an outsde provder, s the use of the famlar ubqutous Ethernet frame format for transportng data. Dest. Address (6 bytes) Source Address (6 bytes) Type ( bytes) Payload (n bytes) CRC (4 bytes) e.g. 0x800 for IP v4 e.g. IP packet The Ethernet frame format s used not only over regular wred Ethernet, but also over ADSL or cable modems broadband access networks, wreless LAN (IEEE80.11 W-F), power lne networks (Home Plug), n-home coaxal cable (MoCA (Multmeda Over Coax allance), Coaxsys, HPNA(Home Phone Network Allance)), etc. Most IP streamng systems use the Ethernet frame format for transportng IP packets, regardless of the actual physcal network. The Destnaton Address feld wll be ether the IP STB unque Ethernet address (uncast frame) n the case of dedcated contents lke Vdeo on Demand (VOD), or an Ethernet multcast address (multcast frame) when streamng broadcast channels to the IP-STB. The Type feld ndcates the type of payload transported nsde the Ethernet frame. A Type value of 048 (0800 hexadecmal) ndcates that the payload s an IP packet (also called IP datagram). The payload sze s varable wth a mnmum of 60 bytes and a maxmum of 1500 bytes (also called Maxmum Transmsson Unt or MTU). Typcally for IP streamng, AV contents payload wll be fragmented so that each fragment can be ft nto a 1500-byte IP packet that can, n turn, ft nto a sngle Ethernet frame. A 3-bt CRC s appended to the Ethernet frame to check for transmsson errors. 7. IP PROTOCOLS SUITE 7..1 Uncast and Multcast Each devce connected to an IP network (also called IP host) s dentfed by a unque IP address. For nternet protocol verson 4 (IPv4), an IP address s 3 bts wde, often 10

129 dsplayed usng a so-called byte decmal notaton, such as: , , , or , etc. when sendng an IP packet (sometmes called IP datagram) to an IP host, the packet s destnaton address must be set to the host unque IP address. Such a unque IP address s called a uncast address. There s also a mechansm to send an IP packet to more than one host by usng a specal address called multcast address (or group address) as the destnaton address. The IP address range to s reserved to multcast addresses and cannot be assgned to an ndvdual IP host devce. An IP host can receve IP packets sent to a multcast (or group) address by settng ts network nterface and IP stack to accept packets sent to ths group address. In vdeo IP streamng systems, a lve broadcast TV channel wll typcally be sent to a multcast address, where several recever devces wll be able to receve the same content. On the other hand, a Vdeo on Demand (VOD) server wll send content to the uncast IP address of the ntended destnaton devce. 7.. IP Protocols Byte and Bt Representaton By conventon, mult-byte data on IP networks are transported wth the most sgnfcant byte frst (bg endan), as per IP protocol descrbed (RFC 791). All the standards (RFC) n the IP protocol sute use the same data representaton, grouped by 3- bt words, wth the most sgnfcant bt havng the number 0 always on the left sde and the least sgnfcant bt beng the bt 31 on the rght sde: 103

130 For nstance, the 3-bt value x s represented as follows: When stored n memory, after recepton from a network nterface, the same data wll be stored as follows (often called network byte order) : 0x1 Address N 0x34 Address N+1 0x56 Address N+ 0x78 Address N+3 So, when parsng IP protocol data on a small endan CPU, all 16-bt and 3-bt words must be converted from network byte order to host byte order, usng macros that are provded wth the protocol stack. Else, wthout ths network to host converson, the above example would be erroneously nterpreted as 0x nstead of 0x Note that on Ethernet networks (Ethernet IEEE 80.3), each byte s sent wth the least sgnfcant bt frst. So, n the above 3-bt word example, the frst bt transmtted wll be bt 7, followed by bt 6, and so on wth bt 4 (most sgnfcant bt of the last byte) beng transmtted last Transport Protocols IP packets carry data usng a transport layer. The two basc transport protocols used n IP networks are the Transmsson Control Protocol (TCP) and the Unversal 104

131 Datagram Protocol (UDP) (TCP/IP, 001). There are some addtonal sgnalng and management transport protocols used n IP streamng lke DHCP (Dynamc Host Confguraton Protocol), IGMP (Internet Group Management Protocol) and RTSP (Real Tme Streamng Protocol), but all these addtonal protocols run ether on top of ether TCP or UDP transport servces. TCP: Transmsson Control Protocol: TCP s mostly used for relable fle transfers. It establshes a connecton between two end ponts and uses an acknowledge mechansm for each packet. If a packet s not receved by the destnaton host, t wll be retransmtted by the sender (guaranteed delvery). TCP protocol also ncludes other functons such as flow control, packet re-orderng, etc. Because TCP wll attempt retransmsson of all lost packets, t s not necessarly well suted to real-tme AV contents where t s more mportant to ensure a tmely delvery of the AV payload wth mnmal delay, even at the cost of havng to conceal eventual errors due to mssng packets. TCP s, by defnton, a one-to-one transmsson protocol; so t can be used only for uncast data transfer and cannot be used to send data to a multcast address. So, t s not sutable to lve broadcast TV channel. TCP also provdes an addtonal addressng mechansm wthn each host called port numbers. In addton to the host beng dentfed by a unque IP address, each TCP port number (from 0 to 65535) dentfes a unque end pont nsde the host. Ths mechansm allows for several smultaneous TCP transfers nsde the same host, usng dfferent TCP destnaton port numbers to delver each packet to the rght target end pont. A TCP packet (called TCP segment ) s sent from a uncast IP source address and a source port number to a destnaton port number at a uncast IP address. TCP s descrbed n RFC

132 UDP: Unversal Datagram Protocol: UDP s a fre-and-forget transport protocol. There s no acknowledgng mechansm between source and destnaton. Lost packets must be handled by the upper level applcaton that s usng UDP transport UDP uses source and destnaton port numbers (from 0 to 65535) to dentfy more than one end pont nsde a host. Unlke TCP, a UDP packet (called UDP datagram ) can be sent to a multcast address (more than one destnaton host) as well a uncast address (unque destnaton host). For that reason lve broadcast TV channels wll often be streamed over IP networks usng UDP based transport protocols. Snce UDP does not guarantee packet delvery at the destnaton end pont, applcatons usng UDP transport wll have to mplement adequate mechansms to handle lost packets. When streamng AV contents over an IP network, t s generally preferable to mplement error concealment mechansms to handle lost or mssng packets rather than attemptng a lost packet retransmsson. UDP s descrbed n RFC 768. RTP: Real-Tme Transport Protocol: RTP s a transport protocol that generally uses UDP transport: RTP packets are carred nto UDP datagrams (TCP/IP, 001). The UDP destnaton port must always be an even number. RTP has been desgned for the transport of real-tme content: voce (Instant Messagng or telephony over IP), vdeo, etc. IP header (0 bytes) UDP header (8 bytes) RTP header (1 +n bytes) AV payload (n bytes) The RTP header sze s generally 1 bytes, plus optonal extensons. RTP headers provde followng features that are well suted to the transport of AV payload: Payload type dentfer: MPEG-, H.63 Sequence numbers: to dentfy lost or out-of-order packets Tme stamp: to allow synchronzaton between sender and recever 106

133 Source dentfer: a 3-bt number mostly used for mult-party audo/vdeo conferences. Marker bt (M): generally used to mark a frame boundary. RTP s descrbed n RFC HTTP: Hyper Text Transport Protocol: HTTP s the transport protocol used by a web browser to download a web page from a web server (or to upload user s data). It s usng TCP as underlyng transport protocol. Snce IP STB and other networked consumer applances are by defnton connected to an IP network, usng a web browser for the user nterface s an obvous soluton. All web browsers nclude an HTTP clent that wll send commands (called methods), over TCP segments, to an HTTP server. Man HTTP methods nclude: GET: to download a web page (and bnary fles eventually) from a web server. POST: to upload data (such as a form flled by the user) to the server HTTP can also be used as a transport protocol for AV contents for example: DLNA (Dgtal Lvng Network Allance) (DLNA, 004). HTTP verson 1.1 s descrbed n RFC 616. Thus n above secton varous transport protocols have been descrbed. In addton to these AV transport protocols, IP streamng systems need sgnalng and management protocols to set up and montor the AV payload transport. Those are explored n appendx-iii. 107

134 7.3 PROTOCOL STACKS Stack Representaton As explaned n the prevous sectons, IP networks requre the use of several protocols for transmttng data from end to end. These protocols are logcally organzed as dfferent layers pled on top of each other n a stack (hence the name protocol stack ), where each protocol layer uses the servces provded by the layer underneath and, n turn, provdes ts servces to the layer above. For nstance: RTP uses UDP servces UDP uses IP servces IP uses Ethernet servces At the bottom of the stack are the network nterfaces (lke Ethernet) whle the applcaton software s shown at the top of the stack: 7.3. Data Encapsulaton When observng data crculatng on an IP network, the data structure reflects the dfferent protocol layers by wrappng each layer data nsde another data structure, n a Russan doll fashon. For nstance: A web page (HTML fle) s encapsulated nto an HTTP method An HTTP method s encapsulated nto TCP segments A TCP segment s encapsulated nto an IP datagrams An IP datagram s encapsulated nto an Ethernet frame 108

135 Applcaton Software Web Browser (HTTP Clent) RTSP Clent DHCP Clent SNMP Agent NTP Clent RTP Clent TCP UDP ARP ICMP IP IGMP Ethernet Drver (Software) Ethernet Controller (Hardware) Fgure 7.1 IP Network Stack Representaton Protocol Stack Implementaton Most operatng systems today nclude a TCP/IP protocol stack (Lnux, Wndows, VxWorks, ). All these protocol stacks mplement smlar functonaltes (IP, TCP and UDP protocols) and provde smlar nterfaces to the other software components. A protocol stack provdes a standard nterface to attach one or more network nterface drvers, such as an Ethernet drver. The exact nterface detals vary from one OS to the other, but there are generally functons to set the network nterface up or down, modfy some settngs, send data and receve data from the network. 109

136 Applcaton Layer HTTP Web Browser Transport Layer TCP HTTP Header Web Page (HTML), HTTP Method HTTP: Hyper Text Transfer Protocol Network Layer IP TCP Header HTTP Method TCP Segment TCP: Transport Control Protocol Data Lnk Layer Ethernet Drver IP Header TCP Segment IP Packet IP: Internet Protocol Physcal Layer Ethernet Controller Hardware Ethernet Header IP Packet CRC Ethernet frame Fgure 7. IP Data Encapsulaton At the top, most TCP/IP stacks provde a standard nterface called socket. Socket mplementatons are often derved from the orgnal Unx sockets and are very smlar from one OS to another. The two most wdely used types of sockets are: Stream sockets that use TCP transport Datagram sockets that use UDP transport All the TCP/IP stack components, up to the socket nterface, as well as the network nterface drver are generally runnng n kernel mode. Applcaton software usng socket nterfaces are runnng n user mode. 110

137 Applcaton S/W #1 Applcaton S/W # Applcaton S/W #3 USER Stream Socket Datagram Socket Datagram Socket Datagram Socket TCP Layer TCP/IP Protocol Stack IP Layer UDP Layer KERNEL Network Interface Ethernet Drver Ethernet Controller Fgure 7.3 Protocol Stack Implementaton Note: An IP network connected devce can have more that one network nterface. The above schematc shows a sngle Ethernet-lke network nterface. Any software task runnng n user space can open one or more sockets of ether stream or datagram type. The socket can be assocated wth a specfc UDP or TCP port number, for nstance usng the bnd() functon under Lnux, n order to receve the traffc wth ths specfc destnaton port value. Ths s generally the case for a server applcaton. If no port number s assgned to the socket, the protocol stack wll assgn a UDP or TCP port number when ntatng a connecton (TCP protocol) or sendng a datagram (UDP). Ths 111

138 s generally the case for a clent applcaton. Socket nterfaces provde read and wrte functons to send and receve data over the network. 7.4 AV CONTENT TRANSPORT FORMATS There are several formats used to transport AV content over an IP network. The followng sectons wll deal some of the most frequently used formats. AV content transport formats can be dvded nto several categores: MPEG Transport Stream based Formats: These formats use the MPEG Transport Stream format used n broadcast systems (satellte, cable, terrestral) as a frst packetzaton layer; TS packets are then aggregated nto RTP/UDP datagrams. Natve AV Content over RTP Formats: When the RTP protocol was orgnally desgned, t was ntended for each AV component (vdeo, audo) to be transmtted over a dedcated RTP stream, accordng to payload formats defned for each audo or vdeo codec. Ths s what most PC based meda players do (QuckTme, Real, ), a control protocol lke RTSP s used to set up separate RTP streams for each audo and vdeo component. Thus, each vdeo or audo stream s transported over separate RTP streams, each accordng to the RTP packetzaton format defned for ths audo or vdeo content. HTTP based Transport Formats: On an n-home network, where the dstance between the server and the recever s short (resultng n a short transmsson tme) and where there s a sngle recever (no multcast), t s possble to use ths transport protocols and formats that retransmt eventual lost packets, for a better 11

139 pcture and sound qualty. Thus, ths format s mostly used on n-home networks (lke DLNA), the AV payload s transferred just lke a data fle downloaded from a web ste, usng an HTTP GET method. The Dgtal Lvng Network Allance s actually recommendng such a meda transport system n ts gudelnes. (DLNA, 004) As mentoned above, MPEG Transport Stream based Formats s used for our applcaton, so only ths format s dscussed n detal further MPEG Transport Stream based Formats DVB IP Transport Format and Encapsulaton: DVB has created a techncal group, TM-IPI (Techncal Module, IP Infrastructure) n charge of defnng standards for IP streamng on operator networks as well as nsde the subscrber s home. The frst verson of the DVB-IP standard has been publshed by ETSI n 005: Transport of MPEG- Based DVB Servces over IP Based Networks (DVB IP TS v1.1.1). DVB-IP defnes a format usng MPEG- transport stream encapsulated n RTP over UDP, usng the IETF standard encapsulaton method defned n RFC 50. The man requrement s that a RTP packet must contan an ntegral number of MPEG TS packets. Snce the maxmum IP packet sze that can ft nto a sngle Ethernet frame (MTU) s 1500 bytes, and gven the sze of IP, UDP and RTP headers, there are generally 7 MPEG TS packets n each IP packet. IP header (0 bytes) UDP header (8 bytes) RTP header (1 bytes) 7 x TS packets (7 x 188 bytes) x 188 bytes The RTP header ncludes a tme stamp that must be derved from the sender's 90KHz clock reference (PCR) and s representng the target transmsson tme for the 113

140 frst byte of the packet. (RFC 50) The tme stamp s ntended for jtter correcton and clock recovery purposes. The RTP header also ncludes a sequence number that can be used to detect lost packets as well as out of sequence packets. Accordng to DVB (DVB IP TS v1.1.1) ths format can be used to encapsulate any MPEG- Transport Stream, whether contanng sngle PTS (SPTS) or multple programs (MPTS), wth constant bt rate (CBR) or varable bt rate (VBR). Transport streams contanng multple Program Clock References (PCRs) are, by defnton, constant bt rate streams. In practce, n most IPTV systems, the data lnk from the servers to the IP STB has a lmted bandwdth (e.g. ADSL), so a sngle program transport stream or a partal transport stream wll be used. Drect MPEG TS over UDP Format and Encapsulaton: Even though DVB-IP specfes the use of an RTP header for transportng MPEG- transport stream over IP, many actual IPTV deployments, especally n Europe, do not use RTP, but a drect UDP encapsulaton nstead. There s a proposal n DVB TM-IPI to nclude ths de facto format standard nto the next revson of the DVB-IP standard. The man reason for not usng RTP s that the tmng nformaton provded by the tme stamp are already present n the MPEG TS (PCR) and that lost packets can be detected when parsng the transport stream. IP header (0 bytes) UDP header (8 bytes) 7 x TS packets (7 x 188 bytes) x 188 bytes In ths format, an ntegral number of MPEG TS packets are transmtted n a UDP datagram. As for RTP encapsulaton, the magc number s seven MPEG TS packets n each IP packet, resultng nto a 1344-byte IP packet n each Ethernet frame. 114

141 7.5 IP STREAMING RECEIVER SOFTWARE Server Push or Clent Pull Server Push: When IPTV operators are sendng lve TV channels to several IP-STBs at the same tme, ths s called a Server Push model. Each and every recevng IP STB has to play the AV content at the same rate t s beng sent (pushed) by the server. Ths also mples that the IP STB has to synchronze ts local clock to the IPTV server va a clock recovery method. A Server Push system Allows streamng from one server to several clent recevers (multcast). Impose that each clent synchronzes ts local clock to the server s clock. Clent Pull: In a Clent Pull system, the recever s local clock s the reference clock for AV content playout, so there s no need for clock synchronzaton to the server s clock. By defnton, a Clent Pull system s a one-to-one system: t s not adapted to lve TV channels streamng to multple recevers. A Clent Pull system Is always streamng contents to a sngle clent recever. Does not force the recever to synchronze ts local clock to the server s clock. When streamng AV content to a sngle recever, a Server Push model can also be used, but t s also concevable to have the recever (clent) pacng the content delvery rate from the server ( Clent Pull model). The recever would nstruct the server va the network to send more data whenever the recever s ready to accept t. A Clent Pull method s workable n practce f the whole network path between the server and the recever has a relatvely short round trp communcaton delay and low error rate (because 115

142 any packet loss would result nto the recever askng the server for a resend). Ths would typcally be the case on the same n-home network. All Server Push systems use UDP based transport formats (wth or wthout RTP), whch allows for IP multcast streamng. Clent Pull systems could use UDP/RTP transport formats, wth another protocol (such as RTSP) for flow control nteracton wth the server, but n practce, TCP based transport s used, snce TCP has a bult-n flow control mechansm. DLNA specfed HTTP based transport s an example of a Clent Pull system MPEG TS based Recever Software Stack When usng an MPEG TS based transport format, such as DVB-IP, the clent recever software wll be able to use the exstng demultplexng resources provded by the DEMUX hardware and the other Software drvers. TS packets are receved va the approprate UDP socket nterface (wth or wthout RTP header) and coped n system memory, Then the DMA(Drect Memory Access) s programmed to nject these TS packets nto the DEMUX sub-system, usng SWTS nput. Snce the Transport Stream contans PCR and PTS tme stamps, they can be used to synchronze the audo and vdeo streams and for the head-end clock recovery. For the audo and vdeo drvers, ths njecton from memory va SWTS s essentally ndstngushable for other SWTS njecton, for nstance, when playng a stream back from a dsk drve RTP Elementary Stream based Recever Software Stack When usng an ES over transport formats, such as those defned n ISMA, the clent recever software does demultplexng of audo and vdeo, snce the dfferent audo and vdeo streams wll arrve on separate RTP streams, each on dfferent sockets. 116

143 Fgure 7.4 MPEG TS based Recever Software Stack The man ssue s that the RTP payloads are n the form of Elementary Streams and nether contan any start codes nor PTS tme stamps. As for now, Software drvers requre PES (Packetzed Elementary Stream) packets as nput. So, the RTP clent recever software wll have to artfcally reconstruct a PES packet out of the RTP payload, before submttng t to the audo or vdeo drver. A PES header must be reconstructed, wth a specfc start code for each RTP stream and a 33-bt PTS feld that wll be derved from the 3-bt RTP tme stamp. The resultng PES packets can then be fed to AUDIO or VIDEO drvers for PES parsng and further decodng. 117

144 Fgure 7.5 RTP ES based Recever Software Stack 7.6 IP STREAMING RECEIVER CLOCK SYNCHRONIZATION In Server Push systems usng UDP transport (wth or wthout RTP), the IP streamng recever system must synchronze ts local clock to the server s clock: f the local clock s even slghtly slower that the server s clock, the recever wll play the audo and vdeo payload at a slower rate than t s beng sent out by the server. Inevtably, the recever s buffers wll nevtably overflow at some tme. Smlarly, f the local clock s faster than the server s clock, the recever wll play the audo and vdeo at a faster rate than what the server s sendng out. In that case, the recever s buffers wll be empty (underflow).there are several technques that can be used n such a stuaton: ether skp or repeat a frame n the case of overflow or underflow n order to accommodate the slght 118

145 dfference n the server s and recever s clock frequences. Such a skp & repeat may produce vsble and audble artfacts n the vdeo and audo. Another technque wll am at synchronzng the recever s clock wth the server s clock, usng the tmng nformaton receved from the server. Ths clock synchronzaton s beng analyzed (secton 7.6.1) and s found dffcult due to the large jtter found n IP networks Clock Synchronzaton for TS based Transport In MPEG transport stream, the PCR tme stamps are present after every 100 ms. Each tme a PCR tme stamp s receved from the server, the correspondng local System Tme Clock (STC) s read. If the recever clock s perfectly synchronzed wth the server s clock, the PCR tme stamps should ncrease at exactly the same rate as the STC tme stamps. When plotted on a graph n Fgure 7.6, the (PCR, STC) pars should result nto a straght lne wth a slope of 1. Except, that due to the IP network jtter, the STC value wll vary and the ponts wll look more lke a cloud of ponts. However, the long term trend of ths cloud should average to a straght lne. A clock recovery algorthm s amed at computng the slope of the lne out of the accumulated (PCR, STC) pars measured over tme. If the computed slope s less than 1, the STC values grow at a slower rate than the PCR values, ndcatng that the local clock frequency s lower than the server clock frequency and should be adjusted upwards. If the slope s greater than 1, the STC values grow at a faster rate than the PCR values, ndcatng that the local clock frequency s hgher than the server clock frequency and should be adjusted downwards. A clock recovery system s essentally a feedback loop control system: the computed slope value (frequency error) s used to correct the local clock frequency (frequency syntheszer) whch results n a new STC rate of ncrease and so on. 119

146 STC STC (n) (PCR, STC) Data Ponts look lke a Cloud, due to strong Network Jtter ( ms or more ) Fndng the (PCR, STC) Lne s needed to compute the Local Clock Drft wth Respect to the Head-End Clock. Slope: must be 1. The Local Clock must be corrected (ncrease or decrease frequency) so that the slope s 1. PCR (n) PCR Fgure 7.6 PCR vs STC A basc approach to mplement such a clock recovery system s based on PLL desgn that, by contrast, provdes satsfactory clock recovery only when the network jtter s mnmzed and thus t s approprate only for conventonal network servces lke those provded by crcut-swtchng networks. A more sutable approach for packet swtchng networks s LLR based desgn. Ths approach s also not sutable for IP-STB as already explaned n chapter-. Therefore, a strong need s felt for sutable clock recovery algorthm for IP set-top box. In ths chapter, detaled study of IP envronment for developng clock recovery algorthm has been presented. The present chapter has descrbed the man techncal ssues assocated wth the applcaton of streamng AV contents over a telecom operator s IP network to an IP-STB. In-depth study of IP envronment and analyss of varous ssues helped us to develop a robust and stable clock recovery algorthm for IP-STB. Our newly developed algorthm would be presented n next chapter. 10

147 Chapter 8: Clock Recovery for IPTV In ths chapter, analyss of Jtter and color loss n IP envronment has been done. Lmtatons of exstng lnear regresson technques have been dscussed. New contnuous adapton enhancements n lnear regresson algorthm for IP envronment have been proposed. Smulaton results and performance n real envronment has been llustrated. 8.1 ANALYSIS OF JITTER AND COLOUR LOSS IN IP ENVIRONMENT IP networks are asynchronous by nature. Each packet may have a dfferent transt tme between source and destnaton. Even consecutve packets of the same sze from the same server to the same recever wll have a varable transt tme, dependng on the rest of the traffc on the network. Such a varaton of the average packet transt tme between server and recever s called network nduced jtter. Jtter on IP networks s often n the order of tens of mllseconds, sometmes several hundreds of mllseconds. In a hghly jttery IP envronment, possble sources of error are: Transmsson delay Encoder processng delay Recever processng delay Above delays can be combned nto two components latency and jtter. Mathematcally the latency s the mean delay, and the jtter s the standard devaton of the delay. The standard devaton s a measure of how wdely values are dspersed from the average value (the mean). It s the jtter component that causes the problem for clock recovery. When data s transmtted over an IP network, the data packets are collected and placed n the correct order before enterng the clock recovery process. 11

148 Fgure 8.1 Jtter dstrbuton Ths re-orderng process ntroduces a large asymmetry nto the jtter dstrbuton. Some key characterstcs of jtter dstrbutons are shown n above Fgure 8.1. The transmsson delay s composed of a few long delays, and a large number of short delays. The average of these values s the mean delay, or the average transmsson latency. The decoder can not measure the mean delay, the decoder can only detect f a packet arrves earler or later than average. Although each measurement s subject to jtter, f the tme perod T s ncreased, then the jtter becomes a smaller component of the clock dfference. Therefore for a gven jtter error, we have to average over a suffcently large tme perod T to reduce the error n the calculaton to an acceptable level. However, the recever can not afford to wat a long tme to calculate the clock frequency. So another method has to be found. Ths method s flterng, an estmate of the clock dfference s made after one or more new PCR/STC pars have been receved, and the estmates are averaged to reduce the amount of jtter. Intally ths estmate wll have a large amount of error, but ths wll reduce as more and more PCR/STC values are added to the average. The resultant averaged jtter wll reach an acceptable amount as the tme approaches T. Ths was the approach used prevously and have been dscussed n chapter 5 & 6. Our old 1

149 algorthm (chapter 5 & 6) performed well for use wth satellte and terrestral data because the amount of jtter on these networks was relatvely small. However, there s a new requrement for clock recovery to work wth data transmtted over hghly jttery IP network. Accordng to the DVB-IP standard (DVB-IP, 005), the amount of jtter expected on an IP network s typcally about 0 mllseconds, t s assumed ths s the standard devaton of the delay. However, as can be seen from Fgure 8.1, the maxmum delay s probably much larger. Values up to several hundred of mllseconds mght be experenced under some crcumstances. To avod stallng the decoder because of late packets, a buffer s generally used to store a certan amount of receved packets pror to sendng them out to the demultplexer and decodng chan: ths s called the jtter buffer. As a rule of thumb, the jtter buffer should be large enough to store at least the amount of packets that correspond to the maxmum jtter expected on the network. For nstance, f the maxmum expected jtter s 40ms peak-to-peak (recommended maxmum jtter value by DVB-IP), the jtter buffer sze should large enough to store at least 40 ms worth of AV payload packets. If the AV stream average bt rate s, say 4 Mbps, the jtter buffer sze should be at least: (4 x 10E6 x 40 x 10E-3) /8 = 0,000 bytes A second rule of thumb s to start playng out the AV payload packets when the jtter buffer s about half full as shown n Fgure 8., to further allow the buffer content to vary around ths md-pont, from almost full to almost empty. The downsde of nsertng a large buffer between the protocol stack and the AV processng (demux and decodng), s the added latency when swtchng the IP streamng recever to a new AV stream. 13

150 Packets receved at Varable Intervals from the Network Packet Packet Packet Jtter Buffer Tme Stamp N+ Tme Stamp N+1 Tme Stamp N Jtter Buffer Sze: Corresponds to the Maxmum Expected Peak-to-Peak Jtter. Packet Packet Packet Start Playng Stream when Buffer Half-Full Packets Played at Constant Rate Packet Packet Packet Packet Tme Stamp M+ Tme Stamp M+1 Tme Stamp M Fgure 8. Jtter and Latency n IP envornment The jtter buffer must frst be flushed Then the buffer must be flled up agan wth the AV payload packets correspondng to the new AV stream When the jtter buffer s about half full, then the AV playout can resume wth the new AV stream. In the DVB-IP example (40ms peak-to-peak maxmum jtter), ths would add another 0 ms to the overall channel change tme. If the jtter buffer s szed for 500 ms peak-to-peak maxmum jtter, then the addtonal latency when changng channels wll be 50 ms. As a general rule, lmtng the jtter and the need for a large jtter buffer s crucal to mprove the nteractvty of an IP streamng system. Some constrants are also posed by the output montor as well. The TV recever connected to the set top box (STB) has to locate a color burst sgnal n order to decode the color sgnal. Accordng to Robn and Pouln (000), the frequency of the color burst must 14

151 be accurate to 50 ppm that s +/ Hz at 7 MHz. In STB, f the decoder clock has a large error, then the color burst sgnal wll not be found. The requrement of fndng colour burst sgnal s mportant due to below explaned reason- When the color burst has been successfully found, a PLL n the recever s used to track subsequent changes n the color burst frequency. After samplng the small color burst sgnal at the start of each lne, the PLL generates the color reference for the duraton of each lne. If the STB frequency changes too rapdly, then a color shft s observed as the PLL momentarly losses track. Although ths s a known problem, at present no specfcaton for the maxmum acceptable rate of frequency change was found n any standard. Ths maxmum drft rate was approxmated under the assumpton that typcal tme constant for a TV PLL s 15 ms and STB drft rate tolerance should be 1000 tmes faster than ths tme constant. Under theses mentoned assumptons, we arrve at a maxmum acceptable drft rate of about 67 KHz/second. If the local clock s adjusted every 100ms, ths would lmt the FS output correcton to a maxmum of 6.7 KHz. Thus from above analyss, we conclude that to prevent color loss the local frequency overshoot should be less than 1350 Hz. (overshoot may occur, whle applyng correcton on decoder clock to acheve clock recovery). Secondly we can nfer that at present no fgures exst for the maxmum rate of change of frequency. However, larger step changes n frequency are lkely to upset the PLL crcutry n a TV montor and cause a vsble color shft. 8. NEW PROPOSED ALGORITHM FOR CLOCK RECOVERY IN IP SET-TOP BOX LLR algorthm s the smplest and most commonly appled form of lnear 15

152 regresson (Wessten- least squares, 009) and provdes a soluton to the problem of fndng the best fttng straght lne through a set of ponts. Regresson s a mathematcal procedure for fndng the best-fttng curve to a gven set of ponts by mnmzng the sum of the squares of the offsets of the ponts from the curve. The old applcaton of Least squares Lnear Regresson (LLR) algorthm for achevng clock recovery n IP envronment montors Program Clock Reference (PCR) arrval and generaton tme. Ths s done by fndng the PCR and correspondng System Tme Clock (STC) error values n consecutve samples. One of the problems of the LLR algorthm was the requrement for an addtonal dejtterng buffer to store the sample set of ncomng PCR and STC values. Moreover, the algorthm uses floatng pont precson whch may ncrease the tme for computaton and hence ncrease RTOS system nstablty for applcaton on STB. Furthermore, the frequency-drft rate of the algorthm was ndetermnstc, too. If the drft rate ncreases more than 0.1 Hz, color loss could be a potental problem Proposed Algorthm A contnuous feedback loop has been desgned to solve above mentoned problems n the LLR algorthm. In our newly devsed enhanced LLR algorthm, the X value s the PCR dfference (called PCR_dff), and the Y value s a smulated pseudo buffer level (rather montorng of STC) whch vares accordng to the sum of current errors between the PCR and STC values. The reason for ths desgn change s explaned below. Many exstng set top boxes suffer from hgh ncdence of dropped or skpped frames n DVB-IPTV envronment. Let s consder nput buffer at the decoder end, f the decoder frequency s too low, ths buffer wll overflow. The decoder can crudely correct the buffer level by skppng a frame. Smlarly, the decoder frequency that s too hgh may lead the decoder to pause as no frames are avalable to decode. On correcton of the 16

153 local frequency, the buffer level should stablze and should no longer overflow or underflow. However, the buffer may now be operatng at nearly full, or nearly empty. The natural varablty of the compressed nput data rate may well stll push the nput buffer nto an overflow or underflow state. We proposed soluton to above problem by change n clock recovery algorthm, such that errors n buffer level are corrected, rather than errors n frequency. For the purpose of clock recovery, t s not necessary to know the real nput buffer level. A smulated pseudo buffer can be created as follows: Buf _ lvl = Buf _ lvl + Err _ dff (1) Here, Err_dff s dfference of encoder and decoder clock as calculated by subtractng the PCR and STC errors. If the encoder frequency s faster than the decoder frequency, then Err_dff wll be postve, and the buffer level wll be ncreased. The true buffer level s not montored but pseudo buffer level, a functon of tmestamp errors s montored. Ths smulated buffer level s fed to LR algorthm. Fgure 8.3 Prncple of Enhanced LLR algorthm for Clock Recovery n IP envronment 17

154 18 In the enhanced LR algorthm as shown n Fgure 8.3, the X-value s PCR error called PCR_dff, and the Y value s the smulated buffer level. If a trangle s drawn usng two adjacent ponts, as shown n Fgure 8.3, then the horzontal edge represents the PCR dfference, the vertcal edge represents the Err_dff, and the gradent s the ncremental percentage error. The slope of the ftted lne s the mean percentage error n decoder frequency. If the Y-axs s drawn through the current data pont, then the Y ntercept s an estmate of the mean buffer level. The LR algorthm calculates the ntercept and slope. The algorthm mnmzes the errors by mnmzng the sum of least squares of the sample ponts. The formulae for obtanng the slope and ntercept (Wessten- least squares, 009) from N data ponts are- = = = = = = N N N N N x x N y x y x N Slope () Intercept N x m y K N N = = =.. ) ( 1 1 (3) The above values for slope and ntercept are estmates. To see how ths relates to the current applcaton, followng assumptons are made Number of data ponts are large (represented by N) PCR_dff s approxmately constant equal to L Mean of Err_dff s zero and standard devaton s σ y The encoder and decoder frequences are close that s the unfltered percentage error (σ y /L) s small, that s the slope (m) s very small compared to the ntercept.

155 Based on equaton () & (3) and applyng above assumpton, Slope error and Intercept error are derved n appendx IV at secton B and at secton B and rewrtten as below- y Slope _ Error σ L 48 5 N (4) σy Intercept _ Error (5) N As N ncreases, the error n the pseudo buffer level estmate (ntercept) reduces by a factor of 1/N 0.5, ths s the same as would be obtaned by strct averagng. However, the percentage error (slope) reduces by a factor of 1/N.5, whch s 5 tmes qucker than averagng. 8.3 ALGORITHM ENHANCEMENTS Clock recovery s contnually recevng new data, and therefore N s contnuously ncreasng. If left unchecked eventually the buffer wll overflow. Also, as tme progresses the relatonshp between the clocks may change. For nstance due to program change or temperature drft etc. Therefore, the newer data s more lkely to predct the correct frequency correcton than the older data. Three approaches are consdered for handlng these problems - Pece-wse lnear adapton Overlapped pece-wse lnear adapton Contnuous adapton Each of these approaches wll now be consdered n more detal. 19

156 8.3.1 Pece-wse Lnear Adapton Wth the pece-wse lnear method, the contnuous stream s splt nto peces, and LR s performed on each pece. The sze of each pece s mportant. Ths could be measured by usng the number of PCR values or the number of encoder clock tcks. The more data ponts n each pece, the more nose reducton s acheved. However, more data ponts also ncrease the latency before a calculaton can be made. Furthermore, as the sze of each pece ncreases, the rate at whch frequency correctons are appled s reduced. Also when the correctons are appled they occur n large steps. These large steps could upset the stablty of the algorthm, and also create other adverse effects such as color loss etc. Clearly some extra processng would be requred to cope wth these unwelcome sdeeffects Over-lapped Pece-wse Lnear Adapton In order to reduce some of the artfacts of the above technque, the peces of the LR could be overlapped. That s, a new LR analyss could be started every n data ponts, where n < N. Each LR stll uses N data ponts. The smaller the value of n, the smaller the steps szes would be on each frequency update. The down-sde of reducng n s the amount of extra processng requred. Also crcular buffers would be requred to hold the prevous (n + N) data ponts Contnuous Adapton Technque Nether of the pece-wse methods successfully addresses the ssue of weghtng the newer data more hghly than the older data. Wth both the pece-wse methods the last N data ponts are weghted equally (weght one), and older ponts are not used (weght zero). The proposed contnuous adapton method smoothly reduces the weghtng of data ponts as they age. Furthermore, wth the contnuous method, a new frequency correcton 130

157 can be produced every data pont (smlar to the overlapped case wth n = 1), and all ths s acheved wthout the extra overhead of mantanng crcular buffers. Ths contnuous adapton method has the followng 3 refnements: Exponental weghtng, X co-ordnate shft and Parameter Scalng. These wll now be dscussed n more detal Exponental Weghtng In the smple pece-wse algorthm, a data pont s used once, and then never agan. Ths s equvalent to havng a weght = 1 when t s used, and then a weght zero when t s not used. Now consder a data pont wth the followng seres of weghts 3 4 a, ab, ab, ab, ab, where a +b = 1. In the contnuous scheme, the frst tme a data pont s used t has a weght a, each subsequent tme the data pont s used the weght s reduced by a factor b. Ths acheves the goal of smoothly reducng the mportance of a data pont as t ages. Furthermore, the sum of ths nfnte set of weghts s also 1, so t has the same overall contrbuton as f t was used once only. Another feature of usng the above weghtng schedule s that t elmnates the requrement to store all the prevous data ponts. Consder how ths operates for the summaton of Y values - N N 1 N N 1 ab x = axn + b ab x (6) = 0 = 0 Ths may be relabeled as WeghtedSu mx (7) n = axn + bweghtedsu. mx n 1 The prevous weghted sum of X values s reduced by the factor b, and added to the new data value weghted by the ntal factor a. All the other sums n equatons () and (3) are smlarly updated. Therefore no crcular buffers are requred. In the pece-wse algorthms, the nose reducton was mproved by ncreasng the value of N. In the contnuous algorthm the nose reducton s ncreased by reducng the value of the parameter a. For convenence, a s expressed as a power of as follows- 131

158 = 1 (8). a Flter _ strength If Flter Strength (FS) s a postve nteger, then a s an exact power of and fast algorthms are avalable for performng the summaton updates. If the nput jtter s doubled then the value of a needs to be halved to acheve the same output jtter value. The slope and ntercept error s now calculated n appendx-iv at secton B4.1.. and at secton B as wrtten below - Weghted _ Slope _ err e a 8 y 5 σ (9) L a Weghted _ Intercept _ err σ y (10) Wth exponental weghts, 1/a seems to play a smlar role to that of the number of samples (N) n equaton (4) and (5) X Co-ordnate Shft Potentally we are now dealng wth an nfnte data stream. The PCR clock tck value (X value) could become very large. We have to keep the summaton expressed n equatons () and (3) fnte. Also, the PCR_Dff values are beng passed to the lnear regresson as the X values. These may become very large to handle. To prevent ths, X coordnate s shfted to make the newest sample at X=0 whle the older sample le n the nd quadrant. Thus another refnement s acheved by X coordnate shft Parameter Scalng Even after the co-ordnate shft, there s a possblty that under some crcumstances the summatons could overflow, Therefore, the nput values were downscaled by a on entrance to the LR routne, and the output ntercept was up-scaled by 1/a. As the slope s a rato of X and Y values, t does not requre up-scalng. The 13

159 output of ths feedback loop s used to provde the error correcton as shown n Fgure PROPOSED CONTROL FEEDBACK LOOP Fgure 8.4 Clock Recovery module usng Enhanced Lnear Regresson Fgure 8.4 shows a schematc of our proposed control feedback loop. It shows how LR algorthm nterfaces to the rest of the clock recovery algorthm. As LR algorthm flterng the data, the feedback loop tself also offers some flterng capablty. It s the flter response of the whole feedback loop, ncludng the n-loop flter that predcts the behavor of the clock recovery algorthm. A thorough understandng of how the n-loop flter nteracts wth the feedback loop s crtcal to achevng a stable soluton for clock recovery. In a feedback loop errors can buld up very easly, t s mportant to make every effort to keep the errors to a mnmum. Therefore the algorthm usng LR mantans an estmate of the local clock frequency at a hgher precson than can be acheved by the FS 133

160 hardware. Ths value s referred to as the control frequency. Once a new estmate for the control frequency s avalable t s converted to FS parameters for programmng the hardware. The quantzed output frequency of the hardware s never drectly used n the feedback loop. However the quantzed frequency does ndrectly govern the next STC measurement. As dscussed n Secton 8..1, the nputs to the Lnear Regresson algorthm are the PCR dfference, and the pseudo buffer level, and the outputs are the slope and ntercept. Another output s the weghted sum of PCR dfferences (7), ths s requred to scale the ntercept value. Ths wll be dscussed n detal below. The slope s an estmate of the mean percentage frequency error, and ndcates by how much the local clock needs correctng to make the local frequency equal to the encoder frequency. The ntercept s an estmate of the mean pseudo buffer level and ndcates how much the local frequency needs to be altered n order to return the pseudo buffer level to ts deal operatng level. Ths s a desgn goal of the newly developed algorthm. If the buffer has stablzed at ts correct operatng value, then the frequency must also have stablzed at the correct correcton value. In fact, ether the slope or ntercept can be used wth the approprate dampng factor to correct the FS frequency. However, usng both estmates provdes more flexblty n talorng the transent response of the system, For example n achevng a fast settlng tme. The slope s a rato of the frequency dfference dvded by the PCR dfference. The ntercept s the mean pseudo buffer level and has the unts of frequency. The ntercept s normalzed by dvdng by the mean PCR dfference so that the two estmates 134

161 have the same unts and can be combned. The mean PCR dfference s proportonal to the MeanPCRdff weghted sum of PCR dfferences calculated n the LR routne, as below- a WeghtedSumX = WeghtedSumX. ScaleUp. = (11) b b In above equaton (11), value of the scalng parameter = 1/a s substtuted (as mentoned n Secton ). Weghted sum needs to be stored to hgh accuracy to prevent unstable behavor. As the sum s stll n unts of percentage error, t s multpled by the prevous estmate of the control frequency to generate a frequency correcton value. The frequency correcton value s then added to the prevous control frequency to generate the new control frequency. Once the control frequency has been updated t can be used to change the programmed output frequency of the Frequency Syntheszer. The programmed output frequency s quantzed (roughly 50 Hz step sze), and s therefore not the same as the control frequency. The quantzed frequency s then used to measure the next STC tme stamp. Ths closes the feedback loop System Response The control feedback loop has been analyzed and a system response produced. When the outputs of the LR algorthm are combned, a dampng weght of α s appled to the normalzed ntercept, and a dampng weght of β s appled to the slope to acheve the fast settlng tme wthout any oscllatory behavor. The dampng parameters α and β must have a range of values for whch the system s stable, and provde a flexblty pont for tryng to meet the requred desgn goals. For a crtcally damped system α and β were derved n appendx-iv at secton D4.1. The value of α and β are rewrtten as below ( 3 3) S α = and β = bsa (1) a 135

162 where S a s a scalng parameter and s equal to a/6. a and b are the exponental weghtng parameters dscussed n Secton The scalng parameter demonstrates that whle α vares approxmately lnearly wth a, β vares as the square of a. Fgure 8.5 Quantzed Frequences n Response to 0ms Jtter Over-Dampng The frequency response shown n Fgure 8.5 shows a maxmum excurson of about 11 KHz from the nomnal frequency (7 MHz). Ths s far too large and does not meet the specfcaton for the color burst of 1350Hz (See Secton 8.1). It was analyzed that to reduce the frequency overshoot ether α or β can be reduced. However, ths wll ncrease the settlng tme. Hence, an over-dampng factor (OD) was ntroduced nto the scheme to reduce the overshoot to an acceptable level. Ths s used to reduce the values of α and β. OD effectvely ntroduces more flterng nto the feedback loop. As dscussed n secton 8.4.1, the amount of flterng provded by α and β s controlled by a scalng parameter S a. So ths s the pont at whch the overdampng s ntroduced as follows - 136

163 ( a / ) 6 S a = (13) OD Ths results n β beng over-damped lnearly wth OD, whle α s over-damped as the square of OD. It may be possble to fnd a dfferent combnaton of α and β that meets the over-shoot requrement and has a lower settlng tme. Another problem s the value OD s very much data dependant and has to be found emprcally. 8.5 MATLAB SIMULATION OF PROPOSED ALGORITHM FOR IP ENVIRONMENT Frstly algorthm has been smulated n MATLAB envronment. Followng dfferent statstcal jtter dstrbutons (Wessten- Pareto, 009), (Wessten-Webull, 009) have been studed. Pareto (Order ) Pareto (Order 3) JMB (Order 1) JMB (Order ) JMB (Order 3) Webull (Order 1) Webull (Order ) Webull (Order ) Where the order s represented by n n the followng equatons. The PDF s (Probablty Dstrbuton Functon) for these jtter models are - n Pareto ( x) = (14) n+ 1 ( x + 1) 137

164 nx JMB ( x) = (15) ( n+ 1) ( x + 1) Webull n ( n 1) x ( x) = nx e (16) By sutable choce of parameter n, these dstrbutons can all be made to approxmate the network jtter curve shown n Fgure 8.6. Fgure 8.6 Lnear Comparson of Dfferent order of Jtter dstrbuton Model In our analyss, we found that Pareto (Order ) Jtter dstrbuton s very close to real tme IP envronment so same jtter dstrbuton has been selected for testng n matlab smulaton envronment and real tme testng. Although the jtter values are selected from a statstcal dstrbuton, the actual value chosen s determned by a unform random number generator. The random generator can be seeded to produce repeatable test data. Fgure 8.7, Fgure 8.8, Fgure 8.9 and Fgure 8.10 shows the response of new LR 138

165 algorthm for Pareto- jtter dstrbuton for maxmum delays n PCR equals to 18 ms, 35ms, 5 ms and 70 ms. The decoder clock has been recovered n 0 seconds, 4 seconds, 35 seconds and 50 seconds respectvely for above four scenaros. Fgure 8.7 Performance of new LR algorthm n Matlab envronment (Pareto- for jtter 18 ms wth FS=3 OD= 4.83) 139

166 Fgure 8.8 Performance of new LR algorthm n Matlab envronment (Pareto- for maxmum delay of 35 ms wth FS=3, OD= 9.38) Fgure 8.9 Performance of new LR algorthm n Matlab envronment (Pareto- for jtter 5 ms wth FS=3 OD= 18.73) 140

167 Fgure 8.10 Performance of new LR algorthm n Matlab envronment (Pareto- for jtter 70 ms wth FS=5 OD= 18.73) 8.6 PERFORMANCE ANALYSIS OF NEW PROPOSED LR ALGORITHM IN REAL- TIME IP ENVIRONMENT As dscussed n secton 8.5, new desgned algorthm was checked n the Matlab smulaton and had proved the competency. Now, ths algorthm has been tested n real tme envronment. The algorthm was mplemented for IP complant STB RTOS envronment. Test setup for ths envronment has been shown n Fgure

168 Fgure 8.11 IP-STB clock recovery test setup As per set-up shown above, the IP stream s sent to Altronka DVS Packet Injector Devce, whch njects the MPEG stream to the DCM9900 IP streamer. IP streamer converts the MPEG stream to IP stream. The IP stream s then sent to Shunra Emulator, whch ntroduces network jtter n the stream as requred. The jttered IP stream s sent to the ST7109 SoC of IP-STB board, whch uses the enhanced LLR algorthm for clock recovery. The STB s connected to TV recever set to vew any A-V frame skps or color loss. Pareto (Order-) jtter dstrbuton was used to smulate real-tme IPTV envronment. Several PCR-STC data-set was taken from lve IP jttered VBR stream wth artfcally ntroduced jtter usng Shunra network emulator. Intal test result suggested that new algorthm couldn't stablze the clock even n zero-jtter envronment. We analyzed whole system and could suspect f new IP data path tself has not ntroduced any jtter so we frst calculated amount of average jtter n ncomng stream. To calculate jtter n any stream, PCR & STC log have been taken wthout correctng decoder clock by our clock recovery algorthm. Certan analyss and tests(test1-test4) were conducted under varous condtons wth zero jtter ntroduced by shrunra emulator 14

169 to calculate average value of jtter n ms as shown n Table 8.1 to Table 8.4. We followed the below mentoned procedure for calculatng average jtter- By subtractng consecutve samples of PCR, PCRdff n terms of tck error s calculated. For decoder clock of 7 MHz, tme delay between two consecutve PCR samples can be calculated as- PCR _ dff 7 10 PCR _ dff t ( PCR) = = 10 (17) 6 3 PCR _ dff t ( PCR)( ms) = (18) t(pcr)(ms) wll gve ndcaton that n a specfc stream f PCR s are encoded as per MPEG standard unformly at approxmately 40 ms. Smlarly, by subtractng consecutve samples of STC, STCdff n terms of tck error s calculated. For decoder clock of 7 MHz, tme delay between two consecutve STC samples can be calculated as- STC _ dff 7 10 STC _ dff t ( STC) = = 10 (19) 6 3 STC _ dff t ( STC)( ms) = (0) t(stc)(ms) wll gve an ndcaton at amount of jtter presented n a specfc stream. In next step mean value and devaton from mean s calculated. Further, average jtter (Standard devaton) usng formula STDEV (STDEV (STC_Dff0:STC_Dffn)) has been calculated, where n s number of samples taken for Jtter analyss. Test1- DCM 9900 IP streamer output was selected for VBR encodng stream at rate of 3.8 Mbps (max.) A sports channel (AV) s selected from the entre MUX and njected nto 143

170 the loop. In ths test there was no Shunra Emulator.e. no network jtter was ntroduced. Table 8.1 s shown for ths test. Table 8.1: Test1- SportsVBR3.8 - NoShunra PCR STC t(pcr) n ms= PCRdff /7000 t(stc) n ms= STCdff /7000 Mean Devaton from mean Average Jtter (ms) Observaton: Even wth zero Shunra jtter we have a net jtter of ~0ms. We were suspectng parastcal jtter beng setup n the datapath. We tred another test, by keepng n mnd that ths parastcal jtter could be compensated by ensurng an output btrate comparable wth the system capacty (0~30 ms). 144

171 Test- IP streamer O/P selected was VBR encodng stream at ncreased rate of 33.7 Mbps (max.) The entre MUX was njected nto the loop. In ths test also, Shunra Emulator s out-of-loop.e. no network jtter was ntroduced. Table 8. s shown for ths test. PCR STC t(pcr) n ms= PCRdff /7000 Table 8.: Test- AllVBR38 No Shunra t(stc) n ms= STCdff /7000 Mean Devaton from mean Average Jtter (ms) Observaton: When the varable btrate fgures around/exceeds the system capacty, jtter observed s much less here. But some parastcal jtter s stll nduced durng IP 145

172 packetzaton at DCM 9900 O/P. Another test were performed for CBR encodng stream rather VBR stream. Test3- IP streamer s O/P selected was CBR encodng stream at lesser rate of 0 Mbps (max.) The stream of a sports channel s selected from the entre MUX and njected nto the loop. In ths test also, Shunra Emulator s out-of-loop.table 8.3 s shown for ths test. PCR STC t(pcr) n ms= PCRdff /7000 Table 8.3: Test3- SportsCBR0 No Shunra t(stc) n ms= STCdff /7000 Mean Devaton from mean Jtter (ms)

173 Observaton: Ths was another confrmatory test n whch even f the nput btrate s not upto the mark, mantanng a constant output bt rate equalng system capacty (usng paddng) compensates for the jtter due to IP packetzaton. Test4 - DCM 9900 IP streamer O/P selected was CBR encodng stream at hgher rate of 40 Mbps (max.) The stream of a sports channel (AV) s selected from the entre MUX and njected nto the loop. Table 8.4 s shown for ths test. PCR STC t(pcr) n ms= PCRdff /7000 Table 8.4: Test4-SportsCBR40-NoShunra t(stc) n ms= STCdff /7000 Mean Devaton from mean Jtter (ms)

174 In ths test also, Shunra Emulator s out-of-loop.e. no network jtter was ntroduced. Observaton: Above test confrms that by ncreasng the output bt rate, IP packetzaton jtter could be mnmzed further. After above observaton (Table 8.1-Table 8.4), jtter was observed even wthout shurna emulator. Therefore, above conducted tests (Test-1 to Test-4) helped us to fnd out the causes of nstablty of new proposed algorthm. After analyzng whole system, we come-up wth some nterestng observatons regardng whole IP data path. Although, ssues n IP data path s not scope of our work, even a bref dea s mentoned below- In the data path for IP streamng from Network to Transport Stream Merger, IP packets are ntercepted by the Lnux TCP/IP Stack whch s a part of the kernel. There s a *skb ponter (socket buffer ponter) to each IP packets (1.5k max). A maxmum of 7 TS packets are present n each IP packets. NET (Network drver) regstered callback functon netsb_nethook() s called by the Lnux stack for each receved IP packets. NET does the reorderng, strpng of headers and enqueue n an enqueue lst. When njecton granularty occurs reached a pre-defned value, NET drver was njectng the packet usng Flexble Drect Memory Access to an ntermedate buffer managed by applcaton. Data flow from buffer to SWTS (Software Wrtable Transport Stream) was managed by a tme scheduled pollng task n PRM (Play Record Manager) applcaton.therefore, as explaned above, ths whole IP data path was not optmzed. Therefore, some optmzaton was needed and has been done on applcaton sde. The applcaton of optmzaton work s not under the scope of our thess but was very crtcal and mportant for our testng. In vew of above, after optmzaton n IP playback overall system, no parastcal jtter was observed and testng of new algorthm could started. 148

175 8.6.1 Matlab smulaton wth Real tme data Matlab smulaton envronment s used to calculate the value of FS & OD. It was analyzed that low value of FS causes nstablty. To handle large jtter, value of FS must be hgh. However, too hgh FS value resulted n loss of numercal precson. So, a sutable value dependng on the jtter was chosen as a compromse. Thus, to determne the optmum value of Flter Strength (FS) and OD, data set of PCR and STC has been captured wthout correcton n decoder clock. Because, wth enabled clock recovery, value of STC s beng contnuously changed (as applyng correcton on decoder clock), so that tme STC values can not gve true measure of jtter. Therefore, we captured PCR- STC data wth optmzed IP playback path n real tme and calculated jtter as shown n Table 8.5 Table 8.7. MATLAB smulaton of our algorthm for these varyng jttery streams s shown n Fgure 8.1 Fgure Matlab Smulaton of Real tme data for 0 ms jtter In ths smulaton, PCR- STC data set were captured n real tme envronment wth zero jtter ntroduced by shunra emulator. PCR-STC data stream for 0 ms jtter s shown n Table Fgure 8.1: Plot of quantzed decoder frequency for real tme data havng 0 ms jtter 149

176 PCR STC t(pcr) n ms= PCRdff /7000 Table 8.5: Real Tme PCR- STC data set (0 ms jtter) t(stc) n ms= STCdff /7000 Mean Devaton from mean Jtter (ms) Jtter analyss of stream n Table 8.5, suggest that average jtter was Above, PCR- STC data set that was captured n real tme envronment has been smulated 150

177 n matlab by choosng best sutable value of FS=3 and OD =15. Response of new algorthm n MATALB smulaton envronment s shown n Fgure 8.1. From above graph t s clear that decoder clock s stablzes at around = 600 PCR samples.e ms = 4 seconds for 0 ms jtter Matlab Smulaton of Real tme data for 40 ms jtter In ths smulaton, PCR- STC data set were captured n real tme envronment wth maxmum jtter of 40 ms ntroduced by shrunra emulator. PCR-STC data stream for 40 ms jtter s shown n Table Table 8.6: Real Tme PCR- STC data set (40 ms max jtter) PCR STC t(pcr) n ms= PCRdff / t(stc) n ms= STCdff / Mean Devaton from mean Average Jtter (ms)

178

179 Fgure 8.13: Plot of quantzed decoder frequency n matlab for real tme data havng maxmum jtter=40 ms Jtter analyss of stream n Table 8.6, suggest that average jtter n ths case was Above, PCR- STC data set for 40 ms jtter has been smulated n matlab by selectng best sutable value of FS=4 and OD =10. Response of new algorthm n matlab s shown n Fgure From above graph t s clear that decoder clock s stablzes at around = 800 PCR samples.e ms = 3 sec. 153

180 Matlab Smulaton of Real tme data for 100 ms jtter In ths smulaton, PCR- STC data set were captured n real tme envronment wth maxmum jtter of 100 ms ntroduced by shunra emulator. PCR-STC data stream for 100 ms jtter s shown n Table Table 8.7: Real Tme PCR- STC data set (100 ms max jtter) PCR STC t(pcr) n ms= PCRdff /7000 t(stc) n ms= STCdff /7000 Mean Devaton from mean Average Jtter (ms)

181

182 Fgure 8.14: Plot of quantzed decoder frequency n matlab for real data havng maxmum jtter=100ms Jtter analyss of stream n above Table 8.7, suggest that average jtter n ths case was Above, PCR- STC data set for 100 ms jtter has been smulated n matlab by selectng best sutable value of FS=6 and OD =8. Response of new algorthm n matlab s shown n Fgure From above graph n Fgure 8.14 t s clear that decoder clock s stablzes at around = 100 PCR samples.e ms = 48 sec Results of Real tme IP streams for varyng jtter As per set-up shown n Fgure 8.11, the jttered IP stream s sent to the ST7109 SoC of IP-STB board. The Stream used was VBR stream wth maxmum speed of 33.7 Mbps. The jtter ntroduced usng Shunra was second order Pareto dstrbuton wth varyng jtter. Our proposed enhanced LLR algorthm for clock recovery s beng 156

183 mplemented n ST7109 decoder chp. Response of clock recovery algorthm for varyng jtters s shown n Fgure Fgure Results of Real tme IP streams for 0 ms jtter Graphcal plot shown n Fgure 8.15 s the response of decoder frequency wth FS=4 and OD = 6 n 0 ms jtter n real tme IP envronment on IP Set-Top Box. In Fgure 8.15, PCR counts and quantzed decoder frequency s plotted. Our clock recovery algorthm s able to recover decoder clock n 6 seconds (650*40ms=6sec) Results of Real tme IP streams for 0 ms jtter Graphcal plot shown n Fg 8.16 s the response of decoder frequency wth FS=4 and OD=10 n 0 ms jtter n real tme IP envronment. In Fgure 8.16, PCR counts and quantzed decoder frequency s plotted. Our clock recovery algorthm s able to recover decoder clock n 34 seconds (850*40ms=34 sec). 157

184 Fgure 8.15 Plot of PCR count and quantzed decoder frequency for 0 ms jtter n real tme IP stream Fgure 8.16 Plot of PCR count and quantzed decoder frequency for 0 ms jtter n real tme IP stream 158

185 Fgure 8.17 Plot of PCR count and quantzed decoder frequency for 50 ms jtter n real tme IP stream Results of Real tme IP streams for 50 ms jtter Graphcal plot shown n Fgure 8.17 s the response of decoder frequency wth FS = 6 and OD= 10 n 50 ms jtter n real tme IP envronment. In above Fgure 8.17, PCR counts and quantzed decoder frequency s plotted. Our clock recovery algorthm s able to recover decoder clock n 38 seconds (950*40ms=38 sec) Results of Real tme IP streams for 80 ms jtter Graphcal plot shown n Fgure 8.18 s the response of decoder frequency wth FS = 8 and OD=10 n 80 ms jtter n real tme IP envronment. In above Fgure 8.18, PCR counts and quantzed decoder frequency s plotted. Our clock recovery algorthm s able to recover decoder clock n 44 seconds.(1100*40ms=44 sec). Fgure 8.18 Plot of PCR count and quantzed decoder frequency for 80 ms jtter n real tme IP envronment Results of Real tme IP streams for 100 ms jtter 159

186 Graphcal plot shown n Fgure 8.19 s the response of decoder frequency wth FS=9 and OD=8 n 100 ms jtter n real tme IP envronment. Fgure 8.19 Plot of Decoder Frequency vs tme elapsed n a VBR stream -nd order pareto 100 ms jttery envronment (FS =9). In above Fgure 8.19, PCR counts and tme elapsed s plotted. Our clock recovery algorthm s able to recover decoder clock n 50 seconds. However, due to a large amount of jtter, the clock frequency vares around 100 Hz. The maxmum jump s shown n nset. Clearly, the frequency drft rate s about 100Hz per second, whch s lesser than the maxmum drft rate of 6.7 KHz per second as dscussed n secton PERFORMANCE COMPARISON OF NEW PROPOSED LR ALGORITHM WITH OLD LR ALGORITHM Further, we compared our algorthm wth old method as shown n Fgure 8..0 The new algorthm was substtuted by old LR algorthm descrbed. Fgure 8.0 compares the performance of both the algorthms when subjected to a jtter of 100 ms. A crcular 160

187 buffer was mantaned nstead of contnuous adaptaton feedback loop. Fgure 8.0 Performance comparsons of old LR algorthm wth new enhanced LR algorthm for VBR (max 33.7 Mbps) -nd order pareto jtter dstrbuton. Color loss s observed when vewed on TV. Some frame-skps were also observed as the decoder s unable to track the frequency of the encoder clock. Ths was probably due to more tme taken by ths algorthm to mantan the buffer and apply correcton to the local clock. Ths lmtaton has also overcome by choosng sutable value of FS. The plot clearly suggests that orgnal LLR algorthm s not stable n RTOS constrants. However, our algorthm gves an estmate of the hgher jtter attenuaton and faster response tme. Table 8..8 shows the relatve settlng tmes of LMS, LLR and enhanced LLR algorthms. FS values correspondng to the broadcast stream for the enhanced algorthm are also shown. Table 8.8 shows the performance comparsons of these algorthms when subjected to low jtter envronment to hgh jtter envronment. Results clearly suggest that whle LMS & LLR fals to sustan n hgh jttery envronment, wth 161

188 our desgned Enhanced LLR mplementaton no frame skp or color loss has been observed. TABLE 8.8 Performance Comparson of OLD LLR and enhanced LLR Broadcast medum Peak Jtter (ms) Settlng Tme (sec) LMS LLR[3] New LLR DVB-S FS DVB-T DVB- IPTV CONCLUSION In ths chapter large jtter n IP envronment has been analyzed. Dffcultes n older algorthms are explored and new algorthm has been presented. Superorty of newly developed algorthm over other has been llustrated wth varous results and graph. The clock stablzes n around 50 seconds only even wth 100 ms jtter, dsplayng hgh jtter attenuaton and fast response Furthermore, no color loss or audo-vdeo frame skps were observed under these jttery condtons. The stablty of the algorthm n RTOS envronment follows from the fact that audo-vdeo decodng went smoothly usng the algorthm. 16

189 Chapter 9: Audo-Vdeo Synchronzaton In ths chapter, detaled analyss of Audo Vdeo Synchronzaton (AV Sync) module has been done. Audo-Vdeo Synchronzaton has always been proved dffcult to mplement n STB. Ths chapter s motvated by a revew of exstng mplementaton of Audo vdeo sync software n Set-top box, explores the problem and provdes some possble solutons. A smple mplementaton that n prncple offers better synchronzaton accuracy than can currently be acheved s a key objectve. 9.1 INTRODUCTION TO AUDIO VIDEO SYNCHRONIZATION (AV SYNC) As explored n earler chapters, Clock Synchronzaton s an mportant part of the MPEG standard and ensures smooth operaton of the MPEG decoder. It s mportant to menton here that clock synchronzaton have two concepts Clock recovery and AV sync- Clock recovery at STB decoder-end to recover the encoder clock so that audo and vdeo streams are played at the same speed at whch they are processed at encoder sde. It also ensures that audo and vdeo bt buffers (BB) should not suffer from underflow or overflow. Ths aspect have been addressed n chapter 5 to chapter 8. AV sync s synchronzaton mutually between audo and vdeo. Accurate AVsync (Lp-Sync) s mandatory for correct user experence as TV vewer expects to hear and see matchng lps movement n the pcture. In ths chapter, ssue of AV sync problem for dual vdeo STB and possble solutons has been presented. The clock recovery and lp Sync mechansm are needed ndvdually or smultaneously dependng on STB use cases as shown n Fgure 9.1 to Fgure

190 Fgure 9.1 Standard MPEG system: Full clock recovery s mandatory wth PCR, Lp Sync wth PTS/STC s also needed Fgure 9. One program n Full screen+ PIP (Pcture In Pcture): Full clock recovery + Lp sync wth PTS/STC for full screen program, PIP s ether free runnng or vdeo synced Fgure 9.3 Vdeo only (Mosac): clock recovery s mandatory, but Lp Sync s not needed Fgure 9.4 Audo only: Full clock recovery s mandatory, but Lp Sync s not needed Fgure 9.5 DVR (recorded system): clock recovery s not needed, but Lp-Sync s mandatory 164