Patent Description:
With ever-increasing availability of high speed data networks and user devices that have computational power to process and display video in real time, videoconferencing is fast becoming a tool for both social networking, e.g., a video chat between two users, and also a business productivity tool, e.g., a video conference between multiple users in multiple locations. Video is often captured using a web camera that is connected to a user computer via a peripheral connection such as a Universal Serial Bus (USB) connection.

<CIT> describes a system and method for zero client communications. A zero client device includes a housing, and in the housing, a transcoding processing unit (transcoder) and a communications processing unit coupled to the transcoder. The transcoder is configured to receive input data from human interface device(s), encode the input data, and provide the encoded input data to the communications processing unit for transmission over a network to a server. The communications processing unit is configured to receive the encoded input data from the transcoder, transmit the encoded input data over the network to the server, receive output data from the server, and send the output data to the transcoder. The transcoder is further configured to receive the output data from the communications processing unit, decode the output data, and send the decoded output data to at least one of the human interface devices.

The present document discloses techniques for allowing a user device to connect to a video camera via an internet protocol (IP) connection, while still allowing its operating system to use natively available video processing capabilities of a non-IP peripheral bus.

The invention relates to a system, as further defined in claim <NUM>, for facilitating exchange of multimedia information between two camera devices and a user device.

These and other aspects, and their implementations and variations are set forth in the drawings, the description and the claims.

Today's computer operating systems natively support video camera using peripheral bus connections. For example, users often use external camera devices, e.g., webcams, for capturing video and/or audio and use them with software applications running on user devices. Many modem operating systems natively support camera functionalities along with device drivers for certain communication peripherals. The "native" support could mean, e.g., that a user need not install proprietary camera software drivers on their devices, and could simply plug a camera into the peripheral connection, wait for the operating system to recognize the camera and begin to use the camera in a matter of a few seconds.

One such example of natively supported camera functionality is the Universal Serial Bus (USB) interface commonly found in modern personal computers, tablets, laptops, and so on. Operating systems, such as various Windows versions by Microsoft, include video camera functionality with a native USB driver, thus providing a "plug-and-play" user experience for a USB-connected camera, without having to load camera-specific device drivers or any other new software.

Wireless implementations of USB connectivity are commercially available, but such products are not universally available, and often require users to install additional software to make the wireless functionality work. Thus, USB often limits connectivity between a user device and a camera device to a USB cable. The need for a wired connection thus limits the distance between the user device and the camera device to typical lengths of USB connectors, or up to about <NUM> meters or so. Furthermore, peripheral bus connection protocols such as USB are often point-to-point connections, meaning that only a single user device may be able to connect to and control a USB camera. A similar problem exits with other wired video transmission standards such as an High Definition Multimedia Interface (HDMI) connector or a Digital Visual Interface (DVI) cable connector.

Such limitations of a peripheral camera device limit the usefulness in many practical applications. For example, to access a USB camera in a conference room, multiple user may have to have their own, possibly long, USB cables plugged into an N:<NUM> USB multiplexer that then provides a one-at-a-time access to users. Furthermore, USB user devices, or hosts, can connect to multiple video sources using USB, but the USB standard does not allow an external controller to tell the USB Host which video source to use at any given time. One solution may be that conference rooms are pre-wired with USB or HDMI or DVI or some other suitable cables such that multiple locations are available throughout the room to allow users to plug in their devices to cameras in the room. However, routing prefabricated cables with attached connectors through walls and conduit is difficult or impossible and often may cause destructive degradation in the quality of connection. Such installations may also need repeaters to stretch out over long lengths of connections, which is an expensive solution. To add to this, not all commercially available USB cable extenders support all USB webcams, making the process of selecting a correct cable difficult.

<CIT> discloses techniques for connecting a mobile device to an external display. In particular, a dongle that carriers video data over USB (encoded using UVC) protocol is disclosed to connect low resolution display on the mobile device side with a high resolution external display. The dongle performs resolution reduction from high resolution to low resolution.

<CIT> discloses operation of a wireless webcam that transmits video data in USB UVC format over a wireless Wi-Fi interface. The encoding of video is adapted to maintain isochronous nature of UVC video over the wireless interface.

<CIT> discloses techniques for connecting a device to a host via multiple bus interfaces, such as USB UVC and wireless, such that the bus interface can be seamlessly switched during operation. The relationship between multiple busses of a single external device is tracked by maintaining a single Physical Device Object (PDO) for each device.

<CIT> discloses an audio/video capture device that uses USB UVC protocol for transmitting audio video data to a host. In particular, the UVC protocol is modified to support multiple isochronous flows on the same USB connection. Video conferencing is specifically mentioned as an example application of the technology.

The prior art, however, fails to provide satisfactory solutions for some of the operational problems described herein.

The techniques described in the present document can be used to overcome these operational limitations, and others. In some embodiments, the disclosed technology can be used for conversion of IP network video streams to the USB Video Class protocol (USB UVC) and vice versa. In another advantageous aspect, the disclosed technology may be implemented in a bridging device that is external to the user device, or may be integrated to operate within the hardware platform of the user device, e.g., by an all-software or a combined hardware-software embodiment. These, and other, aspects are described in greater detail throughout this document.

<FIG> is a block diagram showing an example system <NUM> in which video may be communicated between various video sources <NUM> and end node devices <NUM> that consume the video, e.g., by displaying the video on a display to an end user. Video sources <NUM> may include devices that have a camera functionality built into them, such as a video camera <NUM> that may be directly able to communicate via an IP link, a phone with a built-in camera <NUM>, a desktop computer <NUM> and a tablet or a laptop computer <NUM>. Video sources may also include non-camera sources that still can produce video signals, e.g., a media source <NUM> with a video to IP convertor. The media source <NUM> maybe, e.g., a network reception device such as a set-top box, or a scanner or a film-to-digital video convertor and so on.

The video sources <NUM> may communicate with the end node devices <NUM> via an IP network that includes IP network equipment such as an Ethernet switch <NUM>, a wireless IP transmitter such as a base station of a cellular system or an access point of a Wi-Fi network and and/or other IP functions that are well known to a person of skill in the art. In general, the IP network may comprise multiple wired and wireless networks connected to each other.

By way of example, and not exhaustively, end-node devices may be a personal computer <NUM>, a laptop computer <NUM>, a tablet <NUM>, and/or a phone with an image display <NUM>. An end-node device <NUM> may be able to send and receive data, including video data, via an IP interface such as a wired or a wireline IP interface.

The computational platform on which an end node device <NUM> operates may include an operating system. Many operating systems, e.g., various Windows versions by Microsoft, provide native support for being able to receive and transmit video data and control data related to the video data.

<FIG> is a flowchart for an example method <NUM> of facilitating exchange of multimedia information between a camera device, e.g., a video source <NUM>, and a user device, e.g., the end-node devices <NUM>. The method <NUM> may be implemented by a bridging device, e.g., the bridging device <NUM>.

The method <NUM> includes, at <NUM>, receiving multimedia data via an IP interface. In various embodiments, the IP interface may be wired or wireless, e.g., using cat5 Ethernet cable, as described in this document.

The method <NUM> includes, at <NUM>, transcoding the multimedia data from an IP format to a peripheral bus format. For example, in some embodiments, the IP format may include compressed digital video in H. <NUM> compression format, which is then transmitted using MPEG-<NUM> transport packets over IP. In some embodiments, the IP format may include an uncompressed video format, e.g., IETF format specified in RFC <NUM>, or uncompressed video format specified by the Video Services Forum. In some embodiments, the peripheral bus format may include the UVC format for carriage of video over USB, which supports the carriage of both compressed and uncompressed video. Other examples of IP formats may include RTP using MPEG-<NUM> compression, H. <NUM> (High efficiency video coding HEVC), VP <NUM>/<NUM> video compression, MPEG-DASH or HLS streaming format, or other suitable format. The peripheral bus format may include other peripheral bus formats, such as DisplayPort, HDMI, etc..

The method <NUM> includes, at <NUM>, outputting the reformatted multimedia data on a peripheral bus. One such example of a suitable peripheral bus includes USB, which is natively supported by the operating system of the user device receiving the video data. Native support may be provided, e.g., by bundling software used for operation of the peripheral bus with the installation of the operating system. The software may include, e.g., a driver software that detects plugging/unplugging of external devices to the peripheral bus and receiving and transmitting data over the peripheral bus.

The method <NUM> includes, at <NUM>, translating, for a first control message received on the IP interface, the first control message to the peripheral bus format. The translation may be performed using a look up table (LUT) mechanism. The first control message may be, e.g., an ONVIF control message.

The method <NUM> includes, at <NUM>, translating, for a second control message received on a peripheral bus interface, the second control message into an IP interface format. The translation may be performed using the LUT mechanism. In some embodiments, the second control message may include a USB UVC control message and the IP interface format may include the ONVIF protocol.

The method <NUM> includes, at <NUM>, transmitting the translated second control message via the IP interface. For example, the translated second control message may comply with the Open Network Video Interface Forum (ONVIF) format.

In some embodiments, the transcoding operation may comprise operations as described in the example shown in <FIG> is a block diagram showing an example of a video transcoding operation. Box <NUM> represents a decompression operation in which video received on the IP interface may be decompressed. The decompression <NUM> may be performed using code executed on a processor, in the hardware, or using a combination of hardware acceleration and software execution of the decompression operation. During this operation, transcoding info <NUM> may be extracted. This information may include information, e.g., motion vector data, useful for efficient re-encoding by the video recompression operation <NUM>. Other information extracted for transcoding may include command and control information, and information that is often included in the user data fields of formats such as H. <NUM>, which is useful for an application presenting the information to a user. Such information may include caption data, color space definition, and so on. The information is provided to the format encapsulation stage <NUM> in which the output of the video recompression operation <NUM> is formatted to comply with encoded video format of the peripheral bus on which the transcoded video is sent to the user device <NUM>.

The recompression operation <NUM> may produce, e.g., motion Joint Pictures Experts Group (MJPEG) compatible video output from received H. <NUM> video. In some embodiments, when uncompressed video is received via the IP interface, the uncompressed video may be transcoded into an compressed video format such as MJPEG. In such embodiments, the decompression operation <NUM> may be omitted or alternatively may simply involve packet header removal of received IP packets to extract the video data payload. In some embodiments, when uncompressed video is received via the IP interface, the uncompressed video may be left uncompressed when transferring out over the peripheral bus. In such embodiments, the operations described in <FIG> may simply be omitted; instead, video payload from IP packets may be extracted and re-encapsulated into the USB UVC format.

On the IP network side, any well-known video compression and transportation format may be used. The video encoding format may be H. <NUM>, HVEC/H. <NUM>, MJPEG, etc. Transportation may be performed using MPEG transport encapsulated within IP packets, RTSP, RTP or. mp4 file format using unicast, multicast or broadcast transmission.

In some embodiments, the conversion of IP video to UVC video can be done in the bridging device or as a software solution operating within applications or drivers within the operating systems of the end nodes or user devices.

In one advantageous aspect, because the IP network allows for communication to/from multiple cameras, and because the bridge device is able to monitor and translate control data, end-nodes <NUM> can simultaneously see and use multiple video sources, e.g., USB UVC cameras. Similarly, multimedia data from a given camera can be transmitted to multiple end-nodes <NUM> at the same time. This may be achieved such that the bridging device <NUM> may receive a single video stream from the source, and may produce multiple outputs on multiple USB UVC connections for multiple end-nodes.

In one advantageous aspect, embodiments can overcome limitation associated with certain peripheral bus standards that allow for a peripheral device to connect only with a single user device (host) at a time. Using the disclosed techniques, USB devices can be connected to multiple end-nodes simultaneously.

In another advantageous aspect, video distribution can be achieved using low-cost and ubiquitously available Ethernet networking technology for carriage of IP traffic, thereby making it un-necessary to use expensive HDMI or DVI outputs and corresponding distribution amplifiers to distribute video to multiple locations. Ethernet distribution allows as many Hosts as Ethernet can support (thousands) to simultaneously connect to the same video source. Cat5 or Cat6 cable could be used for Ethernet wiring. Such cables can be built on-site after routing them through walls and conduit, thus making the installation process inexpensive. Individual Ethernet Cat5 and Cat6 cables can operate for distances of <NUM> without extenders or extra switches.

Furthermore, allowing multiple users to simultaneously access and control the video stream and to also support multiple access locations opens up the possibility of additional application-layer features that are not offered by present-day videoconferencing applications.

In some embodiments, the bridging device <NUM> may present itself as a single video source to a USB Host and it can switch its input to use any source on the Ethernet network at the request of any external controlling device.

Historically, IP camera and IP streaming vendors used proprietary control protocols, which makes it difficult for any given user device to operate with multiple cameras, either simultaneously or at different times, without performing cumbersome software installations.

The ONVIF control protocol, defined by the Open Network Video Interface Forum, provides a video control and streaming protocol that allows cameras and other video sources to operate in a uniform manner, allowing a controller supporting ONVIF to work with many different video device manufacturers. Advantageously, the bridging device <NUM> could convert control commands in the peripheral bus format to the common ONVIF commands and ONVIF IP video streams to USB UVC video streams.

For example, the ONVIF has defined a protocol called PTZ (pan tilt zoom) Service Specification. Using this protocol, a camera can be controlled to perform various operations such as zooming in or out, tilting, panning at a specified velocity, queried for its capabilities, and so on. The bridging device <NUM> may implement a look-up-table (LUT) for control command translations as described in operations <NUM> and <NUM>. The LUT may have multiple columns corresponding to multiple peripheral bus protocols, and a column corresponding to the ONVIF protocol. Each row may provide a translation of a given ONVIF command and a corresponding peripheral bus command. Using the command translation LUT, the bridging device <NUM> may perform command translation such that a user device may use its own peripheral bus specific protocol for controlling the camera, while camera is always being controlled by a uniform, single control protocol.

In some embodiments, the method <NUM> may also include handling of audio data. The multimedia data may be video only, audio and video, or audio only depending on how users have set up their conference sessions. In some embodiments, the audio may be received using a microphone that is co-located with the camera (e.g., near the camera lens). Alternatively, audio may be received and digitized using a microphone that is nearby a user, e.g., a built-in audio capture function of the user device. Because audio processing often experiences delays that are significantly shorter than the corresponding video processing delays (e.g., <NUM> to <NUM> milliseconds instead of <NUM> to <NUM> seconds for video), the bridging device <NUM> may include a buffer for storing audio temporarily for lip synchronization or alignment with the corresponding video. In some embodiments, a user interface control may be provided on the bridging device, or on the application running on a user device that is using the multimedia data, to enable user control of lip synchronization delay adjustment.

<FIG> illustrates an example embodiment of a bridging device <NUM>. The bridging device may include an Ethernet interface <NUM> via which it is able to communicate with the Internet, and in particular IP cameras <NUM>, through a possible Ethernet switch <NUM>. The IP camera <NUM> may implement a camera control API, e.g., ONVIF API for remotely controlling the camera. The bridge device <NUM> may receive video from the IP camera <NUM> in H. <NUM> or another video format via the Ethernet module <NUM>. The Ethernet module <NUM> may provide control portion of the received IP traffic to a Control and Translation module <NUM>, which may, among other things, perform translation between ONVIF commands and UVC commands.

The Ethernet module <NUM> may provide the multimedia portion, which may include video and/or audio data, to a media handling module <NUM>, such as a Gstreamer module that implements RTSP functionality to receive and/or transmit multimedia data. The media handling module <NUM> may extract the received video and provide the extracted video to a transcoding module <NUM>. The reformatted multimedia data may be provided to a capture module <NUM>. The capture module <NUM> may be situated within the bridge device <NUM> such that, at the output of the capture module, the reformatted multimedia data may appear as if it has been captured by a camera plugged into a peripheral of the host device.

The transcoding module <NUM> may reformat the multimedia data to conform to the peripheral bus standard at its output. The transcoding module <NUM> may also perform any other control functions such as bitrate change, resolution change, color space rotation, gamma correction, etc., should under the control of the Control and Translation module <NUM>.

A driver module <NUM> may be used to communicate with the capture module <NUM> and the Control and Translation module <NUM> such that the control data and the multimedia data is passed via the driver module <NUM>, which makes it appear to a host interface module <NUM> as if the IP camera <NUM> is locally plugged into the bus. For example, the host interface module <NUM> may correspond to a USB device and the driver module <NUM> may comprise the USB gadget framework. The host interface module <NUM> may be communicatively connected with a user device via a USB connector and may be using a peripheral bus format such as the UVC <NUM> or UVC <NUM> format.

It will be appreciated that the embodiment depicted in <FIG> can be operated such that, from the perspective of the applications running on the user device, it may appear that a camera is plugged into the peripheral socket, e.g., USB connector of the user device. It will further be appreciated that most operating systems include support for certain types of peripheral devices. For example, in the embodiment depicted in <FIG>, an IP camera that is remotely present in the IP network is able to be communicatively connected with a user device simply by the user device communicating with a bridge device via USB peripheral bus.

In some example embodiments, an apparatus for facilitating exchange of multimedia information between a camera device and a user device includes an IP interface communicatively coupling the apparatus to the camera device. The apparatus may include a module that receives multimedia data via the IP interface in an internet video format and extracts digital video, either compressed or uncompressed, e.g., by parsing using a software program executed on a processor. The apparatus also includes a module that reformats the extracted digital video into a peripheral bus format, e.g., using a LUT mechanism. The apparatus includes a module that provides video in the peripheral bus format to the user device, e.g., using a software driver executed on the user device. The apparatus includes a module that, for a first command received from the user device in the peripheral bus format, translates the first command into an internet format, and for a second command received from the IP interface in the internet format, translates the second command into the peripheral bus format. The apparatus also includes a module that operates to provide connectivity between the user device and the camera device. The translation may be performed using the LUT mechanism.

In some embodiments, a system for video communication includes a camera apparatus (e.g., <NUM>) coupled to an internet protocol (IP) network, a bridging apparatus (e.g., <NUM>) having a first connection coupled to the IP network and a second connection with a peripheral bus, and a user device (e.g., <NUM>) comprising a memory and a processor, wherein the processor executes an operating system that natively supports video communication over the peripheral bus. The bridging apparatus (e.g., <NUM>) transcodes video between the IP network and the peripheral bus. The camera apparatus is controllable using the ONVIF PTZ protocol.

The disclosed and other embodiments and the functional operations and modules described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them.

Claim 1:
A system, comprising:
first and second camera apparatuses (<NUM>) coupled to an internet protocol, IP, network;
a bridging apparatus (<NUM>) having a first connection coupled to the IP network and a second connection with a peripheral bus; and
a user device (<NUM>) comprising a memory and a processor, wherein the processor is configured to execute an operating system that natively supports video communication over the peripheral bus; and
wherein the bridging apparatus (<NUM>) is configured to transcode video data between the IP network and the peripheral bus, wherein the user device (<NUM>) is configured to use its own peripheral bus protocol to access and control the first and second camera apparatuses (<NUM>), and wherein the bridging apparatus (<NUM>) is further configured to transcode control signals from the user device to a uniform, single control protocol for the first and second camera apparatuses (<NUM>) to allow the user device (<NUM>) to simultaneously access and control video streams provided by the first and second camera apparatuses (<NUM>).