JP7247707B2 - Transmission node, broadcasting station system, control node and transmission control method - Google Patents

Description

The present disclosure relates to a transmission node, a broadcasting station system, a control node, and a transmission control method.

Many existing broadcast stations have dedicated networks for transmitting broadcast material such as video, audio and ancillary data within the station. Various devices are connected to the dedicated network, such as capture devices such as cameras and microphones, storage servers that accumulate content data, playback devices that play back content, and gateway devices that convert the format of transmitted signals. . SDI (Serial Digital Interface) has hitherto been widely used as a signal format for transmission of broadcast material on dedicated networks.

However, as a result of the remarkable improvement in performance of IP (Internet Protocol) technology in recent years, broadcasters have discovered the merits of using IP technology with greater versatility, and are making efforts to upgrade their intra-office networks to IP networks. started. Adopting an IP-based network architecture makes it possible to build a high-speed, large-capacity network at low cost using network devices such as general-purpose routers and switches.

Standardization of protocols for transmitting broadcast materials using IP technology is also currently underway. For example, SMPTE (Society of Motion Picture and Television Engineers) has standardized SMPTE ST2022-6, which is a protocol for transmitting SDI images, which are a mixture of video, audio, and ancillary data, in IP packets (non-patent Reference 1). Furthermore, SMPTE is also standardizing the SMPTE ST2110 series, which is a set of protocols for transmitting video, audio, and auxiliary data in separate streams (see Non-Patent Document 2). Among others, according to SMPTE ST2110-10, nodes participating in a broadcasting station system synchronize with each other with high accuracy based on the mechanism of PTP (Precision Time Protocol). This high-precision synchronization allows the receiver to properly time-align different streams transmitted along different paths over an IP network.

ARIB (Association of Radio Industries and Businesses), a standardization body in Japan, has standardized ARIB STD-B73 as a data structure specification for transmitting video, audio and auxiliary data in a single stream. (See Non-Patent Document 3).

Furthermore, in order to ensure interoperability between various devices, AMWA (Advanced Media Workflow Association) has established NMOS (Networked Streaming Interface), a set of control interface standards for managing and controlling stream transmission between devices. Media Open Specifications) standards are being formulated. For example, NMOS IS-04 is a control interface standard for discovery and registration of network resources (see Non-Patent Document 4). NMOS IS-05 is a control interface standard for device connection management (see Non-Patent Document 5). When the NMOS standard is used, the transmitting node provides the control node with an SDP (Session Description Protocol) object describing the attributes of a broadcast signal stream that can be transmitted by the own node, and the control node uses the description of the SDP object. set up the transmission of the stream based on

Patent Documents 1 and 2 disclose examples of SDP objects that can be used when streaming broadcast content.

Thomas Edwards, "SMPTE ST 2022: Moving Serial Interfaces (ASI & SDI) to IP", [online], August 17, 2017, SMPTE Standards Webcast Series, [searched on February 15, 2019], Internet < URL : https://www.smpte.org/sites/default/files/2017-08-17-ST-2022-Edwards-V4-Handout.pdf> SMPTE, “SMPTE ST 2110 FAQ”, [online], [searched on February 15, 2019], Internet <URL: https://www.smpte.org/st-2110> ARIB, “Data Structure Standard for Essence-Independent Single Stream RTP Datagram in IP Interface for Production (ARIB STD-B73 Version 1.0)”, [online], July 26, 2018, [February 15, 2019 Japan], Internet <URL: https://www.arib.or.jp/kikaku/kikaku_hoso/desc/std-b73.html> AMWA, “AMWA IS-04 NMOS Discovery and Registration Specification (Stable)”, [online], [February 15, 2019], Internet <URL: https://amwa-tv.github.io/nmos-discovery -registration/> AMWA, “AMWA IS-05 NMOS Device Connection Management Specification”, [online], [February 15, 2019], Internet <URL: https://amwa-tv.github.io/nmos-device-connection- management/＞

JP 2015-73197 A Japanese Patent Publication No. 2007-531368

When video, audio and ancillary data that are related to each other are transmitted in separate streams like SMPTE ST2110, the port numbers of these streams are different in the transport layer, so processing to reconstruct the original contents on the receiving side is required. Complicated. If the port numbers are different, each stream may receive a different delay due to the difference in the transmission path followed by each stream as a result of path control on the IP network. On the other hand, ARIB STD-B73 video, audio and auxiliary data streams have the same port number in the transport layer, so they do not have the above-mentioned problem specific to SMPTEST ST2110. However, ARIB STD-B73 does not specify how the nodes participating in the broadcasting station system should operate cooperatively to process streams.

For example, if high-precision synchronization is not established between nodes involved in stream transmission, and if there is no consensus on the field for time information that should be used for time alignment between packets, communication within the broadcasting station system Broadcast contents cannot be configured by flexibly combining various essences.

Also, the format of the SDP objects normally used for SMPTE ST2110 streams is not necessarily suitable for the characteristics of ARIB STD-B73 streams, either in format structure or in the information content described.

An object of the technology according to the present disclosure is to solve at least one of the above-described problems.

According to one aspect, a transmitter for transmitting a broadcast signal stream that transmits different types of essence data with a single port number to an IP network of a broadcast station, and an SDP (Session Description) that describes attributes of the broadcast signal stream a control unit for providing a protocol object to other nodes, wherein the SDP object includes compression-related information indicating whether video essence data is compressed, audio channel number information related to audio essence data, and essence data. error correction information indicating an error correction scheme to be applied to the broadcast signal stream in attribute fields describing format-specific parameters of said broadcast signal stream.

According to yet another aspect, there is provided a broadcast station system including said transmitting node and a receiving node for receiving said broadcast signal stream set up according to said SDP object description.

According to another aspect, a control node for controlling transmission from a transmitting node to a receiving node of a broadcast signal stream carrying different types of essence data on a single port number in an IP network of a broadcast station, comprising: a control unit that acquires an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream from the transmission node, the SDP object including compression-related information indicating whether video essence data is to be compressed, audio essence including one or more of audio channel number information associated with the data and error correction information indicating an error correction scheme applied to the essence data in an attribute field describing format specific parameters of the broadcast signal stream. , a control node is provided.

According to another aspect, providing other nodes with an SDP (Session Description Protocol) object describing attributes of a broadcast signal stream that transmits different types of essence data with a single port number; sending the stream to the broadcast station's IP network, wherein the SDP object includes compression related information indicating whether video essence data is compressed, audio channel number information related to audio essence data, and essence data. error correction information indicating an error correction scheme to be applied to the broadcast signal stream in an attribute field describing format-specific parameters of said broadcast signal stream. A computer program may be provided that causes a processor to execute the transmission control method. A non-transitory computer-readable storage medium storing the computer program may be provided.

According to another aspect, a transmission control method for controlling transmission from a transmission node to a reception node of a broadcast signal stream that transmits different types of essence data with a single port number in an IP network of a broadcast station obtaining from the transmitting node an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream, wherein the SDP object is compression-related information indicating whether video essence data is to be compressed; One or more of audio channel number information associated with the audio essence data and error correction information indicating an error correction method applied to the essence data in the attribute field describing the format-specific parameters of the broadcast signal stream. A transmission control method is provided, comprising: A computer program may be provided that causes a processor to execute the transmission control method. A non-transitory computer-readable storage medium storing the computer program may be provided.

According to the technology according to the present disclosure, when using a protocol for transmitting essence data such as video data, audio data, or auxiliary data in a single stream on an IP network of a broadcasting station, the transmission of the stream is appropriately set up. It becomes possible to It should be noted that the technology according to the present disclosure may produce other effects instead of or in addition to the above effects.

1 is a schematic diagram showing an example of a configuration of a broadcasting station system according to an embodiment of the present disclosure; FIG. FIG. 2 is an explanatory diagram for describing an example of a logical configuration of IP domains of a broadcasting station system according to an embodiment of the present disclosure; FIG. 1 is an explanatory diagram for explaining a system timing model defined by SMPTE ST2110-10; FIG. FIG. 4 is an explanatory diagram for explaining time alignment between a video essence and an audio essence based on the system timing model described with reference to FIG. 3; FIG. 4 is an explanatory diagram for explaining the structure of a datagram in ARIB STD-B73; FIG. 4 is an explanatory diagram for explaining transmission of video essence and audio essence in a single stream according to ARIB STD-B73; 2 is a block diagram showing an example of the configuration of a broadcast signal processing node according to the first embodiment; FIG. 8 is a block diagram showing an example of a detailed configuration of a reception stream processing unit shown in FIG. 7; FIG. FIG. 4 is an explanatory diagram for describing a first example of a technique for time alignment of essence data between two RTP packets; FIG. 10 is an explanatory diagram for explaining a second example of a technique for time alignment of essence data between two RTP packets; FIG. 11 is an explanatory diagram for explaining a third example of a technique for time alignment of essence data between two RTP packets; FIG. 11 is an explanatory diagram for explaining a fourth example of a technique for time alignment of essence data between two RTP packets; 6 is a flow chart showing an example of the flow of stream transmission processing according to the first embodiment; 6 is a flow chart showing an example of the flow of stream reception processing according to the first embodiment; FIG. 9 is a block diagram showing an example of the configuration of a broadcast signal processing node according to the second embodiment; FIG. FIG. 11 is a block diagram showing an example of the configuration of a broadcast signal processing node according to the first modified example of the second embodiment; FIG. FIG. 12 is a block diagram showing an example of the configuration of a broadcast signal processing node according to a second modified example of the second embodiment; FIG. FIG. 4 is an explanatory diagram for describing a typical format structure of an SDP object for an essence-separated stream; FIG. 16 is an explanatory diagram showing an example of an SDP object describing attributes of an SMPTEST ST2110 stream having the format structure explained with reference to FIG. 15; FIG. 11 is an explanatory diagram for explaining the format structure of an SDP object defined for an essence-mixed stream in the third embodiment; FIG. 18 is an explanatory diagram showing an example of an SDP object describing attributes of an ARIB STD-B73 stream having the format structure explained with reference to FIG. 17; FIG. 11 is a block diagram showing an example of a schematic configuration of a broadcasting station system according to a third embodiment; FIG. FIG. 12 is a block diagram showing an example of the configuration of a transmission node according to the third embodiment; FIG. 21 is a flow chart showing a first example of the flow of transmission control processing that can be executed by the transmission node shown in FIG. 20; 21 is a flow chart showing a second example of the flow of transmission control processing that can be executed by the transmission node shown in FIG. 20; FIG. 12 is a block diagram showing an example of the configuration of a control node according to the third embodiment; FIG. FIG. 24 is a flow chart showing a first example of the flow of transmission control processing that can be executed by the control node shown in FIG. 23; FIG. 24 is a flow chart showing a second example of the flow of transmission control processing that can be executed by the control node shown in FIG. 23; FIG. 12 is a block diagram showing an example of the configuration of a transmission node according to the fourth embodiment; FIG. FIG. 14 is a block diagram showing an example of the configuration of a control node according to the fourth embodiment; FIG.

Hereinafter, embodiments of the technology according to the present disclosure will be described in detail with reference to the accompanying drawings. In addition, in the present specification and drawings, elements that can be described in the same manner can be omitted from redundant description by assigning the same reference numerals.

The description is given in the following order.
1. Overview 2. First Embodiment 2-1. Configuration example of broadcast signal processing node 2-2. Detailed configuration example of reception stream processing unit 2-3. Flow of processing3. Second Embodiment 3-1. Configuration example of broadcast signal processing node 3-2. Modification 4. Summary of the first embodiment and the second embodiment5. Third Embodiment 5-1. Example of existing SDP object 5-2. New format of SDP object 5-3. Configuration example of broadcasting station system 5-4. Configuration example of transmission node 5-5. Configuration example of control node6. Fourth Embodiment 6-1. Configuration example of transmission node 6-2. Configuration example of control node7. Summary of the third embodiment and the fourth embodiment

<<1. Overview＞＞
First, using FIG. 1, an outline of a broadcasting station system to which some embodiments of the present disclosure can be applied will be described. FIG. 1 is a schematic diagram showing an example configuration of a broadcasting station system 1 according to an embodiment of the present disclosure. Referring to FIG. 1, the broadcasting station system 1 includes one or more network devices 12, a camera 20a, a monitor 20b, an IP gateway 20c, an IP gateway 20d, a camera 22, a microphone 24, a data server 26, an integrated playout ) 32 , a monitor 34 , an APS (Automatic Program Control System) 40 and a control terminal 50 . Network device 12 , camera 20 a , monitor 20 b , IP gateway 20 c , IP gateway 20 d , APS 40 and control terminal 50 belong to IP domain 10 .

(1) Description of Various Devices The network device 12 is a device in charge of transferring streams in the IP network. Each of network devices 12 may be any type of network device, such as a router, switch, bridge or repeater. Each of the network devices 12 may be a general-purpose product (also called COTS (Commercial Off-The-Shelf)) that can be introduced at low cost. Although six network devices 12 are shown in FIG. 1 , the broadcasting station system 1 may include any number of network devices 12 without being limited to such an example. IP domain 10 may consist of a single network or may include multiple sub-networks.

Camera 20a is a type of capture device that generates broadcast material. For example, the camera 20a shoots some object and generates video data. The camera 20a may acquire audio through a built-in microphone and generate audio data. The camera 20a belongs to the IP domain 10 and is capable of packetizing a data stream of video and audio data into a series of IP packets for transmission over the IP network.

The monitor 20b is a type of reproduction device that receives broadcast material and reproduces content. For example, the monitor 20b receives video data and reproduces the video. The monitor 20b may receive audio data and reproduce audio. The monitor 20b may receive additionally transmitted auxiliary data and process the auxiliary data (eg, play closed captions). The monitor 20b may provide the user with editing functions for editing content. The monitor 20b belongs to the IP domain 10 and can receive a series of IP packets transferred over the IP network.

IP gateway 20c is a gateway device located at the boundary between IP domain 10 and other signaling domains. IP gateway 20 c connects to one or more network devices 12 . In the example of FIG. 1, a camera 22, a microphone 24 and a data server 26 are also connected to the IP gateway 20c. For example, IP gateway 20c may receive SDI signals carrying video data from camera 22 . IP gateway 20 c may also receive SDI signals carrying audio data from microphone 24 . IP gateway 20c may also receive SDI signals from data server 26 that carry one or more of video data, audio data and ancillary data. It should be noted that the signal format of signals transmitted outside the IP domain 10 may be any derivative of SDI, such as SD-SDI, HD-SDI, 3G-SDI, 6G-SDI or 12G-SDI, or , SDI may be used. IP gateway 20c packetizes signals carrying broadcast material received from cameras 22, microphones 24 and data server 26 as described above, into a series of IP packets after multiplexing or demultiplexing as necessary. can be sent to the IP network via

IP gateway 20d is also a gateway device located at the boundary between IP domain 10 and other signaling domains. IP gateway 20 d connects to one or more network devices 12 . In the example of FIG. 1, an integrated playout 32 and a monitor 34 are further connected to the IP gateway 20d. For example, IP gateway 20d receives IP packets transferred over an IP network, converts the IP packets to SDI signals (or signals in other signal formats), and sends them to one of integrated playout 32 and monitor 34. Or you can send to both. Of course, the IP gateway 20c may have the function of converting IP packets into SDI signals, like the IP gateway 20d. Also, the IP gateway 20d may have a function of converting an SDI signal into an IP packet like the IP gateway 20c.

The APS 40 is a system that advances broadcasting of television programs according to a predetermined schedule. For example, APS 40 sends control messages to the IP network to cause transmission of data streams output from given sources (eg, cameras and microphones, or data servers) at predetermined times to integrated playout 32 . The integrated playout 32, which has received the data stream, transmits a broadcast signal of the television program to the antenna through the line of the broadcasting station. The data stream may also be delivered to monitor 20b or monitor 34, for example, to reproduce the broadcast content within the broadcast station.

The control terminal 50 is a terminal device that provides a user with a user interface related to management and control of nodes included in the broadcasting station system 1 . The control terminal 50 may be a user terminal dedicated to the broadcasting station system 1, or may be a general-purpose terminal such as a PC (Personal Computer) or a smart phone. The control terminal 50 acquires, for example, setting information related to stream transmission on the network within the broadcasting station via the user interface and registers it in the database within the system. The control terminal 50 also accepts requests for transmission of streams between given nodes via, for example, a user interface.

(2) IP Multicast Transmission of broadcast signal streams within the IP domain 10 of the broadcasting station system 1 is typically performed by multicast. The source IP address of the multicast packet is the IP address of the sending node, and the destination IP address is a multicast address belonging to a specific address range. A set of nodes that receive multicast packets destined for individual multicast addresses is called a multicast group, and a multicast address is also called a group address. A receiving node that intends to receive a stream sends a message (eg, Internet Group Management Protocol (IGMP) JOIN) to its neighboring routers to join the multicast group corresponding to that stream. Messages are then exchanged between the routers to update the multicast tree, and a stream transmitted from a specific sending node is delivered to the receiving node via the IP network. When the receiving node finishes receiving the multicast stream, the receiving node sends a message notifying of leaving the multicast group to the neighboring routers. It should be noted that the technology according to the present disclosure is not limited to the example described above, and can also be applied to cases where streams are transmitted by unicast.

(3) Logical Configuration Example of IP Domain FIG. 2 shows an example of a logical configuration of the IP domain 10 of the broadcasting station system 1 shown in FIG. terminal 50 is omitted). Referring to FIG. 2, the first node corresponding to camera 20a includes sender 60a. A "sender" is a functional entity capable of sending a stream. A second node corresponding to IP gateway 20c includes senders 60b, 60c and 60d. Senders 60b, 60c and 60d may correspond to devices from which individual streams are served by IP gateway 20c. A third node, corresponding to monitor 20b, includes a receiver 65a. A "receiver" is a functional entity capable of receiving a stream. A fourth node corresponding to IP gateway 20d includes receivers 65b and 65c. Receivers 65b and 65c may correspond to devices to which individual streams are received by IP gateway 20d.

As understood from the above description, one node (which may be called a "card") represents one physical entity. Without being limited to the example of FIG. 1, a node may include any number of senders and/or any number of receivers as functional entities. Also, a logical unit (for example, see the dashed frame in the figure) that includes multiple functional entities within one node may be defined (for example, one device accommodated in one IP gateway may be (case of sending or receiving a stream of For example, NMOS, which is being considered by AMWA, presupposes such a logical system model and specifies an application protocol interface (API) specification for managing and controlling the transmission of streams in the IP domain.

In this specification, when there is no need to distinguish between the nodes 20a, 20b, 20c, and 20d, they are collectively referred to as nodes 20 by omitting the alphabet at the end of the reference numerals. The same applies to senders 60a, 60b, 60c, 60d (sender 60) and receivers 65a, 65b, 65c (receiver 65), as well as other component numbers.

(4) Essence and Stream As described above, television program content generally consists of three types of broadcast material data: video data, audio data, and auxiliary data. The term "essence" is used herein to distinguish between types of broadcast material and to refer to these content components. In other words, the essence is broadcast material represented as data. When an essence is to be transmitted over an IP network, it is converted into digital signals and packetized according to some IP-based protocol. A series of IP packets carrying the essence is assigned a common port number for each stream. That is, a stream can be a sequence of IP packets with a common IP address and port number. No matter which protocol is used as the IP-based stream transmission protocol, packets are normally transmitted according to RTP (Real-time Transport Protocol) in the application layer and UDP (User Datagram Protocol) in the transport layer. be.

(5) IP-based stream transmission protocol One of the representative protocols for IP-based stream transmission is SMPTE ST2022-6. SMPTE ST 2022-6 maps the SDI signal as-is to the IP packet. Therefore, a single ST2022-6 stream contains different types of essence and data corresponding to blanking periods. The ST2022-6 stream may be suitable for transitional broadcast station systems with mixed IP and SDI domains.

Another typical protocol for IP-based stream transmission is SMPTE ST2110. SMPTE ST 2110 maps different types of essences to different streams. Therefore, a single stream contains only a single type of essence, and no stream contains data corresponding to blanking periods. SMPTE ST2110-10 defines a technique for highly accurate synchronization between nodes participating in a broadcasting station system based on the PTP mechanism. SMPTE ST2110-20 defines a transmission format for uncompressed video essence. SMPTE ST2110-21 defines a technique for traffic shaping of video essence. SMPTE ST2110-30 defines a transmission format for uncompressed PCM audio essence. SMPTE ST2110-31 defines a transmission format for AES3 voice essence. SMPTE ST2110-40 defines the transmission format of the auxiliary data essence. It should be noted that the SMPTE ST2110 series does not support compression of video essence, nor does error correction encoding/decoding.

(6) Time Synchronization in SMPTE ST2110-10 In order to broadcast television programs according to an accurate schedule, nodes in the system must know the exact time. Also, when multiplexing streams received from different nodes, synthesizing multiple videos, or reproducing video and audio simultaneously, it is necessary to ensure that fine time synchronization is established between nodes. need. FIG. 3 is an explanatory diagram for explaining the system timing model defined by SMPTE ST2110-10 for the purpose of such time synchronization.

FIG. 3 shows the nodes 20a and 20b of the broadcasting station system 1 and the common reference clock 70 as an example. The common reference clock 70 synchronizes with a highly accurate time source (for example, a GNSS (Global Navigation Satellite System) satellite such as a GPS (Global Positioning System) satellite) and operates as a so-called PTP grandmaster. Common reference clock 70 distributes synchronization messages to slave nodes in the system according to the PTP mechanism.

The node 20a is a PTP slave node. Node 20 a synchronizes its device internal clock 72 a to common reference clock 70 and maintains that synchronization (eg, adjusts delay) based on synchronization messages received from common reference clock 70 . The video media clock 73a of the node 20a is locked to the device internal clock 72a and runs at a video-specific frequency. Audio media clock 76a is locked to device internal clock 72a and runs at audio-specific frequencies. The video specific frequency specified by SMPTE ST2110-20 is 90 kHz and the audio specific frequency specified by SMPTE ST2110-30 is 48 kHz.

Normally, RTP packets are timestamped with a randomly generated offset relative to the media clock, but in SMPTE ST2110-10 the offset is zero. This allows rapid restoration of stream transmission when the sender is restarted due to some failure (because the process for determining the random offset is omitted). That is, the video RTP clock 74a of the node 20a has no offset with respect to the video media clock 73a and indicates the same time as the video media clock 73a. An RTP time stamp is added to the RTP header of each packet of the RTP stream of the video essence transmitted by the node 20a according to the video RTP clock 74a. Similarly, the audio RTP clock 77a of the node 20a has no offset with respect to the audio media clock 76a and indicates the same time as the audio media clock 76a. An RTP time stamp is added to the RTP header of each packet of the RTP stream of the audio essence transmitted by the node 20a according to the audio RTP clock 77a.

Generally speaking, in SMPTE ST2110-10, a device that captures video or audio attaches the capture time as an RTP timestamp to each packet. A device that plays back content from a storage attaches the essence output time from the communication interface to each packet as an RTP time stamp. A device that converts an SDI signal into IP packets attaches the clock value of the SDI signal at the time of alignment to each packet as an RTP timestamp.

Node 20b is also a PTP slave node. Node 20 b synchronizes its device internal clock 72 b to common reference clock 70 and maintains that synchronization (eg, adjusts delay) based on synchronization messages received from common reference clock 70 . Although not shown, like node 20a, node 20b also has a media clock locked to device internal clock 72b and an RTP clock that has no offset relative to the media clock. The node 20b receives, for example, the RTP stream of the video essence and the RTP stream of the audio essence transmitted from the node 20a with different port numbers. Then, the node 20b performs time alignment between packets based on its own RTP clock and the RTP timestamp added to the RTP header of each packet of the received RTP stream. Such a scheme that utilizes PTP enables high-precision time synchronization with an error of 10 μs or less between nodes participating in the IP network of a broadcasting station.

FIG. 4 is an explanatory diagram for explaining time alignment between a video essence and an audio essence based on the SMPTE ST2110-10 system timing model described with reference to FIG. Referring to FIG. 4, the node 20a transmits an RTP stream 81 of video essence and an RTP stream 82 of audio essence in parallel to the network. Each packet (V ₁ , V ₂ , V ₃ , . . . ) included in the RTP stream 81 has an RTP time stamp and a sequence number assigned according to the video RTP clock in the RTP header. Each of the packets (A ₁ , A ₂ , A ₃ , . . . ) included in the RTP stream 82 has an RTP timestamp and a sequence number assigned according to the audio RTP clock in the RTP header. Node 20b receives a series of RTP packets of RTP stream 81 at UDP port _PV and processes the received RTP packets in sequence number order. Node 20b also receives a series of RTP packets of RTP stream 82 at UDP port _PA and processes the received RTP packets in sequence number order. For example, when reproducing video and audio synchronously, the node 20b compares the RTP time stamp of each packet of the RTP stream 81 with the RTP time stamp of each packet of the RTP stream 82, and reproduces video and audio. Synchronize times (eg, frame timing) with each other. It should be noted that time alignment between video essences, between audio essences, and between video or audio essences and auxiliary data essences can be performed as well.

(7) ARIB STD-B73
When video, audio and ancillary data that are related to each other are transmitted in separate streams like SMPTE ST2110, the port numbers of these streams are different in the transport layer, so processing to reconstruct the original contents on the receiving side is required. Complicated. If the port numbers are different, each stream may receive a different delay due to the difference in the transmission path followed by each stream as a result of path control on the IP network. In order to eliminate these inconveniences, ARIB, a standardization organization in Japan, has standardized ARIB STD-B73 as a data structure specification for transmitting video, audio and auxiliary data in a single stream. .

FIG. 5 is an explanatory diagram for explaining the structure of a datagram described in Chapter 2 of ARIB STD-B73 Version 1.0. A datagram indicated by a thick frame in FIG. 5 constitutes one packet together with a preceding network header and a subsequent FCS (Frame Check Sequence). Network headers include, for example, MAC (Medium Access Control) headers (eg, Ethernet headers), IP headers, and UDP headers. An RTP datagram for essence data includes a transport header including an RTP header and a common header, an essence header, and an essence payload. An essence datagram includes an essence header and an essence payload. The portion including the common header, essence header and essence payload is also called RTP payload. On the other hand, although not shown, the RTP datagram for FEC data contains the FEC payload instead of the essence header and essence payload. Note that the terms packet and datagram are used interchangeably herein. The meaning of these terms will be readily understood by those skilled in the art.

The RTP header includes, for example, "payload type", "sequence number" and "time stamp" as data items. A fixed value (for example, 110) is set in the “payload type”. The "sequence number" value is incremented by one with each transmission. Its initial value can be set randomly. Although the "timestamp" value is monotonically linearly incremented, ARIB STD-B73 Version 1.0 specifies that this field is not used for synchronization.

The common header includes, for example, "frame count", "datagram type" and "sequence number" as data items. The "frame count" of the common header is set to the same value as the "frame count" of the corresponding essence header. A value indicating whether the corresponding datagram is an essence datagram or an FEC (Forward Error Correction) datagram is set in the "datagram type". The "sequence number" value is incremented by one for each transmission separately for video essence, audio essence and auxiliary data essence (and FEC). Its initial value can be set randomly.

The essence header includes, for example, "payload type" and "frame count" as data items. "Payload type" is set with a value indicating the type of essence contained in the subsequent essence payload (0: video, 1: audio, 2: auxiliary data, etc.). A value for synchronizing datagrams of each essence on the receiving side is set in the "frame count" of the essence header. The epoch time defined in SMPTE ST2059-1 is used as the initial value of zero for the "frame count". The "frame count" value is incremented by one at the start of each new video frame, and all essence datagrams belonging to the same video frame are set to the same value.

FIG. 6 is an explanatory diagram for explaining transmission of video essence and audio essence in a single stream according to ARIB STD-B73. Referring to FIG. 6, node 20c sends an RTP stream 83 containing both packets for video essence and packets for audio essence to the network. Each of the packets (V ₁ , A ₁ , V ₂ , A ₂ , . . . ) contained in RTP stream 83 has a frame count value in its essence header. Node 20d receives a series of RTP packets of RTP stream 83 at a single port _PM and processes the received RTP packets in sequence number order. As described above, according to ARIB STD-B73, a group of RTP packets that are arranged one behind the other in the order of sequence numbers in the RTP header belong to the same video frame and have the same frame count value. Therefore, the node 20d can synchronously process the group of RTP packets containing video essence and audio essence.

However, ARIB STD-B73 does not specify how the nodes participating in the broadcasting station system should operate cooperatively to process streams.

For example, if high-precision synchronization is not established between nodes involved in stream transmission, and if there is no consensus on the field for time information that should be used for time alignment between packets, communication within the broadcasting station system Broadcast contents cannot be configured by flexibly combining various essences. Therefore, in a first embodiment and a second embodiment to be described later, a protocol (for example, ARIB STD- B73), we propose a mechanism for appropriately adjusting the time of essence data.

In addition, the format of the SDP objects normally used for SMPTE ST2110 streams is not necessarily suitable for the characteristics of ARIB STD-B73 streams, either in format structure or in the information content described. Therefore, in the third and fourth embodiments described later, when using a protocol for transmitting essence data such as video data, audio data, or auxiliary data in a single stream on an IP network of a broadcasting station, Techniques are described that allow the transmission of the stream to be properly set up.

In this specification, a stream in which different types of essence data are transmitted in a single stream is also called an essence-mixed stream. Examples of mixed-essence streams include ARIB STD-B73 streams and SMPTE ST2022-6 streams. Also, in this specification, a stream in which different types of essence data are transmitted in different streams is also referred to as an essence separation type stream. Examples of essence-separated streams include SMPTE ST2110 streams.

<<2. First Embodiment>>
The broadcast signal processing node 100 described in this section includes the functionality of both the sender 60 and receiver 65 described above. However, as will be apparent to those skilled in the art, in broadcast signal processing node 100 the functionality of one of sender 60 and receiver 65 may be omitted. The broadcast signal processing node 100 can correspond to any one of the nodes 20a to 20d described with reference to FIGS. 1 and 2 in the broadcasting station system 1, for example.

<2-1. Configuration example of broadcast signal processing node>
FIG. 7 is a block diagram showing an example of the configuration of the broadcast signal processing node 100 according to the first embodiment. Referring to FIG. 7, broadcast signal processing node 100 includes device internal clock 110, media clock 112, RTP clock 114, PTP processing unit 116, communication unit 120, transmission stream processing unit 130, reception stream processing unit 140, data processing unit 180 and a control unit 190 .

(1) Device Internal Clock The device internal clock (also called device internal clock) 110 is a unique internal clock held by the broadcast signal processing node 100 . In this embodiment, the device internal clock 110 is directly or indirectly synchronized to the PTP's time source. Typically, when the broadcast signal processing node 100 is a PTP slave, the device internal clock 110 is indirectly synchronized to the PTP's time source via the PTP grandmaster. On the other hand, if the broadcast signal processing node 100 is the PTP master, the device internal clock 110 is directly synchronized to the PTP's time source. For example, the control unit 190, which will be described later, may set itself so that the broadcast signal processing node 100 does not become the PTP master.

(2) Media Clock Media clock 112 is a clock used for processing (eg, sampling and reconstruction) of digital media signals. In this embodiment, the media clock 112 uses the epoch time defined in SMPTE ST2059-1 as an initial value of zero and is frequency locked to the device internal clock 110 to run at the correct rate. If the broadcast signal processing node 100 cannot obtain a common reference clock and is operating on a local timebase, it will use the best available time source given the above epoch defined in SMPTEST ST2059-1. can be used for the media clock 112 and the RTP clock 114 described below.

In this embodiment, the broadcast signal processing node 100 supports ARIB STD-B73, which is a transmission protocol for transmitting different types of essence data in a single stream. In ARIB STD-B73, the timing of each video essence, audio essence and ancillary data essence is associated with a video frame. In this case, the media clock on which the RTP timestamp is based may be a single one regardless of the type of essence data. The same applies to the RTP clock 114, which will be described later.

SMPTE ST2110-20 specifies that the media clock frequency for video essence is 90 kHz. On the other hand, many existing broadcasting equipment have a clock of 27.0 MHz. SMPTE ST2022-8, which is under consideration for integrating SMPTE ST2022-6 streams carrying SDI images into the SMPTE ST2110-10 system, specifies a media clock frequency of 27.0 MHz. When the media clock frequency is 90 kHz, the frequency is not an integer multiple of 60/1.001 Hz, which is often used as the frequency of video frames. On the other hand, when the media clock frequency is 27.0 MHz, the frequency is an integer multiple of 60/1.001 Hz. Considering this point, in the present embodiment, 27.0 MHz is used as the clock frequency of the media clock 112, which is advantageous in terms of handling in that the frame period is accurately kept constant and the clock value is monotonously increased.

(3) RTP Clock The RTP clock 114 is a clock that forms the basis of time stamps added to the RTP headers of RTP packets. In this embodiment, the RTP clock 114 shall have no offset with respect to the media clock 112 as specified in SMPTE ST2110-10. That is, the RTP clock 114 has the same value as the associated media clock 112 . Therefore, in this embodiment, the clock frequency of RTP clock 114 is equal to 27.0 MHz, as is the clock frequency of media clock 112 .

(4) PTP Processing Unit In this embodiment, the broadcast signal processing node 100 supports the PTP profile of SMPTE ST2059-2, for example. Then, the PTP processing unit 116 exchanges synchronization messages with the PTP master (for example, the common reference clock 70 described using FIG. 3) via the communication unit 120 to obtain the PTP time of the device internal clock 110. Stay synchronized with the source. Thereby, the broadcast signal processing node 100 can operate synchronously with high precision with other nodes having clocks synchronized with the PTP time source as well.

(5) Communication Unit The communication unit 120 is an interface that mediates communication between the broadcast signal processing node 100 and other nodes. The communication unit 120 may include connection terminals and connection circuits for wired communication, or may include an antenna, an RF (Radio Frequency) circuit, and a baseband circuit for wireless communication. In this embodiment, the communication unit 120 includes a transmitter 122 and a receiver 124 .

A series of RTP packets for a broadcast signal stream generated by a transmission stream processing unit 130 (to be described later) are input to the transmission unit 122 . Each RTP packet contains essence data corresponding to any one of video data, audio data and ancillary data in the RTP payload. The RTP header of each RTP packet is given an RTP timestamp according to the RTP clock 114 which has no offset with respect to the media clock 112 locked to the device internal clock 110 . The transmitting unit 122 adds a network header to each input RTP packet and transmits each packet to other nodes participating in the broadcasting station system 1 . If the stream is an ARIB STD-B73 stream, the port number described in the network header is common to packets carrying video data, packets carrying audio data, and packets carrying auxiliary data.

The receiver 124 receives a broadcast signal stream consisting of a series of RTP packets from another node having the same sender function as the transmission stream processor 130 and the transmitter 122 of the broadcast signal processing node 100 . Each RTP packet contains essence data corresponding to any one of video data, audio data and ancillary data in the RTP payload. If the stream is an ARIB STD-B73 stream, a series of RTP packets are received as a single stream through a common port number. The RTP header of each RTP packet contains an RTP timestamp appended according to the RTP clock with no offset relative to the media clock locked to the device internal clock of the sending node. The header in the RTP payload of each RTP packet contains frame count information based on the same RTP clock. The broadcast signal processing node 100 and the node on the transmitting side are directly or indirectly synchronized with the PTP time source as described above. Therefore, the clock error between those nodes can be, for example, 10 μs or less.

The receiving unit 124 may receive broadcast signal streams other than the ARIB STD-B73 stream from other nodes. For example, the receiver 124 may receive a mixed-essence stream similar to the ARIB STD-B73 stream (eg, SMPTE ST2022-6 stream). The receiver 124 may also receive an essence-separated stream such as an SMPTE ST2110 stream.

The receiving unit 124 removes the network header from each packet of the received broadcast signal stream and outputs RTP packets composed of the RTP header and RTP payload to the received stream processing unit 140 .

(6) Transmission Stream Processing Unit The transmission stream processing unit 130 processes a sequence of video data, audio data or auxiliary data input from the data processing unit 180 to generate a series of RTP packets for the broadcast signal stream. . The transmission stream processor 130 may, for example, segment an incoming data sequence into one or more essence payloads and add an essence header to each payload. The payload type in the essence header is set to a value that indicates the type of the corresponding essence, and the frame count value is incremented by one at the start of each new video frame. The transmission stream processing unit 130 further adds a transport header (common header and RTP header) to each packet. The value of the sequence number in the common header is incremented by 1 for each transmission separately for video essence, audio essence and ancillary data essence. The payload type in the RTP header is set to a fixed value and the sequence number value is incremented by 1 for each transmission regardless of the payload type. The transmission stream processing unit 130 further adds an RTP timestamp to the RTP header according to the RTP clock 114 . The transmission stream processing unit 130 outputs a series of RTP packets generated in this way to the transmission unit 122 .

(7) Received Stream Processing Unit The received stream processing unit 140 processes a series of RTP packets of the broadcast signal stream received from other nodes via the receiving unit 124 to restore video data, audio data or auxiliary data. do. Then, reception stream processing section 140 outputs the restored data sequence to data processing section 180 . In particular, in this embodiment, the received stream processing unit 140 uses the RTP timestamp obtained from the RTP header of the received RTP packet, or the header (e.g., essence header or common Based on the frame count information obtained from the header), time alignment of essence data is performed between the RTP packet and other RTP packets. An example of a more detailed configuration of the received stream processing unit 140 for such time adjustment will be further described later.

(8) Data Processing Unit The data processing unit 180 generates video data, audio data, or auxiliary data, and outputs the generated data sequence to the transmission stream processing unit 130 . The data processing unit 180 may, for example, compress video data input from a data source (not shown) to generate compressed video data. Also, the data processing unit 180 processes video data, audio data, or auxiliary data restored by the reception stream processing unit 140 . The data processing unit 180 extracts a plurality of essences (for example, two or more of a video essence, an audio essence and an auxiliary data essence, or multiple video essences) may be played back synchronously. Also, the data processing unit 180 may record the video data, audio data, or auxiliary data restored by the reception stream processing unit 140 in a recording medium (not shown) in a predetermined file format. Further, when the video data input from the reception stream processing unit 140 is compressed video data, the data processing unit 180 decompresses the compressed video data to restore the original video data. You may

(9) Control Unit The control unit 190 controls the overall operations of the broadcast signal processing node 100 described above. The control unit 190 causes the transmission unit 122 to transmit the broadcast signal stream or causes the reception unit 124 to receive the broadcast signal stream in accordance with instructions received from an external device such as the APS 40 or the control terminal 50 . If the broadcast signal processing node 100 supports a plurality of transmission protocols, the control unit 190 causes each processing unit to perform operations for the transmission protocol selected by instructions from the external device, for example. The control unit 190 notifies other nodes via the communication unit 120 of the functionality of the broadcast signal processing node 100 (for example, the supported protocol, the type of essence that can be transmitted/received, the clock frequency and other attributes). may

In some embodiments described herein, attributes of broadcast signal streams that are RTP streams are described in SDP objects. According to SMPTE ST2110-10, a device containing one or more senders shall construct one SDP object per RTP stream. Also in this embodiment, an SDP object describing attributes of a stream that can be transmitted by the transmission stream processing unit 130 and the transmission unit 122, which serve as senders, is stored in advance in the storage unit (not shown) of the broadcast signal processing node 100. can be stored. Then, prior to starting stream transmission, the control unit 190 provides the SDP object to the external device via a predefined management application protocol interface (for example, NMOS API). On the other hand, when the control unit 190 causes the reception unit 124 and the reception stream processing unit 140 to receive a broadcast signal stream from another transmission node, the control unit 190 processes the received broadcast signal stream according to the description of the SDP object provided by the transmission node. Configure receiver processing for correct processing. The format of the SDP object suitable for the characteristics of the ARIB STD-B73 stream will be described in detail in third and fourth embodiments, which will be described later.

<2-2. Detailed Configuration Example of Reception Stream Processing Unit>
FIG. 8 is a block diagram showing an example of a detailed configuration of reception stream processing section 140 shown in FIG. Referring to FIG. 8 , the received stream processor 140 includes a transport processor 142 , an essence datagram processor 150 and an FEC datagram processor 170 .

(1) Transport Processing Section The transport processing section 142 includes a transport header (TH) removing section 144 . The TH removing unit 144 removes the RTP header and the common header (that is, transport header) at the beginning of the RTP packets of the broadcast signal stream input from the receiving unit 124 . Then, the TH removal unit 144 distributes the datagram of the RTP packet to the essence datagram processing unit 150 or the FEC datagram processing unit 170 depending on the value of "datagram type" in the common header. For example, when the value of “datagram type” indicates an essence datagram, the essence datagram is output to the essence datagram processing unit 150 . On the other hand, when the value of “datagram type” indicates an FEC datagram, the FEC datagram is output to the FEC datagram processing unit 170 .

Datagrams are output from the transport processing unit 142 to the essence datagram processing unit 150 or the FEC datagram processing unit 170 in the order of the "sequence number" in the RTP header. Processing of datagrams corresponding to missing sequence numbers may be skipped. The transport processing unit 142 outputs the value of the RTP timestamp in the RTP header corresponding to the essence datagram to the alignment unit 160 .

(2) Essence Datagram Processing Unit The essence datagram processing unit 150 includes an essence header (EH) removal unit 152, a video essence processing unit 154, an audio essence processing unit 156, an auxiliary data essence processing unit 158, and an alignment unit 160. .

The EH remover 152 removes the essence header at the beginning of the essence datagram input from the transport processor 142 . Then, the EH removal unit 152 converts the essence payload of the essence datagram into a video essence processing unit 154, an audio essence processing unit 156, or an ancillary data essence processing unit, depending on the value of "payload type" in the essence header. 158. For example, when the value of “payload type” indicates video essence, the video essence is output to video essence processing section 154 . When the value of “payload type” indicates voice essence, the voice essence is output to voice essence processing section 156 . When the value of “payload type” indicates an auxiliary data essence, the auxiliary data essence is output to auxiliary data essence processing section 158 . The EH removal section 152 also outputs the value of “frame count” in the essence header to the alignment section 160 .

The image essence processor 154 processes the image essence sequentially input from the EH remover 152 to restore image data. For example, when an ARIB STD-B73 stream is received, the video essence processing unit 154 can restore the video data by depacking the video essence according to the video payload packing format defined by ARIB STD-B73. . If the video essence includes compressed video data, the video essence processing unit 154 may decompress the video essence to restore the video data (the decompression is performed by the data processing unit 180 as described above). may be done).

The voice essence processing unit 156 processes the voice essence sequentially input from the EH removal unit 152 to restore voice data. For example, when an ARIB STD-B73 stream is received, the audio essence processing unit 156 can depack the audio essence according to the audio payload packing format defined by ARIB STD-B73 to restore the audio data. .

The auxiliary data essence processor 158 processes the auxiliary data essence sequentially input from the EH remover 152 to restore the auxiliary data. For example, when the ARIB STD-B73 stream is received, the auxiliary data essence processing unit 158 reverse-packs the auxiliary data essence according to the auxiliary data payload packing format defined by ARIB STD-B73, and converts the auxiliary data to can be restored.

The alignment unit 160 aligns the essence data based on the RTP timestamp acquired by the transport processing unit 142 from the RTP header of each RTP packet or the frame count information acquired from the header in the RTP payload of each RTP packet. time adjustment.

In this embodiment, at least the first RTP packets are packets generated according to the protocol for mixed-essence streams. The protocol for mixed-essence streams may be, for example, ARIB STD-B73. When ARIB STD-B73 is used, each RTP packet of the essence-mixed stream does not contain data corresponding to the blanking period, and essence data corresponding to any one of video data, audio data and ancillary data. in the RTP payload.

FIG. 9A is an explanatory diagram for explaining a first example of a technique for time alignment of essence data between two RTP packets. FIG. 9A shows a first RTP packet 161a and a second RTP packet 166a. It is assumed that both the first RTP packet 161a and the second RTP packet 166a are generated according to ARIB STD-B73. A first RTP packet 161a and a second RTP packet 166a are received via a single port _PM .

The first RTP packet 161a contains a "timestamp" in the RTP header 162a and a "payload type" and "frame count" in the essence header 163a. The "payload type" value of the essence header 163a indicates that the corresponding essence payload contains video essence, and the "frame count" indicates the value F1. The value F1 corresponds to the capture time of the video frame to which the video essence belongs, for example, when the epoch time defined in SMPTE ST2059-1 is zero.

The second RTP packet 166a includes a "timestamp" in the RTP header 167a and a "payload type" and "frame count" in the essence header 168a. The "payload type" value of the essence header 168a indicates that the corresponding essence payload contains audio essence, and the "frame count" indicates the value F1. The value F1 corresponds to the capture time of the video frame to which the audio essence belongs, for example, when the epoch time defined by SMPTE ST2059-1 is zero.

In the first example shown in FIG. 9A, the alignment unit 160 aligns the RTP packets 161a and 166a between the RTP packets 161a and 166a based on the frame count information obtained from the essence headers 163a and 168a of these RTP packets 161a and 166a. Adjust the time of the essence data. In this way, when time alignment is performed based only on the frame count information in the essence header, it becomes unnecessary to output time stamp information from the transport processing unit 142 to the alignment unit 160, and reference to information across protocol layers becomes unnecessary. is suppressed, the configuration of the reception stream processing unit 140 can be simplified.

FIG. 9B is an explanatory diagram for explaining a second example of a technique for time alignment of essence data between two RTP packets. FIG. 9B shows a third RTP packet 161b and a fourth RTP packet 166b. It is assumed that both the third RTP packet 161b and the fourth RTP packet 166b are generated according to ARIB STD-B73. A third RTP packet 161b and a fourth RTP packet 166b are received via a single port _PM .

The third RTP packet 161b contains a "timestamp" in the RTP header 162b and a "payload type" and "frame count" in the essence header 163b. The "timestamp" of the RTP header 162b indicates the value T2. The "payload type" value of the essence header 163b indicates that the corresponding essence payload contains video essence. The value T2 corresponds, for example, to the capture time of the video frame to which the video essence belongs.

The fourth RTP packet 166b includes a "timestamp" in the RTP header 167b and a "payload type" and "frame count" in the essence header 168b. The "timestamp" of the RTP header 167b indicates the value T2. The "payload type" value of essence header 168b indicates that the corresponding essence payload contains audio essence. The value T2 corresponds, for example, to the capture time of the video frame to which the audio essence belongs.

In the second example shown in FIG. 9B, the alignment unit 160 aligns the RTP packets 161b and 166b between the RTP packets 161b and 166b based on the RTP timestamps obtained from the RTP headers 162b and 167b of these RTP packets 161b and 166b. Adjust the time of the essence data. When time alignment is performed based on RTP timestamps in this way, the alignment unit 160 can be configured simply by reusing the implementation for the system timing model of SMPTE ST2110-10, which also uses RTP timestamps. can be done.

FIG. 9C is an explanatory diagram for explaining a third example of a technique for time alignment of essence data between two RTP packets. FIG. 9C shows a fifth RTP packet 161c and a sixth RTP packet 166c. Assume that the fifth RTP packet 161c is generated according to ARIB STD-B73 and the sixth RTP packet 166c is generated according to SMPTE ST2110-30. For example, the fifth RTP packet 161c is received via port _PM and the sixth RTP packet 166c is received via port _PA for essence separated streams containing audio essence.

The fifth RTP packet 161c contains a 'timestamp' in the RTP header 162c and a 'payload type' and a 'frame count' in the essence header 163c. The "payload type" value of the essence header 163c indicates that the corresponding essence payload contains video essence, and the "frame count" indicates the value F3. The value F3 corresponds to the capture time of the video frame to which the video essence belongs.

The sixth RTP packet 166c includes a "timestamp" in the RTP header 167c. The "timestamp" of the RTP header 167c indicates the value T3. The value T3 corresponds, for example, to the earliest sampling time of the audio data within the audio essence.

In the third example shown in FIG. 9C, the alignment unit 160 uses the frame count information obtained from the essence header 163c of the fifth RTP packet 161c and the RTP header 167c of the sixth RTP packet 166c. Based on the RTP timestamp, time alignment of essence data is performed between the RTP packet 161c and the RTP packet 166c. For example, when the sampling time corresponding to the value T3 is included in the frame period of the video frame corresponding to the value F3, the alignment unit 160 transfers the audio data restored from the sixth RTP packet 166c to the fifth RTP packet. 161c should be synchronized to the same video frame as the video data recovered from 161c. According to such a method, even if an effective timestamp value is not set for the RTP timestamp of the RTP packet of the ARIB STD-B73 stream, the time can be properly set between the ARIB STD-B73 stream and the SMPTE ST2110 stream. Alignment can be done.

FIG. 9D is an explanatory diagram for explaining a fourth example of a technique for time alignment of essence data between two RTP packets. FIG. 9D shows a seventh RTP packet 161d and an eighth RTP packet 166d. It is assumed that the seventh RTP packet 161d is generated according to ARIB STD-B73 and the eighth RTP packet 166d is generated according to SMPTE ST2110-20. For example, the seventh RTP packet 161d is received via port _PM and the eighth RTP packet 166d is received via port _PV for essence separated streams containing video essence.

The seventh RTP packet 161d contains a "timestamp" in the RTP header 162d and a "payload type" and "frame count" in the essence header 163d. The "timestamp" of the RTP header 162d indicates the value T4. The "payload type" value of essence header 163d indicates that the corresponding essence payload contains audio essence. The value T4 corresponds, for example, to the capture time of the video frame to which the audio essence belongs.

The eighth RTP packet 166d includes a "timestamp" in the RTP header 167d. The "timestamp" of the RTP header 167d indicates the value T4'. The value T4' corresponds, for example, to the capture time of the video frame to which the video essence belongs (in the case of an interlaced second field, the time offset by half the frame period).

In the seventh example shown in FIG. 9D, the alignment unit 160 uses the RTP timestamp obtained from the RTP header 162d of the seventh RTP packet 161d and the RTP timestamp obtained from the RTP header 167d of the eighth RTP packet 166d. Based on the RTP timestamp, the essence data is time aligned between the RTP packet 161d and the RTP packet 166d. According to such an approach, the implementation for the system timing model of SMPTE ST2110-10, which utilizes RTP timestamps, is reused for the processing of ARIB STD-B73 streams to simplify the configuration of alignment section 160. be able to.

(3) FEC Datagram Processing Unit As described above, the SMPTEST ST2110 series does not perform error correction processing. On the other hand, ARIB STD-B73 supports FEC with RS (Reed-Solomon)-based technique or XOR-based technique. The FEC datagram processing unit 170 takes charge of this error correction processing. That is, the FEC datagram processing unit 170 performs error correction processing on the FEC datagrams input from the transport processing unit 142 .

For example, when the RS-based method is selected as the error correction method, the FEC datagram processing unit 170 uses the number of datagrams (n, k) set by the control unit 190 as the processing unit of RS decoding. Perform decryption. Here, n represents the sum of the number of essence datagrams to be subjected to FEC calculation and the number of corresponding FEC datagrams. k represents the number of essence datagrams concerned. In addition, when the XOR-based method is selected as the error correction method, the FEC datagram processing unit 170 performs XOR-based processing on an FEC block of size (L, D) set by the control unit 190 as a processing unit. Perform decryption. Here, L represents the number of essence datagrams in the row direction and D represents the number of essence datagrams in the column direction.

<2-3. Process Flow>
Next, the flow of main processing that can be executed in the first embodiment will be described with reference to FIGS. 10 and 11. FIG.

(1) Stream Transmission Processing FIG. 10 is a flowchart showing an example of the flow of stream transmission processing according to the first embodiment. Here, the stream transmission processing is described as being performed by the broadcast signal processing node 100, but the stream transmission processing may be performed by any node having the functions of the sender 60 described above.

First, the PTP processing unit 116 directly or indirectly synchronizes the device internal clock 110 with the PTP time source (step S101). Synchronization of the device internal clock 110 with the PTP's time source continues to be maintained thereafter.

The transmission stream processing unit 130 generates an essence payload from the essence data input from the data processing unit 180 under the control of the control unit 190, for example (step S103). Essence data includes either video data, audio data or auxiliary data. The essence payload can be generated by packing essence data according to the packing format for video data, audio data or auxiliary data defined by ARIB STD-B73, for example.

Next, the transmission stream processing unit 130 calculates a frame count value (and/or RTP timestamp) according to the RTP clock 114 that has no offset with respect to the media clock 112 locked to the device internal clock 110 (step S105). The frame count value remains the same while essence data belonging to the same video frame is being processed.

Next, the transmission stream processing unit 130 adds an essence header including the frame count value to the beginning of the essence payload to generate an essence datagram (step S107). The essence header also contains a "payload type" that indicates the type of essence contained in the essence payload.

Next, the transmission stream processing unit 130 adds a transport header including an RTP timestamp having a value according to the RTP clock 114 to the essence datagram to generate an RTP packet (step S109). The transmission stream processing unit 130 may further perform error correction coding processing to generate RTP packets containing FEC datagrams.

Next, the transmission unit 122 adds a network (NW) header to the RTP packet generated by the transmission stream processing unit 130 to generate an IP packet (step S111). The port number in the UDP header of an IP packet indicates a common value assigned to ARIB STD-B73 streams, regardless of the type of essence contained. A destination IP address in the IP header indicates, for example, a multicast address assigned to the stream.

Next, the transmission unit 122 transmits the generated IP packet to the network (step S113). A transmitted IP packet is received by a receiving node that has subscribed to the corresponding multicast group.

The processing of steps S103 to S113 described above can be repeatedly performed while unprocessed essence data remains (step S115). When all the essence data have been processed, the stream transmission process shown in FIG. 10 ends.

(2) Stream Reception Processing FIG. 11 is a flowchart showing an example of the flow of stream reception processing according to the first embodiment.

First, the PTP processing unit 116 of the broadcast signal processing node 100 directly or indirectly synchronizes the device internal clock 110 with the PTP time source (step S151). Synchronization of the device internal clock 110 with the PTP's time source continues to be maintained thereafter.

Next, the receiving unit 124 receives IP packets of broadcast signal streams transmitted from other nodes through the same process as the stream transmission process described using FIG. 10 (step S153). Since the device internal clock 110 of the broadcast signal processing node 100 is synchronized with the PTP time source, the broadcast signal processing node 100 is also highly accurately synchronized with the above-mentioned other node that is the transmission source of the IP packet.

Next, the receiving unit 124 extracts the RTP datagram by removing the network header of the received IP packet (step S153). The receiving unit 124 then outputs the extracted RTP datagram to the reception stream processing unit 140 .

Next, the reception stream processing unit 140 extracts the essence payload by removing the transport header and essence header of the RTP datagram (step S155).

Next, according to the value of the payload type in the essence header, the received stream processing unit 140 reverse-packs the essence payload according to the packing format of video data, audio data or auxiliary data defined by ARIB STD-B73. The essence data is restored (step S157). Although not shown in FIG. 11, when an FEC datagram is received together with an essence datagram, the reception stream processing unit 140 performs error correction decoding based on the FEC datagram to convert the reception data to Bit errors may be detected.

Next, the alignment unit 160 of the reception stream processing unit 140 performs time alignment between essence data derived from different RTP packets based on the RTP timestamp in the RTP header or the frame count information in the RTP payload (step S159). ).

Next, the data processing unit 180 executes processing based on the essence data time-aligned by the alignment unit 160 (step S161). The processing performed here may be, for example, the synchronous reproduction of multiple essences, or the conversion of essence data into SDI signals.

The processing of steps S153 to S161 described above can be repeatedly performed while packets of the same stream are continuously received (step S163). When packet reception stops, the stream reception processing shown in FIG. 11 ends.

<<3. Second Embodiment>>
Next, a second embodiment will be described with reference to FIG. 12 . The first embodiment described above is a specific embodiment, while the second embodiment is a more general embodiment.

<3-1. Configuration example of broadcast signal processing node>
FIG. 12 is a block diagram showing an example configuration of a broadcast signal processing node 200 according to the second embodiment. Broadcast signal processing node 200 is a node that receives broadcast signal streams from one or more other nodes. Streams received by broadcast signal processing node 200 include, but are not limited to, mixed-essence streams such as ARIB STD-B73 streams. Referring to FIG. 12, the broadcast signal processing node 200 includes a communication section 210 and an alignment section 220.

The communication unit 210 is an RTP packet whose RTP header is time-stamped according to the RTP clock, which has no offset to the media clock locked to the device internal clock that is directly or indirectly synchronized to the PTP time source. Then, the RTP packet (first RTP packet) containing the essence data corresponding to any one of the video data, the audio data and the auxiliary data in the RTP payload is received. The communication unit 210 also receives another RTP packet (second RTP packet). The first RTP packet and the second RTP packet may be packets included in the same broadcast signal stream, or may be packets included in different broadcast signal streams.

The alignment unit 220 , based on the time stamp obtained from the RTP header of the received RTP packet or the frame count information obtained from the header in the RTP payload of the received RTP packet, Time alignment of essence data is performed between the RTP packet and the other RTP packet.

Broadcast signal processing for time alignment of essence data may include the above operational steps of the broadcast signal processing node 200 . A computer program may also be provided that causes a processor to perform those operational steps. A non-transitory computer-readable storage medium storing a computer program that causes a processor to perform those operational steps may also be provided. Additionally, any function or process described in the first embodiment may be applied to this embodiment.

<3-2. Variation>
FIG. 13 is a block diagram showing an example configuration of a broadcast signal processing node 200 according to the first modification of the second embodiment. Referring to FIG. 13, broadcast signal processing node 200 includes reproducing section 230 in addition to communication section 210 and alignment section 220 described using FIG.

The reproduction unit 230 synchronously reproduces the essence based on the essence data of the RTP packet (first RTP packet) and the other RTP packet (second RTP packet) time-aligned by the alignment unit 220. do. For example, video received from multiple cameras may be played simultaneously, video and audio may be played synchronously, or auxiliary data may be played along with video and/or audio.

FIG. 14 is a block diagram showing an example configuration of a broadcast signal processing node 200 according to the second modification of the second embodiment. Referring to FIG. 14, broadcast signal processing node 200 includes first communication unit 215 , alignment unit 220 , conversion unit 240 and second communication unit 250 .

The first communication unit 215 generates RTP packets whose RTP headers are time-stamped according to the RTP clock that has no offset with respect to the media clock locked to the device internal clock that is directly or indirectly synchronized with the PTP time source. and receives an RTP packet (first RTP packet) containing essence data corresponding to any one of video data, audio data, and auxiliary data in the RTP payload. The first communication unit 215 also receives another RTP packet (second RTP packet). The first RTP packet and the second RTP packet may be packets included in the same broadcast signal stream, or may be packets included in different broadcast signal streams.

Based on the time alignment of the essence data between the RTP packet (first RTP packet) and the other RTP packet (second RTP packet) by the alignment unit 220, the conversion unit 240 extracts data derived from these RTP packets. The essence data to be converted into an SDI signal. The signal format of the SDI signal produced by converter 240 may be any derivative of SDI, eg SD-SDI, HD-SDI, 3G-SDI, 6G-SDI or 12G-SDI.

The second communication unit 250 transmits the SDI signal generated by the conversion unit 240 based on the time adjustment described above to other nodes belonging to the SDI domain.

<<4. Summary of First Embodiment and Second Embodiment>>
So far, the first and second embodiments of the present disclosure have been described in detail. In the above-described embodiment, time alignment of essence data between an RTP packet containing essence data corresponding to any one of video data, audio data, and auxiliary data in the RTP payload and other RTP packets is performed in the RTP header. or based on the frame count information obtained from the header in the RTP payload. RTP timestamps are applied according to the RTP clock, which has no offset to the media clock locked to the device internal clock that is directly or indirectly synchronized to the PTP time source. According to this configuration, when using a protocol for transmitting essence data such as video data, audio data, or auxiliary data in a single stream on the IP network of a broadcasting station, it is possible to perform appropriate time adjustment of the essence data. It is possible.

In one example, the RTP packets are packets generated according to a protocol for mixed-essence streams. The mixed-essence stream may be, for example, an ARIB STD-B73 stream. The ARIB STD-B73 stream does not contain data corresponding to blanking periods. These examples make it easy to time-align essence data without complicating the process of reconstructing the original content at the receiving end, and avoiding the potential for different delays over the network for each essence type. can do.

In one example, the clock frequency of the media clock is equal to 27.0 MHz. According to such a configuration, the clock frequency of the media clock is set to an integer multiple of the video frame frequency to accurately keep the frame period constant, and a single mixed-essence stream that can include video data, audio data, and ancillary data is generated. Information for time alignment can be provided in a common manner based on the clock frequency of the media clock.

<<5. Third Embodiment>>
As already mentioned above, the format of SDP objects normally used for SMPTE ST2110 streams is not necessarily suitable for the characteristics of ARIB STD-B73 streams, neither in format structure nor in the information content described. . In order to properly set up the transmission of an ARIB STD-B73 stream, it is necessary to define the format of the SDP objects suitable for the characteristics of the stream.

<5-1. Example of an existing SDP object>
SDP is a protocol that defines a format for textually describing parameter sets used in streaming (or any other session). By transmitting and receiving an SDP object (for example, a data file described in SDP format) to and from the receiving side, negotiations are made regarding what parameter values should actually be used, and an agreement is reached. Alternatively, if the control node is centrally involved in setting up the stream, the SDP object may be provided to the control node.

FIG. 15 is an explanatory diagram for explaining a typical format structure of an SDP object for an essence-separated stream. As shown in Figure 15, an SDP object consists of a session-level section for describing session-level attributes (specific to a session rather than individual media belonging to the session) and attributes for each of one or more media. and one or more media-level sections for describing The SDP object of FIG. 15 contains media level sections for video essence, audio essence and ancillary data essence respectively. Optionally, in addition to the media level section for the primary video essence, the media level section for the secondary video essence is included in the SDP object if a redundant RTP stream scheme is applied to the video essence for increased availability. can be Note that the redundant RTP stream scheme may be applied to any one or more of video essence, audio essence, and ancillary data essence without being limited to such an example. Each media level section contains attribute fields that describe the attributes of the stream of the corresponding essence type. That is, the media level section for video essence contains video-related attribute fields, the media-level section for audio essence contains audio-related attribute fields, and the media-level section for auxiliary data essence contains auxiliary data-related attribute fields. can include

FIG. 16 shows an example of an SDP object describing attributes of an SMPTE ST2110 stream having the format structure described with reference to FIG.

Referring to FIG. 16, SDP object 301 includes session level section 302 and four media level sections 303 , 304 , 305 and 306 . The session level section 302 is for describing session-specific information such as a protocol version field ("v=..."), a source field ("o=..."), and a session name field ("s=..."). It has a group of fields.

The start of each media level section is identified by a media description field ("m=..."). Media level sections 303 and 304 are for streams of video essence. In the example of FIG. 16, the media level section 303 describes the attributes of the primary video essence stream, and the media level section 304 describes the attributes of the secondary video essence stream. The media level section 305 describes the attributes of the audio essence stream. The media level section 306 describes attributes of the stream of auxiliary data essence.

The media description field ("m=...") at the beginning of the media level section 303 for video contains the media type ("video"), transmission port number ("50000"), transport protocol ("RTP/AVP"). , and the format type number (“112”). In addition to this media description field, media level section 303 includes video related attribute fields 307 . The video-related attribute field group 307 includes a source filter attribute field ("a=source-filter:..."), an RTP map attribute field ("a=rtpmap:..."), and a format-specific parameter attribute field ("a=fmtp:..."). ”), a reference clock attribute field (“a=ts-refclk: …”), a media clock attribute field (“a=mediaclk: …”), and a map ID attribute field (“a=mid: …”). Of these, the RTP map attribute field ("a=rtpmap:...") has the same value as the format type number of the corresponding media description field, payload type number ("112"), subtype name ("raw"). and the media clock frequency (“90000”). The format-specific parameter attribute field ("a=fmtp:...") lists the format type number ("112") followed by parameter name and parameter value pairs for one or more format-specific parameters. The Map ID attribute field ("a=mid:...") is used to distinguish between primary and secondary streams when redundant RTP streams are used. The contents of media level section 304 are omitted in FIG. 16 because they may be similar to media level section 303 except for the transmission port number and map ID attribute fields in the media description field.

The media description field ("m=...") at the beginning of the media level section 305 for audio contains the media type ("audio"), transmission port number ("51200"), transport protocol ("RTP/AVP"). , and the format type number (“97”). In addition to this media description field, media level section 305 includes audio-related attribute fields 308 . Audio-related attribute fields 308 include an RTP map attribute field (“a=rtpmap: …”), a packet time attribute field (“a=ptime: …”), a reference clock attribute field (“a=ts-refclk: …”). ), a media clock attribute field ("a=mediaclk:..."), a format specific parameter attribute field ("a=fmtp:..."), and a map ID attribute field ("a=mid:..."). Of these, the RTP map attribute field ("a=rtpmap:...") has a payload type number ("97"), subtype name ("L24") that has the same value as the format type number of the corresponding media description field. , indicates the media clock frequency (“48000”) and the coding parameter (“6”). Note that the subtype name "L24" indicates that the voice essence is encoded by 24-bit linear encoding. The encoding parameter "6" indicates that the number of audio channels is six. The format-specific parameter attribute field ("a=fmtp:...") lists the format type number ("97") followed by parameter name and parameter value pairs for one or more format-specific parameters.

The media description field ("m=...") at the beginning of the media level section 306 for ancillary data includes media type ("video"), transmission port number ("51300"), transport protocol ("RTP/AVP"), ), and the format type number (“98”). In addition to this media description field, media level section 306 includes auxiliary data related attribute fields 309 . The auxiliary data-related attribute field group 309 includes an RTP map attribute field ("a=rtpmap:..."), a reference clock attribute field ("a=ts-refclk:..."), and a media clock attribute field ("a=mediaclk:..."). ”), and a map ID attribute field (“a=mid: …”). Of these, the RTP map attribute field ("a=rtpmap:...") has a payload type number ("98"), subtype name ("smpte291") that has the same value as the format type number of the corresponding media description field. and the media clock frequency (“90000”).

As can be seen from Figure 16, the SDP object for an SMPTE ST2110 stream contains media level sections for each of multiple essence types, which have different sets of fields depending on the corresponding essence type. have. Such format structures are reusable for essence-separated streams like SMPTE ST2110 streams, but are not suitable for describing attributes of mixed-essence streams like ARIB STD-B73 streams. This is because the mixed-essence stream contains multiple essence-type data in a single stream. Furthermore, the SDP object format illustrated in FIG. 16 lacks the information items required to set up an ARIB STD-B73 stream that supports compression of video essence and is also capable of error correction encoding/decoding. .

<5-2. New Format of SDP Object>
FIG. 17 is an explanatory diagram for explaining the format structure of the SDP object defined for the mixed-essence stream in this embodiment.

As shown in Figure 17, in the new format, the SDP object contains a session-level section that describes session-level attributes and a media-level section that is common to multiple essence types. And one common media level section contains attribute fields for describing attributes related to video essence, attributes related to audio essence, and attributes related to auxiliary data essence. Notably, in this embodiment, parameters that are not assigned separate attribute fields in the SDP standard are described in format-specific parameter attribute fields. In this way, by adapting the structure of the SDP object to the characteristics of the mixed-essence stream (or ARIB STD-B73 stream), stream-specific information can be described in the SDP object without ambiguity.

Optionally, in addition to the primary essence-common media-level section, the SDP object may contain a secondary essence-common media-level section if a redundant RTP stream scheme is applied for increased availability.

FIG. 18 shows an example of an SDP object describing the attributes of the ARIB STD-B73 stream having the format structure described with reference to FIG.

Referring to FIG. 18, SDP object 311 contains session level section 312 and two media level sections 313 and 318 . The session level section 312 is for describing session specific information such as a protocol version field ("v=..."), a source field ("o=...") and a session name field ("s=..."). It has a group of fields.

The beginnings of media level sections 313 and 318 are identified by their respective media description fields ("m=..."). Both media level sections 313 and 318 are sections common to multiple essence types. In the example of FIG. 18, the media level section 313 describes the attributes of the primary mixed-essence stream, and the media-level section 318 describes the attributes of the secondary mixed-essence stream.

The media description field ("m=...") at the beginning of the media level section 313 contains the media type ("video"), transmission port number ("50000"), transport protocol ("RTP/AVP"), and format. A format number (“110”) is described. The media level section 313 is a section common to multiple essence types as described above, but in the technology according to the present disclosure, the timing of each essence is associated with a video frame. "video" can be selected as the The sending port number may be, for example, a UDP port number arbitrarily selected from a range of private port numbers. The format type number may be another value (eg, "111"). In this embodiment, the format type number has a role as a format identification value commonly given to a plurality of essence types. In addition to this media description field, media level section 313 includes attribute fields 314 . Specifically, in the example of FIG. 18, attribute fields 314 include an RTP map attribute field ("a=rtpmap:...") 315, a format specific parameter attribute field ("a=fmtp:...") 316, and a packet time attribute field ( "a=ptime:...") 317.

The RTP map attribute field 315 is related to the media description field at the beginning of the media level section 313 by the payload type number (“110”) having the same value as the format type number. The subtype name of the RTP map attribute field 315 describes, for example, the protocol name “ARIB_STD-B73”, which indicates that the broadcast signal stream transmitted by the sender providing the SDP object 311 is an ARIB STD-B73 stream. is specified. The media clock frequency indicated by the RTP map attribute field 315 is now 27 MHz.

The format specific parameter attribute field 316 is related to the media description field at the beginning of the media level section 313 by the format type number (“110”). Format specific parameter attribute field 316 includes at least first attribute information associated with essence data of a first essence type and second attribute information associated with essence data of a second essence type. In the example of FIG. 18, format-specific parameter attribute field 316 contains information categorized as follows:
- Video-related attribute - attribute information related to essence data of video essence - Audio-related attribute - attribute information related to essence data of audio essence - Auxiliary data-related attribute - attribute information related to essence data of auxiliary data essence - FEC-related Attribute - Attribute information related to error correction scheme Traffic shaping related attribute - Attribute information related to traffic shaping

The following Tables 1-5 respectively list parameters for video-related attributes, audio-related attributes, auxiliary data-related attributes, FEC-related attributes, and traffic shaping-related attributes that may be described in the format-specific parameter attribute field 316 in this embodiment. showing.

In this embodiment, compression-related information is newly defined to indicate whether video essence data is compressed. Video-related attributes containing this compression-related information can be described in the format-specific parameter attributes field 316 of the media level section 313 of the SDP object 311 . Specifically, for example, as shown in Table 1, the compression-related information includes a compression parameter "compression" indicating whether video essence data is compressed. Further, when the compression parameter indicates that the video essence data is compressed, the compression-related information includes a codec parameter "codec" indicating the codec (compression method) used when compressing the video essence data. .

According to the existing SDP format, audio channel number information related to audio essence data is stored in the RTP map attribute field ("a=rtpmap:...") of the media level section for audio, as illustrated in FIG. Described. However, as in this embodiment, when only a common media level section is provided for multiple essence types and "video" is selected as the media type character string, the number of audio channels cannot be described in the RTP map attribute field. is against the SDP standard. Therefore, in this embodiment, as shown in Table 2, audio channel number information is defined as format-specific audio-related attributes. Audio-related attributes, including this audio channel number information, can be described in the format-specific parameter attributes field 316 of the media level section 313 of the SDP object 311, along with the video-related attributes described above. Specifically, for example, the audio channel number information includes an audio channel number parameter “channel-number”. Whereas in SMPTE ST2110-30 the number of audio channels can be any integer ranging from 1 to different upper limits depending on the level, in ARIB STD-B73 the number of audio channels can be 4, 8, 12 or 16. constrained by

In this embodiment, auxiliary data-related attributes may be described in format-specific parameter attribute field 316 of media level section 313 of SDP object 311, along with video-related attributes (and audio-related attributes). Specifically, for example, as shown in Table 3, the auxiliary data-related attributes include data ID and secondary data ID "DID_SDID" and video payload ID code "VPID_Code".

In this embodiment, error correction information indicating an error correction method applied to essence data is newly defined. This error correction information can be described in the format specific parameter attribute field 316 of the media level section 313 of the SDP object 311 along with the other attributes described above. Specifically, for example, as shown in Table 4, the error correction information includes a type parameter "FECtype" indicating the error correction method applied to the essence data, and the set value of the error correction method indicated by the type parameter. and a configuration parameter indicating If the type parameter indicates XOR encoding (“XOR”), the configuration parameters include a size parameter “XORsize” indicating the error correction block size. On the other hand, when the type parameter indicates Reed-Solomon encoding (“RS”), the setting parameter includes a datagram number parameter “RSnum” indicating the number of datagrams corresponding to the processing unit of Reed-Solomon encoding.

In this embodiment, the traffic shaping related attributes may be described in the format specific parameter attributes field 316 of the media level section 313 of the SDP object 311 along with the other attributes described above. Specifically, for example, as shown in Table 5, the traffic shaping related attributes include a buffer type parameter "TP" that indicates the type of the sender's buffer.

In this embodiment, packet time attribute field 317 is contained within the same media level section 313 as format specific parameter attribute field 316 . This is in contrast to the example of Figure 16 where the packet time attribute field ("a=ptime:...") was included in a different media level section 305 for audio than media level section 303 for video. is. Packet time attribute field 317 indicates the length of time of media in the packet in milliseconds. The length of time indicated by this field governs the buffer size of the device. In this embodiment, the length of time indicated by packet time attribute field 317 may apply only to audio essences.

Note that the format-specific parameters listed in Tables 1-5 are only examples. Media level sections common to multiple essence types may include other additional parameters, or may omit one or more of the parameters shown in the table.

The contents of the media level section 318 may be similar to the media level section 313 except for some parts such as the map ID attribute field. The media level section 318 is not included in the SDP object 311 if the redundant RTP stream scheme is not applied.

By using the format structure of the SDP object described in this section, it is possible to appropriately describe the attributes of a mixed-essence stream such as the ARIB STD-B73 stream in line with the structure of the stream. Furthermore, it is possible to set up an ARIB STD-B73 stream that supports compression of video essence and is also capable of error correction encoding/decoding by exchanging information on the attributes of the stream without shortage through the provision of SDP objects. becomes.

<5-3. Configuration example of broadcasting station system>
FIG. 19 is a block diagram showing an example of a schematic configuration of a broadcasting station system 3 according to the third embodiment. Referring to FIG. 19, broadcasting station system 3 includes one or more transmitting nodes 300a-300n, a control node 400, and one or more receiving nodes 450a-450n.

Each of transmission nodes 300a to 300n (hereinafter referred to as transmission node 300) is a broadcast signal processing node capable of transmitting broadcast signal streams in broadcasting station system 3. FIG. Each sending node 300 has at least one sender 60 . The sending node 300 provides the control node 400 with an SDP object describing the attributes of the streams that it can send. The SDP object provided by the sending node 300 can be described according to the new format for the mixed-essence stream described with reference to FIGS. 17 and 18. FIG.

The control node 400 is a node that controls transmission of a broadcast signal stream from a transmission node to a reception node in the IP network of the broadcast station. Broadcast signal streams transmitted in the broadcasting station system 3 include mixed essence streams that transmit different types of essence data with a single port number. Control node 400 sets up transmission of a stream between designated nodes in response to receiving a request from an external device such as APS 40 or control terminal 50 illustrated in FIG. to direct. Transmission setup of the mixed-essence stream can be performed according to the above-described SDP object description provided by the transmission node 300 of the transmission source.

Each of the receiving nodes 450 a to 450 n (hereinafter referred to as receiving node 450 ) is a broadcast signal processing node capable of receiving broadcast signal streams in the broadcasting station system 3 . Each receiving node 450 has at least one receiver 65 . The receiving node 450 , under the control of the control node 400 , configures reception processing for receiving the broadcast signal stream according to the description of the SDP object and receives the broadcast signal stream from the transmitting node 300 . If the broadcast signal stream to be received is a mixed-essence stream, the receiving node 450 receives different types of essence data on a single port number (ie, within a single stream). The configuration of the receiving node 450 may be the same as the configuration of the broadcast signal processing node 100 described in the first embodiment or the configuration of the broadcast signal processing node 200 described in the second embodiment.

<5-4. Configuration example of transmission node>
FIG. 20 is a block diagram showing an example of the configuration of the transmission node 300 according to this embodiment. Referring to FIG. 20, the transmission node 300 includes a device internal clock 110, a media clock 112, an RTP clock 114, a PTP processing unit 116, a communication unit 320, a transmission stream processing unit 130, a reception stream processing unit 140, a data processing unit 180, A control unit 390 and a storage unit 395 are provided.

(1) Communication Unit The communication unit 320 is an interface that mediates communication between the transmission node 300 and other nodes. The communication unit 320 may include connection terminals and connection circuitry for wired communication, or may include an antenna, RF circuitry, and baseband circuitry for wireless communication. In this embodiment, the communication unit 320 includes a transmitter 322 and a receiver 324 .

The transmission unit 322 has a role as the sender 60 and transmits the essence-mixed stream to the IP network of the broadcasting station system 3 . The broadcast signal stream may be, for example, an ARIB STD-B73 stream. Specifically, a series of RTP packets for a broadcast signal stream generated by transmission stream processing section 130 are input to transmission section 322 . Each RTP packet includes time information (RTP timestamp and/or frame count information) similar to the first and second embodiments. The transmitting unit 322 adds a network header to each input RTP packet and transmits each packet to another node.

Transmitter 322 and receiver 324 are also responsible for control communications associated with the transmission of streams. Specifically, for example, receiver 324 receives various control messages related to transmission of the stream from control node 400 (or other nodes such as receiver node 450). The transmitter 322 transmits a response message to the control message to the control node 400 (or another node such as the receiving node 450).

In this embodiment, the receiver 324 may or may not function as the receiver 65 .

(2) Controller The controller 390 includes, for example, one or more processors such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or microcontroller. Control unit 390 controls overall operations of transmission node 300 by executing computer programs stored in storage unit 395 .

For example, when the transmission node 300 is connected to the IP network of the broadcasting station system 3, the control unit 390 discovers the control node 400 by issuing an mDNS (multicast Domain Name System) query and receiving the response. Further, the control unit 390 receives a control message requesting provision of an SDP object from the control node 400 via the receiving unit 324, for example. In response to receiving the control message, the control unit 390 acquires from the storage unit 395 an SDP object describing attributes of the broadcast signal stream according to the above-described new format for the mixed-essence stream. The control unit 390 then transmits the acquired SDP object to the control node 400 via the transmission unit 322 .

After the transmission of the stream is set up based on the SDP object provided by the transmitting node 300, the control unit 390 receives a control message from the control node 400 via the receiving unit 324 instructing the start of transmission of the stream. . In response to receiving the control message, controller 390 initiates transmission of the broadcast signal stream from transmitter 322 .

For example, the sending node 300 may support NMOS, a set of control interface standards for managing and controlling the transmission of streams. In this case, the above-mentioned exchange of control messages may be performed via an HTTP (Hypertext Transfer Protocol)-based control API, which is predefined in NMOS IS-04 and NMOS IS-05, for example.

(3) Storage Unit Storage unit 395 includes temporary and non-transitory computer readable memory. Temporary memory may include, for example, RAM (Random Access Memory). The non-transitory memory may include, for example, one or more of ROM (Read Only Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive). The storage unit 395 stores computer programs for implementing the functionality of the sending node 300 . Furthermore, in this embodiment, the storage unit 395 stores SDP objects describing attributes of broadcast signal streams that can be transmitted by the transmission node 300 .

In one aspect, the SDP object includes, in an attribute field associated with a media description field common to multiple essence types, first attribute information associated with essence data of a first essence type and of a second essence type. It includes second attribute information associated with the essence data. As an example, the first essence type may be a video essence and the second essence type may be an audio essence. In this case, the SDP object contains video-related attributes as exemplified in Table 1 as first attribute information and audio-related attributes as exemplified in Table 2 as second attribute information in an attribute field common to a plurality of essence types. 2 attribute information. As another example, the first essence type may be a video essence and the second essence type may be an auxiliary data essence. In this case, the SDP object has video-related attributes as shown in Table 1 as first attribute information and auxiliary data-related attributes as shown in Table 3 in the attribute field common to multiple essence types. It can be included as second attribute information. However, without being limited to these examples, the SDP object provided by the sending node 300 may include any combination of the information exemplified in Tables 1-5.

In another aspect, the SDP object includes compression-related information indicating whether the video essence data is compressed, audio channel number information associated with the audio essence data, and error correction information indicating the error correction scheme applied to the essence data. , in the attribute field that describes the format-specific parameters of the broadcast signal stream. As described using Table 1, the compression-related information includes a compression parameter indicating whether the video essence data is to be compressed, and if the compression parameter indicates that the video essence data is to be compressed, the video essence data is compressed. and a codec parameter indicating the codec to be used in compressing the . Further, as described using Table 4, the error correction information includes a type parameter indicating the error correction method applied to the essence data, and a setting parameter indicating the setting value of the error correction method indicated by the type parameter. can include The setting parameter may be, for example, a size parameter indicating an error correction block size for XOR encoding, or a datagram number parameter indicating the number of datagrams corresponding to a processing unit for Reed-Solomon encoding.

(4) Flow of Transmission Control Processing--First Example FIG.

First, the control unit 390 discovers the control node 400 according to the connection of the transmission node 300 to the IP network (step S301).

Next, the control unit 390 acquires from the storage unit 395 an SDP object describing attributes of broadcast signal streams that can be transmitted by the transmission node 300, and provides the acquired SDP object to the control node 400 (step S303). The SDP object provided herein contains attribute information related to essence data of first and second essence types in attribute fields associated with media description fields common to multiple essence types.

After that, the transmitting node 300 waits for an instruction to start transmitting the stream (step S305). Then, when a control message instructing the start of stream transmission is received from the control node 400 (or another node), the transmission unit 322, under the control of the control unit 390, converts the attributes indicated by the SDP object to start transmitting the broadcast signal stream it has (step S307).

(5) Flow of Transmission Control Processing--Second Example FIG.

First, the control unit 390 discovers the control node 400 according to the connection of the transmission node 300 to the IP network (step S301).

Next, the control unit 390 acquires from the storage unit 395 an SDP object describing attributes of broadcast signal streams that can be transmitted by the transmission node 300, and provides the acquired SDP object to the control node 400 (step S304). The SDP objects provided herein contain one or more of compression-related information, audio channel number information, and error correction information in attribute fields that describe format-specific parameters of the broadcast signal stream.

After that, the transmitting node 300 waits for an instruction to start transmitting the stream (step S305). Then, when a control message instructing the start of stream transmission is received from the control node 400 (or another node), the transmission unit 322, under the control of the control unit 390, converts the attributes indicated by the SDP object to start transmitting the broadcast signal stream it has (step S307).

<5-5. Configuration example of control node>
FIG. 23 is a block diagram showing an example of the configuration of the control node 400 according to this embodiment. Referring to FIG. 23, the control node 400 includes a communication unit 410, a control unit 420 and a storage unit 430.

(1) Communication Unit The communication unit 410 is an interface that mediates communication between the control node 400 and other nodes. The communication unit 410 may include connection terminals and connection circuitry for wired communication, or may include an antenna, RF circuitry, and baseband circuitry for wireless communication. In this embodiment, the communication unit 410 includes a transmitter 412 and a receiver 414 .

The transmitter 412 and receiver 414 are involved in control communications related to the transmission of streams over the IP network within the broadcast station system 3 . Specifically, for example, the transmitting unit 412 may transmit control messages to the transmitting node 300 for setting up transmission of a stream, starting or ending transmission. Similarly, transmitter 412 may send control messages to receiver node 450 to set up transmission of the stream, start or end reception. The receiving unit 414 can receive response messages to control messages from the transmitting node 300 and the receiving node 450 .

(2) Controller The controller 420 includes one or more processors such as a CPU, MPU, or microcontroller. The control unit 420 controls overall operations of the control node 400 by executing computer programs stored in the storage unit 430 . In this embodiment, the controller 420 includes an information manager 422 and a stream controller 424 .

The information management unit 422 registers and manages information about broadcast signal processing nodes in the broadcasting station system 3 in the database. For example, when the information management unit 422 discovers the transmission node 300 connected to the IP network, the information management unit 422 transmits a control message requesting provision of the SDP object to the discovered transmission node 300 via the transmission unit 412 . The information management unit 422 then receives the SDP object from the transmission node 300 via the reception unit 414 . SDP objects received from transmitting node 300 describe attributes of broadcast signal streams that can be transmitted by transmitting node 300 . The information management unit 422 registers information described in the received SDP object in the database of the storage unit 430 . The information management unit 422 can similarly acquire an SDP object from the receiving node 450 and register information such as attributes of streams receivable by the receiving node 450 in the database of the storage unit 430 .

The stream control unit 424 controls transmission of streams from the transmission node 300 in the broadcasting station system 3 to the reception node 450 . For example, stream controller 424 instructs receiving node 450 to set up reception of a broadcast signal stream from designated transmitting node 300 when a request for transmission of the stream is received from APS 40 or control terminal 50. do. The stream control unit 424 can determine how the reception process should be set up, for example, by referring to the stream attributes registered in the database of the storage unit 430 . For example, one or more of the following may be determined depending on attributes of the stream:
・Should decompression be performed on the received video essence data? ・Codecs to be used when performing decompression ・How many audio channels are included in the audio essence data ・Which method should be used as an error correction method? (XOR or RS)
・FEC block size when executing error correction by XOR decoding ・Number of datagrams used as a processing unit when executing error correction by RS decoding

The receiving node 450 sets up reception of the broadcast signal stream by configuring the reception process and joining the corresponding multicast group according to the above instructions received from the stream controller 424 . The stream control unit 424 then instructs the transmission node 300 to start transmitting the broadcast signal stream. In response, transmitting node 300 begins transmitting the broadcast signal stream.

(3) Storage Unit Storage unit 430 includes temporary and non-transitory computer-readable memory. Temporary memory may include, for example, RAM. Non-transitory memory may include, for example, one or more of ROM, HDD or SSD. The storage unit 430 stores computer programs for implementing the functionality of the control node 400 . Furthermore, in this embodiment, the storage unit 430 stores information described in the SDP objects collected from each node in the broadcasting station system 3 by the information management unit 422 in the database.

(4) Flow of Transmission Control Processing--First Example FIG.

First, the information management unit 422 discovers the transmission node 300 connected to the IP network (step S401).

Next, the information management unit 422 acquires an SDP object describing attributes of broadcast signal streams that can be transmitted by the found transmission node 300 by receiving it from the transmission node 300 (step S403). The SDP object obtained here contains attribute information associated with the essence data of the first and second essence types in attribute fields associated with media description fields common to multiple essence types.

The stream control unit 424 waits for a request for setting up transmission of the stream (step S405). A request to set up the transmission of a stream may be received from an external device, eg APS 40 or control terminal 50 .

When the request is received, the stream control unit 424 instructs the specified receiving node 450 to configure the receiving process according to the attributes indicated by the SDP object and join the corresponding multicast group (step S407). ). The stream control unit 424 then instructs the designated transmission node 300 to start transmitting the broadcast signal stream (step S409).

(5) Flow of Transmission Control Processing—Second Example FIG. 25 is a flow chart showing a second example of the flow of transmission control processing that can be executed by the control node 400. FIG.

First, the information management unit 422 discovers the transmission node 300 connected to the IP network (step S401).

Next, the information management unit 422 obtains an SDP object describing attributes of broadcast signal streams that can be transmitted by the found transmission node 300 by receiving it from the transmission node 300 (step S404). The SDP object obtained here contains one or more of compression-related information, audio channel number information, and error correction information in attribute fields that describe format-specific parameters of the broadcast signal stream.

The stream control unit 424 waits for a request for setting up transmission of the stream (step S405). A request to set up the transmission of a stream may be received from an external device, eg APS 40 or control terminal 50 .

When the request is received, the stream control unit 424 instructs the specified receiving node 450 to configure the receiving process according to the attributes indicated by the SDP object and join the corresponding multicast group (step S407). ). The stream control unit 424 then instructs the designated transmission node 300 to start transmitting the broadcast signal stream (step S409).

<<6. Fourth Embodiment>>
Next, a fourth embodiment will be described with reference to FIGS. 26 and 27. FIG. The third embodiment described above is a specific embodiment, while the fourth embodiment is a more generalized embodiment.

<6-1. Configuration example of transmission node>
FIG. 26 is a block diagram showing an example configuration of a transmission node 500 according to the fourth embodiment. Referring to FIG. 26, transmission node 500 includes transmission section 510 and control section 520 .

The transmitter 510 transmits a broadcast signal stream carrying different types of essence data on a single port number to the broadcaster's IP network.

Controller 520 provides SDP objects describing attributes of the broadcast signal stream to other nodes.

In one aspect, the SDP object includes, in an attribute field associated with a media description field common to multiple essence types, first attribute information associated with essence data of a first essence type and of a second essence type. It includes second attribute information associated with the essence data.

In another aspect, the SDP object includes compression-related information indicating whether the video essence data is compressed, audio channel number information associated with the audio essence data, and error correction information indicating the error correction scheme applied to the essence data. , in an attribute field describing format-specific parameters of said broadcast signal stream.

A transmission control process performed to set up transmission of a stream may include the above operational steps of the transmitting node 500 . A computer program may also be provided that causes a processor to perform those operational steps. A non-transitory computer-readable storage medium storing a computer program that causes a processor to perform those operational steps may also be provided. Additionally, any function or process of the sending node 300 described in the third embodiment may be applied to this embodiment.

<6-2. Configuration example of control node>
FIG. 27 is a block diagram showing an example of the configuration of the control node 600 according to the fourth embodiment. Referring to FIG. 27 , the control node 600 has a control section 610 .

The control node 600 is a node that controls the transmission of broadcast signal streams carrying different types of essence data on a single port number from a transmitting node to a receiving node in the broadcaster's IP network. The control unit 610 obtains an SDP object describing attributes of the broadcast signal stream from the transmitting node. The control unit 610 then sets up transmission of the broadcast signal stream according to the obtained SDP object.

In one aspect, the SDP object includes, in an attribute field associated with a media description field common to multiple essence types, first attribute information associated with essence data of a first essence type and of a second essence type. It includes second attribute information associated with the essence data.

In another aspect, the SDP object includes compression-related information indicating whether the video essence data is compressed, audio channel number information associated with the audio essence data, and error correction information indicating the error correction scheme applied to the essence data. , in an attribute field describing format-specific parameters of said broadcast signal stream.

A transmission control process performed to set up transmission of a stream may include the above operational steps of the control node 600 . A computer program may also be provided that causes a processor to perform those operational steps. A non-transitory computer-readable storage medium storing a computer program that causes a processor to perform those operational steps may also be provided. Additionally, any function or process of the control node 400 described in the third embodiment may be applied to this embodiment.

<<7. Summary of Third Embodiment and Fourth Embodiment>>
So far, the third embodiment and the fourth embodiment of the present disclosure have been described in detail. In these embodiments, an SDP object describing the attributes of a so-called mixed-essence stream that carries different types of essence data on a single port number is placed in an attribute field associated with a media description field common to multiple essence types. , first attribute information associated with essence data of a first essence type and second attribute information associated with essence data of a second essence type. Therefore, attributes of a mixed-essence stream such as an ARIB STD-B73 stream can be appropriately described in the SDP object according to the structure of the stream. As a result, by exchanging SDP objects using the SDP-based management API, it becomes possible to set up the transmission of mixed-essence streams with a simple procedure.

For example, as described with FIG. 15, the existing SDP object format typically used for SMPTEST ST2110 streams describes audio-related attributes separately from the media-level section, which describes video-related attributes. It has a media level section in which attributes related to auxiliary data are described. In contrast, as in the third and fourth embodiments, describing the attributes associated with the essence data of two or more essence types in a media level section common to those essence types allows one The SDP interpretation of one media level section per media (stream) can be kept consistent.

Additionally or alternatively, the SDP object describing attributes of the mixed-essence stream includes compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and essence data. error correction information indicating the error correction scheme to be applied to the format-specific parameters. Therefore, the attributes of broadcast signal streams having unique specifications, such as ARIB STD-B73 streams, can be fully described in SDP objects. As a result, it becomes possible to set up the transmission of ARIB STD-B73 streams with a simple procedure by exchanging SDP objects by utilizing the SDP-based management API.

For example, as described with FIG. 16, the existing SDP object format typically used for SMPTEST ST2110 streams contains compression-related information, audio channel number information and error correction information in format-specific parameter attribute fields. does not have either In contrast, by including compression-related information, audio channel number information and/or error correction information in the format-specific parameter attribute field as in the third and fourth embodiments, ARIB STD-B73 At the receiving end of the stream, the receiving process can be configured appropriately according to the SDP object description.

Note that the technology according to the present disclosure is not limited to the above-described embodiments. Those skilled in the art will appreciate that these embodiments are illustrative only and that various modifications are possible without departing from the scope and spirit of the disclosure.

For example, the process steps shown in the flowcharts do not necessarily have to be performed in the order shown. For example, the processing steps may be performed in a different order than shown, and two or more processing steps may be performed in parallel. Also, some processing steps may be deleted and further processing steps may be added.

Also, the node functions described herein may be implemented in software, hardware, or a combination of software and hardware. Program instructions of a computer program that constitutes software are stored, for example, in a non-transitory computer-readable storage medium inside or outside the node, read into memory at run time, and executed by a processor.

Also, the technology described herein as implemented by a single device or a single node may be implemented as a system by multiple devices or multiple nodes cooperating with each other.

Some or all of the above embodiments may also be described in the following additional remarks, but are not limited to the following.

(Appendix 1)
a transmitter for transmitting a broadcast signal stream carrying different types of essence data on a single port number to an IP network of a broadcaster;
a control unit that provides an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream to other nodes;
with
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
sending node.

(Appendix 2)
The compression-related information is
including a compression parameter indicating whether the video essence data is compressed;
further comprising a codec parameter indicating a codec to be used in compressing the video essence data when the compression parameter indicates that the video essence data is to be compressed;
The sending node of claim 1.

(Appendix 3)
The error correction information is
a type parameter indicating the error correction scheme applied to the essence data;
a setting parameter indicating a setting value of the error correction scheme indicated by the type parameter;
A transmitting node according to clause 1 or clause 2, comprising:

(Appendix 4)
4. The transmitting node of clause 3, wherein if the type parameter indicates XOR encoding, the configuration parameters include a size parameter indicating an error correction block size.

(Appendix 5)
The transmitting node according to appendix 3 or appendix 4, wherein when the type parameter indicates Reed-Solomon encoding, the setting parameter includes a datagram number parameter indicating the number of datagrams corresponding to a processing unit of Reed-Solomon encoding. .

(Appendix 6)
6. The transmitting node according to any one of appendices 1 to 5, wherein the control unit provides the SDP object to the other node via a predefined management application protocol interface.

(Appendix 7)
7. The transmitting node according to any one of the clauses 1-6, wherein the broadcast signal stream is an ARIB STD-B73 stream.

(Appendix 8)
a transmission node according to any one of Appendices 1 to 7;
a receiving node that receives the broadcast signal stream set up according to the SDP object description;
Broadcasting station system including.

(Appendix 9)
A control node for controlling transmission from a transmitting node to a receiving node of a broadcast signal stream carrying different types of essence data on a single port number in a broadcast station IP network,
a control unit that acquires an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream from the transmission node;
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
control node.

(Appendix 10)
providing other nodes with an SDP (Session Description Protocol) object that describes attributes of a broadcast signal stream that carries different types of essence data on a single port number;
transmitting the broadcast signal stream to a broadcast station's IP network;
including
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
Transmission control method.

(Appendix 11)
to a processor at a transmitting node that transmits a broadcast signal stream carrying different types of essence data on a single port number to the IP network of the broadcaster;
providing an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream to other nodes;
and
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
computer program.

(Appendix 12)
to a processor at a transmitting node that transmits a broadcast signal stream carrying different types of essence data on a single port number to the IP network of the broadcaster;
providing an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream to other nodes;
and
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
A non-transitory computer-readable storage medium storing a computer program.

(Appendix 13)
A transmission control method for controlling transmission from a transmission node to a reception node of a broadcast signal stream that transmits different types of essence data with a single port number in an IP network of a broadcast station, comprising:
obtaining an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream from the transmitting node;
including
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
Transmission control method.

(Appendix 14)
to a processor in a control node that controls transmission from a transmitting node to a receiving node of a broadcast signal stream carrying different types of essence data on a single port number in a broadcaster's IP network;
obtaining an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream from the transmitting node;
and
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
computer program.

(Appendix 15)
to a processor in a control node that controls transmission from a transmitting node to a receiving node of a broadcast signal stream carrying different types of essence data on a single port number in a broadcaster's IP network;
obtaining an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream from the transmitting node;
and
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
A non-transitory computer-readable storage medium storing a computer program.

Techniques of the present disclosure can be used, without limitation, in systems that process broadcast signals.

1, 3 Broadcast station system 10 IP domain 20 (20a-d) Broadcast signal processing node 60 (60a-d) Sender 65 (65a-c) Receiver 70 Common reference clock 72a Device internal clock 73a, 76a Media clock 74a, 77a RTP Clocks 81, 82 Essence-separated stream 83 Essence-mixed stream 100, 200 Broadcast signal processing node 110 Device internal clock 112 Media clock 114 RTP clock 116 PTP processing unit 120, 210, 215 Communication unit (first communication unit)
122 transmitting unit 124 receiving unit 130 transmission stream processing unit 140 reception stream processing unit 142 transport processing unit 144 transport header removal unit 150 essence datagram processing unit 152 essence header removal unit 154 video essence processing unit 156 audio essence processing unit 158 auxiliary data essence processing unit 160, 220 alignment unit 161a-d, 166a-d RTP packet 162a-d, 167a-d RTP header 163a-d, 168a-b essence header 170 FEC datagram processing unit 180 data processing unit 190 control unit 230 Reproduction unit 240 Conversion unit 250 Second communication unit 300,500 Transmission node 311 SDP object 312 Session level section 313,318 Media level section 315 RTP map attribute field 316 Format specific parameter attribute field 317 Packet time attribute field 320 Communication unit 322,510 Transmission section 324 Reception section 390, 520 Control section 395 Storage section 400, 600 Control node 410 Communication section 412 Transmission section 414 Reception section 420, 610 Control section 422 Information management section 424 Stream control section 430 Storage section 450 Reception node

Claims (10)

a transmitter for transmitting a broadcast signal stream carrying different types of essence data on a single port number to an IP network of a broadcaster;
a control unit that provides an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream to other nodes;
with
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
sending node. The compression-related information is
including a compression parameter indicating whether the video essence data is compressed;
further comprising a codec parameter indicating a codec to be used in compressing the video essence data when the compression parameter indicates that the video essence data is to be compressed;
A transmitting node according to claim 1. The error correction information is
a type parameter indicating the error correction scheme applied to the essence data;
a setting parameter indicating a setting value of the error correction scheme indicated by the type parameter;
A transmitting node according to claim 1 or claim 2, comprising: 4. The transmitting node of claim 3, wherein if the type parameter indicates XOR encoding, the configuration parameters include a size parameter indicating an error correction block size. 5. The setting parameter according to claim 3, wherein when the type parameter indicates Reed-Solomon encoding, the setting parameter includes a datagram number parameter indicating the number of datagrams corresponding to a processing unit of Reed-Solomon encoding. sending node. The sending node according to any one of claims 1 to 5, wherein said control unit provides said SDP object to said other node via a predefined management application protocol interface. A transmitting node according to any preceding claim, wherein said broadcast signal stream is an ARIB STD-B73 stream. A transmitting node according to any one of claims 1 to 7;
a receiving node that receives the broadcast signal stream set up according to the SDP object description;
Broadcasting station system including. A control node for controlling transmission from a transmitting node to a receiving node of a broadcast signal stream carrying different types of essence data on a single port number in a broadcast station IP network,
a control unit that acquires an SDP (Session Description Protocol) object describing attributes of the broadcast signal stream from the transmission node;
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
control node. providing other nodes with an SDP (Session Description Protocol) object that describes attributes of a broadcast signal stream that carries different types of essence data on a single port number;
transmitting the broadcast signal stream to a broadcast station's IP network;
including
The SDP object is one of compression-related information indicating whether video essence data is compressed, audio channel number information associated with audio essence data, and error correction information indicating an error correction method applied to essence data. one or more within an attribute field describing format-specific parameters of said broadcast signal stream;
Transmission control method.

Images