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 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

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309Transmission or handling of upstream communications
    • H04N7/17327Transmission or handling of upstream communications with deferred transmission or handling of upstream communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242Synchronization processes, e.g. processing of PCR [Program Clock References]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/633Control signals issued by server directed to the network components or client
    • H04N21/6332Control signals issued by server directed to the network components or client directed to client
    • H04N21/6336Control signals issued by server directed to the network components or client directed to client directed to decoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/65Transmission of management data between client and server
    • H04N21/654Transmission by server directed to the client
    • H04N21/6547Transmission by server directed to the client comprising parameters, e.g. for client setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/8146Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/816Monomedia 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)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

A request packet generation unit generates a request packet for requesting the distribution of media information. A request packet transmitting unit transmits the request packet. A request response packet receiving unit receives a request response packet corresponding to the request packet from a transmitting device. A request response analysis unit analyzes a request response set in the request response packet. A mode determination unit switches between an operation mode for real-time transmission and that for non-real-time transmission according to device type information, attached to the request response, indicating whether the transmitting device is for real-time transmission or non-real-time transmission. A first receiving unit receives media information in an operation mode for real-time transmission. A second receiving unit receives media information in an operation mode for non-real-time transmission.

Description

CROSS-REFERENCE TO THE RELATED APPLICATION
This application is based upon and claims the benefit of priority of prior Japanese Patent Application No. 2009-155503, filed on Jun. 30, 2009, the entire contents of which are hereby incorporated by reference.
FIELD
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.
BACKGROUND
When 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.
In real-time transmission, for example, as illustrated in FIG. 1, 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. In order to synchronize the clock of image signals to be decoded/reproduced by the real-time image receiving device 1301 with a clock at the time of encoding in the real-time image distribution device 1303, for example, a method using PCR (program clock reference) is adopted. In this method, a clock synchronization packet called PCR is multiplexed on a motion image packet to be transmitted. On the decoding side, a difference between the received PCR data and a system time clock (STC) at the time of reception on the decoding side is calculated. Then, a voltage-controlled crystal oscillator (VCXO) is controlled by this differential value and a reproduction clock is generated. Specifically, in the real-time transmission, 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.
However, in non-real-time transmission, as illustrated in FIG. 1, 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. In non-real-time transmission, it is technically difficult to transmit an image signal file at the same timing as that at the time of encoding. Therefore, the server distribution image receiving device 1302 exercises flow control in order to absorb a difference between reproduction timing and transmission timing. In the flow control, when a packet remaining in the packet receiving buffer seems to exceed the buffer size, 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. Conversely, when no packet seems to be remaining in the packet receiving buffer, 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.
In this case, although 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, 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.
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.
However, when the real-time image receiving device 1301 attempts to receive an image signal file transmitted from the real-time image distribution device 1303 not in real time, there is no prior art capable of discriminating real-time transmission from non-real-time transmission. Therefore, conventionally a flow control function cannot be mounted on the real-time image receiving device 1301.
Therefore, when 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.
SUMMARY
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.
Firstly, a request packet for requesting the distribution of media information from a receiving device to a transmitting device is transmitted.
Then, 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.
Then, in the receiving device, 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.
The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
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.
DESCRIPTION OF EMBODIMENTS
Preferred embodiments of the present invention will be explained in detail with reference to accompanying drawings.
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.
In the receiving device 100 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).
In the real-time mode, the mode determination unit 105 enables the switching unit 115 to select the output of the VCXO 113. Thus, in the real-time mode, a clock voltage-controlled on the basis of the PCR oscillated from the VCXO 113 is supplied to a motion image decoding unit 116.
Thus, in the real-time mode, 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. In other words, in the real-time mode, 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.
In the real-time mode, since synchronous reproduction is possible as described above, it is not necessary to exercise flow control according to the state of the packet receiving buffer 111. Therefore, in the real-time mode, 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.
However, when operating in a sever mode, since a packet storing PCR data is neglected and discarded, only a data packet is written in the packet receiving buffer 111. This data packet stores the image file transmitted from the transmitting device 200, which is a file distribution server.
In a sever mode, 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. Thus, in a sever mode, the system time clock oscillated from the self-OSC 114 is supplied to the motion image decoding unit 116.
As a result, in a sever mode, 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.
In this case, in a sever mode, the mode determination unit 105 notifies the flow control unit 106 of a server mode. As a result, since the flow control unit 106 absorbs the difference between reproduction timing and transmission timing, it exercises flow control.
Specifically, when packets remaining in the packet receiving buffer 111 seem to exceed the buffer size in a sever mode, the flow control unit 106 issues a first instruction to a transmit stop/start request packet transmitting unit 107. As a result, 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. As a result, 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.
In this case, in a server mode, since the difference between reproduction timing and transmission timing tends to increase, it can also be controlled in such a way that the capacity of the packet receiving buffer 111 may be increased.
Thus, in a server mode, 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.
Then, in the transmitting device 200 illustrated in FIG. 3, 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.
When the request packet requests the start or stoppage of the distribution of an image signal or an image file as an analysis result, 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. At this moment, if 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. Conversely, if its own device is a file distribution server, the request response packet transmitting unit 203 attaches device type information indicating that it is a file distribution server.
When the request packet requests the start or stoppage of the distribution of an image signal or an image file as an analysis result, 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.
If 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.
Furthermore, if 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.
If 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).
In this case, if the request packet is a transmit stop request packet resulting from the analysis when the request packet analysis unit's 202 own device is a file distribution server, 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.
The operation of the first preferred embodiment, having the above configuration of the receiving and transmitting devices, will be explained in detail below.
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.
Firstly, a request packet for requesting the start of distribution is transmitted to an IP (Internet protocol) address specified by a user. As described earlier, this operation is executed by the request packet generation unit 101 and the request packet transmitting unit 102 illustrated in FIG. 2. 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. In step S301, a value indicating a distribute request “0x0001” is specified as “TYPE” information.
Then, 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 S301→S302→S301), it is determined which is specified in the request response packet as device type information, a real-time encoder or a distribution server (step S303). Real-time and server modes are switched between on the basis of this determination result (step S304). 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.
Then, when a real-time mode is set, data is received on the basis of PCR control (step S305→S306). In this operation, as described earlier, 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. In this case, 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.
However, when a server mode is set, data is received on the basis of flow control (step S305→S307). In this operation, as described earlier, 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. In this case, the motion image decoding unit 116 performs decoding/reproduction operations according to a system time clock generated by the self-running OSC 114.
In this case, the flow control unit 106 illustrated in FIG. 2 sequentially checks the packet receiving buffer 111 (step SS308), 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 S308→S307).
However, as described earlier, when packets remaining in the packet receiving buffer 111 seem to exceed its buffer size (buffer over), the flow control unit 106 issues a first instruction to 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 S308→S309). As a result, in 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.
Conversely, as described earlier, when no packets seem to remain in the packet receiving buffer 111 (buffer empty), the flow control unit 106 issues a second instruction to 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 S308→S310). As a result, in 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.
Firstly, the transmitting device 200 is in a state of waiting for a request packet (repetition of the determination in step S401).
When the request packet is received, the contents of the request packet are analyzed (step S402). 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.
When the request packet requests the start of the distribution of an image signal or file as a result of the above analysis, 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 S403). In this case, if 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. Conversely, if 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. In FIG. 7, respective pieces of information “Rsv. 3”, “Rsv. 4” and “Rsv. 5” are reserved for a future purpose.
Then, the transmission start of data packets is instructed from the request packet analysis unit 202 to the motion image transmitting unit 204 (step S404). After this step, the transmission of data packets is continued while it is determined whether a request packet is received (repetition of determination in step S405). As described earlier, 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, and the receiving operation of request packets is performed by the request packet receiving unit 201 illustrated in FIG. 3.
When a request packet is received in the above-described transmitting operation, the contents of the request packet are analyzed and determined (steps S405→S406→S407). This operation is performed by the request packet receiving unit 201 and the request packet analysis unit 202 illustrated in FIG. 3.
If it is determined that the request packet is a distribute stop request packet, 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 S406→S408→S401).
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 real-time image distribution device, step S407 is not performed and the process returns to the determination process in step S405.
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 S407 is performed. Specifically, firstly it is determined whether the request packet is a transmit stop request packet or a transmit start request packet (step S407-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 S407-1→S407-2). Then, the process returns to the determination process in step S405.
If a transmit start request packet is received, 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 S407-1→S407-3). Then, the process returns to the determination process in step S405. Thus, flow control is exercised.
The above operations of the first preferred embodiment of receiving and transmitting devices are summarized in the operational sequence charts illustrated in FIGS. 8A and 8B.
If the transmitting device's 200 own device is a real-time image distribution device, as illustrated in FIG. 8A, the transmitting device 200 returns a request response to which information about the real-time encoder is attached (step S403 in FIG. 5) to an image distribute request from the receiving device 100 (step S301 in FIG. 4). In response to this, the receiving device 100 modifies the state of its own device to a real-time mode (step S304 in FIG. 4). Then, real-time image signals are transmitted from the transmitting device 200 to the receiving device 100 (step S404 in FIG. 5, step S306 in FIG. 4).
If the transmitting device's 200 own device is a file distribution server, as illustrated in FIG. 8B, the transmitting device 200 returns a request response to which information about the distribution server is attached (step S403 in FIG. 5) to an image distribute request from the receiving device 100 (step S301 in FIG. 4). In response to this, the receiving device 100 modifies the state of its own device to a server mode (step S304 in FIG. 4). Then, image files are transmitted from the transmitting device 200 to the receiving device 100 (step S404 in FIG. 5, step S307 in FIG. 4).
Thus, according to the first preferred embodiment of receiving and transmitting devices, 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.
Next, the second preferred embodiment of receiving and transmitting devices will be explained.
Firstly, 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.
However, in the receiving device 100, firstly 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. When 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. When the request response packet in which the mode of a distribution server is set to indicate abnormality is sent from the transmitting device, 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. When a request response packet in which the mode of a distribution server is set to indicate normality is returned from the transmitting device in response to this request packet, the receiving device 100 operates in a server mode.
FIG. 9 is a configuration of a transmitting device 800 in the second preferred embodiment.
In FIG. 9, 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.
If a real-time mode is set in the distribute start request packet when its own device is a real-time image distribution device, 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.
If a real-time mode is set in the distribute start request packet when its own device is a file distribution server, 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.
Firstly, a request packet for requesting the start of distribution is transmitted to an IP (Internet protocol) address specified by a user (step S901). In this case, 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”. In step S901, 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.
Then, 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 S901→S902→S901), 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 S903).
If this determination is YES, 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 S904). Thus, when a real-time mode is set, data is received on the basis of PCR control (step S306). This operation is the same as the operation in step S306 of the first preferred embodiment, illustrated in FIG. 4.
If the determination in step S903 is NO, the mode determination unit 105 notifies the request packet generation unit 101 of this fact. In response to this notice, the request packet generation unit 101 transmits a request packet requesting re-starting of the distribution to the specified IP address (step S905). In this case, a value “1” indicating a server mode is specified in the request packet as distribute request mode information, that is, “RECEIVETYPE” information.
Then, 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 S905→S906→S905), 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 S907). When a server mode is set thus, data is received on the basis of flow control (steps S307 through S310). This operation is the same as the operation in steps S307 through S310 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.
Firstly, the processes in steps S401 and S402 are the same as those in steps S401 and S402 in the first preferred embodiment, illustrated in FIG. 5.
Specifically, firstly, the transmitting device 800 is in a request packet waiting state (repetition of the determination in step S401).
When a request packet is received, the contents of the request packet are analyzed (step S4029). This operation is performed by the request packet receiving unit 201 and the request packet analysis unit 202 illustrated in FIG. 9.
When the request packet requests the start of the distribution of image signals or files as a result of the above analysis, it is determined whether distribute request mode information set in the request packet coincides with the mode of its own device (step S1001). This operation is performed by the request mode determination unit 801 illustrated in FIG. 9.
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 S901 illustrated in FIG. 10. Therefore, if its own device is a real-time image distribution device, it is determined in step S1001 that they are matched and if its own device is a file distribution server, it is determined in step S1001 that they are not matched.
If its own device is a file distribution server, after the determination of non-coincidence in step S1001, the second distribute start request packet is received in step S905 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 S901 illustrated in FIG. 10. Therefore, it is determined in step S1001 that they are matched.
If its own device is a file distribution server and it is determined in step S1001 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 S1002) 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. In step S1002, 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 S1002→S401).
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 S1001 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 S1003). Specifically, in the data structure example illustrated in FIG. 7, 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.
Then, 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 S404). Operations after this are the same as a series of control operations from steps S405 until S408 in the first preferred embodiment.
The above operations of the receiving and transmitting devices in the second preferred embodiment are summarized in the operational sequence charts illustrated in FIGS. 13A and 13B.
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 S1001 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 S901 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 S1003 illustrated in FIG. 11). Then, image signals are transmitted in real time from the transmitting device 800 to the receiving device 100 (step S404 illustrated in FIG. 11, step S306 illustrated in FIG. 4).
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 S1001 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 S901 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 S1002 illustrated in FIG. 11). In response to this request response, the receiving device 100 detects mode non-coincidence (step S903 illustrated in FIG. 10) and transmits an image distribute request in which a server mode is specified (step S903 illustrated in FIG. 10). As a result, in the transmitting device 800, mode non-coincidence is determined (step S1001 illustrated in FIG. 11). Then, the transmitting device 800 returns a request response indicating normality including information indicating a distribution server (step S1003 illustrated in FIG. 11). In response to this, the receiving device 100 sets its own device in a server mode (step S907 illustrated in FIG. 10). Then, image files are transmitted from the transmitting device 800 to the receiving device 100 (step S404 illustrated in FIG. 11, step S307 illustrated in FIG. 10).
Thus, according to the second preferred embodiment of transmitting and receiving devices, 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.
Thus, according to the first or second preferred embodiment of 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.
Using a receiving device according to the above preferred embodiments, images can be received seamlessly without being aware of a distribution source.
Although in the respective preferred embodiments, explanations are given targeting image signals as an example, the disclosed technology is also applicable to various media signals other than image signals, such as voice signals and the like.
All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a demonstration of superior and inferior aspects of the invention. Although the embodiments of the present invention have been described in detail, it should be understood that various changes, substitutions and alterations could be made hereto without departing from the spirit and scope of the invention.

Claims (4)

What is claimed is:
1. A media distribution switching method for switching media information distributed from a transmitting device to a receiving device on a packet network, comprising:
transmitting a request packet for requesting distributing of the media information from the receiving device to the transmitting device;
determining by the transmitting device whether a request mode set in the request packet matches an operation mode of the transmitting device;
returning from the transmitting device to the receiving device when the request mode matches the operation mode, a request response packet to which device type information is attached, the device type information indicating whether the transmitting device is for real-time transmission in which a program clock reference is used to perform synchronization between a transmission side and a reception side when a real-time encoder is specified in the request response packet or non-real-time transmission in which flow control is performed to perform synchronization between the transmission side and the reception side when a distribution server is specified in the request response packet; and
performing a reception process by switching between an operation mode for real-time transmission and an operation mode for non-real-time transmission in the receiving device, according to device type information attached to the request response packet received from the transmitting device.
2. The media distribution switching method according to claim 1, wherein
when transmitting the request packet to the transmitting device, the receiving device attaches distribute request mode information for specifying a first operation mode expected by the receiving device to the request packet, and
when the distribute request mode information attached to the request packet coincides with an operation mode of the transmitting device, the transmitting device returns the request response packet to which information indicating normality is attached, and when the distribute request mode information attached to the request packet does not coincide with an operation mode of the transmitting device, the transmitting device returns the request response packet to which information indicating abnormality is attached, and
when information indicating normality is attached to the request response packet received from the transmitting device, the receiving device performs a receiving operation in an operation mode corresponding to device type information attached to the request response packet, and
when information indicating abnormality is attached to the request response packet received from the transmitting device, the receiving device re-transmits a request packet to which distribute request mode information for specifying an operation mode different from the first operation mode is attached, to the transmitting device.
3. A receiving device for receiving media information transmitted from a transmitting device on a packet network, comprising:
a request packet generation unit configured to generate a request packet in which a request mode is set for requesting distribution of the media information;
a request response packet receiving unit configured to receive a request response packet corresponding to the request packet from the transmitting device;
a request response analysis unit configured to analyze a request response set in the request response packet;
a mode determination unit configured to switch, based on device type information attached to the request response packet, between an operation mode for real-time transmission in which a program clock reference is used to perform synchronization between a transmission side when a real-time encoder is specified in the request response packet and a reception side and an operation mode for non-real-time transmission in which flow control is performed to perform synchronization between the transmission side and the reception side when a distribution server is specified in the request response packet;
a first receiving unit configured to receive the media information in an operation mode for non-real-time transmission; and
a second receiving unit configured to receive the media information in an operation mode for real-time transmission.
4. A transmitting device for transmitting media information to a receiving device on a packet network, comprising:
a request packet receiving unit configured to receive from the receiving device a request packet for requesting distribution of the media information;
a request packet analysis unit configured to determine whether a request mode set in the request packet matches an operation mode of the transmitting device; and
a request response packet transmitting unit configured to return, when the request mode matches the operation mode, to the receiving device in response to the request, a request response packet to which device type information is attached, the device type information indicating whether the transmitting device is a real-time transmission in which a program clock reference is used to perform synchronization between a transmission side and a reception side when a real-time encoder is specified in the request response packet or a non-real-time transmission in which flow control is performed to perform synchronization between the transmission side and the reception side when a distribution server is specified in the request response packet.
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 (en) 2009-06-30 2009-06-30 Media distribution switching method, receiving apparatus, transmitting apparatus
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 (en)
EP (1) EP2271094A3 (en)
JP (1) JP4740356B2 (en)
KR (1) KR101145078B1 (en)
CN (1) CN101938464B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012080257A (en) * 2010-09-30 2012-04-19 Canon Inc Presentation device, distribution device, processing method thereof, and program
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 (en) 1994-06-30 1996-01-19 Toshiba Corp Information communication terminal
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 (en) * 2002-07-04 2004-02-05 Mitsubishi Electric Corp Communication equipment
JP2004193920A (en) * 2002-12-11 2004-07-08 Toshiba Corp Program delivering system and receiving apparatus
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 (en) 1994-06-30 1996-01-19 Toshiba Corp Information communication terminal
WO1999067887A2 (en) 1998-06-23 1999-12-29 Koninklijke Philips Electronics N.V. Telecommunication system with channel sharing
KR100642212B1 (en) 1998-06-23 2006-11-06 코닌클리케 필립스 일렉트로닉스 엔.브이. Telecommunication system suitable for transmitting real-time data and non-real-time packet data, telecommunication station for use in the system, and method of operating the system
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 (en) 2003-01-11 2006-02-22 Lg电子株式会社 Packet service system and method for controlling packet transmission
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 (en) 2011-08-03
JP2011015020A (en) 2011-01-20
US20100332591A1 (en) 2010-12-30
KR20110001906A (en) 2011-01-06
CN101938464B (en) 2015-10-21
EP2271094A2 (en) 2011-01-05
KR101145078B1 (en) 2012-05-14
CN101938464A (en) 2011-01-05
EP2271094A3 (en) 2013-01-09

Similar Documents

Publication Publication Date Title
JP6685989B2 (en) Extended Block-Request Streaming System with Signaling or Block Generation
US9973345B2 (en) Calculating and signaling segment availability times for segments of media data
EP2952006B1 (en) Determining available media data for network streaming
TWI668982B (en) Method and server device for transport interface for multimedia and file transport, and computer-readable storage medium for recording related instructions thereon
US9585062B2 (en) System and method for implementation of dynamic encoding rates for mobile devices
JP4702397B2 (en) Content server, information processing apparatus, network device, content distribution method, information processing method, and content distribution system
KR101797507B1 (en) Media content transceiving method and transceiving apparatus using same
US20090064242A1 (en) Fast channel switching for digital tv
EP3266218A1 (en) File format based streaming with dash formats based on lct
CN103039051A (en) Server-assisted video conversation
KR20170074866A (en) Receiving device, transmitting device, and data processing method
WO2002051155A1 (en) Webcasting method and system for time-based synchronization ofmultiple, independent media streams
US20150271298A1 (en) Reduced latency media distribution system
EP2087702A1 (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 (en) Network device, information processing apparatus, stream switching method, information processing method, program, and content distribution system
JP2002152301A (en) Data communication system, data receiver, data communication method, and program storage medium
US8811478B2 (en) Data transmission method and apparatus
JP5082715B2 (en) Receiving device, receiving method, and computer program
JP2004274619A (en) Moving picture distribution server, moving picture receiving terminal, image packet transmission method, and image packet receiving method
JP2016076884A (en) Multimedia synchronous reproduction device and multimedia synchronous reproduction method
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