US20040255329A1 - Video processing - Google Patents

Video processing Download PDF

Info

Publication number
US20040255329A1
US20040255329A1 US10/813,457 US81345704A US2004255329A1 US 20040255329 A1 US20040255329 A1 US 20040255329A1 US 81345704 A US81345704 A US 81345704A US 2004255329 A1 US2004255329 A1 US 2004255329A1
Authority
US
United States
Prior art keywords
network
resolution
video data
video
data stream
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.)
Abandoned
Application number
US10/813,457
Other languages
English (en)
Inventor
Matthew Compton
Jian-Rong Chen
Daniel Wilson
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.)
Sony Europe BV United Kingdom Branch
Original Assignee
Individual
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 Individual filed Critical Individual
Assigned to SONY UNITED KINGDOM LIMITED reassignment SONY UNITED KINGDOM LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WILSON, DANIEL, CHEN, JIAN-RONG, COMPTON, MATTHEW
Publication of US20040255329A1 publication Critical patent/US20040255329A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347—Demultiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365—Multiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2665—Gathering content from different sources, e.g. Internet and satellite
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP

Definitions

  • the present invention relates to processing video data.
  • the present inventors have identified the need for a system which links audio and video devices in a studio by a switched local area network, for example an Ethernet network, operating with a known protocol such as Internet Protocol (IP).
  • IP Internet Protocol
  • the audio and video devices used in a studio include cameras, editors, audio mixers, video tape recorders (VTRs) and play-out switches amongst other examples. It is also known to use monitors to view video which is being played out or to preview on monitors video which is available to be played out.
  • VTRs video tape recorders
  • a video processor connectable to a data network and being arranged to receive a digital video data stream of a first resolution
  • the processor comprising: a video generator arranged to produce from the video data stream of the first resolution a video data stream of a second, lower, resolution; a packetiser operable to format at least that part of the video data stream of the first resolution not represented by the video data stream of the second resolution into data packets and to format the video data stream of the second resolution into data packets; and a network interface arranged to launch the data packets onto the data network, the video generator, the packetiser and the network interface operating substantially in real time.
  • a network interface device connectable to a network, the device being arranged to receive a digital video data stream of a first resolution and, substantially in real time, to launch data packets representing the digital video data stream onto the network, the device comprising: a video generator to produce from the video data stream of the first resolution a video data stream of a second, lower resolution; and a packetiser operable: to format the video data stream of the second resolution into data packets to be launched onto the network; and to format at least that part of the video data stream of the first resolution which is not represented by the video data stream of the second resolution into data packets to be launched onto the network.
  • second, lower, resolution video data is produced from the first, higher, resolution video data.
  • the higher and lower resolution video data are preferably launched onto a packet-based network in separate multicast groups so that, for example, the higher resolution video may be supplied to a first destination or set of destinations associated with the first multicast group and the lower resolution data may be supplied to a second, possibly different, destination or set of destinations associated with the second multicast group.
  • the higher resolution video supplied to the first destination(s) may be monitored in lower resolution at the second destination(s).
  • the processing of the higher resolution video at the first destination may be controlled by control equipment at the second destination.
  • the use of the lower resolution reduces the processing overhead and data traffic at such control equipment, potentially allowing several such lower resolution streams to be handled at the control equipment.
  • the network interface is arranged to launch the data packets corresponding to the video data stream of the first resolution onto the network as a multicast group.
  • the network interface is also arranged to launch the data packets corresponding to the video data stream of the second resolution onto the network as a second multicast group, different to the first multicast group. This allows different network recipients to be set up for the two streams.
  • the or each video data stream of the second resolution comprises an uncompressed video data stream.
  • the or each video data stream of the second resolution conforms with the RGB 555 format, representing each of red, green and blue pixel values by 5 bits of a pixel word.
  • This format is particularly suited to allow display on a PC's display screen (particularly in a 16-bit colour mode of operation) with a relatively small amount of processing being required at the PC.
  • the packetiser is arranged to format the or each video data stream of the second resolution into RTP (Real time Transport Protocol) packets having a line of video data in each such packet.
  • RTP Real time Transport Protocol
  • the packetiser can be arranged to format the (whole of the) video data stream of the first resolution into data packets. This has the advantage that the video data stream of the first resolution is self-contained. Alternatively, where a subset of the video data stream of the first resolution can be derived from the respective video data stream of the second resolution, the packetiser can be arranged to format only a part, being all but the subset, of the video data stream of the first resolution into data packets. This has the advantage of reducing network data traffic, as unnecessary data is not transmitted.
  • audio and control data need to be transferred between source and destination equipment (possibly different equipment to video destination equipment).
  • this can be carried out over the same network as the video data.
  • the processor is arranged to receive one or more audio and/or control data streams associated with the digital video data stream; the packetiser is arranged to format the audio and/or control data streams into data packets; and the network interface is arranged to launch the data packets of the audio and/or control data streams onto the network.
  • the video generator is selectably operable to generate the video data stream of the second resolution from only odd fields or from only even fields of the video data stream of the first resolution.
  • the video generator could be operable to generate a video data stream of the second resolution from only odd fields and a video data stream of the second resolution from only even fields of the video data stream of the first resolution. This allows network load balancing to be carried out by the network destination selecting which of the two (equally useful) lower resolution streams should be received from that video processor.
  • the processor can be a stand-alone unit connectable to video equipment
  • the processor is preferably embodied as a component of video source equipment (such as a camera, VTR, vision mixer etc) and/or as a component of video destination equipment (such as a monitor, VTR, vision mixer etc).
  • FIG. 1 is a schematic block diagram of a network in a studio
  • FIG. 2 is a schematic simplified diagram of the network showing data flows across the network
  • FIG. 3A is a schematic diagram of the format of an audio or video packet used in the network
  • FIG. 3B is a schematic diagram of the format of an AVSCP or CNMCP packet used in the network
  • FIG. 3C schematically illustrates a unicast data packet
  • FIG. 4 is a schematic block diagram of a network interface of the network of FIG. 1;
  • FIG. 5A is a schematic diagram of the format of an data packet used in the network interface
  • FIG. 5B is a schematic example of current flow assignment
  • FIG. 5C schematically illustrates data flow in an ENIC
  • FIGS. 6A and 6B schematically illustrate a packetiser/depacketiser switch of the network interface
  • FIG. 7 is a schematic block diagram of an illustrative small network for explaining a mode of operation of the network.
  • FIG. 8 is a schematic block diagram of a proxy generator of the network interface
  • FIG. 9 is a schematic diagram of one example of the display of a Graphical User Interface (GUI).
  • GUI Graphical User Interface
  • FIG. 10 is a schematic diagram of another example of the display of a Graphical User Interface (GUI).
  • GUI Graphical User Interface
  • FIG. 11 is a schematic diagram of an example of a graphical interface for illustrating the configuration of the network
  • FIG. 12 is a schematic diagram of an example of a graphical interface for illustrating how data is routed across the network
  • FIG. 13 schematically illustrates a user interface provided on the network manager via which a user may enter configuration data
  • FIG. 14 schematically illustrates a protocol stack
  • FIG. 15 schematically illustrates an AVSCP header.
  • a network is installed in for example a studio.
  • the network comprises a plurality of source group AV devices consisting of three cameras S 1 to S 3 , three video tape recorders (VT 10 s) S 4 to S 6 , two digital signal processors (DSPs) S 7 ,S 8 and two other source groups S 9 , Si 0 which generate serial digital audio data only.
  • the network further comprises a set of destination group AV devices consisting of a video switch D 8 , a pair of monitors D 2 , a pair of audio processors D 3 and a video processor D 9 .
  • An Ethernet switch 2 effects connections between source group devices and destination group devices.
  • the network further comprises a network control arrangement consisting of a first switching and routing client 6 , an additional switching and routing client 61 and a network manager 4 .
  • a user may request a change in the current configuration of the virtual circuit-switched connections of the network via a Graphical User Interface (GUI) generated by a computer software application, which in this arrangement is displayed on a monitor associated with the switching and routing client 6 .
  • GUI Graphical User Interface
  • the GUI is displayed on a monitor associated with the network manager 4 .
  • the GUI is described in detail below with reference to FIGS. 9 to 12 .
  • the network is an Ethernet multicast network comprising the Ethernet switch 2 , which is an asynchronous nGigabit Ethernet switch 2 , where n is 1 or 10 for example.
  • the Ethernet switch 2 Connected to the Ethernet switch 2 are network nodes comprising the source “groups” S 1 to S 10 , the destination “groups” D 1 , D 2 , D 3 , D 8 and D 9 , and the network control arrangement, which in this example comprises the network manager 4 and the switching and routing clients 6 , 61 .
  • a source group is defined to be an AV device such as a camera S 1 or a video tape recorder (VTR) 54 that is operable to generate or supply audio and/or video data for transmission across the network, the source group having one or more input and/or one or more output terminal.
  • Each input/output terminal of the AV device will be connected to a port of one of the ENICs NI 1 to NI 11 .
  • different terminals of the same AV device may be connected to different ENICs as in the case of source group S 1 in FIG. 1, which has a first output terminal connected to ENIC NI 1 and a second output terminal connected to ENIC NI 2 .
  • a destination group is defined to be an AV device such as a video switch D 8 , video processor D 9 or audio processor D 3 , that is operable to receive packetised audio and/or video data via the network and to perform processing operations on the received data.
  • the destination group comprises one or more inputs and/or one or more outputs which can be connected to different ports of the same ENIC or to different ENICs.
  • a destination group may also act as a source and a source group may also act as a destination for different data exchange events on the network.
  • the VTR 54 has audio, video, status and proxy source and/or destination devices associated with it and for a data exchange event involving output of data across the network from a video source device on the VTR 54 to the video processor D 9 , the VTR 54 acts as a source group.
  • a different data exchange event may involve the VTR 54 receiving data from a camera S 1 that has been routed via the network through the video processor D 9 for subsequent recording by the VTR 54 , in which case, the processed video data will be received from the network at a destination device (ENIC input terminal) associated with the VTR 54 for subsequent supply to the VTR 54 in serial digital form for recording so that the VTR 54 acts as a destination group in this context.
  • a destination device ENIC input terminal
  • each of these groups is connected to one or more ENIC ports.
  • the ENIC ports will be denoted “source devices” and “destination devices”.
  • a “source device” is defined to be an ENIC output port, which outputs packetised data onto the network or outputs serial digital data to a destination group AV device whereas a “destination device” is defined to be an ENIC input port, which receives either packetised data from the network or serial digital data from a source group AV device output terminal.
  • the source devices and destination devices of an ENIC can be associated with the source groups (AV devices) from which they receive data for transmission across the network or the destination groups to which they deliver data from the network.
  • the network manager 4 keeps track of the mappings between ENIC ports and AV devices.
  • the network manager 4 stores a freely assignable alphanumeric label denoted “tally text” for each source group S 1 to S 110 of the network.
  • tally text is a name such as “VTR 1 ” which may be given to a source group S 4 or a cameraman's name e.g. “Jim” which may be given to the source group camera S 1 .
  • the tally text is recorded at the network manager. All groups connected to the network may be named in this way. Source devices and destination devices of the ENIC may be labelled with tally text derived from the associated source group or destination group AV device.
  • each source group S 1 -S 6 and each destination group D 1 , D 2 ; D 3 , D 8 , D 9 is coupled to the Ethernet switch 2 by at least one network interface card NI 1 to 11 .
  • These network interface cards are specially adapted for transmission of audio and/or video data across the network according to the present technique and are denoted ENICs (Enhanced Network Interface Cards).
  • ENICs Enhanced Network Interface Cards
  • a single source or destination group may be connected to a plurality of ENICs, for example, in the arrangement of FIG. 1, the camera source group S 1 is connected to two different ENICs, that is, NI 1 and NI 2 .
  • each ENIC NI 1 to NI 8 has a plurality of ports.
  • Input ports of a first subset of the ENICs, NI 1 to NI 7 receive data directly from source groups such as cameras SI 1 to S 13 , VTRs S 4 to S 6 and DSPs SI 7 , SI 8 and the output ports of those ENICs transmit packetised data across the network, whereas input ports of a second subset of the ENICs, NI 8 to NI 11 , receive packetised data derived from other source groups across the network whilst their output ports supply serial digital audio and/or video data to destination groups such as the video switch D 8 and audio processors D 3 .
  • the network optionally also comprises a master ENIC NIM 63 (See FIG. 1) which will be described in more detail in the section Frame Start Alignment below.
  • the source groups e.g. cameras and destination groups e.g. video processors are connected by a cross point switch.
  • the conventional cross point switch requires specific known devices to be connected to corresponding specific known ports on the switch to ensure that they can be connected together via switch.
  • the network of FIG. 1, including the Ethernet switch 2 is configured by the network manager 4 and by the switching and routing client 6 to provide virtual circuit-switched connections that emulate a crosspoint switch at least to the extent that any one or more source groups can be connected to any one or more destination groups.
  • the virtual circuit-switched connections are facilitated by implementation, in the arrangement of FIG. 1, of an Internet Protocol (IP) multicast network that uses a known protocol, IGMP (Internet Group Management Protocol).
  • IP Internet Protocol
  • IGMP Internet Group Management Protocol
  • the multicast network enables transmission of data from one source device to several destination devices belonging to a predetermined multicast group across the network and IGMP provides a means of identifying which multicast group a source device or destination device belongs to.
  • Each source device and destination device is assigned an identifier and predetermined source device identifiers and destination device identifiers are associated with a given multicast address in order to define the virtual connections.
  • the actual physical ports of the Ethernet switch 2 to which the source devices and destination devices are connected are irrelevant because the connections are flexibly specified using the identifiers and multicast addresses and associated communication protocols.
  • the network operates as follows: a single source device should belong to only one multicast group that is not shared by any other sources. At least one destination device receives data from that source device by joining the source device's multicast group. A given destination device joins a multicast group in order to receive data from the associated source device by issuing a multicast group join message.
  • the network control arrangement 4 , 6 , 61 initiates each virtual circuit-switched connection by sending a control message to the destination device (i.e. to an input terminal of one of destination group AV devices or a corresponding ENIC terminal) instructing the device to issue a request to the Ethernet switch 2 to join the multicast group of the appropriate source device.
  • the Ethernet switch 2 performs the required duplication of the data from the source device transmitting to that multicast group.
  • the data that may be transmitted by a source device to the plurality of destination devices of the multicast group includes video data, audio data, timecode data or status data.
  • An ENIC allows any source group, for example a camera, and any destination group, for example a VTR, which is not designed for use with a multicast network to be used in a multicast network.
  • An ENIC is a “dumb” device which can be requested to supply and receive audio, video, and control data streams.
  • An ENIC cannot view or initiate any change to the configuration of the network. Rather, the network manager 4 controls to which multicast group(s) a given ENIC may subscribe and directs the ENIC to issue requests to the Ethernet switch 2 to join those multicast groups.
  • the ENICs NI 1 to NI 11 are distinct entities from the source group and destination group AV devices with which they are associated, it will be appreciated that in alternative arrangements the functionality of an ENIC could be integrated into an AV device.
  • Each ENIC has an associated Ethernet address and an IP address.
  • the Ethernet address is a 48-bit value that specifies a physical address within the LAN whereas the IP address is (in for example IPv 4 ) a 32-bit value that identifies each sender or receiver of packet-based information across the Internet.
  • the Ethernet address typically differs from the IP address but the two addresses can be mapped to each other e.g. using Address Resolution Protocol (ARP).
  • ARP Address Resolution Protocol
  • the IP address is required to enable the Ethernet switch 2 to route data to and from the ENIC.
  • Each data stream associated with the ENIC is identified using both a multicast address and a User Datagram Protocol (UDP) port number.
  • UDP is a transport layer protocol that together with IP mediates data communication across the network. UDP provides port numbers to distinguish different transaction requests (this service is not provided by IP).
  • a single IP address is associated with each ENIC.
  • multiple IP addresses could be associated with a single ENIC.
  • the ENIC also has an associated ENIC identifier (ID) and a plurality of port IDs for respective ones of the destination devices and source devices associated with the ENIC. All of the addresses and IDs associated with each ENIC are recorded by the network manager 4 .
  • the source devices and destination devices i.e.
  • ENIC acts as a switch which switches data received from the switch 2 to a specified physical output of the ENIC and switches data from a specified physical input to the switch 2 .
  • the network implemented using the Ethernet switch 2 , is asynchronous. However video and audio data need synchronous processing.
  • the ENICs provide synchronous operation across the network and align frames of different video streams for purposes such as editing.
  • the video and audio devices i.e. source groups and destination groups
  • the video and audio devices i.e. source groups and destination groups
  • the ENICs convert data from the source device at the transmission end from SDI or AES serial digital format to a packetised format suitable for transmission across the network, in particular to multicast UDP/IP data packets.
  • the ENICs convert multicast UDP/IP data packets received from the network to a serial digital data format suitable for delivery to the destination device.
  • a further functionality provided by the ENICs is to generate from a full resolution video stream a reduced resolution video stream denoted “proxy video”.
  • the proxy video is a reduced-bandwidth version of the corresponding full-resolution video information and, as such, is suitable for processing by network clients having restricted storage capacity and/or processing power or for use in previewing information content for downloading across the network.
  • a source or destination is a networked video server or client in which video data is stored on (for example) a hard disk drive
  • the ENIC associated with that source/destination can act as an interface between data stored at the server in the form of video frames and the packetised format in which the data is transmitted over the network. So, for an outgoing field or frame read from a local hard disk, the ENIC would carry out the conversion into packetised form. For an incoming field or frame, the ENIC would carry out the conversion from packetised form into a field or frame ready to be stored on the hard disk.
  • the ENIC can also operate as a conventional network interface card. So, ancillary asynchronous data such as email traffic can be handled (e.g. via a PCI interface of the ENIC—see below) as well as the synchronous audio and video traffic. Generally, the ENIC is arranged so as to give priority to the synchronous traffic, but this would still normally leave gaps between the audio and video packets for asynchronous packets to be handled.
  • the network manager 4 co-operates with the switching and routing clients 6 , 61 form the network control arrangement that is operable to assign multicast group identifiers to the audio and video source devices and to instruct destination devices to issue requests to the Ethernet switch 2 to join a particular multicast group in order to receive data from the corresponding source device.
  • the network manager 4 maintains information of the current state of the network and all instructions that initiate a change to the device configuration or to the network connectivity originate from the network manager 4 .
  • the network manager is a Personal Computer (PC) that is linked to the network via a standard network interface card.
  • the network manager could be for example a workstation and the network control arrangement may comprise more than one network manager.
  • the network manager 4 maintains a database specifying the configuration of the network.
  • the database is stored on the same PC as the network manager 4 but in alternative arrangements it could be stored on at least one different PC.
  • the database records, for each ENIC, the associated Ethernet address, the IP address, the ENIC ID and the source devices and destination devices (inputs and outputs of the network node devices) currently connected to the network via that ENIC.
  • the section below entitled “Network Configuration Data” describes four different categories of device for which the network manager 4 stores configuration data.
  • the network manager 4 also performs the functions of: allocating network resources to the switching and routing client(s) 6 , 61 and to the ENICs NI 1 to NI 11 ; sending commands to the destination devices to issue requests to the Ethernet switch 2 to join a specified multicast group thereby changing the audio and/or video virtual circuit-switched connections across the network; and ensuring that each switching and routing client's 6 , 61 view of the network is correct.
  • the network manager stores and maintains a set of data relating to each of a number of different categories of device on the network. Since control messages are sent from the network control manager 4 to the ENICs NI 1 to NI 11 (rather than to input/outputs), each ENIC port is categorised as belonging to one of a plurality of device types/categories.
  • the “source device” and “destination device” have already been discussed above.
  • the network configuration data is of four basic types relating to four different types of device (ENIC input/output ports) and a fifth data type associated with a group of devices that are commonly controlled.
  • the four basic device types are:
  • SOURCE device video, audio and status data from a source device is appropriately formatted by an ENIC and transmitted to a multicast group on the network. Each SOURCE device can also transmit a low-bandwidth video proxy.
  • DESTINATION device video, audio and status data from the network is received by a destination device by joining a multicast group.
  • CONTROL SOURCE device control commands are generated by an ENIC or by a network client and are transmitted unicast to a predetermined CONTROL DESTINATION.
  • the switching and routing client 6 cannot directly access the SOURCE and CONTROL DESTINATION devices. These devices are members of a CONTROL SOURCE GROUP, which is a group of devices that cannot be controlled independently.
  • a standard SDI video output and a super SDI output from a VTR are both connected to an ENIC for transmission onto the network 2 .
  • the SDI input is represented as four SOURCE devices comprising two video source devices, V 0 , V 1 (one from the SDI output and one from the super SDI output) and two audio source devices A 0 , A 1 in the network configuration. These four source devices are generated by the same physical device (the source group is the VTR).
  • the four source devices have a common time code and stream status, i.e. stop, FF(fast forward), rew (rewind), etc. Hence these four source devices are jointly controlled via a control source group rather than being independently controlled.
  • a predetermined set of information is stored by the network manager 4 in relation to each of the above device types i.e. source, destination, control source control destination and control source group in addition to an ENIC data structure described below.
  • the network manager stores the following data:—a 32-bit ID of which the most significant 16 bits specify the ENIC ID and the least significant 16 bits specify the UDP port ID; an 8-bit value specifying the data type (audio, video or status data); a 32-bit value specifying the CONTROL SOURCE GROUP to which the source device belongs; a first 32-bit multicast IP address specifying the destination device that the source transmits to and a second 32-bit multicast IP address specifying the destination device to which the video proxy is transmitted; 64 bytes of tally text information; a 32-bit “LINK” value specifying a destination device ID associated with a destination device that supplies the given source (a linked source is one that is supplied by a destination device (e.g.
  • chroma keyer that receives data via the network and subsequently outputs processed data onto the network as a source for another network device); a 32-bit value specifying the number of video lines to delay transmission by for a video source; and an 8-bit state value specifying if the source is currently enabled to transmit data across the network.
  • the network manager stores the following data:—a 32-bit ID of which the most significant 16 bits specified the ENIC ID and the least significant 16 bits specifies the UDP port ID; an 8-bit value specifying the data type (audio, video or status data); a 32-bit value specifying the IP address of the ENIC that implements the destination device; a 32-bit value MCAST_SRC_IP specifying the multicast IP address from which the destination device receives data; a 32-bit value specifying the source device that transmits to the multicast IP address with to which the destination device is assigned; an 8-bit tally text index; a 32-bit value specifying a source device ID associated with a source device that is supplied by the destination device (a linked destination is one that supplies a source); a 32-bit line delay value that specifies the number of video lines by which to delay playout; and an 8-bit status value specifying whether the destination device is on-air, off-air, controlled etc.
  • the network manager 4 stores the following data set:—a 32-bit ID of which the most significant 16 bits specified the ENIC ID and the least significant 16 bits specifies the UDP port ID; a 32-bit value specifying an ID of the control destination device to which messages are to be transmitted; a 32-bit IP address and a 16 bit UDP port address of the ENIC that implements the specified control destination device; a 32-bit IP address and a 16-bit UDP address of the ENIC that implements the actual control source device.
  • the network manager 4 stores the following data set:—a 32-bit ID of which the most significant 16 bits specify the ENIC ID and the least significant 16 bits specify the UDP port ID; a 32-bit ID of the control source group to which the specified control destination device belongs; a 32-bit ID of the control source to which the control destination is connected; a 32-bit IP address and 16-bit UDP address of the ENIC that implements the associated control source; and a 32-bit IP address and 16-bit UDP address of the ENIC that implements the specified control destination.
  • the network manager 4 stores the following data set:—A 32-bit ID that uniquely identifies the specified control source group; a 16-bit value specifying the number of devices belonging to the source group; a 32-bit value specifying the Ids of all of the devices belonging to the group (maximum of ten); a 32-bit value specifying the control destination device associated with the group; a 32-bit source status value specifying the status source device that transmits the status data for each of the (up to ten) devices of the group; 64 bytes comprising tally texts for all of the devices of the group; 128 bytes of description data for storing up to ten descriptions for the group; a 64-byte control source name and an 8-bit status value.
  • the following data is stored by the network manager 4 for each of the ENICs NI 1 to NI 11 as the ENIC data structure:—a 16-bit ID that uniquely identifies the ENIC; a 48-bit media access control (MAC) address associated with the ENIC; a 32-bit ENIC IP address; a 32-bit IP address for the master clock of the ENIC and a 32-bit filed specifying a number of parameters used for device to hardware mappings.
  • MAC media access control
  • the ENIC data structure also maps the four source devices of the above example to the physical ports on the ENIC card and includes any hardware limitations that restrict the ideal model described above.
  • an ENIC initialises it will receive information on what devices are connected to its UDP (RS422) ports, so that the correct driver can be used.
  • the network manager 4 stores each multicast IP address MCAST_SRC_IP from which that destination group derives data. It should be understood that different input/output ports of a given destination group may receive data from different IP multicast addresses. The data received depends on the ENIC port (i.e. source/destination device) to which the input/output ports of the destination group (AV device) are connected. As specified above in relation to the DESTINATION data structure, for each destination group an ID for both the destination group itself and for the source group from which the received data is derived is also stored in the network configuration database.
  • the source/destination group ID comprises an identifier of the ENIC by which the source/destination group is connected to the network and an identifier of the ENIC port to which the associated source/destination group is connected. A similar set of information is stored in respect of each source group. Overview of Switching and Routing Client 6 .
  • the switching and routing client 6 similarly to the network manager 4 , is a PC linked to the network via a standard network interface card.
  • the switching and routing client 6 is operable to view and/or initiate changes to the network configuration i.e. to initiate of change virtual circuit switched connections between source devices and destination devices. Such changes may be initiated by a user interacting with a GUI as described below with reference to FIGS. 9 to 12 .
  • the switching and routing client 6 is operable to control both the video switch D 8 and the associated ENIC NI 8 as well as the supply of video data to the ENIC NI 8 to and from the network.
  • the switching and routing client 6 can also control the supply of video or audio data to other destination devices D 2 , D 3 and D 9 via the associated ENICS NI 9 , NI 10 and NI 11 respectively.
  • the further switching and routing client 61 is operable to control a different subset of destination devices and their ENICS from those controlled by the switching and routing client 6 .
  • the network manager 4 maintains a database specifying the current network configuration and co-operates with the switching and routing client 6 to configure the network.
  • the network manager 4 can grant the switching and routing client 6 permission to send certain commands directly to the ENIC rather than sending them to the ENIC via the network manager 4 , in general, all requests that may jeopardise the network configuration must be sent via the network manager. Examples of particular commands that do not jeopardise the network connections and hence can be sent directly from the switching and routing client 6 to an ENIC are data stream control commands such as play, rewind, fast-forward.
  • the network controller 4 allocates resources to the ENICs and to the switching and routing clients 6 , 61 , controls all commands that may jeopardise the audio and/or video data connections on the network and ensures that the switching and routing clients 6 , 61 have an accurate view of the relevant network connections.
  • the Ethernet network of the arrangement of FIG. 1 implements various conventional protocols including UDP (user datagram protocol)/IP, TCP(transmission control protocol)/IP, and IGMP (Internet Group Management Protocol).
  • Other protocols implemented in the network include a known real-time protocol (RTP), and two protocols that are proprietary to Sony Corporation: firstly AVSCP (Audio Video Switching Control Protocol), which is used for connection control between the network manager 4 and the ENICS NI 1 to NI 11 and secondly CNMCP (Client Network Manager Communication Protocol), which is used for communication between the network manager 4 and the switching and routing clients 6 , 61 .
  • RTP real-time protocol
  • AVSCP Audio Video Switching Control Protocol
  • CNMCP Clientt Network Manager Communication Protocol
  • FIG. 2 is a simplified diagram of the network of FIG. 1 showing only the Network manager 4 , the switching and routing client 6 , and a subset of the ENICs, in particular NI 1 (associated with the camera 1 source group), NI 2 (associated with both camera 1 and camera 2 source groups) and NI 8 (associated with the video switch D 8 destination group) by way of example.
  • FIG. 2 illustrates how the network manager 4 , switching and routing client 6 and the ENICs NI 1 , NI 2 , NI 8 communicate via the LAN using a number of different communication protocols. As shown in FIG.
  • the network manager 4 communicates with ENICS NI 1 , NI 2 , NI 8 using AVSCP whereas the switching and routing client 6 communicates with the network manager 4 using CNMCP.
  • the switching and routing client 6 is operable to receive as input Stream Status (SS) data specifying the status of a CONTROL SOURCE GROUP, to receive AV proxy data P and to output Unicast Control Data (UCD) to the network to control a source or destination device. Note that in this arrangement only the switching and routing client receives proxy video P as input although all three ENICs NI 1 , NI 2 , NI 8 output proxy video to the network.
  • SS Stream Status
  • UCD Unicast Control Data
  • the ENICs NI 1 , NI 2 and NI 8 are each operable to output proxy data P, to receive and transmit SS status data across the LAN, to send and receive RTP communications, to output IGMP data specifying to which multicast group that source device may transmitting data, to receive UCD messages across the network from the switching and routing client 6 and/or network manager 4 .
  • the ENIC NI 2 is operable to send UCD messages directly to another ENIC NI 8 bypassing the network manager 4 . As described above, this direct communication between ENICs is only permissible for control commands that do not jeopardise the network connections.
  • ENIC NI 8 Since the ENIC NI 8 is associated with the destination group video switch D 8 it is operable both to transmit and receive SDI video streams whereas ENICs NI 1 and NI 2 associated with the cameras are operable only to receive SDI video from outputs on those cameras for packetisation by the ENIC and transmission across the network.
  • AVSCP uses UDP (User Datagram Protocol) to carry its messages.
  • UDP is a connectionless transport protocol, which means that a one-way data packet is sent by the sending device without notifying the receiving device that the data is en route. On receipt of each data packet, the receiving device does not return status information to the sending device.
  • the data format is described in the section “Data Format” and FIG. 3B below.
  • AVSCP is used for communication between the network manager and each ENIC for the purpose of connection control and in order to monitor the operation status of ENIC and AV (audio and video) ports. For example, if it is desired to connect a video tape recorder (VTR) destination device to a camera source device to receive AV data then the switching and routing client 6 must send an instruction to the ENIC associated with the destination device, in this case the VTR, to join the port of that ENIC that is connected to the VTR to the specific multicast group that is sourced from the camera. This instruction between the ENIC and the switching control server 6 is sent via the AVSCP protocol.
  • VTR video tape recorder
  • the AVSCP protocol messages have five main functions, which are to:
  • the network manager 4 should be aware of the operational status of an ENIC before it can send any instructions to it. Accordingly the AVSCP protocol requires an ENIC to send status messages to the network manager 4 periodically. The network manager 4 can only control AV stream transmission and reception of an ENIC when it is operational. As an alternative to deriving network configuration information from messages periodically generated by the ENICs, the network manager 4 can actively obtain the current configuration of an ENIC by sending a configuration request message to it. The ENIC responds to this request by returning a message specifying the current configuration.
  • AVSCP messages are as follows:
  • STOP_TX and START_TX these are command messages that allow the network manager 4 to instruct an ENIC to stop transmission and start transmission of a specific AV data stream (specified by AV input port of ENIC).
  • SWITCH_AV and SWITCH_AUDIO these are command messages that enable the network manager 4 to instruct an ENIC to add or delete an AV data stream or audio data stream respectively to a specific multicast group
  • SET_CTRL_TX and SET_CTRL_RX these are command messages to set up transmit (TX) and receive (RX) ends of an AV data stream control path. If an application sends a SET_CTRL_TX message to one ENIC then it will typically also send a SET_CTRL_RX message to the ENIC at the other end of the control path to create a complete AV control path.
  • UPDATE_TALLY this is a command message used to request a source/destination device associated with an ENIC port to update its display of tally text information. This command is usually used when an AV source changes its display information.
  • ACK this message is sent by an ENIC to the network manager 4 when it has received a command message from the network manager 4 .
  • the acknowledged command message is identified by a session ID value and the acknowledgement itself could be either positive or negative.
  • the ACK message of AVSCP is required because UDP is not a guaranteed delivery protocol. If messages are not acknowledged within a predetermined time then they may be retransmitted up to a maximum number of times by the network manager.
  • FIG. 14 schematically illustrates how AVSCP relates to other functional modules in the ENIC network of FIG. 1.
  • the arrangement of FIG. 14 shows identical protocol stacks 1100 A and 1100 B of two different ENICs and a protocol stack 1120 of the network manager 4 .
  • the ENIC protocol stack comprises an AVSCP layer 1104 that sits on top of a UDP/IP/Ethernet layer 1102 .
  • Other protocols 1106 may also be implemented at the same level of the protocol stack as AVSCP.
  • the AVSCP layer communicates with a higher layer 1108 comprising ENIC applications via an AVSC request command and an AVSC indicate command.
  • An uppermost layer of the ENIC protocol stack 1100 A represents a local configuration 1110 of the network.
  • the network manager protocol stack 1120 is similar to the ENIC protocol stack 1100 A, 1100 B in that it comprises an AVSCP layer 1124 that sits on top of a UDP/IP/Ethernet layer 1122 . However, a server applications layer 1128 sits on top of the AVSCP layer 1124 and communications between these two layers are mediated by the AVSC request command and the AVSC indicate command. The server applications layer 1128 is in communication with a higher layer corresponding to a network configuration database 1130 .
  • the AVSCP protocol layer 1104 of the ENIC may send AVSCP protocol messages to and receive messages from the corresponding AVSCP protocol layer 1124 of the network manager 4 .
  • the AVSCP request is a primitive command that is sent from the application layer of the ENIC 1108 , or network manager 1128 to the corresponding AVSCP protocol layer 1104 , 1124 .
  • An application initiates an AVSCP request in order to send an AVSCP message to another AVSCP entity.
  • the AVSCP request has the following parameters: IP address of the message destination (typically an ENIC); AVSCP message type (e.g. stop transmission, switch etc.); and a number of information elements required by the message.
  • One or more remote client controller devices may access the server applications layer 1120 of the network manager 4 via a client controller interface (not shown).
  • the client controller interface of the network manager 4 enables a client controller to connect remotely with and exercise a subset of control functions over a subset of ENIC devices.
  • FIG. 15 schematically illustrates the structure of an AVSCP header that is applied to all AVSCP messages.
  • the AVSCP header has a fixed length of 32 bits.
  • the first octet (bits 0 to 7 ) is used as a protocol identifier. It has a value of 0 ⁇ CC. The purpose of a protocol ID is to detect possible collision with other protocols if they happen to use the same port number.
  • the second octet (bits 8 to 15 ) is used to carry a version number for the protocol.
  • the third octet (bits 16 to 23 ) is reserved for future use.
  • the fourth octet (bits 24 to 31 ) indicates the message type.
  • the last 4 octets of the AVSCP header is a session-ID, which is a random number chosen by the command message initiator to tie up acknowledgement message returned by the responder to the original command message.
  • CNMCP CNMCP messages are carried by TCP (See section “Data Format” and FIG. 3B for a description of the data format
  • TCP is a connection-oriented protocol, which means that before any data is transferred between network nodes, the sending and receiving devices must co-operate in the establishment of a bi-directional communication channel. Subsequently, each package of data sent across the local network receives an acknowledgement and the sending device records status information to ensure that each data package is received without errors.
  • CNMCP enables control messages such as a registration request, a switch request or a permissions update from the switching and routing client 6 to the network manager 4 and further enables control messages such as a registration response, a switch response, an update indication (specifying device configurations) and a permission response from the network manager 4 to the switching and routing client 6 .
  • the network manager 4 informs the switching and routing client 6 of data associated with the ENICs which are connected to the network as well as data associated with source devices and destination devices connected to the network by the ENICs.
  • the network manager 4 informs the switching and routing client 6 of the multicast IP addresses on which it can receive the proxy video streams, audio streams and status streams.
  • the network manager 4 can determine whether sufficient bandwidth is available to service a request by the switching and routing client 6 to add a connection between a source device and a destination device and mediates access to network resources accordingly.
  • SNMP Simple Network Management Protocol
  • the switching and routing client 6 can cause the network to connect audio and video streams from source devices to destination devices, both of which are specified by the switching and routing client 6 and to specify control data routing by sending CNMCP or SNMP messages to the network manager 4 .
  • the transport layer is UDP multicast.
  • the audio and video data are carried in Real-Time Protocol (RTP) format (e.g. a so-called BT.656 format—see reference 1 ) within a UDP packet.
  • RTP Real-Time Protocol
  • RTP provides functions to support real-time traffic, that is, traffic that requires time-sensitive reproduction at the destination application.
  • the services provided by RTP include payload type identification (e.g. video traffic), sequence numbering, time-stamping and delivery monitoring.
  • RTP supports data transfer to multiple destinations via multicast distribution if provided by the underlying network.
  • the RTP sequence numbers allow the receiver to reconstruct the original packet sequence.
  • the sequence numbers may also be used to determine the proper location of a packet.
  • RTP does not provide any mechanism to ensure timely delivery, nor does it provide other Quality of Service guarantees.
  • an ENIC When an ENIC receives an AVSCP switch request from the network manager 4 , the ENIC sends an IGMP join message to the Ethernet switch 2 to join the multicast group of the data it needs to receive.
  • Control data may be sent, only as a Unicast transmission, directly from one ENIC to another.
  • control data that is likely to jeopardise virtual circuit-switched connections on the network the control data must be sent via the switching and routing client 6 and/or the network manager 4 to control a device.
  • a controller connected to one ENIC may directly control a device connected to another ENIC bypassing the network manager 4 and the switching and routing client 6 .
  • commands such as play, pause stop, record, jog etc. may be sent from a controller across the network directly to a source/destination group such as a VTR.
  • the control channels are set up using AVSCP.
  • the control data itself is carried in UDP messages in this embodiment.
  • TCP may alternatively be used to carry control data.
  • CNMCP is used to enable the switching and routing client 6 client to receive the status information SS without the intervention of the network manager.
  • a controller is connected to the network at a first ENIC and controlling a group is connected to the network via a second, ENIC the first ENIC needs to know the status of the controlled group.
  • status data SS may be sent from the controlled group to the controller via the network.
  • the switching and routing client 6 is operable to elect to receive SS data to monitor the current status of the data stream.
  • AV proxy streams are communicated across the network using RTP over UDP multicast.
  • the switching and routing client 6 can elect to receive proxy video for monitoring purposes and to make informed switching decisions with regard to the virtual circuit-switched connections.
  • ENICs NI 1 associated with ‘Camera 1 ’ S 1 source group
  • NI 2 associated with ‘Camera 2 ’ S 2 source group
  • NI 8 associated with video switch D 8 destination group
  • AV proxy streams are generated.
  • video formats stream video data across a network using RTP, these known methods involve heavy compression of the video data. Video compression methods that introduce significant periods (i.e. >one field) of delay are unsuitable for the studio production environment in which the network according to the present technique is likely to be deployed. Furthermore, in a production environment it is likely that multiple AV data sources will have to be displayed substantially simultaneously on a screen and this would place undue burden on the data processor to decompress the multiple data streams, perhaps requiring hardware acceleration.
  • the video proxy is generated as an uncompressed sub-sampled data stream rather than a compressed data stream (e.g. QCIF (176 or 180 samples x144 lines); 16 bit RGB; 25 frames per second; sub-sampling with horizontal and vertical filtering; at 15.2 Mbits per second from a 625 lines ⁇ 1440 samples per line source; or (180 samples ⁇ 120 lines) from a 525 lines by 1440 samples source).
  • QCIF 176 or 180 samples x144 lines
  • 16 bit RGB 25 frames per second
  • sub-sampling with horizontal and vertical filtering at 15.2 Mbits per second from a 625 lines ⁇ 1440 samples per line source; or (180 samples ⁇ 120 lines) from a 525 lines by 1440 samples source.
  • the audio and video data format comprises, in order, an Ethernet header, an IP multicast header, a UDP header, an RTP header, a field specifying the type of payload, the payload, and a CRC (cyclic redundancy check) field.
  • the Ethernet header comprises a source Ethernet address and a destination multicast Ethernet address.
  • the IP multicast header comprises the source ENIC IP address and the destination device multicast IP address.
  • IP address classes e.g. Class A has the first 8-bits allocated to the network ID and the remaining 24-bits to the host ID whereas Class B has the first 16 bits allocated to the network ID and the remaining 16-bits to the host ID.
  • Class D IP addresses are used for multicasting.
  • the four left-most bits of a Class D network address always start with the binary pattern 1110 , corresponding to decimal numbers 224 to 239 , and the remaining 28 bits are allocated to a multicast group ID.
  • IGMP is used in conjunction with multicasting and Class D IP addresses.
  • the set of hosts (i.e. source and/or destination devices) listening to a particular IP multicast address is called a host group.
  • a host group may span multiple networks and membership of a host group is dynamic.
  • the Class D IP address is mapped to the Ethernet address such that the low-order 23 bits (of 28 ) of the multicast group ID are copied to the low-order 23 bits of the Ethernet address. Accordingly 5 bits of the multicast group ID are not used to form the Ethernet address.
  • the mapping between the IP multicast address and the Ethernet address is non-unique i.e. 32 different multicast group IDs map to the same Ethernet address.
  • the UDP header comprises source and destination port numbers, which are typically associated with a particular application on a destination device.
  • UDP is redundant in the case of multicast messages since in this case the multicast group address identifies the stream/content.
  • the audio/video streams are transported using RTP protocol.
  • Forward Error Correction (FEC) may be used for certain data streams e.g. full resolution video streams to provide a level of protection against data corruption due to network errors.
  • FEC is provided using a known RTP payload format that provides for FEC.
  • FEC is a parity-based error protection scheme.
  • a known extension to the RTP protocol allows a video scan line number to be specified in the RTP payload header.
  • the RTP header also comprises a field to specify whether 8-bit or 10-bit video is present.
  • known RTP and RTP/FEC protocol formats provide the data packet fields necessary to transport audio and video data over an IP network it may also be desired to transmit additional information such as source status and source timecode information. For example if the source device is a VTR then the timecode as stored on the tape should be transferred across the network.
  • the source status information might indicate, for example, whether the VTR is currently playing, stopped or in jog/shuttle mode. This status information allows a user to operate the VTR from a remote network location.
  • the timecode data and source status information is required only once per field, the information is transported in an RTP packet marked as vertical blanking.
  • the RTP timecode is based on a 27 MHz clock.
  • the payload type field contains data indicating the type of payload. i.e. video or audio data.
  • the payload field contains the video or audio data to be transmitted.
  • the CRC is a cyclic redundancy check known in the art.
  • AVSCP and CNMCP messages are carried by a data format as shown in FIG. 3B.
  • the format comprises in order, an Ethernet header, an IP header (which is not a multicast header), a UDP or TCP header, the payload, and a CRC field.
  • the Ethernet header comprises source and destination Ethernet addresses.
  • the IP header comprises the source ENIC IP address and the destination ENIC IP address.
  • UDP is used for AVSCP and TCP is used for CNMCP.
  • the payload field contains the AVSCP or CNMCP message data.
  • the CRC is a cyclic redundancy check known in the art.
  • the stream status (SS) format is identical to the audio and video data format as shown in FIG. 3A, with the exception of the content of the payload section.
  • the frame comprises an Ethernet header, an IP multicast header, a UDP header, an RTP header, a payload type identifier, a stream status data payload and a CRC field.
  • the unicast control data format is shown in FIG. 3C and comprises an Ethernet header, a standard IP header (not multicast), a UDP header, a payload section assigned to unicast control data and a CRC field.
  • IGMP is a known protocol. Multicasting that extends beyond a single network is complicated by the fact that Internet routers must establish whether any hosts (in this case source devices and destination devices) on a given physical network belong to a given multicast group. IGMP is typically used to establish this information. IGMP lets all nodes of a physical network know the current association of hosts to multicast groups. IGMP messages are transmitted in IP datagrams and have a fixed 8-byte IGMP message size concatenated with a 20 byte IP header. The IGMP message includes a 32-bit Class D IP address.
  • a number of IGMP queries and reports are used by multicast routers (e.g. the Ethernet switch 2 of FIG. 1) to record which network interfaces have at least one host (source/destination device or group) associated with a multicast group.
  • multicast routers e.g. the Ethernet switch 2 of FIG. 1
  • the Ethernet switch 2 receives a multicast message from a source device to forward, it forwards the message only to interfaces that currently have destination devices associated with that multicast group.
  • An ENIC joins a multicast group by sending an IGMP join message to the asynchronous Ethernet switch 2 .
  • An ENIC may send and/or receive data in the audio/video format shown in FIG. 3A, in the AVSCP/CNMCP format shown in FIG. 3B or in the UCD data format shown in FIG. 3C. Note that an ENIC does not send or receive CNMCP data (which only passes between the network manager 4 and the switching and routing client 6 ).
  • an ENIC comprises a network processor 20 , a buffer and packet switch 22 , a packetiser/depacketiser 24 , a control processor CPU 26 , a peripheral component interconnect PCI 28 , a clock 202 , a clock synchronisation circuit 204 and a frame synchronisation circuit 205 .
  • the clock synchronisation circuit 204 is described in co-pending UK patent Application 0204242.2.
  • the frame synchronisation circuit is described in co-pending patent application 0307459.8.
  • the packetiser/depacketiser has three video inputs 218 for receiving respective SDI video streams, three audio inputs 220 for receiving respective SDI audio streams.
  • three input ports could be provided for receiving combined SDI audio/video streams and the audio and video streams could be subsequently separated to form three audio and three video streams with in the ENIC.
  • AES digital audio streams could be supplied as input to the packetiser/depacketiser.
  • the packetiser/depacketiser 24 has likewise three video outputs 222 and three audio outputs 224 .
  • the CPU 26 has three control data inputs 226 and three control data outputs 228 , here denoted “RS422” because they provide control similar to that provided by RS422 in a conventional studio.
  • the three video inputs 218 are connected to respective ones of three substantially real-time proxy video generators 212 which generate the low resolution versions of the video streams as will be described below.
  • the outputs of the proxy generators and the SDI video inputs 218 are supplied as input to a packetiser and multiplexer 214 , which converts the full resolution serial video from the inputs 218 and the proxy video from the proxy generators 212 to packets suitable for transmission across the network. The packets are then supplied to the buffer and packet switch 22 .
  • the packetiser/depacketiser 24 has a depacketiser 216 and demultiplexer for receiving packets representing the SDI video and audio channels from the packet switch 22 . It depacketises and demultiplexes the video and audio into 3 serial video streams and 3 serial audio streams for supply to respective ones of three video outputs 222 and three audio outputs 224 .
  • the packetiser/depacketiser 24 provides routing of the video and audio received from the network in packetised form via the packet switch 22 to outputs 222 and 224 in serial digital format and further provides the routing of the serial digital video and audio data received from source devices via the inputs 218 , 220 to the buffer and switch 22 for transmission in packetised form across the network.
  • the packetiser/depacketiser 24 also provides synchronisation of the different video and audio streams in conjunction with the clock synchronisation circuit 204 and provides frame alignment of the video frames of the different video streams in conjunction with the frame synchronisation circuit 205 .
  • the compression and/or subsampling used to generate the proxy video can be arranged so that the proxy video stream is a subset of the SDI video stream; and (b) the SDI stream is transmitted as only that part of the input stream which is not represented by the proxy stream. This reduces the bitrate of the SDI stream by omitting that part of the data represented by the proxy stream, so reducing network traffic. However, it does require the two streams to be received in order to reconstruct the original video.
  • the buffer and packet switch 22 provides routing of video, audio and control packets received from the network processor 20 in accordance with a series of tags, which are applied to the packets in the network processor 20 .
  • the network processor 20 generates the tags in accordance with header data in the received packets.
  • tags There are two sorts of tag: a “flow” tag, which defines the route of the data through the packet switch 22 , and a “type” tag, which defines the final output to which the packets are supplied by the packetiser/depacketiser 24 (in effect an action to be carried out on the data).
  • the video and audio packets are routed to the depacketiser 216 , whereas the control packets are routed to the CPU 26 .
  • the network processor 20 comprises UDP/IP filters 208 , which detect, using packet header information, sync, audio, video, status and control data packets received from the network. Received clock sync packets are directed by the network processor 20 directly to the clock synchronisation circuit 204 to synchronise the ENIC clock 202 with a master reference clock as described in the co-pending UK patent application 0204242.2. Frame sync packets are directed by the network processor 20 to the clock sync circuit 204 and then to the frame sync circuit 205 via the ENIC clock 202 . The network processor 20 directs the sync packets directly to the clock synchronisation circuit 204 and to the frame synchronisation circuit 205 to reduce time delays which may otherwise reduce the accuracy of the synchronisation. Other packets, for example AVSCP packets, which are not recognised by the filters 208 are directed to the CPU 26 (although in alternative arrangements) filters could be set up for these.
  • AVSCP packets which are not recognised by the filters 208 are directed to the CPU 26 (although in alternative arrangements) filters could be
  • the network processor 20 attaches tags to the audio and video packets in accordance with the header data received with them.
  • the tagged video and audio packets are supplied to the packet switch 22 , which routes them to the depacketiser 216 or to the PCI 28 computer interface.
  • the tagged control data packets are directed by the buffer and packet switch 22 to the CPU 26 .
  • the buffer and packet switch 22 is described in more detail below.
  • an ENIC may be embodied in hardware, software (provided by a storage medium such as a disk or read-only-memory, not shown, and/or a transmission medium such as a network or internet connection), programmable hardware or combinations thereof.
  • An ENIC may receive from the network: audio and video data packets as shown in FIG. 3A; AVSCP data packets as shown in FIG. 3B; stream status data packets (in essentially the same format as shown in FIG. 3A); and unicast control data packets as shown in FIG. 3C.
  • the Ethernet header provides the physical address of the ENIC allowing a packet to be delivered by the network in known manner to the ENIC.
  • the network processor 20 of the ENIC has the UDP/IP filters 208 that extract the IP and UDP headers, decode the address information in the headers and detect the payload data type from the payload type field (see FIG. 3A).
  • the network processor 20 then replaces the packet header with a tag identifier, which specifies a data processing route through the ENIC for the packet payload data to a target data handling node such as a video or audio processor.
  • FIG. 5A schematically illustrates the data format of a tagged packet.
  • the tagged data packet is 32 bits wide and is of indefinite length i.e. the payload has a variable length.
  • the first 32 bits of the tagged packet comprise an 8-bit “flow” data field, an 8-bit “type “data field and a 16-bit “size” field.
  • the next 32 bits are currently unused.
  • the unused field is followed by a payload field.
  • the tagged packet payload comprises the RTP header and the payload type data in addition to the audio or video data payload of FIG. 3A.
  • the tagged packet payload is the message data.
  • the flow data field of the tagged packet data format of FIG. 5A defines the output of the packet switch 22 (FIG. 4) corresponding to the target data-handling node for which the tagged packet payload is destined.
  • the type data field determines what the target processor does with the data and the size data field specifies the payload size.
  • FIG. 5B schematically illustrates an example of a flow assignment allocation.
  • flow 0 corresponds to data that will not be passed to any target processing device e.g. untagged data
  • flows 1 and 4 correspond to video input and output ports 218 , 222 of the packetiser/depacketiser 24 (see FIG. 4)
  • flows 2 and 5 correspond to CPU data flows from and to the network
  • flows 3 and 6 correspond to PCI 28 data flow from and to the network.
  • FIG. 5C schematically illustrates how video data, PCI data, network data and CPU data is mapped to each of the six defined flow paths via multiplexers (MUX) and demultiplexers (DEMUX).
  • MUX multiplexers
  • DEMUX demultiplexers
  • Each of the data flows of FIG. 5B is associated with a FIFO.
  • the tags associated with the packets specify the packet size so the MUX only requires a “not empty” indication for the FIFO to perform a read operation.
  • the MUX modules are programmable (by external means such as a CPU) such that they are sensitive only to particular flows. This enables virtual flow paths to be set up across the buffer and packet switch 22 of FIG. 4. Similarly, to avoid contention, only a single DEMUX module can write into any one data flow. Again, the mapping is programmably controlled by external means.
  • the video section of the packetiser/depacketiser 24 is shown. It comprises a demultiplexer 2401 which responds to the “type” data in the tags attached to the video packets to feed video packets to three channels V 0 , V 1 and V 2 denoted by the type data. Each channel comprises an RTP/FEC decoder 2402 , 2403 , 2404 followed by a respective frame store 2405 , 2406 , 2407 .
  • the RTP decoder 2402 removes the tag from the packet it receives and writes the packet into the frame store at the address defined by the RTP packet header, in particular the line number data thereof, to create a video frame having the video data in the correct order.
  • the description above relates to a path from the network to the frame stores 2405 , 2406 , 2407 which is basically represents a packetised (FIFO-like) route through the buffer and packet switch 22 , with the video data being reassembled into frames at the frame stores.
  • This mode of operation of the buffer and packet switch will be referred to as a “packet mode”.
  • a variant of this would be to operate in a so-called “frame mode”, though this is a generic term and the technique could of course be applied to fields rather than frames. This choice of modes can be enabled simply by the way in which memory storage is associated with the buffer and packet switch 22 .
  • memory directly associated with the buffer and packet switch 22 stores received video packets on a first-in-first-out basis.
  • the address at which a packet is stored is unrelated to the pixel position(s) represented by video data in the packet.
  • These packets are forwarded on in the same order that they are received. This arrangement is well suited to handling compressed video data.
  • incoming video packets are written into memory associated with the buffer and packet switch 22 at addresses which do relate to the pixel position represented by that video data.
  • the video data is then read out, for example in a pixel scanning order, either straight away, or after a predetermined delay such as a 24 line delay.
  • Multicasting of Audio Data it is desired to form a data communication path to transmit AES audio data from source group S 9 across the network to the audio processors D 3 .
  • the AES audio data is to be packetised by ENIC NI 6 , sent across the network and received and depacketised by ENIC NI 10 before being delivered in serial digital format to the audio processors D 3 .
  • the user may instigate the connection between audio source S 9 and the audio processors by interacting with the GUI described with reference to FIGS. 9 to 11 and displayed by the switching and routing client 6 .
  • the switching and routing client 6 sends a CNMCP switch request message to a predetermined port of the network manager 4 to initiate a change to the current configuration of virtual circuit-switched connections.
  • the network manager 4 sends CNMCP messages to the switching and routing client 6 providing information on the source devices and destination devices (and the associated source groups and destination groups) that are available to it. This enables the switching and routing client 6 to derive a view specifying the current configuration and status of the network.
  • Each source device and destination device has an associated ID assigned by the network manager in communications to the switching and routing client 6 and this device ID is used by the switching and routing client 6 in subsequent communications with the network manager.
  • the switching and routing client 6 send a CNMCP message device to the network manager 4 containing the ID of the relevant source device and the ID of the destination.
  • the network manager 4 sends a NACK (negative acknowledgement) CNMCP message to the switching and routing client 6 in response to the connection request.
  • NACK negative acknowledgement
  • the connection request will be processed as follows.
  • the network manager 4 queries its network configuration database to determine which multicast IP address the AES audio data from source group S 9 is currently being transmitted to. Then an AVSCP switch message containing the multicast IP address to which S 9 transmits is created by the network manager 4 and sent to the relevant port (device) of the ENIC NI 10 , which connects the audio processors D 3 to the network. Embedded software on the ENIC NI 10 sends an IGMP join message to the multicast IP address on which the audio data of S 9 is transmitted and then sends an AVSCP ACK message back to the network manager.
  • the ENIC NI 10 This enables the ENIC NI 10 to receive the output of the audio source S 9 on one of its destination devices and the ENIC NI 9 will route the received audio data to the source device (ENIC AES output port) that connects to the audio processors D 3 .
  • the network manager 4 having received the AVSCP ACK message from the ENIC NI 10 acknowledging that the instruction to join the specified multicast IP address has been received, will update the routing information in the network configuration database to reflect the existence of the newly formed connection. Finally, the network manager 4 sends a CNMCP ACK message to the switching and routing client 6 indicating that the requested audio data connection between S 9 and D 3 has been successfully set up.
  • two of the source groups of FIG. 1 are connected to a single destination group.
  • the outputs of ‘Camera 1 ’ S 1 and ‘Camera 2 ’ S 2 are supplied as inputs to the video switch D 8 .
  • the switching and routing client 6 sends CNMCP switch messages to the network manager 4 containing the ID values associated with ‘Camera 1 ’ S 1 , ‘Camera 2 ’ S 2 and the video switch D 8 .
  • the network configuration database of the network manager 4 also stores data in relation to each ENIC device category.
  • the network configuration database stores data indicating whether each source device is linked, the number of video lines to delay transmission of the data stream by and the current transmission status the source device.
  • the network manager 4 also derives information with regard to the destination devices from the database, including the IP address of the ENIC that implements the device and the number of video lines to delay playout by.
  • the network manager 4 can determine the multicast IP address that each of the camera source groups S 1 , S 2 transmits data to.
  • the network manager 4 transmits AVSCP messages to the ENIC NI 8 specifying both the multicast IP address onto which ‘Camera 1 ’ transmits AV data and the multicast IP address onto which ‘Camera 2 ’ transmits AV data.
  • Each of the AVSCP message from the network manager 4 is detected by the network processor 20 (FIG. 4) of the ENIC NI 8 and fed to the CPU 26 of the ENIC NI 8 which issues an IGMP join message to the network.
  • the AV packets output by each of the two cameras are received by the network processor 20 of the ENIC NI 8 .
  • Each of the received video packets specifies, in its header data, a destination IP address and the multicast group for which that AV packet is destined is derived from the IP address.
  • the ENIC NI 8 determines from the multicast group, to which output port (source device) of the ENIC NI 8 , the depacketised AV data should be routed. As explained above the multicast group determines to which subset of destination devices in the network a data packet should be routed.
  • the headers are removed from the AV packets by the network processor 20 and replaced by the tags (as described above with reference to FIG. 4).
  • the packet switch 22 routes the video packets to the demultiplexer 2401 (see FIG. 6A) according to the flow data in the tag.
  • the demultiplexer 2401 depacketises that data and routes it to RTP/FEC decoders 2402 and 2403 (by way of example) where decoding is performed and video frames are reconstructed.
  • the output from the decoders 2402 and 2403 is subsequently supplied to frame stores 2405 and 2406 respectively.
  • the frame sync circuit 205 of the ENIC NI 8 (see FIG. 4) aligns the frames of the two video streams, taking into account the line delay information stored in the network configuration database by the network manager 4 .
  • the video switch D 8 (FIG. 1) receives the two AV SDI streams from the ENIC NI 8 .
  • the video switch D 8 also receives control data from the CPU 26 (FIG. 4) of the ENIC NI 8 .
  • the control data is sent by the switching and routing client 6 (FIG. 1) as Unicast control data, which is received via the network in packetised form by the network processor 20 (FIG. 4) of ENIC NI 8 .
  • the Unicast control data has a header that identifies it as a control packet and accordingly (as described above with reference to FIG. 4), these control packets are routed to the CPU 26 of the ENIC NI 8 .
  • the control data may instruct the video switcher D 8 to switch its output from one of the AV streams to the other i.e. from ‘Camera 1 ’ to ‘Camera 2 ’.
  • FIG. 7 schematically illustrates a simplified view of a network arrangement according to the present technique.
  • the network comprises two cameras, “camera 1 ” and “camera 2 ”, a Digital Multi-Effects (DME) unit, an AB switch and a monitor that may display the output AV stream of one or other of the two cameras, depending on the current configuration of the AB switch.
  • FIG. 7 illustrates the network in terms of the ENICs associated with each of the network devices.
  • the network comprises ENIC_ 1 710 that is connected to a source device of “camera 1 ”, ENIC_ 2 720 that is connected to a source device of “camera 2 ”, ENIC_DME 730 that is connected to the DME unit, ENIC_AB_SWITCH 740 that is connected to the AB switch and ENIC_AIR 750 that is connected to the monitor.
  • the ENIC_ 1 710 receives SDI data output by “camera 1 ”, packetises it, transmits it across the network via the ENIC_DME 730 to the DME for digital multi-effects processing and the SDI output of the DME is supplied back to ENIC_DME 730 for packetisation and transmission across the network to the AB switch via ENIC_AB_SWITCH 740 .
  • the output of “camera 2 ” is packetised by ENIC_ 2 720 and transmitted in packetised form across the network to the AB switch via ENIC_AB_SWITCH 740 .
  • either the DME processed output of “camera 1 ” or the output of “camera 2 ” is supplied to the ENIC_AIR 750 for conversion to SDI format and for display on the monitor.
  • the broken lines between the ENICs in FIG. 7 represent a network connection from an ENIC whereas the unbroken lines represent an SDI connection to an ENIC.
  • SDI data is supplied input to an ENIC port for packetisation and transmission across the network to a destination device whereas packetised data received from the network by an ENIC is depacketised and supplied to an AV device as a serial digital data stream such as an SDI data stream or AES audio data stream.
  • Each camera has a user group called “Producer” and the Producer has set the tally text to be the name of the cameraman, i.e. “FRED” or “JIM” for “camera 1 ” and “camera 2 ” respectively.
  • ENIC_ 1 710 is associated with “camera 1 ”
  • ENIC_ 2 is associated with “camera 2 ”
  • the three other ENICs on the network are ENIC_DME 730 , ENIC_AB SWITCH 740 and ENIC_AIR 750 .
  • ENIC_DME 730 performs digital multi-effects (DME) on the video from “camera 1 ”.
  • This ENIC will have two device entries in the network configuration database stored by the network manager 4 , the device entries being labelled DME In’ and ‘DME Out’.
  • ‘DME In’ is a destination device, which receives across the network, packetised data from “camera 1 ” for supply to the DME unit and has a video link to the source device ‘DME Out’ on the same ENIC, via which packetised DME—processed data from “camera 1 ” is transmitted across the network to the ENIC_AB_SWITCH 740 .
  • ‘DME Out’ also has a tally entry of E 1 (indicating EFFECT 1 ).
  • ENIC_AB_SWITCH 740 performs a seamless switch between the “DME Out” source device and the source device associated with ENIC_ 2 720 that outputs data from “camera 2 ”.
  • This ENIC 740 will have three device entries in the network configuration database, labelled ‘Switch A In’, ‘Switch B In’ and ‘Switch Out’.
  • ‘Switch Out’ is a source device that will either be linked to ‘Switch A In’ or ‘Switch B In’, depending on which video source is selected (i.e. the processed AV stream from “camera 1 ” or the AV stream from “camera 2
  • the “Monitor” device receives video from the AB switch via ENIC_AB_SWITCH 740 and has a tally that displays the METADATA from its source device, which is the ‘Switch Out’ source device of ENIC_AB_SWITCH 740 .
  • the network manager 4 will update the view of any client that is displaying the tally text data of the ENIC_ 1 source device. If any of these destination devices is a linked device (i.e. if it supplies the received data to a further source device), then it navigates to the corresponding linked source device and update all of its destinations, and so on.
  • the destination device ‘DME In’ of ENIC_DME 730 is linked to the source device ‘DME Out’ on the same ENIC (i.e. linked to a different port on the same ENIC).
  • the source device ‘DME Out’ s' tally text (E 1 ) is concatenated to ROB to form ROB_E 1 and all of the destinations currently receiving data from ‘DME Out’ must be notified.
  • ENIC_AB_SWITCH 740 The only destination device of ENIC_AB_SWITCH 740 is ‘Switch A In’. Since the switch is currently set to receive data from channel A (i.e. from camera 1 ), ‘Switch A In’ (but not ‘Switch B In’) is currently a linked destination device, since it supplies the ‘Switch Out’ source device of (the same ENIC) ENIC_AB_SWITCH 740 and hence all destinations of “Switch Out’ are updated. In this example, ‘Switch Out’ only has one destination device and this is a pure destination ‘Monitor’ on ENIC_AIR 750 . Thus, the tally of ‘Monitor’ is updated with ‘ROB_E 1 ’ (which replaces ‘FRED_E 1 ’). Hence the tally text change has been effectively propagated throughout the relevant nodes of the network.
  • the source device on ENIC_ 2 720 from which destination device ‘Switch B In’ on ENIC_AB_SWITCH 740 derives its data is associated with ‘camera 2 ’.
  • Using the network configuration database of the network manager 4 it is possible navigate to ‘Camera 2 ’ and update its status as being *ON AIR*.
  • ‘camera 1 ’ can be designated as *OFF AIR* by navigating back through the devices from ‘Switch A In’ when the switch AB configuration is changed such that the connection to ‘Switch A In’ is active again.
  • the correct tally text which is the tally text associated with ‘Camera 2 ’,i.e. “JIM”, can now be propagated to ‘Monitor’ as already described to replace the currently displayed tally text “FRED_E 1 ” or “ROB_E 1 ” associated with ‘Camera 1 ’.
  • one channel of SDI video is received by a buffer 2408 from an SDI source such as a camera.
  • the buffer 2408 stores the video temporarily whilst it is packetised by an RTP/FEC encoder 2410 and sent to a buffer 2412 for temporary storage.
  • a tag generator 241 adds to the RTP packets a tag comprising flow and type data as shown in FIGS. 5A and 5B.
  • a multiplexer 2416 receives the tagged packets from the tag generator and multiplexes the video packet with other video packets from similar video channels.
  • the tag is defined by data produced by the CPU 26 in response to an AVSCP message received from the network controller 4 .
  • the packet switch directs the video packets to the network processor (net) or to the PCI 28 according to the flow data in the tag. Audio packets are similarly processed and routed.
  • a header generator 210 strips the tag from the packet and, based on the flow and type flags, generates an appropriate part of the network header which is appended to the packet.
  • proxy video is generated from SDI video as follows.
  • a horizontal filter 70 applies a low-pass FIR filter to the SDI input data.
  • the output of the horizontal filter is supplied as input to a horizontal subsampler 71 , which subsamples the SDI video horizontally to reduce the horizontal resolution.
  • a vertical subsampler 72 reduces the vertical resolution of data received from the horizontal subsampler 71 .
  • the resulting proxy video is then encoded by an encoder 74 to form RTP packets.
  • the proxy video is processed in the same way as the SDI video by the packetiser 24 , the packet switch 22 and the network processor 20 .
  • the proxy video is always directed to the switching and routing client 6 , or one of the switching and routing clients 6 and 61 .
  • one proxy video stream is multicast in a first multicast group to which the client 6 and/or 61 joins and the SDI video (from which that proxy video is derived) is multicast in a second multicast group.
  • the multicast group is defined by the class D IP address that identifies the data stream.
  • (a) alternate fields of either the proxy video stream or the higher-resolution SDI video stream could be assigned to different multicast groups; and/or (b) the proxy video could be generated from only one field (even or odd) of the SDI stream.
  • the phase (choice of field) could be varied in response to network traffic, in order to make the loading on the network more steady.
  • the proxy video comprises 180 samples ⁇ 144 lines (PAL) or 180 sample ⁇ 120 lines (NTSC) and 25 or 30 frames per second, with horizontal and vertical filtering.
  • the number of bits per sample may be 24 bits (i.e. 3 colours, each 8 bits) or 16 bits (i.e. 3 colours, each 5 bits).
  • GUI graphical user interfaces
  • the GUI is provided by the switching and routing client 6 , which is a PC having a monitor, keyboard and mouse.
  • the GUI may be provided by the network manager 4 or by both the network manager 4 and the switching and routing client 6 .
  • the GUI is an interface with underlying software that reacts to actions taken (for example mouse-clicks or keyboard entries) by the user using the GUI.
  • the GUI displays information about the configuration of the network provided to it by the network manager 4 . That information is provided using the CNMCP protocol as discussed above.
  • the GUI also displays proxy video provided by the ENICs using the Real-Time Transport protocol (RTP) described above.
  • the proxy video is multicast across the network by the generating source group via the ENICs and to receive it the switching and routing client 6 joins the multicast groups of the proxy video streams.
  • the routing of data is established using IGMP message commands.
  • the GUI may be used to initiate control of a controllable source group such as a VTR or a destination group such as a video processor.
  • the switching and routing client 6 unicasts control data directly to the ENIC associated with the CONTROL SOURCE GROUP in response to an action taken via GUI. Unicast control data is described above.
  • the switching and routing client 6 receives status stream data which is multicast as described above when it joins the multicast group on which the status stream data is transmitted.
  • GUI When the GUI is used to initiate a routing of video from a source device to a destination device, it sends a CNMCP message to the network manager 4 . The network manager then sends an AVSCP message to the ENIC associated with the destination device to cause it to join the destination device to the required multicast group.
  • the switching and routing client 6 is able to send IGMP join messages to the network. However, the switching and routing client 6 may also self-subscribe to a multicast group for communication of status, audio and proxy data streams only.
  • the network manager controls client access to a multicast group corresponding to a video stream.
  • GUI is operated in conventional manner using at least a pointing device such as a mouse and/or a keyboard.
  • a keyboard interface having “hot keys” mapped to particular GUI commands or a touchscreen interface may be used to issue commands.
  • the GUI of FIG. 9 has three main display areas A 1 , A 2 , and A 3 .
  • the area A 1 is a network management area displaying graphical representations of the groups (e.g. Cameras CAM 1 etc and VTRs VTR 1 etc) and their source devices (e.g. output CAM V 1 of CAM 1 ).
  • the graphical representations of the groups are displayed with the tally text (e.g. CAM 1 ) and the source devices with their sub-tally text (e.g. CAM V 1 ).
  • the data for creating the display in the area A 1 is derived from the database held by the network manager and provided to the switching and routing client using CNMCP messages.
  • the area A 2 is a source content review area which has a plurality of proxy video display areas or windows W 1 to W 10 .
  • the windows W 1 to W 10 display proxy video.
  • the proxy video to be displayed in the windows is chosen by dragging a source device from the network management area A 1 and dropping it into a chosen window.
  • the display window also has an identifier that indicates the source group with which the currently displayed proxy video is associated. This drag and drop event causes the underlying software to send an IGMP join message to the network for the switching and routing client 6 to join the multicast group on which the proxy video associated with the selected source device is being transmitted.
  • the windows have respective label areas L 1 to L 10 in which the GUI displays the appropriate tally text and/or sub tally text associated with the source device.
  • the area A 3 is a routing review area comprising buttons B which act as switches.
  • buttons B which act as switches.
  • a user may select (via a mouse-click event, by keyboard entries or by touching the appropriate region of a touch-screen interface) on the GUI area A 3 a source button and one or more destination buttons and in response to such a selection communication paths are set up such that the source indicated by the selected source button is linked across the network to the selected destinations.
  • the highlighted buttons show CAM 1 is linked to MON 1 , VTR 2 , and DSP 2 and audio data associated with CAM 1 is linked to AU OUT 3 .
  • a source CAM 1 is to be connected to MON 1 .
  • a switching and routing client 6 starts up, it connects to the network manager on a known port 4 and the network manager 4 sends information on the source devices, which are available to it. This allows the client to form a view of the network. This view of the network will be reflected to a user in the GUI display.
  • Each device is delivered to the client with an ID, which the client will use to describe the device in subsequent communication with the Network Manager.
  • a destination device may be a monitor for example. If the client wishes to route video from a source group (e.g. a VTR) then it will send to the network manager 4 a CNMCP Switch message that contains the IDs of the destination device and of the source device.
  • a source group e.g. a VTR
  • the Network Manager will send a CNMCP NAK message to the client in response. Otherwise it will process the request as follows.
  • the network manager 4 will examine the network configuration database and determine which multicast IP address the video is being transmitted to. An AVSCP Switch message will be created that contains this IP address and it is sent to the ENIC, which connects to the Monitor. The ENIC embedded software sends an IGMP Join message to this IP address and sends an AVSCP ACK message back to the Network Manager. The ENIC should now be receiving the desired video data and will send it to the SDI output that connects the Monitor. Meanwhile, the network manager 4 , having received the AVSCP ACK message, will update the routing information in the database. The network manager 4 sends a CNMCP ACK message back to the client to indicate success.
  • the GUI of FIG. 9 preferably also includes, as shown, two further display areas M 1 and M 2 for showing the video displayed on play-out monitors MON 1 and MON 2 .
  • MON 2 has a dark border indicating that it shows the video currently being played out on LINE OUT 1 from for example VTR 1 .
  • MON 1 which has a lighter border, shows the video from CAM 1 , which has been preselected for play-out next.
  • the video may be selected for display in the windows MON 1 and MON 2 by dragging and dropping proxy video from windows W 1 to W 10 into MON 1 and MON 2 .
  • the video to be played out may be selected or switched over by clicking on MON 1 or MON 2 .
  • the GUI of FIG. 9 has an audio control display area AVD.
  • the GUI also has virtual user controls C 1 to C 10 associated with the windows W 1 to W 10 and user controls CM associated with the MON 1 and 2 windows. Operation of such a user control causes the underlying software to send unicast control data UCD across the network directly to the source group from which the video in the associated window originates. Alternatively, or in addition, C 1 to C 10 can indicate the current status of the relevant device.
  • the GUI of FIG. 10 differs in minor ways from that of FIG. 9. It has proxy video display areas W 1 to W 8 , a network management area A 1 (shown only schematically) identical to that of FIG. 9, and monitor displays ‘M 1 ’ and ‘M 2 ’ in an area A 5 .
  • the GUI of FIG. 10 lacks the rows of source and destination buttons corresponding to the area A 3 in FIG. 9, but has two buttons M 1 and M 2 which act, similarly to the buttons of FIG. 9, as switches.
  • the buttons M 1 and M 2 select for play-out video associated with an associated one of windows M 1 and M 2 .
  • the currently played out video is displayed in the play-out window PO.
  • the windows ‘M 1 ’ and ‘M’ 2 have associated audio controls A 1 and A 2 for switching on and off an audio monitor to allow the user to monitor the audio associated with the video of windows M 1 and M 2 .
  • the video to be displayed in windows M 1 and M 2 is dragged and dropped into those windows from the proxy video windows W 1 to W 8 .
  • Such a drag and drop event causes the full resolution video (rather than proxy video) to be sent from the sources to full resolution monitors such as MON 1 and MON 2 in FIG. 1 and to a video switcher such as D 8 in FIG. 1 via ENIC NI 8 .
  • the reduced-bandwidth proxy video assists the user in selection of which virtual circuit-switched connections to establish in the network and the data stored by the network manager 4 correlating each proxy video source with the full resolution data stream from which it was derived enables the data communication path to be set up in response to user initiated GUI events.
  • each source group for which a proxy video stream is generated is associated with at least two multicast IP addresses, the first multicast IP address being that on which the full-resolution video data is transmitted and the second multicast IP address being that on which the lower-resolution proxy video data is transmitted.
  • Operating the button M 1 or M 2 causes the underlying software to send unicast control data UCD via the ENIC NI 8 to the video switcher causing the video switcher to switch between the two different data sources.
  • FIG. 11 schematically illustrates a GUI that presents the operator with an overview of the network configuration.
  • the GUI comprises a first source panel 110 that displays active sources and inactive sources belonging to the IP network.
  • Source groups such as cameras CAM 1 , CAM 2 , CAM 3 are represented.
  • the video tape recorder group VTR 1 has separate audio VTR A 1 / 2 VTR A 3 / 4 and video VTR V 1 devices associated with it (i.e. three different input/output terminals), which are also displayed.
  • Both the source type e.g. MIC 1 for a first microphone and the source name MIC A 1 / 2 that specifies the audio channel device are represented in the first source panel 110 .
  • the source type is represented by an icon but the source name is not.
  • An input may be selected by highlighting a desired source on the first source panel 110 , for example camera 1 (CAM 1 ) is currently selected.
  • a network review panel 112 comprises three sub-panels: a controllers sub-panel 114 , a source sub-panel 116 and a destination sub-panel.
  • the connection between a controller, a source and one or more destinations is represented by colour-coded branch connections between entries in the three sub-panels.
  • the current configuration shows that a first controller CONT 1 is controlling the source group CAM 1 , which in turn is providing data to six different destination devices i.e.
  • the source sub-panel 116 provides pull-down menus for each source that provide more detailed information about devices e.g. audio and video data streams associated with that source.
  • the relationship between a source and digital signal processors (DSP) is indicated by colour coding in the left hand margin of the source sub-panel 116 , for example in this case CAM 1 is associated with both DSP 2 and DSP 3 .
  • the names of the sources e.g. CAM 1 , VTR 1 , MIC 1 are derived from the tally text.
  • the 11 is operable to display status information (e.g. on air/off-air) associated with source devices or destination devices of the network. This status information is supplied to the network by the corresponding device as status packets.
  • the network manager 4 collates the status data in the network configuration database and the GUI representation is updated at regular intervals based on the updated information in the database.
  • FIG. 12 schematically illustrates a GUI which provides one way of indicating the connections between sources and destinations across the network.
  • An area 120 depicts groups (e.g. CAM 1 ) and the associated source devices (e.g. V 1 , V 2 ) and area 122 denotes destinations.
  • Each source group has a coloured bar 124 associated with it.
  • Area 121 is a matrix which uses the coloured bars to indicate the connections between sources and destinations.
  • the GUI shown in FIG. 12 provides the user with an overview and an interface for displaying to an operator how the data is being routed across the network.
  • the GUI comprises a routing review overview panel 121 at the top of the screen and a main routing review panel 122 comprising a source sub-panel 123 and a destination sub-panel 124 .
  • the overview routing review panel 121 provides an easily comprehensible overview of the relationships between sources and destinations. This is achieved by colour-coded highlighting. This panel 121 currently indicates that source CAM 1 is connected to destinations MON 1 , MON 2 , MON 3 , VTR 2 and AUOUT 3 . By clicking on a given source area of the routing review overview panel 121 , that source and any destinations associated with it are highlighted.
  • the sources sub-panel 124 provides an expanded view of the source in which both the source group e.g. CAM 1 and the associated device V 1 or V 2 are graphically represented. Similarly, the destinations sub-panel provides an expanded view of the destination groups.
  • CAM 1 device V 1 is connected to devices V 1 and V 2 of MON 1 for example.
  • the destination sub panel 124 also provides a graphical colour coded matrix representation of source-destination connections.
  • the network manager 4 is operable to store user-specific profiles according to which each user is assigned to a particular access-permissions level with regard to the portion of the network configuration that can be viewed and the virtual circuit-switched connections which that user is authorised to establish or delete.
  • the allowed access-permissions level specified by the user-specific profile could be determined by the job of the user (for example, cameraman, editor, director, producer) or simply by a unique ID associated with the individual user.
  • the director may have access enabled to view the current configuration of the entire network but no permission to alter the virtual circuit-switched connections whereas a cameraman could have access both to view and change the configuration or a subset of the network of which the camera that he operates forms a part.
  • FIG. 13 schematically illustrates a user interface provided on the network manager via which a user may manually enter configuration data.
  • the interface comprises an ENIC ID dialog box, a PORT ID dialog box and a TALLY TEXT dialog box.
  • the user enters into dialog boxes data required by the manager to determine the configuration of the network.
  • the ENIC ID entry is a user-defined identifier e.g. ENIC 6
  • the PORT ID entry specifies the ENIC port to which the device has been connected
  • the TALLY TEXT entry specifies the freely assignable label (referred to above as tally text) used as a source/destination identifier.
  • the tally text ID is used in addition to (rather than as an alternative to) the source and destination identifiers ID discussed above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Studio Circuits (AREA)
  • Television Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
US10/813,457 2003-03-31 2004-03-30 Video processing Abandoned US20040255329A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0307431A GB2400254A (en) 2003-03-31 2003-03-31 Video processing
GB0307431.7 2003-03-31

Publications (1)

Publication Number Publication Date
US20040255329A1 true US20040255329A1 (en) 2004-12-16

Family

ID=9955906

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/813,457 Abandoned US20040255329A1 (en) 2003-03-31 2004-03-30 Video processing
US10/550,928 Active 2027-09-05 US7996567B2 (en) 2003-03-31 2004-03-31 Audio processing

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/550,928 Active 2027-09-05 US7996567B2 (en) 2003-03-31 2004-03-31 Audio processing

Country Status (6)

Country Link
US (2) US20040255329A1 (de)
EP (2) EP1478187A3 (de)
JP (2) JP2004312735A (de)
CN (1) CN100578610C (de)
GB (1) GB2400254A (de)
WO (1) WO2004088926A2 (de)

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060005130A1 (en) * 2004-07-01 2006-01-05 Yamaha Corporation Control device for controlling audio signal processing device
WO2006074093A2 (en) * 2005-01-05 2006-07-13 Divx, Inc. Media transfer protocol
US20060168291A1 (en) * 2005-01-05 2006-07-27 Van Zoest Alexander Interactive multichannel data distribution system
WO2006089146A2 (en) * 2005-02-17 2006-08-24 Lantasm Networks, Inc. System for distribution of numerous streams of multimedia content to a multiplicity of video displays
US20060253542A1 (en) * 2000-06-28 2006-11-09 Mccausland Douglas Method and system for providing end user community functionality for publication and delivery of digital media content
US20070089151A1 (en) * 2001-06-27 2007-04-19 Mci, Llc. Method and system for delivery of digital media experience via common instant communication clients
US20070107012A1 (en) * 2005-09-07 2007-05-10 Verizon Business Network Services Inc. Method and apparatus for providing on-demand resource allocation
WO2007059169A2 (en) * 2005-11-15 2007-05-24 Clairmail Inc Media transfer protocol
WO2008058110A2 (en) * 2006-11-06 2008-05-15 Albert Lee System and architecture for supporting mobility and multipath packet delivery in ip network stacks
US20090097496A1 (en) * 2006-05-02 2009-04-16 Kazunori Nakamura Video Signal Switching System
US20090102974A1 (en) * 2007-10-19 2009-04-23 Isamu Ishimura Video transmission system
US20090187938A1 (en) * 2008-01-18 2009-07-23 Microsoft Corporation Service Substitution Techniques
US20110069652A1 (en) * 2009-09-24 2011-03-24 Nokia Corporation Multicast Group Management In Wireless Networks
WO2011056224A1 (en) * 2009-11-04 2011-05-12 Pawan Jaggi Switchable multi-channel data transcoding and transrating system
US20110164689A1 (en) * 2008-07-31 2011-07-07 Philippe De Neve Method and associated device for generating video
US8139581B1 (en) 2007-04-19 2012-03-20 Owl Computing Technologies, Inc. Concurrent data transfer involving two or more transport layer protocols over a single one-way data link
US20120179867A1 (en) * 2010-11-09 2012-07-12 Tridib Chakravarty Tape data management
US8631226B2 (en) * 2005-09-07 2014-01-14 Verizon Patent And Licensing Inc. Method and system for video monitoring
US20140139865A1 (en) * 2012-11-20 2014-05-22 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and non-transitory computer readable medium
US8972862B2 (en) 2001-06-27 2015-03-03 Verizon Patent And Licensing Inc. Method and system for providing remote digital media ingest with centralized editorial control
US8977108B2 (en) 2001-06-27 2015-03-10 Verizon Patent And Licensing Inc. Digital media asset management system and method for supporting multiple users
US8990214B2 (en) 2001-06-27 2015-03-24 Verizon Patent And Licensing Inc. Method and system for providing distributed editing and storage of digital media over a network
JP2015510349A (ja) * 2012-02-10 2015-04-02 ブリティッシュ・ブロードキャスティング・コーポレーションＢｒｉｔｉｓｈ Ｂｒｏａｄｃａｓｔｉｎｇ Ｃｏｒｐｏｒａｔｉｏｎ オーディオ信号、ビデオ信号、および制御信号を変換するための方法および装置
EP2719169A4 (de) * 2011-06-10 2015-04-15 Thinklogical Llc Verfahren und system zur erweiterung von videodaten
US9076311B2 (en) 2005-09-07 2015-07-07 Verizon Patent And Licensing Inc. Method and apparatus for providing remote workflow management
US20160142648A1 (en) * 2014-11-18 2016-05-19 Branch Media Labs, Inc. Seamless setup and control for home entertainment devices and content
US9373119B2 (en) 2007-08-15 2016-06-21 Monitise Americas, Inc. Machine-implemented system and method for providing timed targeted promotional offers to individual payment account users with feedback
US9401080B2 (en) 2005-09-07 2016-07-26 Verizon Patent And Licensing Inc. Method and apparatus for synchronizing video frames
US20180077432A1 (en) * 2015-04-10 2018-03-15 Sony Corporation Video server, video server system, and command processing method
US20180174438A1 (en) * 2011-10-28 2018-06-21 Universal Electronics Inc. System and method for optimized appliance control
US10091019B2 (en) 2011-10-28 2018-10-02 Universal Electronics Inc. System and method for optimized appliance control
US10182193B2 (en) 2014-11-18 2019-01-15 Caavo Inc Automatic identification and mapping of consumer electronic devices to ports on an HDMI switch
US10250926B2 (en) * 2017-03-17 2019-04-02 Disney Enterprises, Inc. Tally management system for cloud-based video production
US10397494B2 (en) 2014-11-18 2019-08-27 Caavo Inc Seamless setup and control for home entertainment devices and content
US10541933B2 (en) * 2016-11-10 2020-01-21 Disney Enterprises, Inc. Systems and methods for aligning frames of a digital video content in IP domain
US10593195B2 (en) 2011-10-28 2020-03-17 Universal Electronics Inc. System and method for optimized appliance control
US10701284B2 (en) 2017-02-10 2020-06-30 Caavo Inc Determining state signatures for consumer electronic devices coupled to an audio/video switch
US10937308B2 (en) 2011-10-28 2021-03-02 Universal Electronics Inc. System and method for optimized appliance control
US11197736B2 (en) * 2015-10-02 2021-12-14 Sony Corporation Medical control system and method that uses packetized data to convey medical video information
US11295606B2 (en) 2011-10-28 2022-04-05 Universal Electronics Inc. System and method for optimized appliance control

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7664292B2 (en) 2003-12-03 2010-02-16 Safehouse International, Inc. Monitoring an output from a camera
AU2004233453B2 (en) 2003-12-03 2011-02-17 Envysion, Inc. Recording a sequence of images
NZ536913A (en) 2003-12-03 2006-09-29 Safehouse Internat Inc Displaying graphical output representing the topographical relationship of detectors and their alert status
US8069420B2 (en) * 2004-12-29 2011-11-29 Karl Storz Endoscopy-America, Inc. System for controlling the communication of medical imaging data
US20060206618A1 (en) * 2005-03-11 2006-09-14 Zimmer Vincent J Method and apparatus for providing remote audio
TW200701022A (en) * 2005-06-24 2007-01-01 Era Digital Media Co Interactive news gathering and media production control system
WO2008063565A2 (en) 2006-11-16 2008-05-29 Stryker Corporation Wireless endoscopic camera
JP5320772B2 (ja) * 2007-11-16 2013-10-23 沖電気工業株式会社 映像信号通信システムおよび方法
US8773469B2 (en) 2008-04-09 2014-07-08 Imagine Communications Corp. Video multiviewer system with serial digital interface and related methods
US9172900B2 (en) 2008-04-09 2015-10-27 Imagine Communications Corp. Video multiviewer system with switcher and distributed scaling and related methods
JP5874178B2 (ja) * 2010-04-09 2016-03-02 ソニー株式会社 カメラシステム、カメラ装置、カメラ制御装置、および中継装置
DE102011078021A1 (de) * 2011-06-22 2012-12-27 Institut für Rundfunktechnik GmbH Vorrichtung und Verfahren zum Schalten von Echtzeitmedienströmen
JP5733445B1 (ja) * 2014-03-25 2015-06-10 Ｎｔｔエレクトロニクス株式会社 パケット自動受信装置
KR101729978B1 (ko) * 2017-02-21 2017-04-25 (주) 케이투이 Uhd 4k 멀티 뷰어장치
CN111091740A (zh) * 2020-01-14 2020-05-01 中仿智能科技（上海）股份有限公司 一种飞行模拟器的音响操作系统

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5055927A (en) * 1988-09-13 1991-10-08 Deutsche Thomson-Brandt Gmbh Dual channel video signal transmission system
US5625410A (en) * 1993-04-21 1997-04-29 Kinywa Washino Video monitoring and conferencing system
US6115507A (en) * 1995-09-29 2000-09-05 S3 Incorporated Method and apparatus for upscaling video images in a graphics controller chip
US6211869B1 (en) * 1997-04-04 2001-04-03 Avid Technology, Inc. Simultaneous storage and network transmission of multimedia data with video host that requests stored data according to response time from a server
US20020048275A1 (en) * 1997-12-16 2002-04-25 Antonio Atwater Method and apparatus for receiving full-motion digital video multi-casts, interactive data and interactive voice via a DSL circuit
US20020049979A1 (en) * 2000-05-18 2002-04-25 Patrick White Multiple camera video system which displays selected images
US20020191116A1 (en) * 2001-04-24 2002-12-19 Damien Kessler System and data format for providing seamless stream switching in a digital video recorder
US20030061368A1 (en) * 1997-03-17 2003-03-27 Navin Chaddha Adaptive right-sizing of multicast multimedia streams
US20060010245A1 (en) * 2004-06-01 2006-01-12 Telestream, Inc. Internet protocol for the delivery of complex digital media content

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI89439C (fi) 1991-10-30 1993-09-27 Salon Televisiotehdas Oy Foerfarande foer att dekoda en audiosignal i vilken annan information aer infoerd med anvaendning av maskningseffekt
JPH06162674A (ja) * 1992-11-18 1994-06-10 Sony Corp 変換装置
DE4241068C2 (de) * 1992-12-05 2003-11-13 Thomson Brandt Gmbh Verfahren zum Übertragen, Speichern oder Decodieren eines digitalen Zusatzsignals in einem digitalen Tonsignal
JPH06291692A (ja) 1993-03-31 1994-10-18 Victor Co Of Japan Ltd Ｆｍラジオ受信機における音場・音質制御装置
EP0889746B1 (de) * 1995-06-08 2003-03-26 Claus Hvass Verfahren zur umsetzung von tonsignalen in licht
FI98676C (fi) 1995-10-05 1997-07-25 Nokia Oy Ab Tietostoryhmän siirto digitaalisessa yleisradiojärjestelmässä
US5751774A (en) 1996-04-04 1998-05-12 Lucent Technologies Inc. Transmission system for digital audio broadcasting
JP4016160B2 (ja) * 1998-07-16 2007-12-05 ソニー株式会社 データ受信・記録方法及びデータ受信装置
US6466832B1 (en) * 1998-08-24 2002-10-15 Altec Lansing R & D Center Israel High quality wireless audio speakers
AU760164B2 (en) * 1998-10-08 2003-05-08 Panasonic Intellectual Property Corporation Of America Data processor and data recorded medium
JP4087537B2 (ja) * 1998-10-08 2008-05-21 松下電器産業株式会社 データ処理装置及びデータ記録媒体
US6414960B1 (en) * 1998-12-29 2002-07-02 International Business Machines Corp. Apparatus and method of in-service audio/video synchronization testing
EP1063595B1 (de) * 1999-06-23 2003-11-12 Tut Systems, Inc. Videosignal/Netzwerk-Interface
US6446037B1 (en) * 1999-08-09 2002-09-03 Dolby Laboratories Licensing Corporation Scalable coding method for high quality audio
JP2001238193A (ja) * 2000-02-18 2001-08-31 Sony Corp 映像供給装置及び映像供給方法
WO2001074078A1 (en) 2000-03-29 2001-10-04 Digeo Broadband, Inc. Audio source control techniques
EP1146672A1 (de) 2000-04-10 2001-10-17 Sony International (Europe) GmbH Verfahren zum Übertragen von Dienstinformation in einem Rundfunkübertragungssystem
US6642966B1 (en) * 2000-11-06 2003-11-04 Tektronix, Inc. Subliminally embedded keys in video for synchronization

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5055927A (en) * 1988-09-13 1991-10-08 Deutsche Thomson-Brandt Gmbh Dual channel video signal transmission system
US5625410A (en) * 1993-04-21 1997-04-29 Kinywa Washino Video monitoring and conferencing system
US6115507A (en) * 1995-09-29 2000-09-05 S3 Incorporated Method and apparatus for upscaling video images in a graphics controller chip
US20030061368A1 (en) * 1997-03-17 2003-03-27 Navin Chaddha Adaptive right-sizing of multicast multimedia streams
US6211869B1 (en) * 1997-04-04 2001-04-03 Avid Technology, Inc. Simultaneous storage and network transmission of multimedia data with video host that requests stored data according to response time from a server
US20020048275A1 (en) * 1997-12-16 2002-04-25 Antonio Atwater Method and apparatus for receiving full-motion digital video multi-casts, interactive data and interactive voice via a DSL circuit
US20020049979A1 (en) * 2000-05-18 2002-04-25 Patrick White Multiple camera video system which displays selected images
US20020191116A1 (en) * 2001-04-24 2002-12-19 Damien Kessler System and data format for providing seamless stream switching in a digital video recorder
US20060010245A1 (en) * 2004-06-01 2006-01-12 Telestream, Inc. Internet protocol for the delivery of complex digital media content

Cited By (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9038108B2 (en) 2000-06-28 2015-05-19 Verizon Patent And Licensing Inc. Method and system for providing end user community functionality for publication and delivery of digital media content
US20060253542A1 (en) * 2000-06-28 2006-11-09 Mccausland Douglas Method and system for providing end user community functionality for publication and delivery of digital media content
US8972862B2 (en) 2001-06-27 2015-03-03 Verizon Patent And Licensing Inc. Method and system for providing remote digital media ingest with centralized editorial control
US8977108B2 (en) 2001-06-27 2015-03-10 Verizon Patent And Licensing Inc. Digital media asset management system and method for supporting multiple users
US8990214B2 (en) 2001-06-27 2015-03-24 Verizon Patent And Licensing Inc. Method and system for providing distributed editing and storage of digital media over a network
US20070089151A1 (en) * 2001-06-27 2007-04-19 Mci, Llc. Method and system for delivery of digital media experience via common instant communication clients
US7765018B2 (en) * 2004-07-01 2010-07-27 Yamaha Corporation Control device for controlling audio signal processing device
US20060005130A1 (en) * 2004-07-01 2006-01-05 Yamaha Corporation Control device for controlling audio signal processing device
US20060195884A1 (en) * 2005-01-05 2006-08-31 Van Zoest Alexander Interactive multichannel data distribution system
US20060174021A1 (en) * 2005-01-05 2006-08-03 Roland Osborne Media transfer protocol
WO2006074093A3 (en) * 2005-01-05 2009-04-16 Divx Inc Media transfer protocol
US20060168291A1 (en) * 2005-01-05 2006-07-27 Van Zoest Alexander Interactive multichannel data distribution system
US7664872B2 (en) 2005-01-05 2010-02-16 Divx, Inc. Media transfer protocol
WO2006074093A2 (en) * 2005-01-05 2006-07-13 Divx, Inc. Media transfer protocol
WO2006089146A3 (en) * 2005-02-17 2007-11-29 Lantasm Networks Inc System for distribution of numerous streams of multimedia content to a multiplicity of video displays
WO2006089146A2 (en) * 2005-02-17 2006-08-24 Lantasm Networks, Inc. System for distribution of numerous streams of multimedia content to a multiplicity of video displays
US20070107012A1 (en) * 2005-09-07 2007-05-10 Verizon Business Network Services Inc. Method and apparatus for providing on-demand resource allocation
US9076311B2 (en) 2005-09-07 2015-07-07 Verizon Patent And Licensing Inc. Method and apparatus for providing remote workflow management
US9401080B2 (en) 2005-09-07 2016-07-26 Verizon Patent And Licensing Inc. Method and apparatus for synchronizing video frames
US8631226B2 (en) * 2005-09-07 2014-01-14 Verizon Patent And Licensing Inc. Method and system for video monitoring
WO2007059169A2 (en) * 2005-11-15 2007-05-24 Clairmail Inc Media transfer protocol
WO2007059169A3 (en) * 2005-11-15 2009-04-30 Clairmail Inc Media transfer protocol
US20090097496A1 (en) * 2006-05-02 2009-04-16 Kazunori Nakamura Video Signal Switching System
WO2008058110A2 (en) * 2006-11-06 2008-05-15 Albert Lee System and architecture for supporting mobility and multipath packet delivery in ip network stacks
WO2008058110A3 (en) * 2006-11-06 2008-09-12 Albert Lee System and architecture for supporting mobility and multipath packet delivery in ip network stacks
US8565237B2 (en) 2007-04-19 2013-10-22 Owl Computing Technologies, Inc. Concurrent data transfer involving two or more transport layer protocols over a single one-way data link
US8139581B1 (en) 2007-04-19 2012-03-20 Owl Computing Technologies, Inc. Concurrent data transfer involving two or more transport layer protocols over a single one-way data link
US9373119B2 (en) 2007-08-15 2016-06-21 Monitise Americas, Inc. Machine-implemented system and method for providing timed targeted promotional offers to individual payment account users with feedback
US7839896B2 (en) * 2007-10-19 2010-11-23 Panasonic Corporation Video transmission system
US20090102974A1 (en) * 2007-10-19 2009-04-23 Isamu Ishimura Video transmission system
US8352982B2 (en) 2008-01-18 2013-01-08 Microsoft Corporation Service substitution techniques
US20090187938A1 (en) * 2008-01-18 2009-07-23 Microsoft Corporation Service Substitution Techniques
US20110164689A1 (en) * 2008-07-31 2011-07-07 Philippe De Neve Method and associated device for generating video
US20110069652A1 (en) * 2009-09-24 2011-03-24 Nokia Corporation Multicast Group Management In Wireless Networks
US8848590B2 (en) * 2009-09-24 2014-09-30 Nokia Corporation Multicast group management in wireless networks
WO2011056224A1 (en) * 2009-11-04 2011-05-12 Pawan Jaggi Switchable multi-channel data transcoding and transrating system
US9773059B2 (en) * 2010-11-09 2017-09-26 Storagedna, Inc. Tape data management
US20120179867A1 (en) * 2010-11-09 2012-07-12 Tridib Chakravarty Tape data management
EP2719169A4 (de) * 2011-06-10 2015-04-15 Thinklogical Llc Verfahren und system zur erweiterung von videodaten
US11170636B2 (en) 2011-10-28 2021-11-09 Universal Electronics Inc. System and method for optimized appliance control
US10091019B2 (en) 2011-10-28 2018-10-02 Universal Electronics Inc. System and method for optimized appliance control
US10922958B2 (en) * 2011-10-28 2021-02-16 Universal Electronics Inc. System and method for optimized appliance control
US10636288B2 (en) 2011-10-28 2020-04-28 Universal Electronics Inc. System and method for optimized appliance control
US11769397B2 (en) 2011-10-28 2023-09-26 Universal Electronics Inc. System and method for optimized appliance control
US20180174438A1 (en) * 2011-10-28 2018-06-21 Universal Electronics Inc. System and method for optimized appliance control
US12073711B2 (en) 2011-10-28 2024-08-27 Universal Electronics Inc. System and method for optimized appliance control
US11322016B2 (en) 2011-10-28 2022-05-03 Universal Electronics Inc. System and method for optimized appliance control
US11315410B2 (en) 2011-10-28 2022-04-26 Universal Electronics Inc. System and method for optimized appliance control
US11308796B2 (en) 2011-10-28 2022-04-19 Universal Electronics Inc. System and method for optimized appliance control
US10325487B2 (en) 2011-10-28 2019-06-18 Universal Electronics Inc. System and method for optimized appliance control
US10325486B2 (en) 2011-10-28 2019-06-18 Universal Electronics Inc. System and method for optimized appliance control
US11651677B2 (en) 2011-10-28 2023-05-16 Universal Electronics Inc. System and method for optimized appliance control
US11295603B2 (en) 2011-10-28 2022-04-05 Universal Electronics Inc. System and method for optimized appliance control
US11295605B2 (en) 2011-10-28 2022-04-05 Universal Electronics Inc. System and method for optimized appliance control
US11295606B2 (en) 2011-10-28 2022-04-05 Universal Electronics Inc. System and method for optimized appliance control
US10593196B2 (en) 2011-10-28 2020-03-17 Universal Electronics Inc. System and method for optimized appliance control
US10593195B2 (en) 2011-10-28 2020-03-17 Universal Electronics Inc. System and method for optimized appliance control
US10614704B2 (en) 2011-10-28 2020-04-07 Universal Electronics Inc. System and method for optimized appliance control
US11887469B2 (en) 2011-10-28 2024-01-30 Universal Electronics Inc. System and method for optimized appliance control
US10339797B2 (en) * 2011-10-28 2019-07-02 Universal Electronics Inc. System and method for optimized appliance control
US11145189B2 (en) 2011-10-28 2021-10-12 Universal Electronics Inc. System and method for optimized appliance control
US11113954B2 (en) 2011-10-28 2021-09-07 Universal Electronics Inc. System and method for optimized appliance control
US10991239B2 (en) 2011-10-28 2021-04-27 Universal Electronics Inc. System and method for optimized appliance control
US10937308B2 (en) 2011-10-28 2021-03-02 Universal Electronics Inc. System and method for optimized appliance control
US10937306B2 (en) 2011-10-28 2021-03-02 Universal Electronics Inc. System and method for optimized appliance control
US10943469B2 (en) 2011-10-28 2021-03-09 Universal Electronics Inc. System and method for optimized appliance control
US10970997B2 (en) 2011-10-28 2021-04-06 Universal Electronics Inc. System and method for optimized appliance control
JP2015510349A (ja) * 2012-02-10 2015-04-02 ブリティッシュ・ブロードキャスティング・コーポレーションＢｒｉｔｉｓｈ Ｂｒｏａｄｃａｓｔｉｎｇ Ｃｏｒｐｏｒａｔｉｏｎ オーディオ信号、ビデオ信号、および制御信号を変換するための方法および装置
US9197488B2 (en) * 2012-11-20 2015-11-24 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and non-transitory computer readable medium
US20140139865A1 (en) * 2012-11-20 2014-05-22 Fuji Xerox Co., Ltd. Information processing apparatus, information processing method, and non-transitory computer readable medium
US10397494B2 (en) 2014-11-18 2019-08-27 Caavo Inc Seamless setup and control for home entertainment devices and content
US10855935B2 (en) 2014-11-18 2020-12-01 Caavo Inc Seamless setup and control for home entertainment devices and content
US10182193B2 (en) 2014-11-18 2019-01-15 Caavo Inc Automatic identification and mapping of consumer electronic devices to ports on an HDMI switch
US10506180B2 (en) 2014-11-18 2019-12-10 Caavo Inc Seamless setup and control for home entertainment devices and content
US10051204B2 (en) * 2014-11-18 2018-08-14 Caavo Inc Seamless setup and control for home entertainment devices and content
US20160142648A1 (en) * 2014-11-18 2016-05-19 Branch Media Labs, Inc. Seamless setup and control for home entertainment devices and content
US10931981B2 (en) * 2015-04-10 2021-02-23 Sony Corporation Video server, video server system, and command processing method
US20180077432A1 (en) * 2015-04-10 2018-03-15 Sony Corporation Video server, video server system, and command processing method
US11197736B2 (en) * 2015-10-02 2021-12-14 Sony Corporation Medical control system and method that uses packetized data to convey medical video information
US12127891B2 (en) 2015-10-02 2024-10-29 Sony Group Corporation Medical control system and method that uses packetized data to convey medical video information
US10541933B2 (en) * 2016-11-10 2020-01-21 Disney Enterprises, Inc. Systems and methods for aligning frames of a digital video content in IP domain
US10701284B2 (en) 2017-02-10 2020-06-30 Caavo Inc Determining state signatures for consumer electronic devices coupled to an audio/video switch
US11438526B2 (en) 2017-02-10 2022-09-06 Caavo Inc Determining state signatures for consumer electronic devices coupled to an audio/video switch
US10250926B2 (en) * 2017-03-17 2019-04-02 Disney Enterprises, Inc. Tally management system for cloud-based video production

Also Published As

Publication number Publication date
JP4525935B2 (ja) 2010-08-18
WO2004088926A3 (en) 2004-11-11
JP2006522520A (ja) 2006-09-28
EP1535275B8 (de) 2019-12-25
CN100578610C (zh) 2010-01-06
EP1478187A3 (de) 2005-07-06
CN1768374A (zh) 2006-05-03
EP1535275A2 (de) 2005-06-01
EP1535275B1 (de) 2019-11-20
JP2004312735A (ja) 2004-11-04
US7996567B2 (en) 2011-08-09
GB2400254A (en) 2004-10-06
GB0307431D0 (en) 2003-05-07
EP1478187A2 (de) 2004-11-17
WO2004088926A2 (en) 2004-10-14
US20060192892A1 (en) 2006-08-31

Similar Documents

Publication Publication Date Title
US7483421B2 (en) Routing data
US9191191B2 (en) Device and methodology for virtual audio/video circuit switching in a packet-based network
US20040255329A1 (en) Video processing
US20060146184A1 (en) Video network
US10645131B2 (en) Seamless switching between multicast video streams
EP1720283B1 (de) Video/audio-netz
US20080285571A1 (en) Media Data Processing Using Distinct Elements for Streaming and Control Processes
US20050220194A1 (en) Packet-based video network

Legal Events

Date Code Title Description
AS Assignment

Owner name: SONY UNITED KINGDOM LIMITED, ENGLAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:COMPTON, MATTHEW;CHEN, JIAN-RONG;WILSON, DANIEL;REEL/FRAME:015658/0746;SIGNING DATES FROM 20040420 TO 20040504

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION