SMPTE ST 325M-1999 Digital Television - Opportunistic Data Broadcast Flow Control.pdf

《SMPTE ST 325M-1999 Digital Television - Opportunistic Data Broadcast Flow Control.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 325M-1999 Digital Television - Opportunistic Data Broadcast Flow Control.pdf（6页珍藏版）》请在麦多课文档分享上搜索。

1、STD-SMPTE 325M-ENGL 3774 = 8357403 0003877 27T SMPTE STANDARD for Digital Television - Opportunistic Data Broadcast Flow Control SMPTE 325M-I 999 1 Scope This standard defines the flow control protocol to be used between an emission multiplexer and data server for opportunistic data broadcast. Oppor

2、tunistic data broadcast inserts data packets into the output multi- plex to fill any available free bandwidth. The emission multiplexer maintains a buff er from which it draws data to be inserted. The multiplexer will request additional MPEG-2 transport packets from the data server as its buffer bec

3、omes depleted. The number of packets requested depends upon the implementation, with the most stringent requirement being requesting a single MPEG-2 transport packet where the request and delivery can occur in less than the emission time of an MPEG-2 transport packet from the muhiplexer. This protoc

4、ol is designed to be extensible and provide a basis for low-latency, real-time backchannel com- munications from the emission multiplexer. Encapsulated in MPEG-2 transport packets, the messages of the flow control protocol are transmitted via MPEG-2 DSM-CC sections, following the message format defi

5、ned in ISOAEC 13818-6, chapter 2. Such sections provide the capability to support error correction or error detection (or to ignore either). 2 Normative references The following standards contain provisions, which through reference in this text constitute provisions of this standard. At the time of

6、publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. Page 1 of 6 pages ISOAEC 13818-1 :1996, Informat

7、ion Technology - Generic Coding of Moving Pictures and Associated Audio Information: Systems ISOAEC 1381 8-6:1998, Information Technology - Generic Coding of Moving Pictures and Associated Audio Information - Part 6: Extensions for DSM-CC digital storage media command and control 3 Mnemonics bslbf:

8、Bit string, left bit first, where left is the order in which bit strings are written in this standard. Bit strings are written as a string of Is and Os within single quote marks; e.g., loo0 0001. Blanks within a bit string are for ease of reading and have no sigiificance. tpchof: Remainder polynomia

9、l coefficients, highest order first. uimsbf: Unsigned integer, most significant bit first. 4 Flow control protocol The first message defined in the flow control protocol is the FCPacketRequest() message. The FCPacket- Request() message allows the multiplexer to request the data server to send a spec

10、ified number of packets associated with an opportunistic data service in order to maintain buffer fullness. The FCPacketRequest() mes- sages shall be packaged in 18-We MPEG-2 transport packets. The space remaining in the packet ater the message shall be filled with OxFE 4.1 Transport packet The MPEG

11、-2 transport packet as defined in ISOAEC 13818-1, clauses 2.4.3.2 and 2.4.3.3, shall be used with the following constraints as defined below (see table 1): CoWnghl81999 byTHESOCIEPIOF MOTION PICNRE AND TELEVISION ENGINEERS 595 W. Hamdale Ave., white Plains, NY 10607 (914) 761-1100 Approved August 19

12、,1999 SMPTE 325M-1999 sy nc-b yt e transport-error-indicator payload-unit-start-indicator Table 1 - Transport packet 8 0x47 1 O 1 1 I Syntax I No. of bits I Mnemonic I transport-scrambling-control I Transport Dacket ( I I I I 2 00 adaptationf ield-control 2 I transport-priority I 1 l O I 01 I PID I

13、13 I uimsbf I data-byte 8 bsibf l continuitv-counter I 4 1 uirnsbf I I Dointer field I 8 I ox00 I 4.1.1 Semantic definition of fields in transport packet sync-byte: This field shall be set to 0x47. transport-error-indicator: This field shall be set to O. pay I o ad - u n it -s t a rt - i n d i c a t

14、 o r : The pay- load-unit-start-indicator shall be set to a value of 1 to indicate the start of a private section within the current transport packet. transportjriority: This field shall be set to O. PID: The PID is a 13-bit field conveying the session number. The session number (PID) is mapped to t

15、he output service (a PID or aggregate of PIDs) during the provisioning process. The following PID ranges shall not be used: 0x0000-OxOOOF and 0x1 FFB. transport-scramblingcontrol: This field shall be set to OO. adaptationfield-control: This field shall be set to O1 , indicating no adaptation field,

16、payload only. continuity-counter: The continuity-counter is a 4-bit field that shall increment with each transport stream packet with the same PID. The continuity-counter wraps around to O after its maximum value. pointer-field: This is an 8-bit field whose value shall be the number of bytes, immedi

17、ately following the pointer-field until the first byte of the first section that is present in the payload of the transport stream packet (so a value of Ox00 in the pointer-field indi- cates that the section starts immediately after the pointer-field). In this usage, sections may not overlap within

18、packets - so the pointer-field always has a value of 0x00. data-byte: Data-bytes shall be contiguous bytes of data from the DSM-CC section defined below. Any data-byes remaining in the transport packet following the checksum or the CRC-32 field of the DSM-CC section structure shall be set to OxFF. T

19、he total number of data-bytes, N, within the transport packet is 183. 4.2 DSM-CC section for encapsulation of flow control protocol in transport packets Flow control messages shall be encapsulated in the DSM-CC section structure defined in clause 9.2.2 of ISOAEC 1381 8-6. The stream-type value assoc

20、i- ated with this elementary stream shall be OxOD (which per ISO/IEC 13818-6, clause 9.2.3, indicates that the elementary stream consists of DSM-CC sections). A table-id value of OxD7 shall be used to Page 2 of 6 pages STDOSMPTE 325M-ENGL 1777 8357403 0003877 042 I SMPTE 325M-1999 Table 2 - Flow con

21、trol message section signal the presence of flow control messages in DSM- CC sections (see table 2). 4.2.1 Semantic definition of fields in flow control message section table-id: This is an 8-bit field which, in the case of flow control messages, shall be set to OxD7. section-syntax-indicator: This

22、is a 1 -bit indicator that when set to lshall indicate the use of a valid CRC-32 in the CRC-32khecksum field. When set to 0,the bit indicates the use of a valid checksum in the CRC_32/checksum field. This field shall be set as defined by ISOAEC 13818-6, clause 9.2.2.1. private-indicator: This is a 1

23、-bit flag that shall be set to the complement value of the section-syntax-indi- cator. This field shall be set as defined by ISOAEC 1381 8-6, clause 9.2.2.1. dsmcc-section-length: This field shall be set as de- fined by ISOAEC 13818-6, clause 9.2.2.1. table-id-extension: This 16-bit field value shal

24、l be set to OxFFFF. version-number: This field shall convey the version number of the protocol. The current standard defines version 1. current-next-indicator: This is a 1-bit field that shall be set to 1 . section-number: This field shall be set to 0x00. last-section-number: This field shall be set

25、 to 0x00. CRC-32: This field shall be used and set as specified in ISOAEC 13818-6, clause 9.2.2.1. Page 3 of 6 pages STD.SMPTE 3251-ENGL 3999 8357403 0003880 ab4 I Syntax dsmccMeccageHeader0 SMPTE 325M-1999 No. of bits Mnemonic checksum: This field shall be used and set as speci- fied in ISOAEC 1381

26、8-6, clause 9.2.2.1. In particular, if the checksum is set to O, then no checksum is calculated. rnescageld 4.2.2 Flow control messages 16 uimcbf Flow control messages use the DSM-CC message format defined in chapter 2 of ISO/IEC 13818-6. The dsmccType in the message header shall be set to 0x80 for

27、flow control messages. Table 3 defines the flow control message format. This format is called the FlowControlMessage(). The only flow control mes- sages defined in this standard are the FCPacketRe- quest() messages. transaction Id 4.2.2.1 Semantic definition of fields in flow control messages 32 uim

28、sbf The dsmccMessageHeader() is defined in 4.2.2.2. reserved The MessagePayloadO is constructed from data fields and differs in structure depending on the function of the particular message as defined by the messageld. 8 uimsbf 4.2.2.2 DSM-CC message header me sc a g e Len gt h if (adaptationLength

29、O) 1 dsmccAdaptationHeader() All flow control messages shall begin with the DSM-CC MessageHeader. This header contains information about the type of message being passed as well as any adaptation data which is needed by the transport 16 uimsbf mechamism. The DSM-CC message header is speci- fied in t

30、able 4. 4.2.2.2.1 Semantic definition of fields in DSM-CC message header protocolDiscriminator: This field is used to indicate that the message is an MPEG-2 DSM-CC message. The value of this field shall be 0x11. dsmccType: This field is used to indicate the type of MPEG-2 DSM-CC message. Table 5, ex

31、tending table 2 of ISOAEC 13818-6, defines the possible dsmccType field values. The value Ox80 shall be used for flow control messages. messageld: This field indicates the type of message which is being passed. The values of the messageld are defined within the scope of the dsmccType. Only the value

32、s in table 6 shall be used as values for the messageld field. Table 3 - General format of flow control message I Svntax I I FiowControlMeccaae O I I t dsrnccMessageHeader() MecsaaePavioadO I DrotocoiDiccriminator I 8 I 0x11 I I dsmccTvDe I 8 I 0x80 I I adaDtation Lenat h I 8 I uimsbf I Page 4 of 6 p

33、ages - STD-SMPTE 3251-ENGL 3999 W 8357403 0003883 7T0 = ox00 oxo1 0x02 Ox03 transactionld: This field shall be for the version 1 protocol. ISOAEC 1381 8-6 reserved Identifies the message as an ISOAEC 1381 8-6 IS user-to-network configuration message identifies the message as an ISO/IEC 13818-6 IS us

34、er-to-network session message Identifies the message as an ISOAEC 13818-6 IS download messaae reserved: This field is ISO/IEC This field shall be set to OxFE 0x05 set to 0x40000000 1381 8-6 resewed. Identifies the message as an ISO/IEC 13818-6 IS user-to-network pass-through message adaptationlength

35、: This field shall be set to zero for the version 1 protocol. This means that there will not be an adaptation field used. Ox06 - 07F 0x80 OX81 - OXFF messageLength: This field shall be used to indicate the total length in bytes of the message following this field. This length shall include any adapt

36、ation headers indicated in the adaptationlength ISOAEC 1381 8-6 reserved Identifies the message as an SMPTE 325M flow control message User defined message type SMPTE 325M-1999 dsmccMessageHeader() numberof Pac kets 1 and the message payload indicated by the messageld field. 32 uimsbf 4.2.2.2.2. Pack

37、et request message The FCPacketRequest message is defined in table 7. The messagelD value associated with this message is oxooo1. 4.2.2.2.2.1 Semantic definition of fields in FCPacketRequest message numberfPackets: This 32-bit field shall specify the number of MPEG-2 transport packets requested by t

38、he mux from the server. Table 5 - MPEGP DSM-CC dsmccType values d s m ccTy p e 1 Description 0x04 Identifies the message as an ISO/iEC 13818-6 IS I 1 SDB channel chanae Drotocol messaae I Table 6 - messageld values messageld I Description t 0x0000 I Reserved 0x0001 I Packet reauest 0x0002-OxOOFF I R

39、eserved for flow control Ox01 OO-OxFFFE I User defined messaae tvpe Table 7 - FCPacketRequest message I Syntax I No. of bits I Mnemonic I I FCPacketReauestO 4 I I I OxFFFF I Reserved Page 5 of 6 pages SMPTE 325M-1999 Annex A (informative) Additional data The environment for this standard is illustra

40、ted in figure A.1. Within an emission station, one or more data servers are providing broadcast data (contained within MPEG-2 trans- port packets, with appropriate protocol encapsulations) to an emission multiplexer. A real-time control path is available from the emission multiplexer to the data ser

41、ver for flow control messages. Opportunistic data broadcast will attempt to fill any bandwidth available in the emission multiplex with broadcast data on a nearly instantaneous basis. The emis- sion multiplexer is in control of the opportunistic broadcast, since it is aware of the instantaneous gaps

42、 in the multiplex. The operational model is that the emission multiplexer would maintain an internal buffer from which it could draw MPEG-2 data packets to insert into the emission multiplex as the opportunity arose. As the buffer emptied, the mux would request a number of packets from the data serv

43、er to maintain buffer fullness over the control path. These data packets would be delivered over the data path. To avoid buffer overflow problems (should the data server be delayed in servicing the packet request), the following conventions are recommended: 1) the data server should not queue reques

44、ts for a given service (that is, a new request will displace one that has not been acted upon), and 2) the emission multiplexer should request no more than half of its buffer size at a time. While near-term implementations are likely to utilize at least a moderate sized buffer and request a signific

45、ant number of packets each time, future-proofing should require the capa- bility to handle the most stringent case, which is requests of single MPEG-2 transport packets, where the request can be made and satisfied within the time required to emit one transport packet from the mux. Support for multip

46、le opportunistic streams (multiple data servers, multiple opportunistic broadcasts from a single server) is provided by utilizing the MPEG-2 transport header PID as a session identifier. The mapping from PID number to physical resource shall be done during the provisioning process. I I r_l_ - 1-1 i Flow Control I H Figure A.l - Opportunistic flow control environment Page 6 of 6 pages