US9270946B2 - Media distribution switching method, receiving device and transmitting device - Google Patents

Media distribution switching method, receiving device and transmitting device Download PDF

Info

Publication number
US9270946B2
US9270946B2 US12/816,048 US81604810A US9270946B2 US 9270946 B2 US9270946 B2 US 9270946B2 US 81604810 A US81604810 A US 81604810A US 9270946 B2 US9270946 B2 US 9270946B2
Authority
US
United States
Prior art keywords
request
packet
real
transmitting
transmitting device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US12/816,048
Other languages
English (en)
Other versions
US20100332591A1 (en
Inventor
Kaname Yoshida
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Assigned to FUJITSU LIMITED reassignment FUJITSU LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: YOSHIDA, KANAME
Publication of US20100332591A1 publication Critical patent/US20100332591A1/en
Application granted granted Critical
Publication of US9270946B2 publication Critical patent/US9270946B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17327—Transmission or handling of upstream communications with deferred transmission or handling of upstream communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6336—Control signals issued by server directed to the network components or client directed to client directed to decoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6547—Transmission by server directed to the client comprising parameters, e.g. for client setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video

Definitions

  • the embodiments discussed herein are related to a transmission technology in the case where real-time transmission and non-real-time transmission are mixed in the transmission of media information on a packet network.
  • a transmitting device and a receiving device communicate media information such as images, voices and the like with each other on a packet network such as an IP (Internet protocol) network or the like, sometimes real-time transmission and non-real-time transmission are mixed.
  • IP Internet protocol
  • image signals obtained by a monitor camera 1305 are encoded by a real-time image distribution device 1303 , are transmitted to a real-time image receiving device 1301 as a real-time motion image packet, and are decoded/reproduced.
  • a method using PCR program clock reference
  • PCR program clock reference
  • a difference between the received PCR data and a system time clock (STC) at the time of reception on the decoding side is calculated.
  • a voltage-controlled crystal oscillator (VCXO) is controlled by this differential value and a reproduction clock is generated.
  • the size of a packet receiving buffer on the real-time image receiving device 1301 side is reduced as much as possible by synchronizing the clocks of the real-time image distribution device 1303 (encoder) and the real-time image receiving device 1301 (decoder) and the delay of images can be avoided as much as possible.
  • an encoded image signal file accumulated in the storage device of a file distribution server 1304 is read and transmitted using a packet in response to a request from a server distribution image receiving device 1302 .
  • the server distribution image receiving device 1302 decodes/reproduces the image signal file transmitted using a packet on the basis of a system clock in its own device.
  • the server distribution image receiving device 1302 exercises flow control in order to absorb a difference between reproduction timing and transmission timing.
  • a transmit stop request packet is transmitted from the server distribution image receiving device 1302 to the file distribution server 1304 and the file distribution server 1304 stops the transmission of an image signal file.
  • a transmit start request packet is transmitted from the server distribution image receiving device 1302 to the file distribution server 1304 and the file distribution server 1304 starts (re-starts) the transmission of an image signal file.
  • the real-time image receiving device 1301 illustrated in FIG. 1 usually receives image signals transmitted from the real-time image distribution device 1303 in real time
  • the real-time image receiving device 1301 there has been a desire for the real-time image receiving device 1301 to also be able to receive image signals transmitted from the real-time image distribution device 1303 not in real time.
  • the real-time image receiving device 1301 In order to realize such mixed reception, it is necessary for the real-time image receiving device 1301 to have a flow control function for non-real-time transmission.
  • the real-time image receiving device 1301 receives an image signal file transmitted from the real-time image distribution device 1303 not in real time without flow control, as illustrated in FIG. 1 , there is a high possibility that the difference between reproduction timing and transmission timing may increase. As a result, an overflow or underflow of packets occurs in the packet receiving buffer of the real-time image receiving device 1301 and the image signal file cannot be normally received, which is a problem.
  • One aspect can be realized as a media distribution switching method for switching media distributed from a receiving device to a transmitting device on a packet network and has the following configuration.
  • a request packet for requesting the distribution of media information from a receiving device to a transmitting device is transmitted.
  • a request response packet to which is attached device type information indicating whether the transmitting device is for real-time or non-real-time transmission is returned from the transmitting device to the receiving device in response to the request packet.
  • an operation mode for real-time transmission and that for non-real-time transmission are switched on the basis of the device type information attached to the request response packet received from the transmitting device, and a receiving operation is performed.
  • FIG. 1 explains the prior art.
  • FIG. 2 is a configuration of the first preferred embodiment of a receiving device.
  • FIG. 3 is a configuration of the first preferred embodiment of a transmitting device.
  • FIG. 4 is an operational flowchart illustrating the control operation of the first preferred embodiment of a receiving device.
  • FIG. 5 is an operational flowchart illustrating the control operation of the first preferred embodiment of a transmitting device.
  • FIG. 6 is a data structure example of the request packet of the first preferred embodiment of receiving and transmitting devices.
  • FIG. 7 is a data structure example of the request response packet of the first preferred embodiment of receiving and transmitting devices.
  • FIGS. 8A and 8B are the operational sequence charts of the first preferred embodiment of receiving and transmitting devices.
  • FIG. 9 is a configuration of the second preferred embodiment of a transmitting device.
  • FIG. 10 is an operational flowchart illustrating the control operation of the second preferred embodiment of a receiving device.
  • FIG. 11 is an operational flowchart illustrating the control operation of the second preferred embodiment of a transmitting device.
  • FIG. 12 is a data structure example of the request packet of the second preferred embodiment of receiving and transmitting devices.
  • FIGS. 13A and 13B are the operational sequence charts of the second preferred embodiment of receiving and transmitting devices.
  • FIG. 2 is a configuration of the receiving device 100 in the first preferred embodiment, for discriminating image signals by real-time transmission from image files by non-real-time transmission and receiving them on an asynchronous and quality-not-insured packet network.
  • FIG. 3 is a configuration of a transmitting device 200 in the first preferred embodiment.
  • the receiving device 100 and the transmitting device 200 correspond to the real-time image receiving device 1301 , and the real-time image distribution device 1303 or the file distribution server 1304 , respectively, that are illustrated in FIG. 1 .
  • a request packet generation unit 101 generates a request packet for instructing the transmitting device 200 to start or stop distributing image signals or image files.
  • a request packet transmitting unit 102 transmits the request packet generated by the request packet generation unit 101 to the transmitting device 200 on a network, which is not illustrated.
  • a request response packet receiving unit 103 receives a request response packet in response to the request packet transmitted by its own device from the network.
  • a request response analysis unit 104 analyzes the contents of a request response, which are given in the request response packet received by the request response packet receiving unit 103 .
  • a mode determination unit 105 determines which is specified as a device type in the request response, a real-time encoder or a distribution server. If a real-time encoder is specified in the request response, the mode determination unit 105 notifies a flow control unit 106 and a switching unit 115 of a real-time mode. If a distribution server is specified in the request response, the mode determination unit 105 notifies a flow control unit 106 and a switching unit 115 of a server mode.
  • a data packet receiving unit 109 receives a data packet transmitted from the transmitting device 200 via the network.
  • a packet determination unit 110 determines whether the data packet stores PCR or image information other than PCR. When operating in a real-time mode, the packet determination unit 110 detects a data packet storing PCR or a data packet storing image signals transmitted from the transmitting device 200 , which is the real-time image distribution device. The packet determination unit 110 writes the data packet storing image signals in a packet receiving buffer 111 and transfers the data packet storing PCR data to a PCR control unit 112 .
  • the PCR control unit 112 extracts PCR data from the packet transferred from the packet determination unit 110 and calculates a differential value between each piece of PCR data and a system time clock (STC) in its own device. Then, the PCR control unit 112 generates a voltage control signal corresponding to the differential value and supplies it to a VCXO (voltage control Xtal oscillator).
  • STC system time clock
  • the mode determination unit 105 enables the switching unit 115 to select the output of the VCXO 113 .
  • a clock voltage-controlled on the basis of the PCR oscillated from the VCXO 113 is supplied to a motion image decoding unit 116 .
  • the motion image decoding unit 116 can decode/reproduce the image signal packet received by the packet receiving buffer 111 by a clock synchronized with the clock at the time of encoding.
  • the data packet receiving unit 109 , the packet determination unit 110 , the packet receiving buffer 111 , the motion image decoding unit 116 , a PCR generation unit 206 , the VCXO 113 , and the switching unit 115 constitute a first receiving unit for receiving media information in an operation mode for making a real-time transmission.
  • the flow control unit 106 is prevented from operating by the mode determination unit 105 notifying the flow control unit 106 of a real-time mode.
  • This data packet stores the image file transmitted from the transmitting device 200 , which is a file distribution server.
  • the mode determination unit 105 enables the switching unit 115 to select the output of a self-running OSC 114 .
  • the self-running OSC (oscillator) 114 oscillates a system time clock regardless of timing on the transmitting side.
  • the system time clock oscillated from the self-OSC 114 is supplied to the motion image decoding unit 116 .
  • the motion image decoding unit 116 decodes/reproduces the image file received by the packet receiving buffer 111 on the basis of the system time clock oscillated by the self-running OSC 114 at a timing independent of the transmitting device 200 .
  • the mode determination unit 105 notifies the flow control unit 106 of a server mode.
  • the flow control unit 106 absorbs the difference between reproduction timing and transmission timing, it exercises flow control.
  • the flow control unit 106 issues a first instruction to a transmit stop/start request packet transmitting unit 107 .
  • the transmit stop/start request packet transmitting unit 107 generates a transmit stop request packet for the transmitting device 200 in communication and transmits this packet to the network via a request packet transmitting unit 108 .
  • the transmitting device 200 starts (re-starts) the transmission of the data packet storing the image file and the amount of packets received by the receiving device 100 is adjusted.
  • the data packet receiving unit 109 , the packet determination unit 110 , the packet receiving buffer 111 , the motion image decoding unit 116 , the PCR generation unit 206 , the self-running OSC 114 , the switching unit 115 , the flow control unit 106 , the transmit stop/start request packet transmitting unit 107 , and the request packet transmitting unit 108 forma second receiving unit for receiving media information in an operation mode for a non-real-time transmission.
  • a request packet receiving unit 201 receives the request packet transmitted by the receiving device 100 ( FIG. 2 ) via the network.
  • a request packet analysis unit 202 analyzes the received request packet.
  • the request packet analysis unit 202 instructs a request response packet transmitting unit 203 to transmit a request response packet.
  • the request response packet transmitting unit 203 transmits a request response packet to the receiving device 100 ( FIG. 2 ) that has transmitted the above request packet.
  • the request response packet transmitting unit's 203 own device is a real-time image distribution device, it attaches device type information indicating that it is a real-time encoder.
  • the request response packet transmitting unit 203 attaches device type information indicating that it is a file distribution server.
  • the request packet analysis unit 202 also instructs the motion image transmitting unit 204 to start or stop the distribution of an image signal or an image file.
  • a self-running OSC 205 oscillates a system time clock.
  • the motion image transmitting unit's 204 own device is a real-time image distribution device, it encodes image signals in real time and generates image signal packets, on the basis of a clock generated by the self-running OSC 205 , and sequentially writes them in a packet transmitting buffer 207 until the distribution stops after it starts. If the motion image transmitting unit's 204 own device is a file distribution server, it reads image files from a storage device, which is not illustrated, generates image file packets, and sequentially writes them in the packet transmitting buffer 207 until the distribution stops after it starts.
  • the PCR generation unit's 206 own device is a real-time image distribution device, it performs the following operations until the distribution stops after it starts. Specifically, the PCR generation unit 206 generates a packet storing PCR data corresponding to the clock of an image signal distributed in real time by the motion image transmitting unit 204 , on the basis of a clock generated by the self-running OSC 205 . Then, the PCR generation unit 206 writes the packet in the packet transmitting buffer 207 .
  • the PCR generation unit's 206 own device is a file distribution server, the PCR generation unit 206 is not installed.
  • the packet transmitting buffer 207 sequentially transfers the written data packets to a data packet transmitting unit 208 .
  • the data packet transmitting unit 208 transmits the data packets to the network toward the receiving device 100 ( FIG. 2 ).
  • the request packet analysis unit 202 instructs the packet transmitting buffer 207 to stop the transmission of data packets. Also, if the request packet is a transmit request packet resulting from the analysis, the request packet analysis unit 202 instructs the packet transmitting buffer 207 to start (re-start) the transmission of data packets. Thus, flow control is exercised.
  • FIG. 4 is an operational flowchart illustrating the control operation of the receiving device 100 illustrated in FIG. 2 .
  • the control operation of this flowchart can be realized as an operation for a processor, which is not illustrated, in the receiving device 100 so as to execute a control program stored in memory, which is not illustrated.
  • FIG. 6 is a data structure example of the request packet of the first preferred embodiment of receiving and transmitting devices.
  • “TYPE” information sends a distribute request and distribute stop request when its value is “0x0001” and “0x0002”, respectively.
  • “PORT1” information and “PORT2” information specify the TCP/IP port numbers, respectively, of transmission/reception application.
  • ID information specifies the identifier of a connection.
  • ABILITY information specifies a value indicating transmission ability.
  • PULLRATE information specifies the quality information (sample rate) of an image signal or file to be transmitted.
  • SSRC information is a value required to identify session.
  • PROGRAM information specifies a broadcast program.
  • TYPE a value indicating a distribute request “0x0001” is specified as “TYPE” information.
  • step S 303 when a request response packet is received after waiting for the request response packet from the transmitting device 200 whose IP address is specified for 30 seconds (repetition of steps S 301 ⁇ S 302 ⁇ S 301 ), it is determined which is specified in the request response packet as device type information, a real-time encoder or a distribution server (step S 303 ). Real-time and server modes are switched between on the basis of this determination result (step S 304 ).
  • the above operations are performed by the request response packet receiving unit 103 , the request response analysis unit 104 , and the mode determination unit 105 illustrated in FIG. 2 , as described earlier.
  • step S 305 ⁇ S 306 data is received on the basis of PCR control.
  • the motion image decoding unit 116 receives an image signal received in real time via the data packet receiving unit 109 , the packet determination unit 110 , and the packet receiving buffer 111 .
  • the motion image decoding unit 116 performs decoding/reproduction operations according to a synchronous clock generated via the PCR generation unit 206 and the VCXO 113 .
  • step S 305 ⁇ S 307 data is received on the basis of flow control (step S 305 ⁇ S 307 ).
  • the motion image decoding unit 116 receives an image file received via the data packet receiving unit 109 , the packet determination unit 110 , and the packet receiving buffer 111 .
  • the motion image decoding unit 116 performs decoding/reproduction operations according to a system time clock generated by the self-running OSC 114 .
  • the flow control unit 106 illustrated in FIG. 2 sequentially checks the packet receiving buffer 111 (step SS 308 ), and if there is no abnormality in the state in which packets remain in the packet receiving buffer 111 , it continues to receive data without performing any processes (step S 308 ⁇ S 307 ).
  • the flow control unit 106 issues a first instruction to the transmit stop/start request packet transmitting unit 107 .
  • the transmit stop/start request packet transmitting unit 107 Upon receipt of this, the transmit stop/start request packet transmitting unit 107 generates a transmit stop request packet for the transmitting device 200 ( FIG. 3 ) whose IP address is specified and transmits this packet to the network via the request packet transmitting unit 108 illustrated in FIG. 2 (step S 308 ⁇ S 309 ).
  • the transmitting device 200 the transmission of data packets storing an image file is stopped and the amount of packets received by the receiving device 100 is adjusted.
  • the flow control unit 106 issues a second instruction to the transmit stop/start request packet transmitting unit 107 .
  • the transmit stop/start request packet transmitting unit 107 Upon receipt of this, the transmit stop/start request packet transmitting unit 107 generates a transmit start request packet for the transmitting device 200 whose IP address is specified and transmits this packet to the network via the request packet transmitting unit 108 (step S 308 ⁇ S 310 ).
  • the transmitting device 200 the transmission of data packets storing an image file is started (re-started) and the amount of packets received by the receiving device 100 is adjusted.
  • FIG. 5 is an operational flowchart illustrating the control operation of the transmitting device 200 illustrated in FIG. 3 .
  • the control operation of this flowchart can be realized as an operation for a processor, which is not illustrated, in the transmitting device 200 so as to execute a control program stored in memory, which is not illustrated.
  • the transmitting device 200 is in a state of waiting for a request packet (repetition of the determination in step S 401 ).
  • step S 402 When the request packet is received, the contents of the request packet are analyzed (step S 402 ). As described earlier, this operation is performed by the request packet receiving unit 201 and the request packet analysis unit 202 illustrated in FIG. 3 .
  • a request response packet is transmitted toward the receiving device 100 ( FIG. 2 ) having an IP address by which the request packet is transmitted (step S 403 ).
  • the receiving device's 100 own device is a real-time image distribution device
  • device type information indicating that it is a real-time encoder is attached to the request response packet.
  • the receiving device's 100 own device is a file distribution server
  • device type information indicating that it is a distribution server is attached to the request response packet.
  • FIG. 7 is a data structure example of the request response packet of the first preferred embodiment of receiving and transmitting devices.
  • Each piece of information “PORT1”, “PORT2”, “ID”, “ABILITY” and “PULLRATE” is the same as a piece of information attached to a request packet (see FIG. 6 ).
  • “TYPE” information specifies a response value “0x0101” to a distribute request or a response value “0x0102” to a stop request.
  • “ERRORCODE” information specifies a value “0x0000” indicating a normal state or a value “0x0001” indicating an abnormal/distribution impossible state.
  • “EQPTYPE” information specifies a value “0x0000” indicating a real-time encoder or a value “0x0001” indicating a distribution server as a device type.
  • the transmitting device 200 ( FIG. 3 ) can report the device type of its own device by this piece of “EQPTYPE” information in response to a request packet from the receiving device 100 ( FIG. 2 ). Then, the receiving device 100 can switch the operation of its own device between real-time and server modes, according to this piece of information.
  • respective pieces of information “Rsv. 3”, “Rsv. 4” and “Rsv. 5” are reserved for a future purpose.
  • the transmission start of data packets is instructed from the request packet analysis unit 202 to the motion image transmitting unit 204 (step S 404 ).
  • the transmission of data packets is continued while it is determined whether a request packet is received (repetition of determination in step S 405 ).
  • the transmitting operation of data packets is performed by the motion image transmitting unit 204 , the packet transmitting buffer 207 , and the data packet transmitting unit 208 illustrated in FIG. 3
  • the receiving operation of request packets is performed by the request packet receiving unit 201 illustrated in FIG. 3 .
  • step S 405 ⁇ S 406 ⁇ S 407 the contents of the request packet are analyzed and determined. This operation is performed by the request packet receiving unit 201 and the request packet analysis unit 202 illustrated in FIG. 3 .
  • the stoppage of a distribution operation is instructed from the request packet analysis unit 202 to the motion image transmitting unit 204 illustrated in FIG. 3 and the process returns to a distribute start request packet waiting process (steps S 406 ⁇ S 408 ⁇ S 401 ).
  • step S 407 is not performed and the process returns to the determination process in step S 405 .
  • step S 407 If it is determined that the request packet is not a distribute stop request packet, and also that the request packet's own device is a file distribution server, the flow control process in step S 407 is performed. Specifically, firstly it is determined whether the request packet is a transmit stop request packet or a transmit start request packet (step S 407 - 1 ). If a transmit stop request packet is received, the stoppage of the transmission of data packets is instructed from the request packet analysis unit 202 to the packet transmitting buffer 207 , both of which are illustrated in FIG. (steps S 407 - 1 ⁇ S 407 - 2 ). Then, the process returns to the determination process in step S 405 .
  • step S 407 - 1 ⁇ S 407 - 3 the start (re-start) of transmission of data packets is instructed from the request packet analysis unit 202 to the packet transmitting buffer 207 (steps S 407 - 1 ⁇ S 407 - 3 ). Then, the process returns to the determination process in step S 405 . Thus, flow control is exercised.
  • the transmitting device 200 returns a request response to which information about the real-time encoder is attached (step S 403 in FIG. 5 ) to an image distribute request from the receiving device 100 (step S 301 in FIG. 4 ).
  • the receiving device 100 modifies the state of its own device to a real-time mode (step S 304 in FIG. 4 ).
  • real-time image signals are transmitted from the transmitting device 200 to the receiving device 100 (step S 404 in FIG. 5 , step S 306 in FIG. 4 ).
  • the transmitting device 200 returns a request response to which information about the distribution server is attached (step S 403 in FIG. 5 ) to an image distribute request from the receiving device 100 (step S 301 in FIG. 4 ).
  • the receiving device 100 modifies the state of its own device to a server mode (step S 304 in FIG. 4 ).
  • image files are transmitted from the transmitting device 200 to the receiving device 100 (step S 404 in FIG. 5 , step S 307 in FIG. 4 ).
  • the transmitting device 200 can report the device type of its own device by “EQPTYPE” information in response to a distribute start request packet from the receiving device 100 , and the receiving device can switch the operation of its own device between real-time and server modes, according to this piece of information.
  • the configuration of the second preferred embodiment of a receiving device is the same as that of the receiving device 100 in the first preferred embodiment, illustrated in FIG. 2 .
  • the request packet generation unit 101 transmits a request packet in which the distribute request mode information of a real-time mode is set toward the transmitting device.
  • a request response packet in which the mode of a real-time encoder is set to indicate normality is returned from the transmitting device in response to this request packet
  • the receiving device operates in a real-time mode.
  • the request packet generation unit 101 re-transmits a request packet in which the distribute request mode information of a server mode is set, toward the transmitting device.
  • the receiving device 100 operates in a server mode.
  • FIG. 9 is a configuration of a transmitting device 800 in the second preferred embodiment.
  • components to which the same reference numerals as in the configuration of the transmitting device 200 in the first preferred embodiment, illustrated in FIG. 3 , are attached perform the same processes as in FIG. 3 .
  • the configuration illustrated in FIG. 9 differs from that illustrated in FIG. 3 in that a request mode determination unit 801 determines which is set in a distribute start request packet received by the request packet analysis unit 202 , a real-time mode or a server mode.
  • the request mode determination unit 801 instructs the request response packet transmitting unit 203 to return a request response packet indicating normality. Conversely, if a server mode is set in the distribute start request packet, the request mode determination unit 801 instructs the request response packet transmitting unit 203 to return a request response packet indicating abnormality. Simultaneously, device type information indicating a real-time encoder is also attached to the request response packet.
  • the request mode determination unit 801 instructs the request response packet transmitting unit 203 to return a request response packet indicating abnormality. Conversely, if a server mode is set in the distribute start request packet, the request mode determination unit 801 instructs the request response packet transmitting unit 203 to return a request response packet indicating normality. Simultaneously, device type information indicating a distribution server is also attached to the request response packet.
  • FIG. 10 is an operational flowchart illustrating the control operation of the receiving device 100 in the second preferred embodiment, illustrated in FIG. 2 .
  • the control operation in this operational flowchart is realized as an operation for a processor, which is not illustrated, in the receiving device 100 so as to execute a control program stored in memory, which is not illustrated.
  • a request packet for requesting the start of distribution is transmitted to an IP (Internet protocol) address specified by a user (step S 901 ).
  • IP Internet protocol
  • distribute request mode information indicating a real-time mode is attached to the request packet.
  • FIG. 12 is a data structure example of the request packet of the second preferred embodiment of receiving and transmitting devices. Respective pieces of information “TYPE”, “PORT1”, “PORT2”, “ID”, “ABILITY” and “PULLRATE” are the same as those in the data structure of a request packet in the first preferred embodiment illustrated in FIG. 6 (see FIG. 6 ).
  • “RECEIVETYPE” information specifies the above-described distribute request mode information.
  • “EQPTYPE” information indicates that it corresponds to both real-time distribution and server distribution by its value “0”.
  • step S 901 a value “0x0001” indicating a distribute request is specified as “TYPE” information and a value “0” indicating a real-time mode is specified as “RECEIVETYPE” information. This operation is performed by the request packet generation unit 101 and the request packet transmitting unit 102 illustrated in FIG. 2 .
  • step S 903 when a request response packet is received from the transmitting device 200 whose IP address is specified after waiting for it for 30 seconds (repetition of steps S 901 ⁇ S 902 ⁇ S 901 ), it is determined on the basis of the received request response packet whether the device type information of a real-time encoder is specified as a request response specified in the request response packet (step S 903 ).
  • the mode determination unit 105 illustrated in FIG. 2 sets a real-time mode in the switching unit 115 and the flow control unit 106 (step S 904 ).
  • a real-time mode is set, data is received on the basis of PCR control (step S 306 ). This operation is the same as the operation in step S 306 of the first preferred embodiment, illustrated in FIG. 4 .
  • step S 903 the mode determination unit 105 notifies the request packet generation unit 101 of this fact.
  • the request packet generation unit 101 transmits a request packet requesting re-starting of the distribution to the specified IP address (step S 905 ).
  • a value “1” indicating a server mode is specified in the request packet as distribute request mode information, that is, “RECEIVETYPE” information.
  • the mode determination unit 105 illustrated in FIG. 2 sets a server mode in the switching unit 115 and the flow control unit 106 (step S 907 ).
  • a server mode is set thus, data is received on the basis of flow control (steps S 307 through S 310 ). This operation is the same as the operation in steps S 307 through S 310 in the first preferred embodiment, illustrated in FIG. 4 .
  • FIGS. 13A and 13B are the operational sequence charts of the transmitting device 800 illustrated in FIG. 9 .
  • the control operations of these operational flowcharts are realized as operations for a processor, which is not illustrated, in the transmitting device 800 so as to execute a control program stored in memory, which is not illustrated.
  • steps S 401 and S 402 are the same as those in steps S 401 and S 402 in the first preferred embodiment, illustrated in FIG. 5 .
  • the transmitting device 800 is in a request packet waiting state (repetition of the determination in step S 401 ).
  • step S 4029 When a request packet is received, the contents of the request packet are analyzed (step S 4029 ). This operation is performed by the request packet receiving unit 201 and the request packet analysis unit 202 illustrated in FIG. 9 .
  • step S 1001 it is determined whether distribute request mode information set in the request packet coincides with the mode of its own device. This operation is performed by the request mode determination unit 801 illustrated in FIG. 9 .
  • step S 901 When a distribute start request packet is received the first time, a value “0” indicating a real time mode is specified in the request packet as “RECEIVETYPE” information in step S 901 illustrated in FIG. 10 . Therefore, if its own device is a real-time image distribution device, it is determined in step S 1001 that they are matched and if its own device is a file distribution server, it is determined in step S 1001 that they are not matched.
  • step S 1001 If its own device is a file distribution server, after the determination of non-coincidence in step S 1001 , the second distribute start request packet is received in step S 905 illustrated in FIG. 10 . In this case, a value “1” indicating a server mode is specified in the request packet as “RECEIVE TYPE” information in step S 901 illustrated in FIG. 10 . Therefore, it is determined in step S 1001 that they are matched.
  • step S 1001 If its own device is a file distribution server and it is determined in step S 1001 that they are not matched when the first distribute start request packet is received, the following operation is performed. Specifically, the request mode determination unit 801 instructs the request response packet transmitting unit 203 to return a request response packet to which the device type information indicating abnormality and a distribution server (step S 1002 ) is attached.
  • the data structure of the request response packet is the same as the data structure in the first preferred embodiment, illustrated in FIG. 7 .
  • step S 1002 a value “0x0101” indicating a distribute request response, a value “0x0001” indicating abnormality and distribution impossible, and a value “0x0001” indicating a distribution server are specified as “TYPE”, “ERRORCODE” and “EQPTYPE” information, respectively. Then, the process returns to a distribute start request packet waiting process (step S 1002 ⁇ S 401 ).
  • step S 1001 If its own device is a file distribution server and the second distribute start request packet is received or if its own device is a real-time image distribution device 1403 and the first distribute start request packet is received, it is determined in step S 1001 that they are matched. In this case, the request mode determination unit 801 instructs the request response packet transmitting unit 203 to return a request response packet to which device type information indicating normality and its own mode is attached (a distribution server or real-time encoder) (step S 1003 ). Specifically, in the data structure example illustrated in FIG.
  • a value “0x0101” indicating a distribute request response, a value “0x0000” indicating normality, and a value “0x0001” indicating a distribution server (when its own device is a file distribution server) or “0x0000” indicating a real-time encoder (when its own device is a real-time image distribution device) are specified as “TYPE”, “ERRORCODE” and “EQPTYPE” information, respectively.
  • step S 404 the start of transmission of data packets is instructed from the request packet analysis unit 202 to the motion image transmitting unit 204 , both of which are illustrated in FIG. 3 , and the transmission is started (step S 404 ). Operations after this are the same as a series of control operations from steps S 405 until S 408 in the first preferred embodiment.
  • step S 1001 illustrated in FIG. 11 If its own device is a real-time image distribution device, as illustrated in FIG. 13A , in the transmitting device 800 , it is determined that their modes are matched (step S 1001 illustrated in FIG. 11 ) in response to an image distribute request in which a real-time mode is specified, from the receiving device 100 (step S 901 illustrated in FIG. 10 ). As a result, the transmitting device 800 returns a request response indicating normality, to which information indicating a real-time encoder is attached (step S 1003 illustrated in FIG. 11 ). Then, image signals are transmitted in real time from the transmitting device 800 to the receiving device 100 (step S 404 illustrated in FIG. 11 , step S 306 illustrated in FIG. 4 ).
  • step S 1001 illustrated in FIG. 11 If its own device is a file distribution server, as illustrated in FIG. 13B , in the transmitting device 800 , it is determined that their modes are not matched (step S 1001 illustrated in FIG. 11 ) in response to an image distribute request in which a real-time mode is specified, from the receiving device 100 (step S 901 illustrated in FIG. 10 ). As a result, the transmitting device 800 returns a request response indicating abnormality, to which information indicating a distribution server is attached (step S 1002 illustrated in FIG. 11 ). In response to this request response, the receiving device 100 detects mode non-coincidence (step S 903 illustrated in FIG. 10 ) and transmits an image distribute request in which a server mode is specified (step S 903 illustrated in FIG. 10 ).
  • step S 1001 illustrated in FIG. 11 mode non-coincidence is determined (step S 1001 illustrated in FIG. 11 ). Then, the transmitting device 800 returns a request response indicating normality including information indicating a distribution server (step S 1003 illustrated in FIG. 11 ). In response to this, the receiving device 100 sets its own device in a server mode (step S 907 illustrated in FIG. 10 ). Then, image files are transmitted from the transmitting device 800 to the receiving device 100 (step S 404 illustrated in FIG. 11 , step S 307 illustrated in FIG. 10 ).
  • a distribute request mode expected by the receiving device 100 can be explicitly reported from the receiving device 100 to the transmitting device 800 by “RECEIVETYPE” information.
  • receiving and transmitting devices there is no need to prepare receiving devices dedicated for respective devices in an environment where a real-time image distribution device for monitoring and a file distribution server are mixed, thereby reducing costs.
  • images can be received seamlessly without being aware of a distribution source.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Graphics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
US12/816,048 2009-06-30 2010-06-15 Media distribution switching method, receiving device and transmitting device Expired - Fee Related US9270946B2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009155503A JP4740356B2 (ja) 2009-06-30 2009-06-30 メディア配信切替え方法、受信装置、送信装置
JP2009-155503 2009-06-30

Publications (2)

Publication Number Publication Date
US20100332591A1 US20100332591A1 (en) 2010-12-30
US9270946B2 true US9270946B2 (en) 2016-02-23

Family

ID=42988424

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/816,048 Expired - Fee Related US9270946B2 (en) 2009-06-30 2010-06-15 Media distribution switching method, receiving device and transmitting device

Country Status (5)

Country Link
US (1) US9270946B2 (ja)
EP (1) EP2271094A3 (ja)
JP (1) JP4740356B2 (ja)
KR (1) KR101145078B1 (ja)
CN (1) CN101938464B (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012080257A (ja) * 2010-09-30 2012-04-19 Canon Inc 提供装置、配信装置、その処理方法及びプログラム
US9857228B2 (en) * 2014-03-25 2018-01-02 Rosemount Inc. Process conduit anomaly detection using thermal imaging
US10887651B2 (en) 2014-03-31 2021-01-05 Samsung Electronics Co., Ltd. Signaling and operation of an MMTP de-capsulation buffer

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0818622A (ja) 1994-06-30 1996-01-19 Toshiba Corp 情報通信端末装置
WO1999067887A2 (en) 1998-06-23 1999-12-29 Koninklijke Philips Electronics N.V. Telecommunication system with channel sharing
WO2004064424A1 (en) 2003-01-11 2004-07-29 Lg Electronics Inc. Packet service system and method for controlling packet transmission
US20040208158A1 (en) * 1998-08-19 2004-10-21 Fellman Ronald D. Methods and apparatus for providing quality-of-service guarantees in computer networks
US20050216609A1 (en) * 2004-03-10 2005-09-29 Cisco Technology, Inc. (A California Corporation) PVDM (packet voice data module) generic bus
EP1811745A1 (en) 2006-01-23 2007-07-25 Samsung Electronics Co., Ltd. Method and apparatus for handling IMS terminal's call request including request for real-time service received over IMS domain by CSI terminal
US20070251835A1 (en) * 2006-04-28 2007-11-01 Medtronic Minimed, Inc. Subnetwork synchronization and variable transmit synchronization techniques for a wireless medical device network
US20090106807A1 (en) * 2007-10-19 2009-04-23 Hitachi, Ltd. Video Distribution System for Switching Video Streams

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004038677A (ja) * 2002-07-04 2004-02-05 Mitsubishi Electric Corp 通信装置
JP2004193920A (ja) * 2002-12-11 2004-07-08 Toshiba Corp 番組配信システム及び受信装置
US8418206B2 (en) * 2007-03-22 2013-04-09 United Video Properties, Inc. User defined rules for assigning destinations of content

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0818622A (ja) 1994-06-30 1996-01-19 Toshiba Corp 情報通信端末装置
WO1999067887A2 (en) 1998-06-23 1999-12-29 Koninklijke Philips Electronics N.V. Telecommunication system with channel sharing
KR100642212B1 (ko) 1998-06-23 2006-11-06 코닌클리케 필립스 일렉트로닉스 엔.브이. 실시간 데이터 및 비 실시간 패킷 데이터를 송신하기에 적합한 원격통신 시스템, 상기 시스템에서 사용하기 위한 원격통신 지국, 및 상기 시스템을 작동하는 방법
US20040208158A1 (en) * 1998-08-19 2004-10-21 Fellman Ronald D. Methods and apparatus for providing quality-of-service guarantees in computer networks
WO2004064424A1 (en) 2003-01-11 2004-07-29 Lg Electronics Inc. Packet service system and method for controlling packet transmission
CN1739310A (zh) 2003-01-11 2006-02-22 Lg电子株式会社 用于控制分组传输的分组业务系统和方法
US20050216609A1 (en) * 2004-03-10 2005-09-29 Cisco Technology, Inc. (A California Corporation) PVDM (packet voice data module) generic bus
EP1811745A1 (en) 2006-01-23 2007-07-25 Samsung Electronics Co., Ltd. Method and apparatus for handling IMS terminal's call request including request for real-time service received over IMS domain by CSI terminal
US20070251835A1 (en) * 2006-04-28 2007-11-01 Medtronic Minimed, Inc. Subnetwork synchronization and variable transmit synchronization techniques for a wireless medical device network
US20090106807A1 (en) * 2007-10-19 2009-04-23 Hitachi, Ltd. Video Distribution System for Switching Video Streams

Non-Patent Citations (11)

* Cited by examiner, † Cited by third party
Title
Chinese Office Action issued Jun. 24, 2014 in corresponding Chinese Patent Application No. 201010220714.5.
Chinese Office Action mailed Feb. 4, 2013 for corresponding Chinese Application No. 201010220714.5.
European Office Action dated Dec. 1, 2015 in corresponding European Patent Application No. 10 165 501.7.
Extended European Search Report issued in corresponding European Application 10165501.7 mailed on Dec. 6, 2012.
Hoffman, Don, et al. "RTP payload format for MPEG1/MPEG2 video." Request for Comments (Proposed Standard) RFC 2250 (1998). *
J. Rosenberg et al., "SIP: Session Initiation Protocol", IETF Request for Comments (RFC) 3261, Jun. 2002, pp. 1-269.
Korean Office Action issued Jul. 12, 2011 in corresponding Korean Patent Application 10-2010-0059120.
M. Handley et al., "SDP: Session Description Protocol", IETF Request for Comments (RFC) 4566, Jul. 2006, pp. 1-49.
Office Action mailed Dec. 23, 2013 in corresponding Chinese Application No. 201010220714.5.
Office Action mailed Oct. 30, 2013 in corresponding European Application No. 1016501.7.
W. Jia et al., "SIP Based Adaptive Multimedia Transmission for Wired and Wireless Networks", Advanced Parallel Processing Technologies Lecture Notes in Computer Science, Springer, Berlin, 2005, pp. 505-514.

Also Published As

Publication number Publication date
JP4740356B2 (ja) 2011-08-03
KR101145078B1 (ko) 2012-05-14
EP2271094A3 (en) 2013-01-09
KR20110001906A (ko) 2011-01-06
JP2011015020A (ja) 2011-01-20
US20100332591A1 (en) 2010-12-30
CN101938464A (zh) 2011-01-05
CN101938464B (zh) 2015-10-21
EP2271094A2 (en) 2011-01-05

Similar Documents

Publication Publication Date Title
JP6685989B2 (ja) シグナリング又はブロック生成を用いた拡張ブロック−要求ストリーミングシステム
US9973345B2 (en) Calculating and signaling segment availability times for segments of media data
EP2952006B1 (en) Determining available media data for network streaming
TWI668982B (zh) 用於多媒體和檔案傳輸的傳輸介面的方法及伺服器設備、及用於記錄相關指令於其上的電腦可讀取儲存媒體
US9585062B2 (en) System and method for implementation of dynamic encoding rates for mobile devices
JP4702397B2 (ja) コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム
KR101797507B1 (ko) 미디어 컨텐트 송수신 방법 및 그를 이용한 송수신 장치
US20090064242A1 (en) Fast channel switching for digital tv
WO2016141165A1 (en) File format based streaming with dash formats based on lct
CN103039051A (zh) 服务器辅助的视频会话
KR20170074866A (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
WO2002051155A1 (en) Webcasting method and system for time-based synchronization ofmultiple, independent media streams
US20150271298A1 (en) Reduced latency media distribution system
WO2008065317A1 (en) Transport stream migration method and system
US9270946B2 (en) Media distribution switching method, receiving device and transmitting device
EP2882191B1 (en) Synchronization of streaming data
JP5428734B2 (ja) ネットワーク機器、情報処理装置、ストリーム切替方法、情報処理方法、プログラムおよびコンテンツ配信システム
JP2002152301A (ja) データ通信システム、データ受信装置、データ通信方法、並びにプログラム記憶媒体
US8811478B2 (en) Data transmission method and apparatus
JP5082715B2 (ja) 受信装置、受信方法およびコンピュータプログラム
JP2004274619A (ja) 動画配信サーバ、動画受信端末装置、画像パケット送信方法及び画像パケット受信方法
JP2016076884A (ja) マルチメディア同期再生装置及びマルチメディア同期再生方法
US10880586B2 (en) Method and device for transmitting and receiving MMTP packet

Legal Events

Date Code Title Description
AS Assignment

Owner name: FUJITSU LIMITED, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:YOSHIDA, KANAME;REEL/FRAME:024540/0112

Effective date: 20100427

ZAAA Notice of allowance and fees due

Free format text: ORIGINAL CODE: NOA

ZAAB Notice of allowance mailed

Free format text: ORIGINAL CODE: MN/=.

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20240223