CONFIGURABLE HARDWARE IMPLEMENTATION OF A CONCEPTUAL DECODER FOR A REAL-TIME MPEG-2 ANALYSIS Michael Janiaut, Camel Tanougast, Hassan Rabah, Yves Berviller, Christian Mannino and Serge Weber U.H.P., Facult´e des Sciences Laboratoire d’Instrumentation Electronique de Nancy BP239, 54500 Vandoeuvre-les-Nancy, France email: [email protected] ABSTRACT This article describes the theoretical principles and an original microelectronics architecture of a configurable conceptual decoder able to process a MPEG-2 DVB-T stream in real time (T-STD). The proposed hardware architecture allows to continuously measure the Quality of Service of the MPEG-2 stream component. The architecture has been modelled, validated and simulated by using the SystemC language in combination with real MPEG-2 DVB-T streams. It is composed of several modules allowing to model the various buffers of the T-STD parts (video, audio or system). Real time errors flags are generated when the buffers filling level becomes illegal (overflow, empty buffer, transfer delay). A VHDL model allows an implementation on the FPGA circuit Altera APEX20KE600. The hardware implementation of the configurable T-STD requires 9738 logical cells (LCs) and 12 kB of external memory. 1. INTRODUCTION The DVB-T standard defines the conceptual decoder T-STD (Transport stream System Target Decoder) modelling the decoding process during the construction or the verification of the MPEG-2 stream [1, 2, 3]. It is a hypothetical decoder allowing an error detection for digital broadcast related applications by modelling the operation of a real hardware decoder (e.g. Set-top-box or Integrated Receiver Decoder (IRD)) [4]. This MPEG-2 stream analysis is an important criterion for the Quality of Service (QoS) evaluation established on the DVB TR 101 290 standard [5], as too many errors lead to deteriorated pictures or sound. Nowadays, such a decoder is software-realised and does not work in real time [6, 7, 8]. Most of them, the reading and analysing the transport stream is done after its recording. Software applications are too slow to perform the comThis work is supported by the French Ministry of Industry and Research with a RNRT project and by the EQUAST Consortium (THALES B&M, TDF, LORIA, and LIEN) (url : http://www.telecom.gouv.fr/rnrt/projets/res 02 7.htm).

0-7803-9362-7/05/$20.00 ©2005 IEEE

plex computation of the T-STD to control the quality of a MPEG-2 stream in real time. However, the evaluation of QoS in differed time is problematic when it becomes necessary to adjust the MPEG-2 stream in function of any error flags in real time. Furthermore, the usual decoder buffers use memory blocks of significant size which are not necessary for a simple transport stream monitoring. In this article, we present the development and the implementation of a configurable T-STD architecture based on FPGA allowing a real time QoS measurement of either the video, the audio or the system component. This proposed architecture contains no memory blocks for the modelling of the buffers. Moreover, the current implementation using reconfigurable hardware is likely to be less expensive than co-design implementation (SW-HW implementation) [6]. This document is structured in the following way: Section 2 describes the conceptual model of the T-STD according to the DVB-T standard [2]. Section 3 presents an architecture of the T-STD decoder and the realisation of the various buffers of this decoder. The simulation and implementation results on a FPGA circuit are presented in Section 4. Finally, section 5 concludes and presents future work. 2. PRINCIPLE OF THE T-STD A MPEG-2 Transport Stream (TS) is a stream of digital data packets of 188 bytes each which contain the audio, video and system data. One of the aspects of the Quality of Service analysis of a TS is the indication that the audio, video and system parts could be decoded. The goal of the T-STD model is to generate overflow, underflow, empty buffer, or data delay errors flags of the buffer data in a real decoder working at the standard frequency of 27 MHz [2, 1]. Figure 1 represents the model of the T-STD . The T-STD is composed of three parts : the video part consists of three buffers (Transport Buffer TB, Main Buffer MB, Elementary Buffer EB) and checks the possibility to gradually rebuild the picture. Moreover, they assure that all the transmitted data arrives at the decoder in time and

386

1st Buffer Vi deo TS Packets

3rd Buffer

2nd Buffer

Vi deo PES Packets

TB Buffer 512 Bytes

Audio TS Packets

AU’ s decoded at DTS ti m es (tdn)

Audio PES Packets

B Buffer Audi o AU’ s

512 Bytes

PAT,CAT & PMT Packets

E BS iz e = 2 × 1 0 2 4 × v b v b u ff e r siz e ≤ V BV

VBV Bytes

10,000 + VBV_MAX-VBV Bytes

2 Mbps

Dem ux

Vi deo AU’ s

EB Buffer (VBV)

15 Mbps (l eak m ethod)

TB Buffer

TS Packets

Video ES

MB Buffer

18 Mbps

3 584 Bytes

The parameter vbv buffer size is extracted from the TS [10]. The equations (2a) and (2b) give the size of the MB respectively for the level parameters : “main” and “low” or “high” and “high-1440” (see table 1) [2].

Tabl e Data

Table Data

TBsys Buffer

Bsys Buffer

A + V BV m a x − v b v b u ff e r siz e (2a) A (2b)   1 With A = 7 5 0 + 0.004 × Rm a x

M BS iz e M BS iz e

80 kbps (m i n)

1 Mbps 1536 Bytes

512 Bytes

Legend TS: PES: ES: AU: DTS:

Transport Stream Packeti zedEl ementaryStream El ementaryStream Access Uni t Decode Ti me Stamp

V id e o

188 bytes T P

P SEQ E GOP S PIC

I

T P

pusi = 1

STUFFING

I

T P

P P E I S C

STUFF

T P

P

STUFF

P P E I S C

B

P SEQ E GOP S PIC

I

T P

P SEQ E GOP S PIC

A u d io S y ste m

I

pusi = 0 Header PES

TB output M B input

= =

The input and output transfer rates of the buffers can be variable. Equation (3a), (3b) and (3c) gives the output transfer rate of TB buffers (Rx ).

Fig. 1. Model of the T-STD

TB input

P P E I S C

P

P P E I S C

B

(1)

m ax

P SEQ E GOP S PIC

I

P E S

P I C

P

P P E I S C

B

(3a) (3b) (3c)

: Rx = 1 .2 × Rm a x : Rx = 2 M b its/s : Rx = 1 M b its/s

Payload PES

P SEQ E GOP S PIC

I

Fig. 2. Removing data between TB and MB video buffers

The output transfer rate of the second buffer depends on the data type. For the video data, the transfer rate of MB (Rb x ) is specified in the stream. It is either equal to Rm a x (see table 1) or given by equation (4). Rbx (j) =

without loss. The audio part contains two buffers (Transport Buffer TB, Main audio buffer B) and checks the rebuilding of the audio frames. The third part also contains two buffers (Transport Buffer TB, Main system buffer Bsys ) and checks the consistency of system’s data. To carry out the above objectives, the goal of these different sized buffers is to remove the incoming data headers and to send the payload to the following buffer at a specific data rate [9]. For example, the buffer TB of each parts removes the TS packet header before transferring the remainder to the following buffer of this part. The figure 2 presents the data removal from TS between TB and MB video buffers. The buffer sizes are specified by a ISO standard [2]. The TB buffer size for each parts are fixed at 512 bytes. B and Bsys buffers are fixed to 1 536 Bytes and 3 584 Bytes respectively. MB and EB video buffers are variable according the extracted stream data and a parameter called “profile and level” . This parameter specify the maximum size of the EB (v b v m a x ) as well as the maximum transfer rate Rm a x between MB and EB buffers . The table 1 lists the values of Rm a x and v b v m a x in function of the “profile and level” parameter. Equation (1) gives the size of the EB buffer [2].

(T D N

j+ 1

N B (j) − v bv d e lj+ 1 ) − (T D N

j

− v bv d e lj )

(4)

NB(j) represents the number of bytes of the picture. The term [TDN(j) - vbv delay(j)] represents the emission time of the picture j. These parameters are also extracted from stream. This transfer rate varies between 18,75 kB/s and 10 MB/s. For the system data part, the transfer rate of the Bsy s (Rb sy s ) is given by the equation (5) tra n sp o rt ra te (5) 5 00 The “transport rate” parameter is extracted from the TS header [2]. The minimal transfer rate (Rb sy s ) is 80 kbits/s. For the EB and B buffer, the output transfer rate corresponding to decoding time stamp (TDN) which are extracted from the transport stream. Rb sy s =

Level and profile High and main High-1440 and main Main and main Low and main

Rm

ax

(Mbits/s) 80 60 15 4

Table 1. The values of Rm

387

vbvm

ax

(bits)

9 781 248 7 340 032 1 835 008 475 136

ax

and v b v m

ax

3. FUNCTIONAL ARCHITECTURE OF T-STD

TDN). For system data, the B buffer controller is the same of MB.

The T-STD only tests the filling level of the MPEG-2 DVB-T decoder buffers which are subject to variable transfer rates. This is the reason why the suggested architecture is based on logical up/down-counters running at variable frequencies. Figure 3 presents the complete architecture of the T-STD parts.

Conf.[1..0] TB sel ect

Fil ll evel

control l er

Cache memory Enabl e cl ock in

enabl e

Input counter

Externalmemory

enabl e Priority control l er

Rx

TB

Rbx

0

MB

EB

TB 1

1

RxConsign

Acquisition RbxConsign

TS

Transferrate generator Rx and Rbx

0 Stil l _picture_fl ag

conf[1..0] / 00

Config.[1]

Config.[1..0]

Size buffer

Fig. 4. Functional buffer architecture

Error_fl ags

Cl ock TS

output counter

Cl ock_27M

Cache memory

Saved data

Errorfl ags

Errors detection

Enabl e cl ockout

Data_del ay_error

01 10 11

Configuration buffer TB MB video EB video B audio B system /

Positioning 1st b u ff e r 2n d b u ff e r 3rd b u ff e r 3rd b u ff e r 2n d b u ff e r /

Time control l er

PCR_val ue

Table 2. Configuration table of buffers Fig. 3. Architecture of the T-STD The proposed architecture consists in three blocks modelling each operation of the buffers (TB, MB, EB or TB, B or TB, Bs y s). Additionally, there is an acquisition module, an external memory, some cache blocks associated with a priority controller, a transfer rate generation module and a time controller. 3.1. Block buffer Each block buffer is modelled by an input and an output counter, a controller and an error detection, as shown in figure 4. The buffer controller controls the counters according to the extracted stream parameters. The error detection module permanently calculates the filling level of the considered buffer by comparing the input to the output counter in order to generate error fl ags (overfl ow, underfl ow, buffer not emptied during a certain time) [2]. The buffers are configured according to the configuration input (see table 2). For the video data, all buffers are used whereas for the audio and system data, only two buffers are necessary. For the audio data, the MB is disconnected because the buffer controller does the same work as the EB controller (emission at instant

3.2. Acquisition module Starting from the stream, the acquisition module extracts or calculates all the parameters necessary to control the state of the buffers (TS header size, picture or sound size decoding time (TDN), vbv delay parameter etc.). Moreover, the acquisition module computes the transfer rate between the different buffers according to the configuration input. As a lot of parameters have to be stored, an external synchronous memory is used. The time constraints and the TS structure does not enable us to dialogue with the external memory in a way to ensure a continuous real time analysis. This is the reason why a cache module being able to hold up to two information is associated to the external memory through a priority controller. The figure 5 presents the architecture of a cache module based on registers as well as a hierarchical finite states machine (figure 6) managing its operation and controlled by the priority controller. This states machine carries out requests of reading and writing to the controller of priority according to the cache filling level. The function of the priority controller is the control and the management of simultaneous read-write accesses by the

388

MEM0

LATCH

Data_in

Multiplexer

Data_buffer0

Rbx

Rx

Multiplexer 0

enable

0

clock_TS

Rx consi gn (vi deo,audi o,system)

Data_out 1

MEM1

1

Rbx orRbsys rate generator

Rx rate generator

Data_buffer1

select

Cl ock27M

select

Sel ect State machine control 3 states buffer

Enable_write

Rbx l eakorRbsys consi gn

Reading finished

0

Denomi nator

Di vi der

Rbx vbv_del ay consi gn

read_ok

Fig. 5. Architecture of a cache block Cache empty

Nb 1 2 3 4 5 6 7 8

1 Cache not emptyand not full

2

condition New data Acknol edged data New data and acknol eged data and externalmemory not empty New data and externalmemory not empty Acknol edged data and externalmemory not empty Readi ng f i ni shed and wri ti ng i n externalmemory W ri ti ng f i ni shed Readi ng f i ni shed

Fig. 7. Transfer rate generator ing the time difference between incoming and outgoing picture, namely “ TDN” , and by the time when the first data of the picture enters the T-STD(memorised by the acquisition module). The maximal authorised time for a standing picture is 60 seconds while it is one second for any other kind of picture [2].

1

4. SIMULATION RESULTS AND HARDWARE IMPLEMENTATION

3

Cache full

5

Reading

7 W riting and reading

W riting

6

Fig. 6. State machine for the cache memory management cache blocks at the external memory. It also ensures the addressing of the external memory in function of the quantity and the type of data to be stored. 3.3. Transfer rate generation module The aim of the transfer rate generation module is to produce variable frequencies between different buffers. Its scheme is shown in figure 7. The transfer rate generator produces impulses of a duration of 37 ns to validate the data transmission at a rate of Rx and Rb x . The Rx values are obtained by first looking up the corresponding value of Rm a x in table 1 (in fact, table 1 only shows the most common cases) and then by calculation according to equation (3a), (3b) and (3c). The Rb x values are either obtained by looking up table 1 or calculated according to equation (4) using the division operator and by extracting the stream parameters. 3.4. Time controller The task of the time controller is to verify the authorised transport time in all the buffers. It is realised by compar-

The described architecture has been modelled, simulated and validated by using the SystemC language [11] in combination with files of real TS streams. The figures 8 and 9 show the simulation results of the TB, MB and EB buffers with common parameters (Rx = 18 Mbits/s, Rb x = 12 Mbits/s, a MB-EB transmission mode of the type “ leak” [2, 12]). 1200

1,2

1000

Fill level (Bytes)

4

1 TB fill level TB overflow

800

0,8

600

0,6

400

0,4

200

0,2

0

Overflow

8

1

Memory level

write_ok

W rite_request

Read_request

data_memory

Enable_read

2

Rbx orRbsys consi gn

Numerator

Default_value

0 0,0

0,2

0,4

0,6

0,8

1,0

Time (ms)

Fig. 8. Simulation results of the TB buffer Figure 8 shows that the TB buffer generates overrun fl ag if the amount of buffer used exceeds its maximum size of 512 bytes. In the same way, a simulation with the EB buffer just having 72 000 bytes is showing an increase of the MB buffer filling level when the EB buffer becomes full (Figure 9). The total errors counted over a given time would allow an evaluation of the audio visual degradation level. As it is specified for the evaluation of service performance by combination of TS related parameters (see details in §5.5 of the reference [5]).

389

are programmable in video, audio or system buffers. This architecture has been validated, synthesized and implemented in a FPGA. Real time error fl ags are generated when the buffer filling level becomes illegal (overfl ow, empty, transfer delay). This architecture allows a real-time QoS measurement of a MPEG-2 DVB-T stream. The operating mode of this architecture respects the specifications imposed by ETSI standard [5].

180000 160000

MB EB

Fill level (Bytes)

140000 120000 100000 80000 60000 40000 20000 0 0

0,5

1

1,5

2

2,5

6. REFERENCES

3

Times (s)

Fig. 9. Simulation results of the MB and EB buffers A realisable SystemC description has been performed. The implementation in the FPGA Altera APEX20KE has been carried out using a SystemC-VHDL translator [13, 14]. The implementation of the transfer rate generator has been realised with the aid of an arithmetic serial divider in order to minimise at the same time logic resources and computation time. The latter is cadenced by the system clock at 27 MHz. The calculation of the division is anticipated in order to obtain the value for the transfer rate before the picture arrives (adaptation of the transfer rate). The total implementation of the overall architecture needs 9738 logic cells and an external memory of 12 kB. The maximum operating frequency is 29 MHz (table 3). This final frequency is due to the time of additional routing during the total implementation of the T-STD. An operation in real-time requires at least an operating frequency of 27 MHz. Hence, the proposed architecture works in real-time. MODULES

LCs

Fr´equence max. (MHz)

Acquisition TB MB EB Cache memory Transfer rate generator Time controller priority Controller

4322 239 382 333 2099 1554 56 753

30.40 58.67 52.02 40.57 84.22 30.12 / 40.31

TOTAL

9738

29.06

Table 3. Implementation Results with an Altera Circuit (EP20K600EFI672)

5. CONCLUSIONS We have proposed a new configurable architecture which models the operations of MPEG-2 DVB-T hypothetical decoder parts (video, audio, system) called T-STD [2]. This architecture is realized with three configurable buffers which

[1] D. kucera. (Nov 2002) Introduction to mpeg-2 compression and transport streams. [Online]. Available: Chapters.scte.org/cascade/DVB%20Overview.ppt [2] ISO/IEC 13818-1. (2000) Information technology - generic coding of moving pictures and associated audio: Systems. [Online]. Available: http://www.iso.org [3] T. Yoshimura, “ Technologies and services on digital broadcasting: Overview of mpeg-2 systems,” Broadcast Technology, vol. ISBN 4-339-01162-2, no. 11, Summer 2002. [4] V. Kerguelen, Set top box. Technique de l’ingnieur, vol. Trait tlcoms TE 5875. [5] ETSI. (2001) Etsi tr101290 - digital video broadcasting (dvb); measurement guidelines for dvb systems. [Online]. Available: http://www.etsi.org [6] Tektronix. (2002) Mpeg test system - ad953a. [Online]. Available: http://www.tek.com/site/ps/0,,2A-14844INTRO EN,00.html [7] Manzanita. (2003) Mpeg2 transport stream analyzer. [Online]. Available: http://www.lilapple.com/products/mp2tsa.htm [8] M. Azinmi, P. Nasiopoulos, and R. Ward, “ Implementation of mpeg system target decoder.” in Canadian Conference on Electronical and Computer Engineering, 2001, pp. 0943– 0948. [9] M. Janiaut, C. Tanougast, H. Rabah, Y. Berviller, C. Mannino, and S. Weber, “ Impl´ementation mat´erielle d’un d´ecodeur conceptual pour l’analyse vid´eo mpeg-2 temps r´eel,” in Electrical and Computer Engineering (CCGEI 2005), IEEE Canada, Saskatoon, Saskatchewan, Canada, mai 2005. [10] ISO/IEC 13818-2. (2000) Information technology - generic coding of moving pictures and associated audio information: Video. [Online]. Available: http://www.iso.org [11] SystemC, Version 2, User’s Guide, http://www.systemc.org, 2002. [12] W. Zhu, Y. Hou, Y. Wang, and Y.-Q. Zhang, “ End-to-end modeling and simulation of mpeg-2 transport streams over atm networks with jitter,” IEEE transactions on circuits and systems for video technology, vol. 8, no. 1, February 1998. [13] ALTERA. (2004) Apex 20k programmable logic device family data sheet. [Online]. Available: http://www.altera.com/literature/ds/apex.pdf [14] Nepsys, Nepsys Version 1.0, User’s Guide. http://www.prosilog.com: Prosilog, 2002.

390