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
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)
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.
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]
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.
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
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
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
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
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 5 1.3 Objectves of the Thess 6 1.4 Methodology adopted for the Research Work 7 1.5 Scope of the Thess 9 1.6 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 35 3. MPEG Standard Overvew 37 3.3 Part of MPEG Standard 39 v
TABLE OF CONTENTS (Contd...) 3.4 MPEG System Layer 41 3.4.1 Elementary Stream (ES) 43 3.4. Packetzed Elementary Stream (ES) 43 3.5 MPEG Multplexng Layer 47 3.5.1 MPEG Transport Stream 49 Chapter 4 Set-Top Box System 4.1 Introducton 59 4. Set-Top Box components 60 4..1 The Network Interface 60 4.. The Decoder 61 4..3 The Buffer 61 4..4 Synchronzaton hardware 61 4.3 Set-Top Box functon 6 4.4 Functonng of STX7109 HDTV Set-Top Box decoder chp 64 Chapter 5 Clock recovery for Satellte TV 5.1 Introducton to Clock synchronzaton 69 5.1.1 Voltage controlled Oscllator based clock recovery module 73 5.1. FS based clock recovery module 74 5. Analyss of Jtter n DVB-S Envronment 74 5.3 Movng wndow Basc Averagng algorthm FOR DVB-S Broadcastng 75 5.3.1 Flter parameters 76 5.3.1.1 PCR_DRIFT_THRESHOLD 77 5.3.1. MIN_SAMPLE_NUM 77 x
TABLE OF CONTENTS (Contd...) 5.3.1.3 MAX_WINDOW_SIZE 78 5.3. Error calculaton and applyng correctons 78 5.4 Performance of Movng wndow Basc Averagng algorthm 81 5.5 Concluson 83 Chapter 6 Clock recovery for Terrestral TV 6.1 Analyss of Jtter n DVB-Terrestral Envronment 84 6. Lmtaton of DVB Terrestral Broadcastng 86 6.3 Movng wndow Weghtng FIR flter algorthm for DVB-T Broadcastng 88 6.3.1 Low Pass Flter 89 6.3. Movng wndow Weghtng FIR flter algorthm 89 6.3.3 Applyng Correctons 91 6.4 Closed loop analyss of proposed algorthm 9 6.5 Performance of proposed algorthm for Terrestral Broadcastng 96 6.6 Concluson 99 Chapter 7 IP Streamng: Detaled Analyss n IP Envronment TV 7.1 IP Network Interface 101 7.1.1 Networkng Technologes 101 7. IP Protocols sute 10 7..1 Uncast and Multcast 10 7.. IP Protocols Byte and Bt Representaton 103 7..3 Transport Protocols 104 7.3 Protocols stacks 108 x
TABLE OF CONTENTS (Contd...) 7.3.1 Stack Representaton 108 7.3. Data Encapsulaton 108 7.3.3 Protocol Stack Implementaton 109 7.4 AV Content Transport format 11 7.4.1 MPEG Transport Stream based format 113 7.5 IP streamng recever software 115 7.5.1 Server Push or Clent Pull 115 7.5. MPEG TS based Recever Software Stack 116 7.5.3 RTP Elementary Stream based Recever Software Stack 116 7.6 IP streamng recever clock synchronzaton 118 7.6.1 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 11 8. New proposed Algorthm for clock recovery n IP Set-top box 15 8..1 Proposed algorthm 16 8.3 Algorthm enhancements 19 8.3.1 Pece-wse Lnear Adapton 130 8.3. Over-lapped Pece-wse Lnear Adapton 130 8.3.3 Contnuous Adapton technque 130 8.3.3.1 Exponental Weghtng 131 8.3.3. X Co-ordnate Shft 13 8.3.3.3 Parameter Scalng 13 8.4 Proposed feedback loop 133 8.4.1 System response 135 x
TABLE OF CONTENTS (Contd...) 8.4.1.1 Over-Dampng 136 8.5 Matlab smulaton of Proposed algorthm for IP envronment 137 8.6 Performance analyss of new proposed LR algorthm n real tme IP envornment 141 8.6.1 System Matlab smulaton wth real tme data 149 8.6.1.1 Matlab Smulaton of Real tme data for 0 ms jtter 149 8.6.1. Matlab Smulaton of Real tme data for 0 ms jtter 151 8.6.1.3 Matlab Smulaton of Real tme data for 100 ms jtter 154 8.6. Results of Real tme IP streams for varyng jtter 156 8.6..1 Results of Real tme IP streams for 0 ms jtter 157 8.6.. Results of Real tme IP streams for 0 ms jtter 157 8.6..3 Results of Real tme IP streams for 50 ms jtter 159 8.6..4 Results of Real tme IP streams for 80 ms jtter 159 8.6..5 Results of Real tme IP streams for 100 ms jtter 159 8.7 Performance Comparson of new proposed LR algorthm wth old LR algorthm 160 8.8 Concluson 16 Chapter 9 Audo Vdeo Synchronzaton 9.1 Introducton to Audo Vdeo synchronzaton (AV sync) 163 9. Audo Vdeo synchronzaton defnton 166 9.3 Proposed enhancement n exstng schemes 170 9.3.1 Improvng tmng accuracy 170 9.3.1.1 Tmng mprovements by local clock tck quantzaton 170 x
TABLE OF CONTENTS (Contd...) 9.3.1. Tmng mprovements by correct nterrupt 171 handlng 9.3.1.3 Tmng mprovements by software schedulng Optmzaton 171 9.3. Improvng quantzaton accuracy 171 9.3..1 PTS Quantzaton 171 9.3.. Arthmetc Quantzaton 17 9.3..3 Audo Quantzaton 17 9.3..4 Vdeo Quantzaton 17 9.4 Proposed AV sync desgn varaton 173 9.4.1 Mnmze Control Complexty 175 9.4. Mnmze Hgh Qualty Error 176 9.4.3 Mnmze Memory Requrements 178 9.5 Test setup for AV sync problem 179 9.6 Concluson 180 Chapter 10 Results and Conclusons 10.1 Summary of results 181 10. Conclusons 186 10.3 Specfc Contrbutons 187 10.4 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
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
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 4 3.1 Evoluton of MPEG 35 3. Summary of MPEG Compresson Capablty 39 3.3 Formaton of MPEG stream 4 3.4 PES Packet Schematc 43 3.5 Detaled structure of PES Packet 45 3.6 Functonal Block dagram of Standard MPEG 49 3.7 MPEG Transport Stream 50 3.8 Detaled Syntax of Transport stream 5 3.9 Three types of TS Packets 53 3.10 Example of PSI Tables 57 3.11 PSI Table Structures 57 4.1 Schematc of Dgtal Set-Top Box 63 4. 7109 block dagram 66 5.1 PCR mechansm 70 5. PCR mechansm n Transport Stream 71 5.3 Tmng Dagram n a Typcal Set-top Box 7 5.4 VCXO based clock recovery 74 xv
Fgure No Ttle Page No 5.5 Generalzed Desgn of PLL based Clock Recovery 76 5.6 Concept of Movng Wndow 79 5.7 Behavor of algorthm as smulated n Matlab for Satellte data wth P=50, S=10, M=80 5.8 Input PCR Count vs Decoder Frequency graph demonstrate behavor of Proposed Algorthm n Satellte Envronment 8 83 6.1 Hardware Setup 85 6. PCR samples Arrval tme n Terrestral Envronment 87 6.3 Frequency Error Samples n Terrestral Envronment 87 6.4 Feedback Loop expressed as Z transform 94 6.5 Behavor of smulated algorthm n MATALAB for terrestral data wth P=1000, S=50, M=150. 6.6 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) 96 98 99 7.1 IP Network Stack Representaton 109 7. IP Data Encapsulaton 110 7.3 Protocol Stack Implementaton 111 7.4 MPEG TS based Recever Software Stack 117 7.5 RTP ES based Recever Software Stack 118 7.6 PCR vs STC 10 8.1 Jtter dstrbuton 1 8. Jtter and Latency n IP envronment 14 xv
Fgure No 8.3 Ttle Prncple of Enhanced LLR algorthm for Clock Recovery n IP envornment Page No 17 8.4 Clock Recovery module usng Enhanced Lnear Regresson 135 8.5 Quantzed Frequences n Response To 0ms Jtter 136 8.6 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) 138 139 140 140 141 8.11 IP-STB clock recovery test setup 14 8.1 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 149 153 156 157 158 158 159 xv
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 160 161 164 164 164 164 164 9.6 Audo errors wth respect to slower vdeo rate 167 9.7 General Dsplay Tmng 173 9.8 Mnmze control complexty 176 9.9 Mnmze FR Error 177 9.10 Mnmzng memory requrement 178 9.11 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
LIST OF TABLES Table No Descrpton Page No 3.1 PES Scramblng control 45 3. PSI Table 54 3.3 Example of PAT for Three Program Multplex 55 3.4 Example PMT for Program 55 3.5 Example CAT for Program 56 6.1 Effect of Terrestral Parameters on Jtter 97 8.1 Test1- SportsVBR3.8 - NoShunra 144 8. Test- AllVBR38 No Shunra 145 8.3 Test3- SportsCBR0 No Shunra 146 8.4 Test4-SportsCBR40-NoShunra 147 8.5 Real Tme PCR- STC data set (0 ms jtter) 150 8.6 Real Tme PCR- STC data set (0 ms max jtter) 151 8.7 Real Tme PCR- STC data set (100 ms max jtter) 154 8.8 Performance Comparson of OLD LLR and enhanced LLR 16 9.0 STB customer s Audo Vdeo Sync requrement 165 xx
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
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
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
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
α β 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
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 1939. 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
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).
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
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
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
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
. 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
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
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
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
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
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
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
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
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
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
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
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 7..1.1, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,13818-1; MPEG,13818-; MPEG,13818-3).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 (MPEG1 1117-1; MPEG1 1117-; MPEG1 1117-3; 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 13818. 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
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
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 13818-1: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 13818-: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
ISO/IEC 13818-3: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 13818-4:1998 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 4: Conformance testng (avalable n Englsh only) ISO/IEC TR 13818-5:1997 Informaton technology -- Generc codng of movng pctures and assocated audo nformaton -- Part 5: Software smulaton (avalable n Englsh only) ISO/IEC 13818-6: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 13818-7: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 13818-9: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
ISO/IEC 13818-10: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 13818-1 and as ITU-T Rec. H..0. The vdeo and audo data s encoded as descrbed n ITU-T Rec. H.6 ISO/IEC 13818- and ISO/IEC 13818-3. 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
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
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. 3.4. 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 65536 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
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 '0000 0000 0000 0000 0000 0001' (0x000001). The followng well-known stream IDs are defned n the MPEG standard: 1. 110x xxxx - MPEG- audo stream number x xxxx.. 1110 yyyy - MPEG- vdeo stream number yyyy. 3. 1111 0010 - 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
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
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
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
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
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 3.4 3.5.1 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 13818- and ISO/IEC 13818-3 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
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 (0100 0111). 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
. 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
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
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
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
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 3 4 64 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
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 1 01 0 3 03 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
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
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
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
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. 4..1 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
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. 4..3 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. 4..4 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
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
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
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
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
Fgure 4. 7109 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
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
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
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
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
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 + 5.4 KHz. Total error n the system s 810+5.4 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
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
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
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
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
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 = [7000000 / (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. 5.3.1 Flter Parameters Here we wll dscuss three man parameters as per below- 76
5.3.1.1 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. 5.3.1. 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
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 0. 5.3.1.3 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. 5.3. 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
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
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 = (000+000+000+0)/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
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 5.7. 81
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 = 300. 8
Fgure 5.8 Input PCR Count vs Decoder Frequency graph demonstrate behavour of Proposed Algorthm n Satellte Envornment wth P=300, S=10, M=50 5.5 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
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
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 300744, 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
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
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
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
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. 6.3.1 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. 6.3. 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
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
centre exst n the wndow, however the samples at the edges may not have ther complments n t. 6.3.3 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
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
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
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
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 1 1 + 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
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=150. 96
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 = 10000 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
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= 30000 for the worst-case terrestral condtons wth Guard nterval = 1/4, 64 -QAM, FEC=7/8. 98
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
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
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 7.1.1 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
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
dsplayed usng a so-called byte decmal notaton, such as: 19.168.1.100, 17.0.0.1, 55.55.55.55, or 164.19.119.51, 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 4.0.0.0 to 39.55.55.55 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
0 1 3 0 1 3 4 5 6 7 8 9 0 1 3 4 5 6 7 8 9 0 1 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For nstance, the 3-bt value x1345678 s represented as follows: 0 1 3 0 1 3 4 5 6 7 8 9 0 1 3 4 5 6 7 8 9 0 1 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 0 0 1 0 0 1 0 0 0 1 1 0 1 0 0 0 1 0 1 0 1 1 0 0 1 1 1 1 0 0 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 0x7856341 nstead of 0x1345678. 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. 7..3 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
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 793. 105
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
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 3550. 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
7.3 PROTOCOL STACKS 7.3.1 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
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 7.3.3 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
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
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
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
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. 7.4.1 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 10034 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) 40 + 7 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
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 10 034 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) 8 + 7 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
7.5 IP STREAMING RECEIVER SOFTWARE 7.5.1 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
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. 7.5. 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. 7.5.3 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
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
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
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. 7.6.1 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
STC STC (n) (PCR, STC) Data Ponts look lke a Cloud, due to strong Network Jtter (10-100 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
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
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
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
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
be accurate to 50 ppm that s +/- 1350 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
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. 8..1 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
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
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- = = = = = =.. 1 1 1 1 1 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.
Based on equaton () & (3) and applyng above assumpton, Slope error and Intercept error are derved n appendx IV at secton B4.1.1. and at secton B4.1.1.1 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
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. 8.3. 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. 8.3.3 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
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. 8.3.3.1 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
= 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 B4.1..1 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). 8.3.3. 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. 8.3.3.3 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
output of ths feedback loop s used to provde the error correcton as shown n Fgure 8.4. 8.4 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
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
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 8.3.3.3). 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. 8.4.1 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
where S a s a scalng parameter and s equal to a/6. a and b are the exponental weghtng parameters dscussed n Secton 8.3.3.1. 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 8.4.1.1 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
( 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
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
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
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
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 8.11. 141
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
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 7 10 3 t ( PCR) = = 10 (17) 6 3 PCR _ dff t ( PCR)( ms) = (18) 3 7 10 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 7 10 3 t ( STC) = = 10 (19) 6 3 STC _ dff t ( STC)( ms) = (0) 3 7 10 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
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) 5564347885 536739566 ----------- ---------- 35.4309 ---------------- 3.6686 5564441463 536786855 34.57919 1.751444 33.49164556 5564538889 53814889 36.1617 50.4348-15.18039148 5564630331 53957138 34.50007 5.70181-17.4587481 5564791359 53968614 35.964.15037 33.1180596 5564818588 54101051 34.34181 51.57174-16.3865074 5564917576 54447548 35.44956 5.833-17.59013 5565016457 54506883 35.16.197593 33.04549741 55651076118 543930043 35.1763 5.70963-17.46653963 5565016165 545345549 34.81656 5.4615-17.18305815 5565963691 54539181 35.09356 1.713444 33.5964556 5565395103 546787941 35.60785 51.70848-16.46539148 55654879039 54800158 35.33096 5.30433-17.0614333 55655813745 54846913 34.61874 1.731667 33.5114333 55656770884 549684703 35.44959 53.5148-18.00839148 556577397 551076484 35.60789 51.54744-16.30435444 55658688370 551137 35.41011 1.749556 33.49353444 5565967969 55538099 36.71563 5.38433-17.1414333 55660601580 553930536 34.144 51.57174-16.3865074 556615699 553987939 35.60785.16037 33.1170596 5566514790 555390630 35.5178 51.9515-16.708485 5566346876 556809934 35.33096 5.56681-17.337481 55664394885 556867961 34.3019.149148 33.09394185 55665361640 558307689 35.80574 53.336-18.0801696 55666301687 55969536 34.81656 51.39396-16.1508796 556675885 559754589 35.44956.19496 33.04816407 55668198874 56116517 34.81663 5.14548-16.9039148 55669154946 56553758 35.41007 51.5744-16.8435444 55670103538 56611965 35.13304.155815 33.0877519 5567106814 56398451 35.5874 50.8541-15.5831741 5567006067 56543461 34.9353 53.70407-18.46098407 556797816 565494305 36.0035.385 33.0193815 5567395687 566885017 35.0935 51.50785-16.6476185 55674871076 56895678 35.01441 5.467-17.0036137 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
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) 63690707008 754570888 ----------- ----------- 8.66768 ---------------- 6.153074 6369077154 7546060088 3.89681 9.963-0.56194963 63690836595 754657458 3.97604 19.05533 9.61346667 63690937080 754764778 37.38833 38.89615-10.846815 6369100636 754860477 4.09467 3.54441 5.137593 636910960549 754917196 34.7375 33.75737-5.08969037 63691166060 754983710 4.64856 4.14015 4.5753185 6369150979 755064096 3.14515 30.31059-1.6491593 63691361531 75515370 37.4785 3.63607-3.968394074 636913904611 755165987 3.81778 3.80433 4.863346667 636914837181 7553049739 34.53963 3.73156-4.063875556 636915494148 7553764301 4.3311 6.4656.040741 63691615111 755440071 4.33 3.6111 5.046568889 636917164869 7555385459 37.54656 36.4178-7.754097778 6369177887 755603879 3.10567 4.1975 4.470161481 63691874658 755695539 35.33096 33.8448-5.174801481 636919380395 755761785 3.61989 4.640 4.07457778 6369003473 75583018 3.8177 5.34789 3.319791111 6369109753 75593647 37.6963 34.46033-5.79653333 63691676036 755991041 3.93641 5.1041 3.5657593 636963109 7560836775 35.41011 34.30974-5.64060741 6369366643 7561504669 3.5016 4.73681 3.930865185 63693917199 75618967 4.09467 5.36881 3.98865185 63694564550 756834708 3.97596 3.89189 4.775791111 63695568694 756380960 37.1905 36.5785-7.86017185 63696514083 7564787489 35.01441 35.79737-7.1969037 6369715999 7565440664 3.89689 4.19167 4.476013333 636978674 7566063133 4.56944 3.05441 5.6137593 6369844866 7566688791 3.18474 3.175 5.495161481 6369946669 756768335 37.70481 36.79793-8.1304596 636930100156 756837366 3.46163 5.6047 3.0697696 636931047681 75696368 35.0935 3.9637-4.9603704 63693169898 756995340 3.89693 5.54585 3.1188148 63693338113 7570605937 3.89685 4.1673 4.500383704 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
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) 55643484763 4646706703 ------------- ----------- 35.407 ----------------- 3.38957 556444808 46467909584 34.7441 31.1993 3.969953704 55645403489 46468963793 36.315 39.04478-10.37709778 5564639351 464698616 34.9119 31.8086-3.14057959 556479584 46470865556 35.7953 38.6741-9.95977407 5564831838 46471897871 34.66719 38.3389-9.56608889 55649184093 464775536 35.687 31.7546-3.08657959 5565013635 464737968 35.6885 38.4193-9.7544596 55651088609 46474649100 35.6878 31.7119-3.053505185 55650665 4647568336 34.7433 38.30467-9.636986667 5565978910 4647660770 35.6881 34.015-5.55468148 55653931167 46477450335 35.6878 31.463 -.55694963 55654885455 4647849768 35.344 38.78863-10.1094963 5565583499 46479341058 34.7437 31.3815 -.570468148 55656775757 46480388010 35.6881 38.776-10.1083 55657740196 464813844 35.71996 31.49681 -.89134815 55658694486 464886396 35.34407 38.81378-10.14609778 55659687351 4648334313 36.7778 39.13837-10.47069037 55660611183 46484193164 34.16 31.4867 -.814986667 55661577653 4648534730 35.79519 38.5765-9.908838519 556659909 46486091318 35.6874 31.7548-3.057801481 5566348168 4648719551 35.6885 38.45307-9.785394074 55664405998 46487979778 34.1593 31.48989 -.808889 5566537470 4648900796 35.7956 38.556-9.88854 55666310514 4648987413 34.7437 31.60504 -.937357037 556676769 46490909970 35.687 38.36437-9.69669037 556680845 4649176750 34.81763 31.58444 -.916764444 5566916786 4649805364 35.7004 38.61533-9.947653333 55670107359 46493661440 34.8175 31.7065-3.038838519 55671071799 46494585178 35.7 34.15-5.544838519 5567011874 4649560015 34.81759 38.373-9.65961696 556799058 4649648703 36.4644 3.11141-3.44377407 55673930601 46497518969 34.8175 38.0-9.5554 5567488089 4649837885 35.19363 31.8465-3.178838519 146
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) 55643480171 6816799887 ------------ ---------- 35.4076 ---------------- 1.66178 5564441816 6817770087 34.7441 35.93333-0.69573333 55645391791 6818707517 36.05833 34.71963-6.05194963 55646379 6819646095 34.47919 34.7615-6.094468148 5564796306 68064166 36.05841 36.8785-8.0517185 556480138 68155813 34.16 33.74633-5.078653333 55649179501 6853500 35.53196 36.3847-7.71703704 55650131760 68350977 35.6885 36.09359-7.4591593 55651084016 68449515 35.6874 34.066-5.39854 55650060 685340648 34.7437 33.74567-5.077986667 556596711 6868568 35.00559 35.0016-6.33357959 5565396575 68779308 35.53 36.80096-8.1338963 55654885940 68838855 35.5304 35.53878-6.871097778 55655816876 689138348 34.47911 33.31456-4.646875556 5565677640 683017610 35.53 36.63933-7.971653333 55657735605 6831171679 35.5304 38.669-10.00154 55658694971 683040105 35.5307 3.16393-3.4964596 5565968759 68398599 36.58474 35.00719-6.339505185 55660606591 6833895986 34.16 33.7915-5.061468148 55661565953 6834906968 35.53193 37.44378-8.776097778 556651811 6835838476 35.6881 34.5003-5.8361696 55663470470 68368614 35.6885 36.580-7.9154 55664401406 68377605 34.47911 33.33567-4.667986667 55665367878 6838711879 35.7956 36.50644-7.838764444 5566630591 6839633363 34.7433 34.1904-5.461357037 556676583 6840617138 35.53193 36.43611-7.768431111 556680339 684150331 34.7444 33.45159-4.78391593 5566916694 684519114 35.5304 36.99196-8.348963 55670107844 684349014 35.00556 33.7-5.033 5567106707 684438973 35.53196 35.33181-6.664134815 556701358 684534559 35.00559 34.87356-6.05875556 5567985936 6846335384 36.05844 37.43796-8.7708963 55673931086 684786300 35.00556 35.1911-6.551431111 5567487637 6848190474 35.00559 33.48793-4.804596 147
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
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 8.14. 8.6.1.1 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 8.5-. Fgure 8.1: Plot of quantzed decoder frequency for real tme data havng 0 ms jtter 149
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) 1081188 400530910 --------- --------- 3.999876419 ----------------- 0.080957 16376 4005416567 4.0044 3.968685 0.03119134 34106 4005570 3.995 4.1046-0.10549507 4314 4005633448 4.0044 3.941704 0.05817715 5400864 40057414413 3.995 3.999744 0.000131975 64805 4005846777 4.0044 3.90133 0.09854679 756070 40059581505 3.995 4.14937-0.15060618 8641890 400606586 4.0044 3.967856 0.0300864 970540 4006178009 3.995 3.98159 0.01771716 1080178 400683788 4.0044 4.058441-0.0585643 11880378 40063889774 3.995 3.948096 0.05178013 1961566 40064956786 4.0044 3.951896 0.04798013 1404016 40066068971 3.995 4.11904-0.1193785 1511404 40067135544 4.0044 3.9507 0.049606049 1600054 400683111 3.995 4.057693-0.057816173 17814 4006969854 4.0044 3.847159 0.1571716 1836430 4007038183 4.0044 4.118437-0.118560618 19441080 40071445159 3.995 3.93848 0.0616871 0568 400751690 4.0044 3.953819 0.046057901 1600918 4007368875 3.995 4.134019-0.13414099 68106 40074691131 4.0044 3.93481 0.065594938 3760756 40075755637 3.995 3.94615 0.05761604 4841944 400768606 4.0044 3.964537 0.03533938 590594 4007793570 3.995 4.109778-0.109901359 700178 4007901118 4.0044 3.983059 0.01681716 808043 40080068790 3.995 3.91767 0.0860975 916160 4008118195 4.0044 4.17-0.1845803 304070 40085399 3.995 3.964719 0.035157901 3131458 40083313979 4.0044 3.931778 0.068098641 3400108 4008446119 3.995 4.119037-0.119160618 3348196 4008549045 4.0044 3.947874 0.0500345 3456484 40086557345 4.0044 3.945556 0.05430864 35641134 40087643530 3.995 4.0907-0.03030988 3673 40088738051 4.0044 3.968685-0.05390506 Jtter analyss of stream n Table 8.5, suggest that average jtter was 0.080957. Above, PCR- STC data set that was captured n real tme envronment has been smulated 150
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 0.6 10 3 = 600 PCR samples.e. 600 40ms = 4 seconds for 0 ms jtter. 8.6.1. 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 8.6-. Table 8.6: Real Tme PCR- STC data set (40 ms max jtter) PCR STC t(pcr) n ms= PCRdff /7000 14796034 71384899 t(stc) n ms= STCdff /7000 14904151 7133888636 39.95 40.3696 Mean 39.99909 Devaton from mean - 0.370165855 Average Jtter (ms) 4.551915 1501016 7134953738 40.044 38.531 1.468093405 15101350 713613904 39.95 39.448 0.55087118 1580000 713740514 40.044 43.33948-3.340388077 153361188 7138956 39.95 47.4559-7.453499188 15444376 7139651913 40.044 30.53474 9.46435664-1555106 7140486974 40.044 5.67967 1.6805736 1566014 7141498576 39.95 30.9819 9.07090819 157680864 71461677 40.044 37.46674.5335664-1587605 7143676860 39.95 41.63 1.63906595 15984070 7144750144 40.044 39.41419 0.58490819 16091890 714578611 39.95 39.7516 0.47834145 151
16000540 7146867785 40.044 38.395 1.759574886 16308178 7147961987 39.95 40.19163-0.195365 164160378 7149080531 40.044 40.56-0.56906595 16541566 715014510 39.95 41.4756-1.4846151 1663016 715185703 40.044 39.4856 0.570537849-167401404 71599530 39.95 4.4448.45388077 168480054 7153617576 40.044 37.54915.44994556 1695614 7154718898 39.95 48.8165-8.81745114 17064430 7155544093 40.044 40.7897-0.79061099 17171080 7156581190 40.044 30.5678 9.43631567 178068 7157693749 39.95 38.411 1.588093405 173880918 715884571 40.044 41.0589-1.06795484 17496106 715989954 39.95 4.54896 -.549869558 176040756 716107579 40.044 36.56974 3.4935664-17711944 7161978774 39.95 46.1415 6.143054744 17800594 716317986 40.044 33.44378 6.55531567-1798178 716411096 39.95 44.46341 4.464314003 18036043 7165388841 40.044 38.1519 1.78390819-18144160 7166355157 39.95 43.6019 3.61091781 185070 7167464461 40.044 35.78948 4.0961193 183601458 7168656387 39.95 41.08533-1.0863999 184680108 71696971 40.044 44.14541-4.146314003 18576196 7170897415 39.95 36.0374 3.96635664-18684484 717179859 40.044 46.9683 6.969089 18791134 717888468 40.044 33.37459 6.6450081-189003 717390115 39.95 40.36811 0.369017706 15
19008097 717504500 40.044 37.50915.48994556 19116160 7176160453 39.95 4.3648 -.363388077 1940810 717711898 40.044 41.313-1.313906595 19331998 7178589051 39.95 35.60907 4.390019331 194400648 717939969 40.044 54.339-14.3399066 195481836 7180416459 39.95 30.00807 9.991019331 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 4.551915. 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 8.13. From above graph t s clear that decoder clock s stablzes at around 0.8 10 3 = 800 PCR samples.e. 800 40ms = 3 sec. 153
8.6.1.3 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 8.7-. 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 43.65455096 Devaton from mean Average Jtter (ms) 19.3083 704160486 1795598 -------------- ------ 4.055773177 70541674 1795769 39.95 39.59878 1.759954-7063034 179669 40.044 1.90156 16.59748608 70740151 17965597 39.95 60.504 11.373176-70848016 17970469 40.044 3.8133 10.4698194 709561350 17973501 39.95 54.1437 9.958773177 710640000 17975710 40.044 33.69578 19.1160344-71171188 1798795 39.95 4.5385 35.065531 7180376 17984636 40.044 78.7007 3.18855096 71388106 1798731 40.044 0.466 13.9347688 7149614 1799103 39.95 9.73107.37180585 716040864 17993093 40.044 41.3737 0.75436577-717105 1800094 39.95.90019 36.36359719 7180070 18003548 40.044 80.01815 7.50881015 71981890 18008654 39.95 36.14574-13.07989349 750378 18015703 40.044 56.73444-34.67685645 73601566 18018548 119.944 78.33141 1.0486503-7468016 180955 40.044 31.60593 5.309819415 154
75761404 180969 39.95 48.96437-30.50518979 76840054 1803514 40.044 74.15974 11.6056991-7900430 18037807 39.95 3.04885 15.1576717 730081080 1804036 80.088 58.81 15.57176-7311668 18044588 39.95 8.39733 3.301597193 7340918 18047618 40.044 46.95615 9.991143548 7333106 1805784 39.95 33.66341-13.747838 734400756 18059136 40.044 57.39733-6.9007867 735481944 18061815 39.95 70.57463 13.88158799 736560594 18065685 40.044 9.7796 0.65766066 73764178 18067616 39.95 4.99689.194176 7387043 18071310 40.044 1.46033.61036577-73980160 1807761 39.95 41.04419 6.458531 74088070 18080045 40.044 70.11307 16.71177318 743040108 1808650 39.95 6.9478-8.0831575 7441196 18091540 79.994 71.7377-1.396386 7450484 18097644 40.044 55.98381-4.163531 747363 18101 40.044 67.81807-7.1067167 74844097 18104049 79.994 50.757 3.43873-750600810 181138 39.95 0.41 47.3356343 751681998 1811417 79.994 90.99019 1.6708849 75760648 1811667 40.044 1.98367 16.37114355 753841836 18119349 39.95 7.8341 13.916607 75490486 181830 40.044 9.74189 4.97736577 756001674 1817801 39.95 38.67719-11.5836717-75708034 18138370 40.044 55.38 73.7687838 155
75816151 18140395 39.95 117.433 4.055773177 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 19.3083. 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 8.14. From above graph n Fgure 8.14 t s clear that decoder clock s stablzes at around 1. 10 3 = 100 PCR samples.e. 100 40ms = 48 sec. 8.6. 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
mplemented n ST7109 decoder chp. Response of clock recovery algorthm for varyng jtters s shown n Fgure 8.15 - Fgure 8.17. 8.6..1 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). 8.6.. 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
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
Fgure 8.17 Plot of PCR count and quantzed decoder frequency for 50 ms jtter n real tme IP stream 8.6..3 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). 8.6..4 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 8.6..5 Results of Real tme IP streams for 100 ms jtter 159
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 8.1. 8.7 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
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
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 0.1 4 18 15 FS DVB-T 0.5 60 30 5 4 DVB- IPTV 100 300 50 50 7 8.8 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
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 9.5. 163
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