Editing Professional video over IP

{{Short description|None}}
{{Unreferenced|date=September 2023}}

'''Professional video over IP''' systems use some existing standard [[video codec]] to reduce the program material to a [[bitstream]] (e.g., an [[MPEG transport stream]]), and then use an [[Internet Protocol]] (IP) network to carry that bitstream [[encapsulation (networking)|encapsulated]] in a stream of IP packets. This is typically accomplished using some variant of the [[Real-time Transport Protocol|RTP protocol]].

Carrying professional [[video]] over [[IP network]]s has special challenges compared to most non-time-critical IP traffic. Many of these problems are similar to those encountered in [[voice over IP]], but to more stringent engineering requirements. In particular, there are very strict [[quality of service]] requirements that must be fulfilled for use in professional broadcast environments.

== Packet loss ==
Since even well-engineered IP networks tend to have a small residual [[packet loss]] rate caused by low-probability statistical congestion events and amplification of [[bit error]]s in the underlying hardware, most professional solutions use some kind of [[forward error correction]] to ensure that the encoded video stream can be reconstructed even if a few packets are lost. This is usually applied at the packet level, since the encapsulated video bitstream is typically only designed to tolerate low levels of bit or burst errors, rather than the loss of whole packets.  Resending packets is not an option because of the sequential nature of the underlying video signal.  For live video, a re-sent packet would arrive well after the arrival of the next frame of video.

== Network delay variation ==
Network delay variation can be kept to a minimum by using a high-speed network backbone, and ensuring that video traffic does not encounter excessive queue delays. This is typically done by either ensuring that the network is not too close to its full capacity, or that video traffic is prioritized using [[Teletraffic engineering|traffic engineering]] techniques (see below).

The remaining delay variation can be removed by buffering, at the expense of added time delay. If forward error correction is used, a small proportion of packets arriving after the deadline can be tolerated as they can be discarded on receipt and treated in the same way as lost packets.  Added time delay over 250ms is particularly problematical with [[PTZ camera]]s as it makes operator control difficult.

== Timing reconstruction ==
The other problem presented by latency variation is that it makes [[synchronization]] more complex by making the recovery of the underlying timing of the video signal far more difficult. This is typically solved by [[genlock]]ing both ends of the system to external [[station sync]] signals, typically generated from sources such as [[GPS]] or [[atomic clock]]s, thus only requiring the extraction of coarse timing information at the receiving end in order to achieve high-quality video synchronization. The extraction of coarse timing data is typically done using a [[phase locked loop]] with a long time constant.

== Adequate bandwidth ==
Even with packet loss mitigation, video over IP will only work if the network is capable of carrying the content with some reasonable maximum packet loss rate. In practice, this means that video over IP will not work on overloaded networks. Since IP does not of itself offer any traffic guarantees, this must be applied at the network engineering level. One approach to this is the "quality of service" approach which simply allocates sufficient bandwidth to video-carrying traffic that it will not congest under any possible load pattern. Other approaches include dynamic reduction in frame rate or resolution, [[Network Admission Control]], [[Resource Reservation Protocol|bandwidth reservation]], [[traffic shaping]], and [[Quality of service|traffic prioritization]] techniques, which require more complex network engineering, but will work when the simple approach of building a non-blocking network is not possible. See [[Resource reservation protocol|RSVP]] for one approach to IP network traffic engineering.

The [[Pro-MPEG Wide Area Network group]] has done much work on creating a draft standard for interoperable professional video over IP.

== Use in the security industry ==
Within the security products industry, IP-based Closed Circuit Television (CCTV) has made gains over the analog market.  Key components of IP-based CCTV remain consistent with analog technologies: [[image capture]], with a combination of IP-based cameras or analog cameras using IP-based encoders; image transmission; Storage and Retrieval, which uses technologies such as [[RAID]] arrays and [[iSCSI]] for recorded and indexed video; and video management, which affords web browser-enabled management and control of IP-based CCTV systems.

One key advantage of IP-based CCTV is the ability to use network infrastructure, providing adequate bandwidth and availability of switching and routing, rather than coaxial cabling. However, running bandwidth-intensive surveillance video over corporate data networks may worsen network performance.

A class of companies produce [[Video management system|video management software]] to help manage capture and storage of video content. Digital video also makes possible Video Content Analysis, which allows automatic detection and identification of various kinds of objects or motion.

Another emerging{{When?|date=November 2024}} model is off-site storage of surveillance video. Online surveillance providers use [[cloud computing]] technologies to consolidate multi-site surveillance video over the web.

Manufacturers of CCTV equipment have been integrating IP network technology into their product ranges.

== See also ==
* [[Dynamic synchronous transfer mode]]
* [[SMPTE 2022]]
* [[SMPTE 2110]]

{{DEFAULTSORT:Professional Video Over Ip}}
[[Category:Internet protocols]]
[[Category:Broadcasting]]